Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <avalon-dev@jakarta.apache.org>
Message-ID: <3DED089C.3040608@apache.org>
Date: Tue, 03 Dec 2002 20:40:12 +0100
From: Stephen McConnell <mcconnell@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.0) Gecko/20020530
MIME-Version: 1.0
To: Avalon Developers List <avalon-dev@jakarta.apache.org>
Subject: Re: Kick-starting the Charter process
References: <000901c29afd$6c901320$2100a8c0@acsdom1.citius.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


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:avalon-dev-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
>
>
>
>  
>

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>