| <?xml version="1.0" standalone="no"?> |
| <!-- |
| * Licensed to the Apache Software Foundation (ASF) under one or more |
| * contributor license agreements. See the NOTICE file distributed with |
| * this work for additional information regarding copyright ownership. |
| * The ASF licenses this file to You under the Apache License, Version 2.0 |
| * (the "License"); you may not use this file except in compliance with |
| * the License. You may obtain a copy of the License at |
| * |
| * http://www.apache.org/licenses/LICENSE-2.0 |
| * |
| * Unless required by applicable law or agreed to in writing, software |
| * distributed under the License is distributed on an "AS IS" BASIS, |
| * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| * See the License for the specific language governing permissions and |
| * limitations under the License. |
| --> |
| |
| <!DOCTYPE s1 SYSTEM "sbk:/style/dtd/document.dtd"> |
| |
| <s1 title="&XercesCFullName;"> |
| |
| <s2 title="Xerces Project Charter"> |
| <p> |
| The following charter applies to all Xerces projects. |
| </p> |
| </s2> |
| |
| <s2 title="1 INTRODUCTION" > |
| <p> |
| 1.1 Apache Xerces is a collaborative software development project |
| dedicated to providing robust, full-featured, commercial-quality, and |
| freely available XML parsers and closely related technologies |
| on a wide variety of platforms supporting several languages. 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. |
| </p> |
| <p> |
| 1.2 This charter briefly describes the mission, history, organization, and |
| processes of the project. |
| </p> |
| </s2> |
| |
| <s2 title="2 MISSION" > |
| <p> |
| 2.1 Apache Xerces 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 |
| parsers and closely related technologies in order to engender such |
| improvements. |
| </p> |
| |
| <p> |
| 2.2 The Apache Xerces parsers support standard APIs (formal, de facto, |
| or proposed). |
| They are designed to be high performance, reliable, and easy to use. |
| To facilitate easy porting of ideas between languages, the API's supported |
| should be as similar as possible, given the constraints of the languages |
| and existing architectures. Apache Xerces parsers should also be designed |
| to work efficiently with other Apache projects that deal |
| with XML whenever possible. |
| </p> |
| |
| <p> |
| 2.3 We believe that the best way to further these goals |
| 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. |
| </p> |
| <p> |
| 2.4 In order to achieve a coherent architecture between Apache Xerces |
| parsers |
| and other components and applications, standards (formal or |
| de facto) will be used as much as possible for both protocols and |
| APIs. Where appropriate, experiences and lessons learned will be fed |
| back to standards bodies in an effort to assist in the development of |
| those standards. We will also encourage the innovation of new |
| protocols, APIs, and components in order to seed new concepts not |
| yet defined by standards. |
| </p> |
| |
| </s2> |
| <s2 title="3 HISTORY" > |
| <p> |
| 3.1 The code base which formed the foundations of both the |
| Xerces-Java and Xerces-C++ subprojects of the Apache XML Project |
| was originally donated to Apache by IBM in 1999. Xerces-Perl |
| came into existence as a subproject of the Apache XML project |
| after the Xerces-C++ community had already matured to a |
| significant extent. All three were subprojects of the Apache XML |
| Project until late 2004. At this time, reflecting the growth in |
| the Apache XML project and these communities themselves, Apache |
| Xerces became a top-level Project of the Apache Software |
| Foundation. Apache Xerces still shares much infrastructure with |
| the Apache XML project and the other former subprojects of Apache |
| XML that have become projects in their own right. |
| </p> |
| |
| </s2> |
| |
| <s2 title="4 TERMS" > |
| <p> |
| 4.1 The ASF Board. The management board of the Apache Software |
| Foundation. |
| </p> |
| |
| <p> |
| 4.2 The Project. The Apache Xerces Project; intended |
| to refer to the source code, website and community that are Apache Xerces. |
| </p> |
| |
| <p> |
| 4.3 Subproject. Apache Xerces is composed of a number of subprojects |
| which fit into one of two categories: |
| </p> |
| <p> |
| a) An XML parser implementation in some particular programming |
| language. There may be multiple parsers for a given |
| language, if the API's the parsers support are sufficiently |
| dissimilar. At the time of writing, there is one parser for |
| each of Java, C/C++ and Perl. |
| </p> |
| <p> |
| b) A set of components serving some purpose not directly |
| pertinent to XML parsing, but which are used in related |
| applications and are tightly bound, usually through internal |
| API's, to one (or more) of the parser subprojects. |
| </p> |
| |
| <p> |
| 4.4 Product. Some deliverable (usually a binary or source |
| package) that a subproject releases to the public. Subprojects |
| may have multiple products. |
| </p> |
| |
| <p> |
| 4.5 Contributor. Anyone who makes a contribution to the development |
| of the Apache Xerces project or a subproject. |
| </p> |
| <p> |
| 4.6 Committer. Apache Xerces has a set of committers. Committers |
| are contributors who have read/write access to the source code |
| repository. |
| </p> |
| |
| |
| </s2> |
| |
| <s2 title="5 THE PROJECT MANAGEMENT COMMITTEE" > |
| <p> |
| 5.1 The Apache Xerces project is managed by a core group of |
| committers known as the Project Management Committee [PMC], |
| which is composed of volunteers from among the active committers |
| (see 8.3 below) from all subprojects. Each subproject must have |
| at least one representative on the PMC, to ensure active |
| supervision of the subproject. |
| </p> |
| |
| <p> |
| 5.2 The activities of the PMC are coordinated by the Chairperson, |
| who is an officer of the corporation and reports to the Apache |
| Board. The Chairperson will, on the request of the Apache Board, |
| provide reports to the Board on issues related to the running of |
| the Apache Xerces project. |
| </p> |
| |
| <p> |
| 5.3 The PMC has the following responsibilities: |
| </p> |
| |
| <p> |
| a) Accepting new subproject proposals, voting on these |
| proposals and creating the |
| subproject (see SUBPROJECTS below). This is done in collaboration |
| with the Incubator (see http://incubator.apache.org). |
| |
| </p> |
| <p> |
| b) Facilitating code or other donations by individuals or companies, |
| in collaboration with the Incubator. |
| </p> |
| <p> |
| c) Resolving license issues and other legal issues in conjunction with |
| the ASF board. |
| </p><p> |
| d) Ensuring that administrative and infrastructure work is completed. |
| </p><p> |
| e) Facilitating relationships among subprojects and other Apache projects. |
| </p><p> |
| f) Facilitating relationships between Apache Xerces and the external |
| world. |
| </p><p> |
| g) Overseeing Apache Xerces to ensure that the mission defined in |
| this document is being fulfilled. |
| </p><p> |
| h) Resolving conflicts within the project. |
| </p><p> |
| i) Reporting to the ASF board (through the Chair) on the progress |
| of the project. |
| |
| </p><p> |
| 5.4 In cases where the sub-project is unable to directly provide |
| at least one representative on the PMC--implying that there are no |
| active committers on that code base--then the subproject should |
| be considered dormant, and any relevant Apache policies for dormant |
| projects should be implemented. At the least, the subproject's status |
| should |
| be updated on its website. |
| |
| </p><p> |
| 5.5 Every 12 months, or at the request of the Board, the PMC will provide |
| a recommendation to the Apache Board for the position of Chairperson |
| of the PMC. |
| </p><p> |
| 5.6 This recommendation will be made on the basis of an election held |
| within the PMC. The election will be performed using a simple |
| majority vote of PMC members. |
| </p><p> |
| 5.7 Upon agreement by the Apache Board, the recommended Chairperson will, |
| if they are not already, be appointed an officer of the corporation. |
| See http://www.apache.org/foundation/bylaws.html for more information. |
| </p><p> |
| 5.8 In the unlikely event that a member of the PMC becomes disruptive to |
| the process, ceases to make codebase contributions for an extended |
| period, or ceases to take part in PMC votes for an extended period of |
| time, said member may be removed by unanimous vote of remaining PMC |
| members. |
| </p><p> |
| 5.9 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 approved by a two-thirds majority of all members |
| of the PMC. |
| </p> |
| </s2> |
| |
| |
| |
| <s2 title="6 SUBPROJECTS" > |
| <p> |
| 6.1 When a new subproject proposal is submitted to the PMC, it |
| may be accepted by a two-thirds vote of the PMC. |
| |
| </p><p> |
| 6.2 A subproject may be removed by unanimous vote of the PMC, subject to |
| the |
| approval of the ASF board. |
| |
| </p> |
| </s2> |
| <s2 title="7 CONTRIBUTORS" > |
| <p> |
| 7.1 Like all Apache projects, the Apache Xerces project is a meritocracy |
| -- |
| the more work you do, the more you are allowed to do. Contributions |
| will include participating in mailing lists, reporting bugs, providing |
| patches and proposing changes to a product. |
| |
| </p><p> |
| 7.2 In order to ensure that all code contained in the Apache |
| Xerces project's code repository is free of licensing, |
| intellectual property and patent issues, any developer wishing |
| to contribute a new feature to Xerces must either sign: |
| |
| </p><p> |
| a) If contributing as an individual, sign the "Individual |
| Contributor License Agreement (CLA)" |
| (http://www.apache.org/licenses/icla.txt) and file a copy with |
| the Secretary of the Corporation; or |
| </p><p> |
| b) If making the contribution as part of their employment |
| responsibilities, sign the "Corporate CLA (CCLA)", |
| (http://www.apache.org/licenses/cla-corporate.txt) and file a |
| copy with the Secretary of the Corporation. |
| |
| </p><p> |
| 7.3 If the contribution in question is a small bugfix, the |
| contributor need not sign a CLA, but need only provide the |
| following information, attaching it to the communication |
| containing the patch: |
| |
| </p><p> |
| a) Name and employer |
| </p><p> |
| b) Are you the author of the code being contributed? |
| </p><p> |
| c) Do you have the right to grant the copyright and patent |
| licenses for the contribution that are set forth in the ASF v.2.0 |
| license (http://www.apache.org/licenses/LICENSE-2.0)? |
| </p><p> |
| d) Does your employer have any rights to code that you have |
| written, for example, through your contract for employment? If |
| so, has your employer given you permission to contribute the code |
| on its behalf or waived its rights in the code? |
| </p><p> |
| e) Are you aware of any third-party licenses or other |
| restrictions (such as related patents or trademarks) that could |
| apply to your contribution? If so, what are they? |
| |
| </p><p> |
| 7.4 Contributors who make regular and substantial contributions may become |
| committers as described below. |
| |
| </p> |
| </s2> |
| |
| <s2 title="8 COMMITTERS" > |
| <p> |
| 8.1 Each subproject has a set of committers. Committers are |
| contributors who have read/write access to the source code |
| repository. |
| |
| </p><p> |
| 8.2 Normally, a new committer is added after a contributor has |
| been nominated by a committer and approved by at least 50 percent |
| of the active committers for that subproject with no opposing |
| votes. In the case that a subproject has a very small number of |
| active committers, the PMC may choose to require a PMC resolution |
| to approve the nomination of a contributor by one of the active |
| committers in that subproject. All committers must have a signed |
| Contributor License Agreement on file with the Secretary of the |
| Corporation. Since, in most cases, contributors will already |
| have contributed significant amounts of code, this should usually |
| have been done before nomination. |
| |
| </p><p> |
| 8.3 Although committers have write access to all Apache Xerces |
| subprojects, |
| they are only permitted to make changes to the subprojects to which they |
| have been elected committers. A committer may be elected to multiple |
| subprojects, but, except that no new access need be granted, the |
| process is the same as for any other contributor. |
| |
| </p><p> |
| 8.4 For the purposes of voting, committers will be classed as "active" or |
| "inactive". Only active committers will be included in the totals used to |
| determine the success or failure of a particular vote, and |
| only active committers are part of the PMC. |
| |
| </p><p> |
| 8.5 Committers remain active as long as they are contributing code or |
| posting to the subproject mailing lists. If a committer has neither |
| contributed code nor posted to the subproject mailing lists in 3 |
| months, the PMC chair may e-mail the |
| committer, the subproject development list, and the PMC mailing list |
| notifying the committer that they are going to be moved to inactive |
| status. If there is no response in 72 hours, the committer will become |
| inactive, and may be removed from the PMC mailing list. |
| |
| </p><p> |
| 8.6 An inactive status will not prevent a committer committing new code |
| changes or posting to the mailing lists. Either of these activities will |
| automatically re-activate the committer for the purposes of |
| voting, and necessitate their addition to the PMC mailing list. |
| |
| </p> |
| </s2> |
| <s2 title="9 INFRASTRUCTURE" > |
| <p> |
| 9.1 The Apache Xerces project relies on the Apache XML project |
| and the Apache Infrastructure project for the following: |
| |
| </p><p> |
| a) Bug Database -- This is a system for tracking bugs and feature |
| requests. |
| |
| </p><p> |
| b) Subproject Source Repositories -- These are several repositories |
| containing both the source code and documentation for the |
| subprojects. |
| |
| </p><p> |
| c) Website -- A xerces.apache.org website will contain information about |
| the Apache Xerces project, including documentation, downloads of |
| releases, and this charter. Each subproject will have its own website |
| with subproject information. |
| |
| </p><p> |
| d) 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. |
| |
| </p><p> |
| e) General Mailing List -- This mailing list is open to the public. It is |
| intended for discussions that cross subprojects. |
| |
| </p><p> |
| f) Subproject Mailing Lists -- Each subproject should have at least one |
| 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. |
| |
| </p> |
| </s2> |
| <s2 title="10 LICENSING" > |
| <p> |
| 10.1 All contributions to the Apache Xerces project adhere to the |
| Apache Software Foundation License, v.2.0 |
| (http://www.apache.org/licenses/LICENSE-2.0)? |
| All further contributions must be made under the |
| same terms. |
| |
| </p><p> |
| 10.2 When a committer is considering integrating a contribution |
| from a contributor who has no CLA on file with the Corporation, |
| it is the responsibility of the committer, in consultation with |
| the PMC, to conduct due diligence on the pedigree of the |
| contribution under consideration; see sections 7.2 and 7.3. |
| |
| </p> |
| </s2> |
| <s2 title="11 THE DEVELOPMENT PROCESS" > |
| <p> |
| 11.1 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 significant 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. |
| |
| </p> |
| </s2> |
| <s2 title="12 SUBPROJECT REQUIREMENTS" > |
| <p> |
| 12.1 Each subproject should have a set of requirements as well as an |
| up-to-date release plan and design document on its dedicated web page. |
| |
| </p><p> |
| 12.2 It is recommended that each subproject have a smoke-test system |
| that works at least as a basic integration test. |
| |
| </p> |
| </s2> |
| <s2 title="13 RELATIONSHIP TO OTHER APACHE PROJECTS" > |
| |
| <p> |
| 13.1 The Apache Xerces project should work closely with other Apache |
| projects, such as XML, Jakarta and the Apache Server, to avoid redundancy |
| and achieve a coherent architecture among Apache Xerces and these |
| projects. |
| |
| </p> |
| |
| </s2> |
| |
| |
| </s1> |