On Fri, 2005-07-01 at 01:55 -0500, Curt Arnold wrote:
There has been some discussion about modifying the Logging Services
project bylaws (http://logging.apache.org/site/bylaws.html) to
address some concerns particular to the project. I was researching
the Jakarta guidelines and stumbled across http://jakarta.apache.org/
site/proposal.html. It is referenced at the bottom of http://
jakarta.apache.org/site/guidelines.html as a working proposal, but it
does not appear from the SVN log to have any activity for over two
years.
i thought that it'd been removed during spring cleaning earlier this
way. anyone remember any reasons why it was retained?
Was there a resolution on the proposal? If so or if has been
abandoned, then it might be good to pull it and the link from the
site or at least update the status. Has the activity moved elsewhere
or is it just sleeping?
it's a bit of a long story. the only real records exist on the (private)
archives of the jakarta pmc mailing list.
IIRC this represents the earliest stage of the long road towards reform.
the consensus was that the problem wasn't the guidelines but the basic
bylaws. once these were fixed, arguing about the guidelines became
moot...
If either was going to be considered as a
starting point for a rework of the LS bylaws, would you recommend the
proposal or the accepted guidelines?
i'm not sure whether it'd be a good idea to start from either. i'd start
from the bylaws and from henri's wiki pages.
it seems to me that the guidelines have really turned into a directory
page for general information. a lot of the information linked to
probably belongs at the foundation level (though would need editing).
I haven't had a chance to attempt to compare and contrast the current
and proposed guidelines, but the proposal's one page format left a
better impression since you can see everything at one glance.
the proposals are a good document in a cool format but didn't solve the
real problems
One of significant differences between our current bylaws and either
of the proposal or existing guidelines is that the PMC is tasked with
electing new committers. There is a desire to move that decision
towards the sub-project,
i recommend asking this question again on community.
the model used by jakarta is believed (by many seniors figures from
other projects) to be both unusual (within apache) and far from best
practise. some feel that too much delegation to sub-projects may be to
the detriment of the community spirit at project level. others that it
creates problems with oversight. IMHO the model works ok for us here but
i'd hesitate to recommend it to other projects.
but I'm concerned that without any role for
the PMC and no private medium for the vote, that there isn't a clean
way for the PMC to address a potential disruptive or legally
entangling committer candidate except to accept the sub-project vote
and for the PMC to attempt to revoke his committer rights requiring a
full consensus.
AIUI no project is actually entitled to abdicate responsibility for
oversight. IMHO the right way to proceed (if this happened here at
jakarta) would be to -1 the result posted to the pmc list and so veto
the action (lazy consensus). this should force a vote on the pmc list.
one of the problems with holding votes for committers on public lists is
that there is no way that the individual in question could be kept from
the knowledge of their rejection.
There would also be no private forum to discuss any
sensitive issues since only the PMC has a private list.
this is a problem that we have here at jakarta. current practise is that
there is usually a certain amount of private chat (but it would be
better if this happened on a private list).
For the LS bylaws, I was considering suggesting a two-phase vote, lazy
consensus
at the sub-project and then lazy approval followed by lazy consensus
at the PMC. Considering the damage a rogue committer could do,
having the PMC with some means of intervening without invoking the
nuclear option would seem to be warranted.
the pmc is charged with oversight. whatever system is agreed must
provide that.
- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
