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]
