This is where to find what you need to know in order to check code in to OpenSees's CVS repository. If you've never built OpenSees before, then you should start by looking at the source code and building it.

1. Anything you check in must belong to you or you must have full rights to publish and license it.

2. All source files you submit must contain your name and an open license which will allow for the free non-commercial use of your code.

3. If you have a patch to fix a bug, submit it to OpenSees Bugs as an attachment to that bug. Use the Message Board to discuss patches. When you're submitting patches frequently and have an established track record of good code then we may want to give you your own checkin priviledges. BUT DON'T COUNT ON IT!

4. If you have new code to add to OpenSees and you don't have CVS checkin priviledges CONTACT ME. I'm more than happy to help you out, and make sure your code gets incorporated. BE WARNED that it's upto you to ensure that the code has been tested.

5. To get write access to the CVS tree, someone must vouch for you. At present this is ME. AND I TRUST NO-ONE! The person who vouches for you will be responsible for making sure you know and follow our rules and will be responsible for your tree breakages if you're not around to fix your own. Vouching for another person is a big responsibility so people need to take care who they vouch for. They will want to see evidence that you do good work that rarely busts the tree. Usually they will want to see a record of patch submissions although they may skip this formality for co-workers whose work they're already familiar with.

   • Your CVS account is for your own use only. Do not let others use it. If you check in someone else's patch, attribute the patch to them in the CVS log.

6. Our next most important rules are those regarding the build process. Disregarding them wastes a lot of other people's time. Blatant offenders will be pestered into compliance. Resistance is futile.

   • If you're not sure about how to do something: 1) DON'T DO IT and 2) CONTACT ME. I'm more than happy to help you out, and make sure that the right things can happen.
   • Everyone checking into the repository must do their part to keep the tree green. Make sure your code builds on other platforms before it's checked in. For you windows users this includes a UNIX platform, and for you unix programmers this include WINDOWS. And make sure your changes do not break the library build. Just because your main program compiles does not mean that the OpenSees library will compile with your changes, particularly if you changed header files. After your checkin, it's your responsibility to be available to help fix unanticipated build or runtime problems.
   • When creating a new directory, get the permission from ME. We prefer not to add new top level directories unless there is a very good reason. Most new projects will fit somewhere already in the tree like under elements. If you do add a new directory, follow the naming conventions used for the existing directories, e.g. fourNodeQuad; and do not add directories which begin with a non-alpha character, e.g. 4nquad.

7. One of our primary design considerations is that our code work on a wide variety of platforms. There are people porting OpenSees to small platforms using compilers that may not support all the latest standards (e.g. VisualC++ is way behind!). Help these platforms by following our C/C++ Portability and Style Guidelines and compiling with as many warnings turned on as possible.

Happy hacking!