On Feb 13, 2007, at 6:03 AM, William A. Rowe, Jr. wrote:
Curt Arnold wrote:
http://www.mail-archive.com/general@incubator.apache.org/
msg12442.html)
suggest to me that it may be good for the Incubator project to
oversee a
collaboration to produce a Uniform Project Procedures that podlings,
newly graduated projects and established projects could adopt in
whole
or in part.
Tweak 2 things please.... they aren't Procedures - those are whatever
suits the project at the current time...
please substitute Policies (which are also dynamic but established,
guiding
principals) which is what every ASF project has had forever (even
if they
didn't really pay attention to the fact that they were following
established
traditions as policy).
I have no attachment to the name and I like policies better. It does
broaden the scope to non-procedural issues so we could address
statements of condition as well.
And these should be the Uniform Policies which already exist at
http://www.apache.org/dev/ - I'm not suggesting they are complete, we
should definitely help to flush them out.
I see http://www.apache.org/dev/ as the equivalent of US Federal Law
in the analogy. There is a body of policy that is promulgated by the
Board to which all projects within ASF must adhere, lets call that
"Apache Policy". The body of "Apache Policy" covers license policy,
source header policy, etc. Then there are areas where the PMC are
allowed to establish their own policy, however it benefits the
community if the PMC-level policies are relatively consistent. The
Uniform Project Policies would exist to address issues outside of
Apache Policy and could be adopted or ignored by PMC's at their
will. Ideally, the UPP would be suitable for almost all of the
podlings to accept in whole.
Projects at graduation should either have a commitment to follow them
in whole; or have a written set of policies which are deliberately
updated
to suit that project.
I think that would lead to a cut-and-paste policies. For example, if
the UPP established a procedure for the election of new committers,
the Harmony PMC may decide that it needs to add a requirement that
the committer has signed a document stating their exposure to the Sun
Java implementation. I think it would be beneficial if the Harmony
PMC could just state that it adopts the UPP 1.0 with the additional
requirement that new committers have signed the disclosure document,
instead of having to replace that entire procedure or duplicate the UPP.
Good thought, I think we are already closer than you suspected, and
I think
your idea to flush them out is also goodness.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
