Dormant guidelines proposal?

[Curt Arnold <ca...@apache.org>]

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.

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

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, 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.  There would also be no private forum to discuss any  
sensitive issues since only the PMC has 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.

If anyone wants to contribute advice or opinions on the LS bylaws and  
proposed modifications, there should be a discussion starting in  
general@logging.apache.org starting in the next few days.

p.s.: s/immediate tactic/immediate tacit/

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org

Re: Dormant guidelines proposal?

[robert burrell donkin <ro...@blueyonder.co.uk>]

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: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org