Return-Path: Delivered-To: apmail-xml-general-archive@xml.apache.org Received: (qmail 87992 invoked by uid 500); 3 Apr 2001 16:17:51 -0000 Mailing-List: contact general-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: general@xml.apache.org Delivered-To: mailing list general@xml.apache.org Received: (qmail 87737 invoked from network); 3 Apr 2001 16:17:48 -0000 From: Scott_Boag@lotus.com Subject: Full charter proposal draft #2 To: general@xml.apache.org X-Mailer: Lotus Notes Release 5.0.1 July 16, 1999 Message-ID: Date: Tue, 3 Apr 2001 12:18:58 -0400 X-MIMETrack: Serialize by Router on CAMMAIL04/CAM/M/Lotus(Release 5.0.6a |January 17, 2001) at 04/03/2001 12:17:10 PM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N I made most of the changes that Ted suggested, which I think also addre= ss Arved's comments. I added some detail about the process of new subproj= ect creation. BTW, I'm not sure if there's something here that should instead be in t= he bylaws. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D xml.apache.org Project Charter =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Document State: draft xml.apache.org is a collaborative software development project dedicate= d to providing robust, full-featured, commercial-quality, and freely-availab= le XML support on wide variety of platforms. This project is jointly managed by a group of individuals (both from companies and priv= ate individuals) throughout the world, using the Internet and the Web to communicate, plan, and develop XML software and its related documentati= on. This charter briefly describes the mission, history, organization, and processes of the project. Mission =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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 ou= r 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 X= ML 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 cycl= es. Components must be vendor neutral and useable as core components for al= l. In order to achieve a coherent architecture both between xml.apache.org= components and between other components and applications, standards (ei= ther 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 componen= ts to occur in order to seed new ideas and concepts that have not yet been defined by standards. History =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D In order to facilitate joint, open-source development, this project was= set up under the direction of the newly-formed Apache Software Foundation i= n August, 1999. Subprojects =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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 developers. 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The xml.apache.org project is managed by a small, core group of contributors known as the PMC (Project Management Committee). This gro= up 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 subproject. 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 externa= l world. 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 b= y a two-thirds majority of committers. In most cases, developers will have actively contributed to development for at least six months before bein= g considered for membership on the PMC. The goal is to keep the membershi= p 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 th= e process or ceases to contribute for a long period, he or she may be rem= oved 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 t= he development process necessitate a change to the charter. Changes must b= e unanimously approved by all members of the PMC. At any time a contribu= tor 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.= Committers =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Each subproject has a set of committers. Committers are developers who have read-write access to the source code repository. New committers ar= e added when a developer is nomonated by a committer and is approved by at least 50% of the committers for that subproject, with no= "no" votes. In most cases, new commiters will have already been participati= ng in the development process by submitting suggestions and/or fixes using= the bug report page or newsgroups. Contributors =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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 votin= g 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 messa= ge should contain a Subject beginning with [PATCH] and a distinctive one-l= ine 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 origi= nal software file(s) to the modified software file(s). It is recommended th= at patches are submitted against the latest CVS versions of the software i= n order 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 Infrastructure =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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 committ= ers 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 chart= er. 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 mailin= g lists. Licensing =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D All contributions to the xml.apache.org project adhere to the "ASF Sour= ce Code License". All further contributions must be made under the same te= rms. All contributions must contain the following copyright notice: [This changes now that the license is available] Copyright =A9 {date} {name of contributor} and others. All rights reser= ved. This program and the accompanying materials are made available under th= e 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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 ne= eded 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Each subproject must have a set of requirements that is visible from th= eir 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 fr= om their web page. It must be possible for each project to plug into the Gump nightly buil= d system (see http://jakarta.apache.org/builds/gump). It is recommended t= hat each project have a smoke-test system that at least works as a basic integration test. Relationship to other Apache projects =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The xml.apache.org projects should work closely with other Apache proje= cts such as Jakarta and the Apache Server to avoid redundancy and to achiev= e a coherent architecture between xml.apache.org and these projects. -scott = --------------------------------------------------------------------- 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