avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@citi-us.com>
Subject RE: Kick-starting the Charter process
Date Tue, 03 Dec 2002 20:05:07 GMT
> From: Stephen McConnell [mailto:mcconnell@apache.org]
> 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.

We need a starting point, and this is the only example of a PMC
charter I could find.  That's all it is for.

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

Ok.  You're words?

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

Services are components, so they are included.  However your point is

> Sounds like a mission for commons - needs to be replaced with
> a concrete
> mission that defines Avalon objectives.

It's a starting point.  I took a stab, what's yours?

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

Copy and paste.  All I did was make it accurate as regards us.

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

Copy and paste.  what is your wording?

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

Again, copy and paste.  What is your preferred wording?

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

This is a copy from the wording at XML.  Remember I didn't do alot of
fussing with it.

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

Propose something different.  Don't say no.  Counter-propose.

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

I want it to be VERY difficult to remove someone.  As a result, I
personally would stick with UNANIMOUS vote to remove someone.

Points are taken in regards to PMC not doing their job, but bear in
mind that there are a few people (not many) who are so hard-headed
and bent on undermining something that even if the PMC was doing
their job, the only solution for the COMMUNITY's sake is to remove
that person.  We have yet to run into one of those people (Peter does
not qualify according to the information I have), but we must
legally protect ourselves by stating the rules in which someone
can be removed.

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

Not all Avalon committers are on the PMC.  If we as the PMC
introduce something that an Avalon committer is uneasy with,
unknown to him until the deed is done, the Avalon committer
needs an outlet to let his voice be heard.

> >===========
> >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.
> >
> -1
> A recepie for fragmentation.

If we have no sub-projects, there is no issue here.

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

Ok.  Propose something.

> Don't think this contributors text is needed because iut does
> not seem
> to impact the procedures.

We need to document the procedures for becoming a Committer.

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

Again, if there is only one project and no subprojects, this
is a non-issue.

> >=========
> >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
> >committers.
> >
> There are much stronger guidelines that this comming out of the
> incubator project - the above is insufficient.

Where are they?  Provide some details.

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

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