New Committer or Developer Role Requests

Please join the project first as an Observer and then work with a Developer as a Contributor. Per the Governance Policy the Project Owner has the ability to grant Committer privileges.

Contributor Information

You can contribute to the project in various ways: bug fixes, enhancements or new features.

• All Contributors must sign and return a Sun Contributor Agreement (SCA)
• See the Governance Policy for more information on roles and responsibilities
• If you would like to contribute new code, please send an email to project "dev" alias, i.e., dev@_project_.dev.java.net
• If you would like to contribute patches for existing code, please contact the Project Owner
• If you have found a problem with the existing code, please file a bug using Issue Tracker
• All code checked into the workspace must follow the coding conventions (see below)

Committer Information

These are the rules and conventions for contributing to any OpenPortal project. All Committers must follow the processes described below when delivering code into a project.

General Check-in Procedures

1. Have your code reviewed by appropriate module owner/tech leads and copy to the project "diffs" alias, i.e., diffs@_project_.dev.java.net
2. Run appropriate set of regression and/or unit tests based on the scope and risk of your change. You are responsible for figuring out the right set of tests to run. Please contact the module owner/tech lead if necessary.
3. Include the following information in the commit message:
   • Issue ID
   • Code reviewer(s)
   • Description or problem and solution
4. If there is a documentation impact, please use Issue Tracker and file a new task/feature.

Checklist for Code Submitters

1. Is there an issue filed in Issue Tracker?
2. Has the code been reviewed?
3. Have you run all appropriate regression and/or unit tests?
4. Has information about the change been sent to the documentation writers and testers?
5. Has your workspace been updated recently? Are you using the right branch? Have you checked and resolved all CVS/subversion conflicts?
6. Are there enough comments in the code to understand the change?
7. Is the code I18N compliant?
8. Is the code formatted with the same format as the rest of the code in the file? Are the Java coding conventions followed?

Checklist for Code Reviewers

1. Are you the right reviewer?
2. Can you review the code within 1 business day? (Can you find a delegate if not?)
3. Is there an issue filed?
4. Is there sufficient test coverage for the change?
5. Are there enough comments in the code to understand the change?
6. Is the code I18N compliant?
7. Is the code formatted with the same format as the rest of the code in the file? Are the Java coding conventions followed?
8. Is the design sound? Does it fit in with the design of the rest of the module? Is it robust enough?

Checklist for Post-review/Check-in

1. Did you incorporate all the changes requested and get them reviewed?
2. Did you add all of the new files to the repository?
3. Did you update, recompile, and run the appropriate tests?
4. Did you check in all the changes together and make sure your check-in comment contains a description, a reviewer, and the tests run? If the change spans multiple areas, it is recommended to include the list of changed files into the log message as well.
5. If the change is a bug fix, update the issue in Bugtraq to integrated along with a pointer to the unit or Quicklook test that covers the bug.
6. Notify testing, documentation, and any other groups of your change if it affects user functionality or a bug that was blocking them.

Conventions

Coding Conventions

All code developed for the any OpenPortal project must follow the Java Coding Conventions.

How to write documentation comments for the Javadoc tool

See this document for information on writing Javadoc comments.