Since we opened up Excalibur to our Cocoon brothers, I realized that different projects have different styles of working. The diversity is not a bad thing, in fact its a good thing. However, something that will help other teams and new committers understand us better would be a Committer Guidelines Document. The guidelines are not hard and fast rules, but guidelines that help us ensure a better project, and make things run a bit smoother.
The document should map the way we *want* to work, which means some of us old dogs might need to learn some new tricks. Also, that means that some common questions and answers can be addressed before the conversations degrades from constructive to argumentative.
The recent set of questions from Anton, and a recent contribution from Bruno of Cocoon fame is what prompted this proposal. The things I would like to see:
1) Framework is very well guarded for good reason. Every future release must be binary backwards compatible. We are very resistant to adding new interfaces/classes without a very good reason. Expect to hear a dozen different ways that a need can be fulfilled without changing Framework.
2) Test first. If you are fixing a bug, please add a unit test to prove the problem before you commit code to make that test pass. We want to follow TDD [add link here] as much as possible. We are currently playing catch up, but if you want to make sure your bug doesn't accidentally creep back in we need a test case to catch it.
3) If you are brainstorming, and would like some feedback, post a Random Thought (RT). We will kick it around, and if it generates enough interest, you just might see that feature in the future.
4) Please warn us if you are doing some major refactoring and the code base might not pass the tests for a couple days. That way we won't panic. If the software is released, please respect backwards compatibility concerns--other people are using the software too.
5) Please use proper deprecation policies on released software. If a class is moving or being deleted, please post a note why and how the developer can work around their need for the class. The same goes publically accessible methods.
This small set of guidelines should be small enough and simple enough so that they are not constricting, yet smooth potential problems before they become problems.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
