Title: The Apache(tm) XML Graphics Project - Charter

#The Apache&trade; XML Graphics Project - Charter

## The Apache XML Graphics Project Charter

1 INTRODUCTION
==============

1.1 Apache&trade; 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.