xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ted Leung" <twle...@sauria.com>
Subject Re: Full charter proposal draft #1
Date Sun, 01 Apr 2001 23:11:35 GMT
Some minor changes to accomodate subprojects, change of Core Team
to committers,  altered wording to try to capture that companies themselves
are not represented, but are represented by individuals (see

>----- Original Message -----
>From: <Scott_Boag@lotus.com>
>To: <general@xml.apache.org>
>Sent: Sunday, April 01, 2001 11:37 AM
>Subject: Full charter proposal draft #1
>Here is a formal Charter proposal draft.  When you suggest changes, I
>recommend that you make specific language change proposals to this draft,
>or make a complete competing Charter proposal.  We should try to get the
>Charter concrete and wrapped up within a week or two, if this is feasible,
>so we can move on to other business.
>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 information set support on a wide variety of platforms. This project is
XML support on wide variety of platforms.  This project is
>jointly managed by a group of companies and individual volunteers
managed by a group of individuals (both from companies and private

>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
>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.  But we will also allow innovation of new protocols and APIs to occur
APIs. We will also allow innovation of new protocols, APIs and components to
>in order to seed new ideas and concepts that have not yet been defined by
>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 which
possess a  well defined scope.  Each subproject has its own set of

>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) Final acceptance of new project proposals.
>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
11) creation of subprojects - or should this be by majority committer vote?
>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.
>In addition to the Core Team, there are a number of contributors to the XML
Each subproject has a set of committers.

>project. Contributors are individual or company-affiliated developers who
Committers are developers who
>have read-write access to the source code repository. New Contributors are
have read-write access to the source code repository. New committers are

>added when a developer is nominated by a member of the Core Team and is
added when a developer is nomonated by a committer and is
>approved by at least 50% of the Core Team members, with no "no" votes. In
approved by at least 50% of the committers for that subproject, with no "no"
votes.  In
>most cases, new Contributors will have already been participating in the
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 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
you submit patches 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.

>Patches should be submitted in zip files to the mailing lists, or as
>attachements to the bug database.  Attribution must be given for all
>patches that are integrated with the code base.
>Developers who have been participating for six months or so may decide to
>become regular contributors, as described below.
Developers who have made regular substantial contributions may become
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 all Core Team members and
This newsgroup is open to the public.
>developers/contributors. It is intended for discussions about cross-project
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 Core Group decides which changes may be committed to the
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 Core Group.
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
>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

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