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 Mon, 25 Jun 2001 16:50:33 GMT
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


Mime
View raw message