xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott_B...@lotus.com
Subject Full charter proposal draft #2
Date Tue, 03 Apr 2001 16:18:58 GMT

I made most of the changes that Ted suggested, which I think also address
Arved's comments.  I added some detail about the process of new subproject

BTW, I'm not sure if there's something here that should instead be in the

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.

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
occur in order to seed new ideas and concepts that have not yet been
defined by standards.

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.

xml.apache.org is composed of subprojects: a subproject is a component
possess a  well defined scope.  Each subproject has its own set of

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
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
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.


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
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.

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
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
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

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

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

View raw message