| Title: The Apache(tm) XML Graphics Project - Charter |
| |
| #The Apache™ XML Graphics Project - Charter |
| |
| ## The Apache XML Graphics Project Charter |
| |
| 1 INTRODUCTION |
| ============== |
| |
| 1.1 Apache™ XML Graphics is a collaborative software development project |
| dedicated to providing robust, full-featured, commercial-quality, and freely |
| available software packages for the conversion of XML to graphical output and |
| for related components. 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. |
| |
| 1.2 This charter briefly describes the mission, history, organization, and |
| processes of the project. |
| |
| 2 MISSION |
| ========= |
| |
| 2.1 Apache XML Graphics 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 products for the conversion of XML to graphical output and closely |
| related technologies in order to engender such improvements. |
| |
| 2.2 The Apache XML Graphics products 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 XML Graphics products should also be designed to |
| work efficiently with other Apache projects that deal with XML whenever |
| possible. |
| |
| 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. |
| |
| 2.4 In order to achieve a coherent architecture between Apache XML Graphics |
| products 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. |
| |
| 3 HISTORY |
| ========= |
| |
| 3.1 Both Batik and FOP 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 XML Graphics became a top-level project of the |
| Apache Software Foundation. Apache XML Graphics 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. |
| |
| 4 TERMS |
| ======= |
| |
| 4.1 The ASF Board. The management board of the Apache Software |
| Foundation. |
| |
| 4.2 The Project. The Apache XML Graphics Project; intended to refer to the |
| source code, website and community that are Apache XML Graphics. |
| |
| 4.3 Subproject. Apache XML Graphics is composed of a number of subprojects |
| which fit into one of two categories: |
| |
| a) Implementations of a graphics-related XML standard in some particular |
| programming language. At the time of writing, there is one implementation |
| for both SVG (Batik) and XSL-FO (FOP) written in Java. |
| b) A set of components serving some purpose not directly pertinent to the |
| conversion of XML to graphical output, but which are used in related |
| applications and are tightly bound, usually through internal API's, to one |
| (or more) of the XML Graphics subprojects. |
| |
| 4.4 Product. Some deliverable (usually a binary or source |
| package) that a subproject releases to the public. Subprojects |
| may have multiple products. |
| |
| 4.5 Contributor. Anyone who makes a contribution to the development |
| of the Apache XML Graphics project or a subproject. |
| |
| 4.6 Committer. Each Apache XML Graphics subproject has a set of committers. |
| Committers are contributors who have read/write access to the source code |
| repository. |
| |
| 5 THE PROJECT MANAGEMENT COMMITTEE |
| ================================== |
| |
| 5.1 The Apache XML Graphics 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. |
| |
| 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 XML Graphics project. |
| |
| 5.3 The PMC has the following responsibilities: |
| |
| 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). |
| b) Facilitating code or other donations by individuals or companies, in |
| collaboration with the Incubator. |
| c) Resolving license issues and other legal issues in conjunction with |
| the ASF board. |
| d) Ensuring that administrative and infrastructure work is completed. |
| e) Facilitating relationships among subprojects and other Apache projects. |
| f) Facilitating relationships between Apache XML Graphics and the external |
| world. |
| g) Overseeing Apache XML Graphics to ensure that the mission defined in |
| this document is being fulfilled. |
| h) Resolving conflicts within the project. |
| i) Reporting to the ASF board (through the Chair) on the progress |
| of the project. |
| |
| 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. |
| |
| 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. |
| |
| 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. |
| |
| 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 |
| https://www.apache.org/foundation/bylaws.html for more information. |
| |
| 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. |
| |
| 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. |
| |
| 6 SUBPROJECTS |
| ============= |
| |
| 6.1 When a new subproject proposal is submitted to the PMC, it may be accepted |
| by unanimous vote of the PMC. |
| |
| 6.2 A subproject may be removed by unanimous vote of the PMC, subject to the |
| approval of the ASF board. |
| |
| 7 CONTRIBUTORS |
| ============== |
| |
| 7.1 Like all Apache projects, the Apache XML Graphics 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. |
| |
| 7.2 Contributors who make regular and substantial contributions may become |
| committers as described below. |
| |
| 8 COMMITTERS |
| ============ |
| |
| 8.1 Each subproject has a set of committers. Committers are contributors who |
| have read/write access to the source code repository. |
| |
| 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. |
| |
| 8.3 Committers have write access to the primary subproject by which they have |
| been nominated as well as the area for common components, if any. A committer |
| may be elected to multiple subprojects. |
| |
| 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 can be members of the PMC. |
| |
| 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. |
| |
| 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. |
| |
| 9 INFRASTRUCTURE |
| ================ |
| |
| 9.1 The Apache XML Graphics project relies on the Apache XML project and the |
| Apache Infrastructure project for the following: |
| |
| a) Bug Database -- This is a system for tracking bugs and feature requests. |
| |
| b) Subproject Source Repositories -- These are several repositories containing |
| both the source code and documentation for the subprojects. |
| |
| c) Website -- The xmlgraphics.apache.org website will contain information about |
| the Apache XML Graphics project, including documentation, downloads of |
| releases, and this charter. Each subproject will have its own website with |
| subproject information. |
| |
| 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. |
| |
| e) General Mailing List -- This mailing list is open to the public. It is |
| intended for discussions that cross subprojects. |
| |
| f) Subproject Mailing Lists -- Each subproject (except for common components) |
| should have at least one devoted mailing list. Many subprojects may wish to |
| have both user and dev (development) lists. The individual subprojects may |
| decide on the exact structure of their mailing lists. |
| |
| 10 LICENSING |
| ============ |
| |
| 10.1 All contributions to the Apache XML Graphics project adhere to the Apache |
| Software Foundation License, v.2.0 (https://www.apache.org/licenses/LICENSE-2.0). |
| All further contributions must be made under the same terms. |
| |
| 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. |
| |
| 11 THE DEVELOPMENT PROCESS |
| ========================== |
| |
| 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. |
| |
| 12 SUBPROJECT REQUIREMENTS |
| ========================== |
| |
| 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. |
| |
| 12.2 It is recommended that each subproject have a smoke-test system that works |
| at least as a basic integration test. |
| |
| 13 RELATIONSHIP TO OTHER APACHE PROJECTS |
| ======================================== |
| |
| 13.1 The Apache XML Graphics 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 XML Graphics and these projects. |
| |