-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Ted,
Comments/thoughts in-line. Take with grain of salt. I haven't attempted to create new text, and am not sure what process you want to follow to evolve this document to final form.
Cheers, ~ Berin
Ted Leung wrote: | Hi All, | | | | Here is a first cut at a revised charter for xml.apache.org. This is | just a starting point, | | so please comment, etc. | | | | I've included the text and diffs inline. I've also committed this | version to xml-admin. | | | | Ted | | ----------------------------------- | | xml.apache.org is a collaborative software development project | | dedicated to providing robust, full-featured, commercial-quality, and | | freely available XML support on a wide variety of platforms. This | | project is managed in cooperation with various individuals worldwide | | (both independent and company-affiliated experts), who use the | | Internet to communicate, plan, and develop XML software and related | | documentation. | | | | This charter briefly describes the mission, history, organization, and | | processes of the project. | | | | MISSION | | ======= | | xml.apache.org exists to promote the use of XML. We view XML as a | | compelling paradigm that structures data as information, thereby | | facilitating the exchange, transformation, and presentation of | | knowledge. The ability to transform raw data into usable information | | has great potential to improve the functionality and use of | | information systems. We intend to build freely available XML | | processing components in order to engender such improvements. | | | | xml.apache.org defines a set of components that exchange or deal with | | XML information sets. These components plug into each other using | | standard APIs (formal, de facto, or proposed). The components must be | | high performance, reliable, and easy to use. The components must be | | part of an underlying architectural orchestration that will allow them | | to work together without major negotiations or breakage. | | | | We believe that the best way to define this XML information exchange | | architecture is by having both individuals and corporations | | collaborate on the best possible infrastructure, APIs, code, testing, | | and release cycles. Components must be vendor neutral and usable as | | core components for all. | | | | In order to achieve a coherent architecture between xml.apache.org | | components and other components and applications, standards (formal or | | de facto) will be used as much as possible for both protocols and | | APIs. We will also allow the innovation of new protocols, APIs, and | | components in order to seed new concepts not yet defined by standards. |
Do we see it as part of the charter to also provide feedback into the developing standards from other forums (e.g. w3c)? Maybe "where applicable"? (There is an implication of this below.)
| | | HISTORY | | ======= | | | | This project was established under the direction of the newly-formed | | Apache Software Foundation in August 1999 to facilitate joint | | open-source development. | | | | 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). | | 2) Facilitating code or other donations by individuals or companies. | | 3) Resolving license issues and other legal issues. | | 4) Approving new committers.
I thought this was de-volved to the sub-projects?
| | 5) Ensuring that administrative and infrastructure work is completed. | | 6) Facilitating relationships among projects.
And sub-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. In most cases, developers will | | have actively contributed to development for at least six months | | before being considered for membership on the PMC. | |
Is this all xml.apache.org committers? The process recently gone through is fairly different - 2 people per sub-project, voted in by committers on the sub-project. Maybe this should now be updated to reflect the new approach?
The definition of committer/contributors is given below. Without it (and assuming no background) this gets quite confusing.
| | In the unlikely event that a member of the PMC becomes disruptive to | | the process or ceases to contribute for an extended period, said | | member may be removed by unanimous vote of remaining PMC members. |
Without any input from committers of the sub-project that member was representing?
| | | 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 which case a two-thirds | | majority must approve the change. |
There are a number of places above and below that mention unanimous approval by all PMC members. I think the PMC has grown a bit from the recent process, so is this realistic. A lack of response from a PMC member could stall a change until that person could be voted off.
The larger the group, the harder it is to get consensus. Maybe three quaters?
| | | SUBPROJECTS | | =========== | | xml.apache.org is comprised of subprojects; a subproject is a | | component whose scope is well defined. Each subproject has its own | | set of developers. | | | | A new subproject proposal is submitted to the PMC, accepted by majority | | committer vote, and then subject to final approval by the PMC. |
Shouldn't it be the other way around? If the PMC is going to knock it back, then it's better to do it when it's submitted rather than once everyone has had a vote.
| | | A subproject may be removed by unanimous vote of the PMC, subject to the | | approval of the ASF board. A contributor 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. |
You would also want to ensure that there are people who are going to be committers for the sub-project if it remains.
| | | 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. |
This would seem to contradict earlier statements? (Approved by PMC)
| | | CONTRIBUTORS | | ============ | | 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. |
It might be better to require the use of bugzilla? (Rather than submission of potentially large patches to an entire mailing list.)
| | | 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. | |
If they are not the latest CVS version, then the e-mail/bugzilla report should clearly identify which versions they are against.
On another thought - wouldn't this best be left to the subproject and the particular situation at hand?
|
| Developers who make regular and substantial contributions may become
|
| committers as described above.
|
|
|
| INFRASTRUCTURE
|
| ==============
|
| The xml.apache.org project site must provide the following:
|
|
|
| Bug Database -- This is a system for tracking bugs and feature
|
| requests.
|
|
|
| Subproject Source Repositories -- These are several CVS repositories
|
| containing both the source code and documentation for the
|
| subprojects. Each subproject will have a set of committers to its
|
| repository.
|
|
|
| Website -- An xml.apache.org website will contain information about
|
| the xml.apache.org project, including documentation, downloads of
|
| releases, and this charter. Each subproject will have its own website
|
| with subproject information.
|
|
|
| PMC Mailing List -- This list is for PMC business requiring
|
| confidentiality, particularly when an individual or company requests
|
| discretion. All other PMC business should be done on the general
|
| mailing list.
|
|
|
| General Mailing List -- This mailing list is open to the public. It is
|
| intended for discussions that cross subprojects.
|
|
|
| Subproject Mailing Lists -- Each subproject should have a devoted mailing
|
| list. Many subprojects may wish to have both user and development
|
| lists. The individual subprojects may decide on the exact structure of
|
| their mailing lists.
|
|
|
| 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]
|
|
|
| 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.
|We need to be clear that this is committers of the _sub-project_. (In other places committers seems to have an implication of XML project.)
Am not entirely convinced that this is lightweight (and I'd be interested to know whether anyone does it?)
Feature additions (as mentioned above) would generally be approved up front and the work assigned to individuals.
But there are parts of code bases that are seen as the "domain" of a small subset (one person in many cases) of people. That person (those people) does (do) frequent changes to that part of the code-base and having a vote every time they want to do something is unwieldy.
Bug fixes can be worked through via bugzilla. If I take on a bug, I create the fix and post some small details on bugzilla, which will report back to the mailing list. If anyone objects then we can vote and potentially back out the CVS or add another "fix". Otherwise, no response can be taken as acceptance of the change.
| | | 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. |
What about C/C++ sub-projects?
Actually I've been meaning to post a general question to the list for some time about whether anything exists for these. If not, should we look at setting something up? (We can, it won't be as flexible as Gump, but it can still be very useful.)
| | | 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. | | | | | | | Diffs | | | Index: charter.txt | | =================================================================== | | RCS file: /home/cvs/xml-admin/charter.txt,v | | retrieving revision 1.3 | | diff -r1.3 charter.txt | | 55c55,56 | | < http://www.apache.org/foundation/bylaws.html for reference. | | --- | | > http://www.apache.org/foundation/bylaws.html for reference. The | | > Chairperson will serve a term of one calendar year | | 77,80c78 | | < before being considered for membership on the PMC. The goal is to keep | | < the membership of the core group at four to seven people in order to | | < minimize the bureaucratic overhead required to keep the project | | < operational. | | --- | | > before being considered for membership on the PMC. | | 101a100,104 | | > | | > A subproject may be removed by unanimous vote of the PMC, subject to the | | > approval of the ASF board. A contributor 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. | | | | | ------------------------------------------------------------------------ | | | xml.apache.org is a collaborative software development project | dedicated to providing robust, full-featured, commercial-quality, and | freely available XML support on a wide variety of platforms. This | project is managed in cooperation with various individuals worldwide | (both independent and company-affiliated experts), who use the | Internet to communicate, plan, and develop XML software and related | documentation. | | This charter briefly describes the mission, history, organization, and | processes of the project. | | MISSION | ======= | xml.apache.org exists to promote the use of XML. We view XML as a | compelling paradigm that structures data as information, thereby | facilitating the exchange, transformation, and presentation of | knowledge. The ability to transform raw data into usable information | has great potential to improve the functionality and use of | information systems. We intend to build freely available XML | processing components in order to engender such improvements. | | xml.apache.org defines a set of components that exchange or deal with | XML information sets. These components plug into each other using | standard APIs (formal, de facto, or proposed). The components must be | high performance, reliable, and easy to use. The components must be | part of an underlying architectural orchestration that will allow them | to work together without major negotiations or breakage. | | We believe that the best way to define this XML information exchange | architecture is by having both individuals and corporations | collaborate on the best possible infrastructure, APIs, code, testing, | and release cycles. Components must be vendor neutral and usable as | core components for all. | | In order to achieve a coherent architecture between xml.apache.org | components and other components and applications, standards (formal or | de facto) will be used as much as possible for both protocols and | APIs. We will also allow the innovation of new protocols, APIs, and | components in order to seed new concepts not yet defined by standards. | | HISTORY | ======= | | This project was established under the direction of the newly-formed | Apache Software Foundation in August 1999 to facilitate joint | open-source development. | | 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). | 2) Facilitating code or other donations by individuals or companies. | 3) Resolving license issues and other legal issues. | 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. 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, 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 which case a two-thirds | majority must approve the change. | | SUBPROJECTS | =========== | xml.apache.org is comprised of subprojects; a subproject is a | component whose scope is well defined. Each subproject has its own | set of developers. | | A new subproject proposal is submitted to the PMC, accepted by majority | committer vote, 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 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 | ============ | 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. | | INFRASTRUCTURE | ============== | The xml.apache.org project site must provide the following: | | Bug Database -- This is a system for tracking bugs and feature | requests. | | Subproject Source Repositories -- These are several CVS repositories | containing both the source code and documentation for the | subprojects. Each subproject will have a set of committers to its | repository. | | Website -- An xml.apache.org website will contain information about | the xml.apache.org project, including documentation, downloads of | releases, and this charter. Each subproject will have its own website | with subproject information. | | PMC Mailing List -- This list is for PMC business requiring | confidentiality, particularly when an individual or company requests | discretion. All other PMC business should be done on the general | mailing list. | | General Mailing List -- This mailing list is open to the public. It is | intended for discussions that cross subprojects. | | Subproject Mailing Lists -- Each subproject should have a devoted mailing | list. Many subprojects may wish to have both user and development | lists. The individual subprojects may decide on the exact structure of | their mailing lists. | | 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] | | 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. | | 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. | | | | | ------------------------------------------------------------------------ | | --------------------------------------------------------------------- | In case of troubles, e-mail: [EMAIL PROTECTED] | To unsubscribe, e-mail: [EMAIL PROTECTED] | For additional commands, e-mail: [EMAIL PROTECTED] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE+cFoGF/2r6GCc0sARAl1IAJ0Y7YP09hk4KpGwURnWWz3qJR53LwCgkB2e VjHX+e9oRuOYGGSfoPvpVlo= =bYi3 -----END PGP SIGNATURE-----
--------------------------------------------------------------------- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
