History: 3Rules

the 3 rules

Used by mose in the Recruitment Ceremony. A one line set of maxims on how members of the Tiki Community collaborate.

1. Preserve Environment
   Tikiwiki is a software and also a community. The mix of both, contextualized in the Internet and the real life, is called The Environment. Any change in TikiWiki should take in account the more possible from this environment, to give changes of a balanced evolution respectful for humans and computers.
2. Commit early, Commit often
   CVS is the central point in tikiwiki collaborative development. CVS commits have to be frequent even at first stages to offer an opportunity of interaction between contributors. It provides more chances for transversal communication in benefit of the respect of environment.
3. Make it Optional
   TikiWiki is used in various contexts and its modularity is very appreciated. Preserve it by making most of your changes optional, accessible for tuning to the admin at least, via admin panels.

verbose mode

1. Think about other users
   Tiki is both a piece of software and a community of people. This combination means that we invite you, as developer, to think not only about the code, but also to consider the wide variety of people who use Tiki everyday. Consider any changes in this context. We believe that a careful, thoughtful, and highly collaborative approach is a way to maintain respect for both the code and the people that depend on it. Rather than seeing Tiki as a game, we invite you to see Tiki as a manner of producing change. Recognize that your code could affect the lives of people.
2. Share Early, Share Often
   If you have an idea for an improvement, new feature, performance enhancement, or anything else of that nature, be quick to share it. Be proud of your idea and get it out there on the e-mail list. Be open to problems and issues that others may point out. As you work out your ideas and implementations, share your progress and approch often. Ask for advice, there are many smart people (and a few, really, really dumb ones) in the Tiki Community who love to help. Documenting what you are doing on TikiWiki.org keeps others up to date with changes. Create a showcase site to show off your work in progress. Once it basically works and the community likes it, commit your code to CVS. Yes, it may be imperfect, nevertheless by following the maxim of Release Early, Rlease Often others are more able to help with development and debugging.
   One BIG caution: Don't commit sweeping or wide reaching changes to CVS until there is community consensus, or at least approval from one or more of the project administrators. They are those who have that designation in the list of developers. Checking with others is the right way to develop code and helps us to avoid really screwing up other people's lives and projects. When in doubt, communicate! This could be on IRC, by email, or some other agreed upon method.
   A caution about the BIG caution : I feel it is impossible to reach consensus without effective code. Asking before is a matter of gathering information, not getting prior acceptance of something. Good decisions can provide bad implementations and in such cases there is a difficulty in correcting what was mutually agreed beforehand (without really knowing). Of course, that only applies to experienced coders who are supposed to know what they are doing. People who learn to code need to be particularly cautious. You decide whether this is for authoritative reasons or as a means of obtaining wisdom (if available). That's my 2 cents. — mose
3. Make It Optional
   Tiki is used in the real world by MANY people for MANY different uses. Try to avoid forcing new features onto everyone, allow it to be tuned and configured by the site admin, and, if at all possible, allow it to be turned off. At the very least, make sure that the default config doesn't change Tiki's behavior.