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/05/30 07:08:36 UTC
cvs commit: xml-admin charter.txt
twl 01/05/29 22:08:35
Modified: . charter.txt
Log:
reword first paragraph
Revision Changes Path
1.2 +215 -214 xml-admin/charter.txt
Index: charter.txt
===================================================================
RCS file: /home/cvs/xml-admin/charter.txt,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- charter.txt 2001/05/03 03:37:15 1.1
+++ charter.txt 2001/05/30 05:08:33 1.2
@@ -1,214 +1,215 @@
-==================================
-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.
-This charter briefly describes the mission, history, organization, and
-processes of the project.
-
-Mission
-===============
-xml.apache.org exists to enable information to be easily exchanged,
-transformed, presented, and used in a great variety of configurations, and
-we believe that XML is the best protocol for that information. It is our
-belief that the XML information set will help to change the world in a
-positive way by making knowledge and data as they exist on computer
-networks much more powerful than they are currently.
-
-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.
-
-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.
-
-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
-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.
-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
- 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.
-
-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.
-
-Developers who have made regular 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.
-
-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.
+==================================
+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.
+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 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.
+
+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.
+
+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
+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.
+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
+ 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.
+
+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.
+
+Developers who have made regular 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.
+
+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