forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: [DRAFT] Forrest Project Guidelines
Date Thu, 01 Jul 2004 14:06:01 GMT
Dave Brondsema wrote:
> Moreover, if we did have non-voting committers to work on a certain
> feature, we need to define another process for "graduation" to voting
> committership.  I don't like having so many levels of stratification, it
> makes the community feel less open.

I understand.

Let me try to explain again what I'm trying to solve instead of 
discussing on the solution :-)

Let's say that all committers can VOTE. This sets a high bar on 
committership, as one needs to demonstrate that he can work well 
together. Some project set this as high as 6 months of continuous and 
good patches. The fact is that a voter can veto changes (even if they 
have to be explained), and this can have a big impact on the community.

In this way, the distinction between PMC members and committers is moot, 
as all committers become PMC members. If they can vote, then they are 
steering the project, so they are de facto part of the PMC and must take 

Because of this, we cannot have people helping out on a certain feature 
for a limited set of time or for a particular part of the code. For 
example, let's say that we put a XYZ skin in Forrest and that a certian 
person wants to maintain it. Shall we make him part of the PMC? I say 
no. Shall we have him send in patches continually, just to have that 
skin up to date? Would not partial commit access be a solution?

Note that partial commit access is not a step to PMC membership. It's an 
alternative for some cases.

Another use case is that we wouldn't have Lenya or Cocoon committers 
with access to the CVS, as they would have to be PMC members, which has 
to be voted based on merit. How would we treat this?

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message