Berin Loritsch wrote:
At this location, you can see the current XML Project charter: http://cvs.apache.org/viewcvs.cgi/xml-admin/charter.txt
I propose that we take that charter and adapt it to ours since it is easier to start from something already accepted ;P .
-1
From a clear an unambigouse process perspective its not a good example. Yes - its perhaps a starting point but al of the stuff to do with unanimouse decision making is a recepie for making the PMC totally disfunctional.
If we like it, let's commit it to CVS so that we can track changes. (I would do it, but I am behind a corporate firewall).
Below is my first stab. Aside from writing the mission statement (which needs to be updated and commented on), I added this phrase to the PMC section:
" It is also
possible for a project depending on Avalon to nominate a representative.
The representative of the client project still needs to be unanimously
approved by all PMC members, and a two-thirds majority vote of
committers. "
This can be much more cleanly addressed by simply reducing word - not adding them. More notes below.
The only other work I did was changing all references from XML to Avalon.
------------------------ avalon.apache.org -----------------------------
avalon.apache.org is a collaborative software development project dedicated to providing robust, full-featured, commercial-quality, and freely available component architecture.
"component and service architecture" - no just "component architecture"
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 Avalon component software and related documentation.
This charter briefly describes the mission, history, organization, and processes of the project.
MISSION =======
avalon.apache.org exists to promote the use of Avalon components. Component Based Design is a proven practice that helps create systems
that are loosely coupled and easy to maintain. Component Based
Design requires a general framework, components, and containers to
function properly.
avalon.apache.org defines the framework, the reference implementation of the containers, the compliance testing suite, and a set of components that can be used in third party projects. These components plug into each other using standard APIs (formal, de facto, or proposed). The components must be high performance, reliable, secure, and easy to use. The components must be part of an underlying architectural orchestration that will allow them to work together without major negotiations or breakage.
We believe that the best way to define this Avalon 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 usable as core components for all.
In order to achieve a coherent architecture between avalon.apache.org
components and other components and applications, standards (formal or
de facto) will be used as much as possible for both protocols and
APIs. We will also allow the innovation of new protocols, APIs, and
components in order to seed new concepts not yet defined by standards.
Sounds like a mission for commons - needs to be replaced with a concrete mission that defines Avalon objectives.
HISTORY =======
This project was established under the direction of the newly-formed
Apache Software Foundation in November 2002 to facilitate joint
open-source development.
History should be more complete - including reference to Jakarta Avalon.
THE PROJECT MANAGEMENT COMMITTEE
================================
The avalon.apache.org project is managed by a small, core group of
contributors known as the Project Management Committee [PMC]. The PMC
must have at least one officer from the Apache Board, who will be the
Chairperson and report to the Apache Board. See
http://www.apache.org/foundation/bylaws.html for reference.
I would change the first sentence to:
The avalon.apache.org project is managed by a elected group known as the Project Management Committee [PMC].
The PMC has the following responsibilities:
1) Accepting new subproject proposals, formally submitting these proposals for committer vote, and creating the subproject (see SUBPROJECTS below).
Don;t like this notion of SUBPROJECT scope - the issue is not about accepting a new subproject or not - its about properly managing the project. Breaking out subprojects isn't management.
2) Facilitating code or other donations by individuals or companies. 3) Resolving license issues and other legal issues. 4) Approving new committers. 5) Ensuring that administrative and infrastructure work is completed.
Point 5 is infussiently defined and more an action item - should be reworded to a responsibility. Is probably redundant anyway with respect to point 8.
6) Facilitating relationships among projects. 7) Facilitating relationships between avalon.apache.org and the external world. 8) Overseeing avalon.apache.org to ensure that the mission defined in this document is being fulfilled. 9) Resolving conflicts within the project.
To become a member of the PMC, an individual must be nominated by a
contributor, 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.
Disagree.
If a single PMC member can veto the introduction of another member or any process - we have a lame duck PMC. This whiole notion of "you must be a committer" - "in most cases" - etc. is unnecessary noise - instead this needs to be written with the objective of laying down the laws about PMC evolution that gaurantee member representation.
Don;t have a replacement at the moment but coiinsider this as a big -1 on current wording here.
It is also
possible for a project depending on Avalon to nominate a representative.
The representative of the client project still needs to be unanimously
approved by all PMC members,
No, no no - any criteria for a unanimouse action is just plain off-the-planet in terms of procedure - it would dramatically change my perception of who I would consider for PMC membership - and for all the wrong reasons.
and a two-thirds majority vote of
committers. The goal is to keep the membership of the core group
at four to seven people in order to minimize the bureaucratic overhead
required to keep the project operational.
Size qualification is unnecessry - this should be abiout the process for change - which should be up to the community based on the procedures. This sort of noice should be dropped from the charter.
In the unlikely event that a member of the PMC becomes disruptive to
the process or ceases to contribute for an extended period, said
member may be removed by unanimous vote of remaining PMC members.
Same issue here - these sort of things should not be qualified by "disruptive" - maybe soneone is being disruptive because the PMC isn't doing what needs to be done - whatever - the policies should not precondition a procedure with adjectives like this - and secondly - the ugly "unanimous" word appears again - in any sort of body that is anywhaere near representative - things like thins are at worst case a 2/3 majority - as are things like changing the charter.
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 unanimously approved by all members of the
PMC.
2/3 - not unanimous.
A contributor may challenge a change to the charter at any time and ask for a vote of all committers, in which case a two-thirds majority must approve the change.
Disagree. A contribnuter should intervi8ne though participation as an elected member. This should be dropped.
SUBPROJECTS =========== avalon.apache.org is comprised of subprojects; a subproject is a component whose scope is well defined. Each subproject has its own set of developers.
A new subproject proposal is submitted to the PMC, accepted by majority
committer vote, and then subject to final approval by the PMC.
Not relevant to Avalon. We should not be subproject driven.
COMMITTERS ==========
Each subproject has a set of committers.
-1 A recepie for fragmentation.
Committers are developers who
have read/write access to the source code repository. New committers
are added when a developer is nominated by a committer and approved by
at least 50 percent of the committers for that subproject with no
opposing votes. In most cases, new committers will already be
participating in the development process by submitting suggestions
and/or fixes via the bug report page or mailing lists.
Probably needs to be rewritten from our perspective of a single committer community.
CONTRIBUTORS ============ Like all Apache projects, the Avalon 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.
Specific changes to a product proposed for discussion or voting on the appropriate development mailing list 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 including a distinctive one-line summary that corresponds to the action item for that patch.
Use the diff -u command from the original software file(s) to the modified software file(s) to create the patch. Patches should be submitted against the latest CVS versions of the software to avoid conflicts and ensure that you are not submitting a patch for a problem that has already been resolved.
Developers who make regular and substantial contributions may become
committers as described above.
Don't think this contributors text is needed because iut does not seem to impact the procedures.
INFRASTRUCTURE ============== The avalon.apache.org project site must provide the following:
Bug Database -- This is a system for tracking bugs and feature requests.
Subproject Source Repositories -- These are several CVS repositories
containing both the source code and documentation for the
subprojects. Each subproject will have a set of committers to its
repository.
-1
Recepie for fragmentation.
Website -- An avalon.apache.org website will contain information about the avalon.apache.org project, including documentation, downloads of releases, and this charter. Each subproject will have its own website with subproject information.
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.
General Mailing List -- This mailing list is open to the public. It is
intended for discussions that cross subprojects.
Would change the above to "Mailing Lists" (plural) and not go into details here.
Subproject Mailing Lists -- Each subproject should have a devoted mailing
list. Many subprojects may wish to have both user and development
lists. The individual subprojects may decide on the exact structure of
their mailing lists.
-1 Recipe for fragmentation.
LICENSING ========= All contributions to the avalon.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 (c) {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.
Should be revised to include the full ASF license in the source header.
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) with 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 changed as needed, with conflicts resolved by majority vote of the committers.
There are much stronger guidelines that this comming out of the incubator project - the above is insufficient.
SUBPROJECT REQUIREMENTS ======================= Each subproject must have a set of requirements as well as an up-to-date release plan and design document on its dedicated web page.
It must be possible for each subproject to plug into the Gump nightly build system (see http://jakarta.apache.org/builds/gump). It is recommended that each subproject have a smoke-test system that works at least as a basic integration test.
Should be replaced with Avalon project requierements concerning actions plans, release plans, goals, etc. This could be broken down into product plans - but subprojects.
RELATIONSHIP TO OTHER APACHE PROJECTS ===================================== The avalon.apache.org project should work closely with other Apache projects, such as Jakarta and the Apache Server, to avoid redundancy and achieve a coherent architecture among avalon.apache.org and these projects.
This is ok.
Cheers, Steve.
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
Stephen J. McConnell
OSM SARL digital products for a global economy mailto:[EMAIL PROTECTED] http://www.osm.net
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
