avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Kick-starting the Charter process
Date Tue, 03 Dec 2002 19:40:12 GMT

Berin Loritsch wrote:

>At this location, you can see the current XML Project charter:
>I propose that we take that charter and adapt it to ours since it
>is easier to start from something already accepted ;P .


 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 

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

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


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

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.

A contribnuter should intervi8ne though participation as an elected member.
This should be dropped.

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

>Each subproject has a set of committers. 
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.

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

>The avalon.apache.org project site must provide the following:
>Bug Database -- This is a system for tracking bugs and feature
>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

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.
Recipe for fragmentation.

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

There are much stronger guidelines that this comming out of the 
incubator project - the above is insufficient.

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

>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

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

digital products for a global economy

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

View raw message