|
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. ======= 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. 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. |
charter.diff
Description: Binary data
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]
