xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From t..@apache.org
Subject cvs commit: xml-admin charter.txt
Date Wed, 30 May 2001 05:08:36 GMT
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


Mime
View raw message