Ted Husted wrote:
(Again, sorry about the quoting.)

o·ver·sight

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

<http://dictionary.reference.com/search?q=oversight>

The board expects PMCs to exercise (2) so as to avoid (1). :)

For a PMC this 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)

IMHO, if we were to

* require subprojects to file regular reports with bullets regarding consensus and oversight, and

* subscribe all committers to the PMC list where these reports are filed

then we'd be able to defuse these happenstances before they turn into incidents.

Thanks for directly addressing the oversight issue. This looks like a good plan to me. Can you explain a little more


a) what kinds of "issues" we need to worry most about;
b) what kinds of things should go into the reports; and
c) how subproject committers could share the responsibility of creating the reports.



IMHO, the one and only set of individuals that can provide "watchful care" over a codebase is the set of committers we already have for each subproject.

I agree.

IMHO, each and every committer to a Jakarta subproject has already passed through a gauntlet that proves they are PMC material and entitled to binding votes.

Until I understand fully what the responsibilities are, I am not sure that I agree with this, partly because subproject committers may not have "signed up for" a role beyond the subproject. I agree with your statements about votes being binding, however, so we clearly need to change (or "legalize" ;) something.


All we need to do is complete the process that promotes our committers to PMC members with binding votes, as our original guidelines contemplated, and require subprojects to provide regular status reports. (Just as the board requires our project to report.)

This will solve the problem of committers having binding votes on the codebase that they work on, but it may not be the best solution for the Jakarta PMC. Is it totally out of bounds from the ASF perspective to allow subproject committers to have binding votes for their subprojects without being PMC members? I know that this has been discussed and categorical statements have been made, but I frankly do not get it. If the Jakarta PMC reviews and aggregates all of the subproject reports and includes representation from each of the subprojects, where is the gap in oversight? I don't mean to be argumentative or dense here, but it is very important that we understand clearly what the constraints are (and why these constraints exist, and whether they can be changed as the ASF scales).

As both Roy and Greg have said, if the Jakarta committers truly understood how few rights and privileges they have, they would be demanding both ASF and PMC membership. Few do, so few have.

IIUC, it is mostly a matter of legal protection, not so much "rights and privileges" (unless you view indemnification as a right or privilege). Here again, a little more background / facts would be helpful, as well as some indication of what is "written in stone" and why that is so.


Phil

-Ted.





--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to