I've incorporated many of the suggestions made on the list and prepared another draft for community review.
-ISSUE-
The ASF Board has indicated that it does not believe that the Jakarta PMC, in its present form, is capable of providing oversight of all the subprojects under its purview.
The role of the Jakarta PMC is two-fold:
* The PMC is responsible the active management of the project
* The PMC provides oversight for the project
-Management-
When the board creates a project, it passes a resolution. Resolutions regarding Jakarta
have been passed here:
<http://tinyurl.com/3x6rs>
and here
<http://tinyurl.com/2zkdb>
The board's authority to create Projects and PMCs stems from section 6.3 of the ASF bylaws:
<http://apache.org/foundation/bylaws.html>
From a legal perspective, the PMC is the only entity that the board recognizes as being responsible for the management of a project. Only committee members have "binding" votes. Only committee members would be indemnified by the ASF in the event of a law suit
<http://tinyurl.com/3eq9c>.
In fact, most of the rights and responsibilities we at Jakarta have ascribed to "committers" in fact belong only to "PMC members".
Originally, we envisioned the PMC to be a steering committee <http://tinyurl.com/2o2v5>, responsible for the "strategic direction and success of the Jakarta Project". But this is *not* the case. The PMC doesn't just "set the agenda", it is the body that *actively manages* the project. The PMC has the rights and responsibilities that most of us would ascribe to the subproject committers.
-Oversight-
As used here, the term oversight follows its dictionary definition:
o·ver·sight
1. An unintentional omission or mistake. 2. Watchful care or management; supervision
<http://tinyurl.com/2eyvg>
The board expects PMCs to exercise (2) so as to avoid (1). :) All good managers must provide oversight, and a PMC is no exception.
For a PMC, oversight boils down to issues of "committer consensus" and "intellectual property". In the past, there have been incidents at Jakarta on both counts that lead to suspension of access, for both individuals and modules (on different occasions).
Jakarta now manages 21 subprojects (with Pluto on the way), and another 40+ components in the Commons and Commons Sandbox, The board's question is "How can the Jakarta PMC, as it is now constituted, possibly provide oversight for all of this code?".
-CURRENT APPROACH-
The PMC has decided to expand its membership to an indefinite number and is actively soliciting nominations of qualified committers. So far, the PMC has rejected the idea of nominating all the committers or any committers who volunteers. Each new nominee must be voted in by the PMC (or not).
At this time, no other changes are on the agenda.
For additional background, see
* <http://tinyurl.com/226pt>
* <http://tinyurl.com/2vclu>
and the archives for the general list
* <http://tinyurl.com/2gq7d> or <http://tinyurl.com/3cw3e>.
-PROPOSED CHANGES-
(1) Require all Jakarta products (or subprojects) to file regular reports with the PMC
(2) Promote all Jakarta Committers to the Jakarta PMC, nunc pro tunc
-PROPOSITION (1)-
* Require all Jakarta products (or subprojects) to file regular reports with the PMC.
A key element of oversight is vigilance. One way to achieve vigilance is regular reporting. Just as the board requires the vice president of a project to file regular reports, the PMC should require each subproject to file a similar report.
Here is a format often used by projects reporting to the board:
----
* What code releases have been made?
* Legal issues:
* Cross-project issues:
* Any problems with committers, members, etc?
* Plans and expectations for the next period?
----
Since the PMC cannot delegate its responsibilities, the report would have to be prepared by a PMC member, ideally one directly involved with subproject. (A likely suspect being the DEV list moderator.)
Failure to report would have to be considered a serious matter, possibly leading to blocking CVS access. Accordingly, each subproject would want to be very, very sure these reports are in fact being filed.
-PROPOSITION (2)-
* Promote all Jakarta Committers to the Jakarta PMC, nunc pro tunc
The original Jakarta guidelines state that committers have the binding votes and make the decisions regarding the codebase. We now know that, from an ASF perspective, committers have write-access to the codebase, but the PMC members have binding votes and make the decisions.
The idea of committers with non-binding votes has been broached many times over the years. Each time, the consensus has been that we vote most with our commits, and that every volunteer committing to a Jakarta codebase is entitled to a binding vote (and veto).
Whenever we selected any committer for any Jakarta codebase, we did so with the expectation that they would be responsible for its "active management". We were in fact not merely electing "committers" but "PMC members".
It was the community's expectation that these individuals actively manage our codebases, and so these are the individuals who should be the PMC members.
"Nunc pro tunc" is a legal term meaning "now for then" <http://tinyurl.com/38dlj> or "retroactively". Applied here, it means we are saying that the active committers are members of the Jakarta PMC and have always been members of the Jakarta PMC. It was our intention for them to be PMC members, with all the associated rights and responsibilities, we simply didn't understand the shade of meaning.
Work regarding a specific subproject can continue to occur on that subproject's DEV list. PMC members (aka committers) following that list can vote on its releases and other day-to-day affairs. So long as the minimum quorum is met, the vote is legal and binding.
Under proposition (1), the significant events occurring for each subproject would be reported to the PMC list, for the review of the PMC at-large.
PMC membership is voluntary. Anyone can resign from the PMC at any time. If a volunteer would like to be a committer, but not a PMC member, then each subproject can then decide whether to support separate committer and PMC member roles or not.
-STATUS-
Note that this is a proposal only, not a vote. If this proposal, or a subsequent draft, receives informal majority approval on the general list, an alert will be posted on all the DEV lists, to be sure that all active subproject committers are aware of this discussion.
If it appears that there is a consensus as to proposition (1) or (2), a vote can be called on the general list, or the chair can take direct action, as appropriate.
####
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
