Community members do their best to follow Tiki Social Contract and guidelines below.

Others expect you to read, understand, and do your best to follow Tiki's Social Contract. In addition, you are requested to follow these basic guidelines within Tiki Community:

• 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.

• 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.

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.

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.

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.

For more information, see the WhoWhat page.

And welcome to the Tiki Community! 😊