1.1.1. Use and improve the docs

• Search the documentation first and read the FAQ before asking questions.
• When asking questions, update the documentation when you get the answers.
  When answering questions, please reference the docs/FAQs/etc. This will increase the visibility (and maybe overall usage) a valuable resource.
• Those who have concerns about the documentation are encouraged to update its pages to improve it.

1.1.2. Report bugs or request feature enhancements

• A bug should be reported in the bug tracker
  • When in doubt, ask in the forums or IRC chat first
• If you can't code yourself your own enhancement ideas, don't expect that your request will be implemented in short, if ever. You might be interested in hiring a coder to do that for you, if you think that things are getting done much more slowly than you would need/like.

1.2.1. Respect the Environment

Tiki is both software and a community. Any change in Tiki should take into account its effect on the entire Tiki Community and should allow for a balanced evolution. Also, please make sure any code you commit respects the LGPL license and that you are allowed to share it.

1.2.2. Commit Early, Commit Often

SVN is the central point in the Tiki collaborative development process. Commits should be frequent, even in the early stages, to offer an opportunity for interaction between contributors. Early commits provide more chances for feedback and for the community to start to assimilate the ideas you propose. Use an experimental branch if it's disruptive/risky.

1.2.3. Make it Optional

Tiki is used in many smaller contexts and its modularity is key to adoption in those areas. Help preserve this flexibility by making your changes optional whenever possible, and able to be tuned by the site administrator at least, via admin panels.