3 Rules

The 3 rules (guidelines)

1. Preserve Environment
   openOSEK is the software and also a community. The mix of both, contextualized in the Internet and the real life, is called The Environment. Any change in openOSEK should take into account the most possible from this environment, to give changes of a balanced evolution respectful for humans and computers.
2. Commit early, Commit often
   SVN is the central point in openOSEK collaborative development. Commits should 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
   openOSEK is used on various platforms and its modularity is very appreciated. Please try to preserve it.

verbose mode

1. Think about other users
   openOSEK 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 will use openOSEK. 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 openOSEK as a game, we invite you to see openOSEK 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 approach often. Ask for advice, there are many smart people in the openOSEK Community who love to help. Documenting what you are doing on the mailing list keeps others up to date with changes. Once it basically works and the community likes it, commit your code to the repository. Yes, it may be imperfect, nevertheless by following the maxim of Release Early, Release Often others are more able to help with development and debugging.
   One BIG caution: Don't commit sweeping or wide reaching changes to the repository 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 are learning to code, as part of the project, need to be particularly cautious. You decide whether this is for authoritative reasons or as a means of obtaining wisdom (if available).''
3. Make It Optional
   openOSEK is intended to be 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 openOSEK's behaviour.