Developer Rules

We're hoping that many people will participate in our project, but we're also assuming that people will come from different backgrounds and have different levels of experience. With that in mind, here are the rules that all developers on this project must respect and stick to. This will help maintain the readability of the code, the quality of the project, and the effectiveness of the team as a whole. Cool?
  1. You don't get added to the dev team until you've shown us some code. Not that we don't trust you but...well, ok, we don't trust you. We're security people :) Seriously, we just want to see some code before you get added to the list of developers so we have a sense of your coding skill/style.
  2. Always let people know what you're working on. If you decide to take an item from our task list, or if you start working on a new idea, let everyone on the development team know about it. Someone else might already be doing it, or might be interested in working on it with you. It's all about good communication folks!
  3. Always get your code reviewed before you check it in. There are no exceptions to this rule. We want to make sure that at least two people have looked at every line of code. Code reviews catch bugs, improve readability, and make sure that multiple people are familiar with every part of the system, so they're a good idea all around.
  4. Always make sure your code builds. We cannot stress this enough. No code should be checked back in unless your whole code base builds. At some point we'll also have tests as part of the project, and then we'll extend this rule to passing all the tests too. Until then, you're getting off easy :)
  5. Always make sure that you've told the development team about checkins and what changed, preferably giving far advance notice if any changes will affect other code. We want to make sure that everyone is familiar with any changes happening in the system and how they may affect anything under active development.
  6. We use the Java coding conventions (basically) in this project. You should get familiar with them and with the style of code in this project. No code should be checked in that has a different look and feel, since we want to keep it easy for people to read through the whole codebase. These conventions include keeping every line to under 80 characters and making each tab be 4 spaces (instead of a tab character). There are no exceptions to these rules.
  7. Finally, discuss things on the sunxacml-devl list. Communication is key to a good project, and we want to make sure that everyone knows what's going on and has a chance to provide input. If you have questions about anything, or are considering some different approaches to a problem, by all means bring it up on the list.
As always, if you have any questions about this, feel free to send mail to the developers or post to the forums. We're waiting to hear from you!

Copyright 2003-2004 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms.

Sun, Sun Microsystems, the Sun Logo, and Java are trademarks or registered trademarks of Sun Microsystems, Inc. in the US and other countries.


Last Updated On: July 16, 2004