You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@xml.apache.org by tw...@apache.org on 2001/06/25 18:50:33 UTC
cvs commit: xml-admin charter.txt
twl 01/06/25 09:50:33
Modified: . charter.txt
Log:
Final charter after vote in general@xml.apache.org
Revision Changes Path
1.3 +181 -191 xml-admin/charter.txt
Index: charter.txt
===================================================================
RCS file: /home/cvs/xml-admin/charter.txt,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- charter.txt 2001/05/30 05:08:33 1.2
+++ charter.txt 2001/06/25 16:50:29 1.3
@@ -1,215 +1,205 @@
-==================================
-xml.apache.org Project Charter
-===============
-
-Document State: draft
-
-xml.apache.org is a collaborative software development project dedicated to
-providing robust, full-featured, commercial-quality, and freely-available
-XML support on wide variety of platforms. This project is
-jointly managed by a group of individuals (both from companies and private
-individuals) throughout the world, using the Internet and the Web to
-communicate, plan, and develop XML software and its related documentation.
+
+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
-===============
+MISSION
+=======
xml.apache.org exists to promote the use of XML. We view XML as a
-compelling paradigm that structures data as information thereby
+compelling paradigm that structures data as information, thereby
facilitating the exchange, transformation, and presentation of
-knowledge. The transformation of raw data into useful information has
-great potential to improve the functionality and usability of information
-systems. In order to bring such improvements about, we intend to build
-freely available XML processing components.
-
-xml.apache.org defines a set of components that exchange or deal with XML
-information sets. These components plug into each other using standard
-(either formal, defacto, or proposed) APIs. The components must be high
-performance, reliable, and easy to use. The components must be part of a
-underlying architectural orchestration that will allow them to work
-together without major negotiations or breakages.
+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 useable as core components for all.
-
-In order to achieve a coherent architecture both between xml.apache.org
-components and between other components and applications, standards (either
-formal or defacto) will be used as much as possible, for both protocols and
-APIs. We will also allow innovation of new protocols, APIs and components
-to
-occur in order to seed new ideas and concepts that have not yet been
-defined by standards.
-
-History
-===============
-In order to facilitate joint, open-source development, this project was set
-up under the direction of the newly-formed Apache Software Foundation in
-August, 1999.
-
-Subprojects
-===============
-xml.apache.org is composed of subprojects: a subproject is a component
-which
-possess a well defined scope. Each subproject has its own set of
-developers.
-
-A new project proposal is submitted to the PMC, accepted by majority
-committer vote, and then subject to final approval by the PMC.
+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 PROJECT MANAGEMENT COMMITTEE
+================================
The xml.apache.org project is managed by a small, core group of
-contributors known as the PMC (Project Management Committee). This group
-must have least one officer of the Apache board, who will be considered the
-Chair person of the PMC, and who will report to the Apache board. See
+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 PMC has the following responsibilities:
-1) Acceptance of new project proposals, formal submission of these
- these proposals for a committer vote, and creation of the
- subproject.
-2) Facilitation of code or other donations by individuals or companies.
+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) Making sure administrative gets done.
-6) Making sure that infrastructure work is accomplished.
-7) Facilitation of relationships between projects.
-8) Facilitation of relationships between xml.apache.org and the external
+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.
-9) Oversight of xml.apache.org to ensure the mission defined in this
- document is being fulfilled.
-10) Conflict resolution within the project.
-
-New members of the PMC are added when an individual is nominated by a
-contributor and 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. The goal is to keep the membership of
-the core group low (4 to 7 people) in order to minimize the amount of
-bureaucratic overhead required to keep the project running.
-
-In the unlikely event that a member of the PMC becomes disruptive to the
-process or ceases to contribute for a long period, he or she may be removed
-by a unanimous vote of the remaining members of the PMC.
-
-The PMC is responsible for maintaining and updating this charter.
-Development must follow the process outlined below, so any changes to the
-development process necessitate a change to the charter. Changes must be
-unanimously approved by all members of the PMC. At any time a contributor
-may challenge a change to the charter, and ask for a vote of all
-committers, in which case it must be approved by a two-thirds majority.
+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. 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.
+
+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.
-Committers
-===============
+A new subproject proposal is submitted to the PMC, accepted by majority
+committer vote, and then subject to final approval by the PMC.
+
+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 nomonated by a committer and is
-approved by at least 50% of the committers for that subproject, with no
-"no"
-votes. In most cases, new commiters will have already been participating
-in the development process by submitting suggestions and/or fixes using
-the bug report page or newsgroups.
-
-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.
-
-When a specific change to a product is proposed for discussion or voting on
-the appropriate development mailing list, it 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 a distinctive one-line
-summary in the subject corresponding to the action item for that patch.
-
-The patch should be created by using the diff -u command from the original
-software file(s) to the modified software file(s). It is recommended that
-patches are submitted against the latest CVS versions of the software in
-order
-to avoid conflicts. This will also ensure that you are not submitting a
-patch for a problem that has already been resolved.
+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 have made regular substantial contributions may become
-committers as described above
+Developers who make regular and substantial contributions may become
+committers as described above.
-Infrastructure
-===============
+INFRASTRUCTURE
+==============
The xml.apache.org project site must provide the following:
+
+Bug Database -- This is a system for tracking bugs and feature
+requests.
-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.
-Project Source Repositories
-These are a number of CVS repositories containing both the source code and
-documentation for the projects. Each project will have a set of committers
-to their repository.
-
-Web site
-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 their own website with project information.
-
-PMC Mailing List
-This list is for PMC business that involves a need for privacy,
-particularly when discretion is requested by an individual or company. All
-other PMC business should be done on the general mailing list.
-
-General Mailing List
-This newsgroup is open to the public.
-It is intended for discussions about cross-project
-
-Project Mailing Lists
-Each project should have mailing lists devoted to the projects. Many
-projects may wish to have both user and development lists. It is up to the
-individual subprojects to 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 � {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) and 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 then changed as
-needed, with conflicts resolved by majority vote of the committers.
-
-Subproject Requirements
-===============
-Each subproject must have a set of requirements that is visible from their
-web page.
-
-Each project must have an up-to-date release plan that is visible from
-their web page.
-
-Each project must have an up-to-date design document that is visible from
-their web page.
-
-It must be possible for each project to plug into the Gump nightly build
-system (see http://jakarta.apache.org/builds/gump). It is recommended that
-each project have a smoke-test system that at least works as a basic
-integration test.
-
-Relationship to other Apache projects
-===============
-The xml.apache.org projects should work closely with other Apache projects
-such as Jakarta and the Apache Server to avoid redundancy and to achieve a
-coherent architecture between xml.apache.org and these projects.
---------------------------------------------------------------------
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