Skip to main content

Controlling code in your open source project

Posted by turbogeek on February 22, 2005 at 12:07 PM PST

How do you manage an open source project? Part of the problems is that most owners of projects fear uncontrolled change. The second problem is really that no one wants to change code because they are afraid of breaking an unwritten rule. The key is as simple as writing downs a few rules that both make project owners feel safe to open up their software and second for contributors to feel that they can contribute source code. Rules also give owners a way to kick off a contributor that is not following the rules.

The following rules and process can be copied to your project's home page. They represent what we have seen on several successful open source projects. These rules can be modified to suit your needs, however these have been proven time and again. If you are a member of a project which has no code submission process or rules, please email a link to this blog to your project owner.

So, without further ado are the rules:



------ cut here -----------------------------------



Code Submission Rules


This is an open project so anyone that is a member can submit an issue and/or attach code to an issue to resolve an issue. However, not all code or issues will be accepted by the owners and existing developers of this project. Issues, code, comments, and documentation must be well written and pass a review by at least one of the developers and may be vetoed by any developer or the project owners. In addition we have the following code submission process. Failure to follow the process may cause you to be removed from the project.

Code Submission Process

1) All changes must be in reference to a issue to resolve a Defect, Patch, Task, Feature, or Enhancement.

2) All code to resolve the issue must be attached to an issue for review prior to committing to the database

3) All changes must be reviewed by at least one other member with developer status or the project owner

4) Any reviewed code that receives a negative review or request for modification cannot be committed until either a discussion of the code and issue reverses the negative review or that the code is modified to remove the objection. You may also be required to include comments, changes to documentation, and unit tests before code can be committed.

5) When code is posted to CVS, in the submission comment you must reference a short description of the issue, short description about the change, the issue number, and the developer ID of the reviewer.

Note: All members can submit issues and attach code modifications to the issues for review. If code is reviewed positively, you may be granted a developer role at that time or someone will post the code to CVS for you.

------ cut here -----------------------------------

Resources



For help on the issue tracker, go here: http://www.dev.java.net/scdocs/ProjectIssues#aboutIZ

Help for using CVS: http://www.dev.java.net/nonav/scdocs/ddCVS.html



Requesting membership/roles in an open source project: http://wiki.java.net/bin/view/Gelc/RequestingMembership

Rules/Process for code submissions: http://wiki.java.net/bin/view/Gelc/ChangingCodeInOpenSource

Related Topics >>