[PROPOSAL] As it ever were

I've incorporated many of the suggestions made on the list and prepared
another draft for community review.


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


When the board creates a project, it passes a resolution. Resolutions
regarding Jakarta

have been passed here:


and here


The board's authority to create Projects and PMCs stems from section 6.3
of the ASF bylaws:


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


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.


As used here, the term oversight follows its dictionary definition:


   1. An unintentional omission or mistake.
   2. Watchful care or management; supervision


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


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


(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


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


* 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

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

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.


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]

Reply via email to