xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter B. West" <pbw...@powerup.com.au>
Subject Re: Revisions to xml.apache.org charter
Date Thu, 13 Mar 2003 01:51:27 GMT
Ted,

See comments below.

Ted Leung wrote:
...
> 
> HISTORY
> 
> =======
> 
>  
> 
> This project was established under the direction of the newly-formed
> 
> Apache Software Foundation in August 1999 to facilitate joint
> 
> open-source development.
> 
>

I would like to see the terms 'contributor', 'developer' and 'committer' 
and 'subproject' briefly defined here, so that the uninitiated reader 
can follow the subsequent argument.

> 
> THE PROJECT MANAGEMENT COMMITTEE
> 
> ================================
> 
> The xml.apache.org project is managed by a small, core group of
> 
> contributors known as the Project Management Committee [PMC].  The PMC
> 
> must have at least one officer from the Apache Board, who will be the
> 
> Chairperson and report to the Apache Board.  See
> 
> http://www.apache.org/foundation/bylaws.html for reference. The
> 
> Chairperson will serve a term of one calendar year
> 
>  
> 
> The PMC has the following responsibilities:
> 
>  
> 
> 1) Accepting new subproject proposals, formally submitting these
> 
>    proposals for committer vote, and creating the subproject (see
> 
>    SUBPROJECTS below).

Which committers?

> 
> 2) Facilitating code or other donations by individuals or companies.
> 
> 3) Resolving license issues and other legal issues.

In conjunction with the Board?

> 
> 4) Approving new committers.
> 
> 5) Ensuring that administrative and infrastructure work is completed.
> 
> 6) Facilitating relationships among projects.
> 
> 7) Facilitating relationships between xml.apache.org and the external
> 
>    world.
> 
> 8) Overseeing xml.apache.org to ensure that the mission defined in
> 
>    this document is being fulfilled.
> 
> 9) Resolving conflicts within the project.
> 
>  
> 
> To become a member of the PMC, an individual must be nominated by a
> 
> contributor, unanimously approved by all PMC members, and approved by
> 
> a two-thirds majority of committers.

Again, which committers?

  In most cases, developers will
> 
> have actively contributed to development for at least six months
> 
> before being considered for membership on the PMC.
> 
>  
> 
> In the unlikely event that a member of the PMC becomes disruptive to
> 
> the process or ceases to contribute for an extended period,

Nit-picking here, but possibly something like:

In the unlikely event that a PMC member becomes disruptive to the PMC, 
or if a PMC member ceases to make codebase contributions for an extended 
period, ...

  said
> 
> member may be removed by unanimous vote of remaining PMC members.
> 
>  
> 
> The PMC is responsible for maintaining and updating this
> 
> charter. Development must follow the process outlined below, so any
> 
> change to the development process necessitates a change to the
> 
> charter. Changes must be unanimously approved by all members of the
> 
> PMC. A contributor may challenge a change to the charter at any time
> 
> and ask for a vote of all committers,

In this case, all committers to Apache XML subprojects?

  in which case a two-thirds
> 
> majority must approve the change.
> 
>  
> 
> SUBPROJECTS
> 
> ===========
> 
> xml.apache.org is comprised of subprojects; a subproject is a

Maybe, "...a subproject (develops|is responsible for)..."
> 
> component whose scope is well defined.  Each subproject has its own
> 
> set of developers.

... , although developers may be active in more than one subproject.
> 
>  
> 
> A new subproject proposal is submitted to the PMC, accepted by majority
> 
> committer vote,

I think this one needs to be defined.  I'm not sure what it means.

  and then subject to final approval by the PMC.
> 
>  
> 
> A subproject may be removed by unanimous vote of the PMC, subject to the
> 
> approval of the ASF board.  A contributor

...to the subproject...  ?

  may challenge the removal of a
> 
> subproject at any time and ask for a vote of all committers,

??

  in which
> 
> case a two-thirds majority must approve the change.
> 
>  
> 
> COMMITTERS
> 
> ==========
> 
>  
> 
> Each subproject has a set of committers. Committers are developers who
> 
> have read/write access to the source code repository. New committers
> 
> are added when a developer is nominated by a committer and approved by
> 
> at least 50 percent of the committers for that subproject with no
> 
> opposing votes.  In most cases, new committers will already be
> 
> participating in the development process by submitting suggestions
> 
> and/or fixes via the bug report page or mailing lists.
> 
>  
> 
> CONTRIBUTORS
> 
> ============

This section seems out of character.  I think it should basically be a 
definition, so that the meritocracy comments seem unnecessary, and the 
technical details of contribution feel out of place.  Shouldn't they be 
under "The Development Process"?

> 
> Like all Apache projects, the XML project is a meritocracy -- the more
> 
> work you do, the more you are allowed to do. Occasional contributors
> 
> will be able to report bugs and participate in the mailing lists.
> 
>  
> 
> Specific changes to a product proposed for discussion or voting on the
> 
> appropriate development mailing list should be presented in the form
> 
> of input to the patch command. When sent to the mailing list, the
> 
> message should contain a subject beginning with [PATCH] and including
> 
> a distinctive one-line summary that corresponds to the action item for
> 
> that patch.
> 
>  
> 
> Use the diff -u command from the original software file(s) to the
> 
> modified software file(s) to create the patch. Patches should be
> 
> submitted against the latest CVS versions of the software to avoid
> 
> conflicts and ensure that you are not submitting a patch for a problem
> 
> that has already been resolved.
> 
>  
> 
> Developers who make regular and substantial contributions may become
> 
> committers as described above.
> 
>  
> 
...
> 
> LICENSING
> 
> =========
> 
> All contributions to the xml.apache.org project adhere to the "ASF
> 
> Source Code License." All further contributions must be made under the
> 
> same terms. All contributions must contain the following copyright
> 
> notice: [This changes now that the license is available]
> 
>  

I'm not subscribed to licensing, but at FOP, Jeremias has just gone 
through the pain of substituting the full license for the 'reference' 
version.  Does this mean that it was unnecessary?

> 
> Copyright (c) {date} {name of contributor} and others. All rights
> 
> reserved. This program and the accompanying materials are made
> 
> available under the terms of the ASF Source Code License, as found in
> 
> the file ASF.code.license.html that is included in this distribution.
> 
>  
> 
> THE DEVELOPMENT PROCESS
> 
> =======================
> 
> The development process is intentionally lightweight; like other
> 
> Apache projects, the committers decide which changes may be committed
> 
> to the repository. Three +1 ('yes' votes) with no -1 ('no' votes or
> 
> vetoes) are needed to approve a code change. For efficiency, some code
> 
> changes from some contributors (e.g. feature additions, bug fixes) may
> 
> be approved in advance, in which case they may be committed first and
> 
> changed as needed, with conflicts resolved by majority vote of the
> 
> committers.
> 

The above may need a reality check.  Does anyone actually do this?

>  
> 
> SUBPROJECT REQUIREMENTS
> 
> =======================
> 
> Each subproject must have a set of requirements as well as an
> 
> up-to-date release plan and design document on its dedicated web page.
> 
>  
> 
> It must be possible for each subproject to plug into the Gump nightly
> 
> build system (see http://jakarta.apache.org/builds/gump). It is
> 
> recommended that each subproject have a smoke-test system that works at
> 
> least as a basic integration test.
> 
>  
> 
> RELATIONSHIP TO OTHER APACHE PROJECTS
> 
> =====================================
> 
> The xml.apache.org project should work closely with other Apache
> 
> projects, such as Jakarta and the Apache Server, to avoid redundancy
> 
> and achieve a coherent architecture among xml.apache.org and these
> 
> projects.
> 

-- 
Peter B. West  pbwest@powerup.com.au  http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"


---------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org


Mime
View raw message