It seems that we are getting into the nitty-gritty on many of these
issues without really discussing the expectations we have for these
projects.
We need to set some operating instructions for the pragmatic management
of the commons repository. This might live as a document separate from
the charter, but subject to similar approval rules and amendments.
Below is a proposed outline for such a document. We may need to
refactor portions of the charter into this document, or perhaps move
parts of this document into the charter.
I hope the outline is comprehensive. Please post suggestions or
proposed contents to the document. I will compile your suggestions and
contents and periodically repost the document.
Let's take a week to collect responses. Then we will present the
resultant document as a proposal to the committers for a vote. Please
try to have your contributions in by [Thu Apr 12 00:00:00 UTC 2001]
(Just about 7*24 hrs from now).
Just to be clear what I'm setting out to do:
[Charter] - Goals and governing rules for the Jakarta-commons
initiative
[Opertating Guide] - Pragmatic conventions and expectations for
handling the sub projects
============================================================
Jakarta-commons Operating Guidelines
I. Introducing a project
A. Submission of package
1. Sandbox usage
2. Approved repository usage
3. Migratory submission from another project
a. License issues
b. Migration process
B. Request for comments (RFC) to developers
1. Time frame for response
C. Proposal to voters
1. Proposal discussion
2. Sandbox review
3. Approval process
4. Migration from sandbox to repository
II. Coding standard
A. Relation to Apache guidelines
B. Endorsed dependencies
C. Java packaging guidelines
III. Documentation guidelines
A. Javadoc
B. Supplemental docs
C. Pages for the website
1. Content expectations
2. Format
IV. Package organization guidelines
A. Directory structure
1. Source
2. Tests
3. Documentation
4. Commons website pieces
V. Builds
A. End user binary releases
1. Statement of purpose
2. Release process
3. Desired frequency
4. Naming convention
5. Build requirments spec
a. Base environment expectations
b. Dependency lib handling
B. Developer snapshot releases
1. Statement of purpose
2. Release process
3. Desired frequency
4. Naming convention
5. Build requirments spec
a. Base environment expectations
b. Dependency lib handling
C. Integration builds
1. Statement of purpose
2. Release process
3. Desired frequency
4. Naming convention
5. Build requirments spec
a. Base environment expectations
b. Dependency lib handling
VI. Project intervention
A. Implementation disputes
B. Project termination
C. Evolution to standalone project
1. Conditions
2. Finding a new home
3. Migration process
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
