forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: Simple committership
Date Sun, 07 Aug 2005 16:44:34 GMT
Addi wrote:
> David Crossley wrote:
> 

...

>>
>> Thorsten Scherler wrote:
>>  
>>
>>> Nicola Ken Barozzi wrote:
>>> <snip valuable background information/>
>>>   
>>> ...snip lots of good discussion...
>>
>>
>>> My reasoning is that we can ensure that this "newbies" can learn the
>>> apache way to it fullest (which is one of the most important point in
>>> the process to become a PMC member) without the "pressure" to be an
>>> official PMC member.

There are *no* additional requirements to being a PMC member than there 
are to being a committer, therefore no additional "pressure". The only 
reason for a PMC is that some things need to be discussed in private. 
These things are few and far between, votes for new committers, reports 
to the Board, security issues etc.

(PMC members have a binding vote, I'll come to that later)

>> It is the mention of "pressure" that i wonder might
>> be the key to your concerns.
>>
>> Apache projects should be fun, no pressure.
>>
>> I hope that you are aware that as a PMC member,
>> or as a developer, you do as much work as you feel
>> like doing. You do not need to participate in every
>> discussion, just because it concerns the PMC.
>> Neither do you need to participate in every vote
>> or in every development issue.
>>  
>>
> Maybe this concept should be added to the new committer doc so it is 
> stated clearly what the expectations of a comitter are.  I am not 
> terribly involved in Forrest at this time, but even I feel guilty when I 
> don't have time to read the mail lists or tinker in Forrest for a 
> while.  Now, that is part of my personality but I suspect that many 
> people who commit themselves to projects like this naturally have a 
> similar feeling of responsibilty (and internal pressure).

+1

Davids words are very important. There are *no* expectations on any 
member of an Apache project. We like people to be involved and we reward 
contributions (meritocracy), but we do not punish a lack of 
contributions. People come and go as their needs change and we adapt to 
those changes.

>>> New committers have to learn
>>> a) "how the Foundation works"
>>> b) "how the Project works"
>>>
>>> One can argue that this should be learned before becoming a committer on
>>> the mls but I see a certain process behind it which takes time (some
>>> times too much).
>>>   
>>
>>
>> Therefore there should not be a "learn first" situation.

I would say there *can't* be a "learn first" approach. When have you 
learnt everything?

> While I agree with Thorsten that these are important things to know, I 
> don't believe it is a focus limited to committers.  I believe it should 
> be something that devs pick up as well and I think that spending a 
> decent amount of time on the dev list and really reading what is going 
> on serves this purpose maybe more than you think.  See below for more.

+1

...


>>> I started to use them here on forrest when getting into the
>>> documentation for lenya. In lenya we are using forrest to create our
>>> documentation and website. We had a custom skin and heaps problems with
>>> maintaining it because forrest is developing very rapid.
>>> The lenya skin was nearly all div based. At the time I started here in
>>> forrest there was an issue about an "all div based" skin. The result is
>>> called "pelt". While I was developing the skin I had "simple
>>> committership" to forrest. I am happy that I could concentrate on
>>> developing the skin and meanwhile learning all the new responsibilities
>>> of a PMC member. After a while I was invited to join the PMC and helping
>>> on the long run of forrest.
>>> I could fully participate in the project as committer. I just did not
>>> had a counting vote but normally forrest consider every concern.   
>>
>>
>> Thankfully we all agreed with your work. It could be
>> disastrous if we didn't agree and you had no binding
>> vote in the matter.
>>  
>>
> Agreed about the vote.  I think if you are trusted to commit you should 
> be trusted to vote.  It only makes sense.  I'll take this space to pipe 
> up with my little shout on the whole concept as well.

Here is the only real difference between a committer and a PMC member, 
PMC members have a *binding* vote. This does not mean other members of 
the community do not have a vote, in fact they do. It is used to gauge 
the general feeling of the community an, on the rare occasions a vote is 
called for it can be a powerful feedback mechanism for the PMC.

Imagine a vote for a release. Only PMC members can actually prevent a 
release with a binding -1 vote. However, if a user casts a (non-binding) 
-1 along with a bug report it is the job of the PMC to examine this and, 
if necessary make the vote a binding one by supporting it.

So why have binding and non-binding votes then? Very occasional someone 
comes to an Open Source project with the intention of causing trouble. 
We deal with these people by having mechanisms to "cut them out". That 
is, their vote is non-binding. As soon as someone shows they are 
reasonable, cooperative people we will listen to their view, binding or 
otherwise.

In other words, I totally agree with Addi, if you are trusted to commit 
you should be trusted to vote.

> it seems to me 
> that they have looked at that person's work and attitude for a certain 
> amount of time and decided that they trust that person enough to let 
> them tinker directly with the code.  That is a huge responsibility from 
> my perspective and to allow that but not really allow them into the 
> project itself strikes me as a little weird.   Sort of giving them a
> direct hand in the DoC part of CoPDoC, but not letting them fully into 
> the CoP part.

+1 Very well said.

> If the concern for an incubation place is not code, but project  
> management, then why not consider the opposite of the "incubator" being 
> proposed and create a PMC incubator where potential committers can be 
> given more direct involvement in the project management/infrastructure 
> side of things without the right to commit yet?  I don't know how/if 
> that could work because obviously I'm not in the PMC and honestly I'm 
> not sure what all that entails.

Actually, I think the PMC is its own incubator. I'm not sure that we 
need some "school" for PMC members.

> I am also not entirely sure that I think a distinct incubator is a good 
> idea altogether.  It seems to me, that if used properly by the PMC, the 
> dev list is already a good place for incubation and assessment of 
> potential committers.  A lot is in here if you pay attention.  Perhaps 
> taking the mentor role more directly on the list (like when Ross put on 
> his mentor hat with Anil) would serve our purposes.

I have a background in training and education, such a "mentor" role 
comes naturally to me. In the case of the GSoC I have a responsibility 
to Anil to act as his mentor. Before GSoC started the Forrest PMC 
requested that I conduct all *relevant* mentoring onlist because it is 
of value to the community as a whole.

Perhaps the PMC Incubator that Thorsten feels there is a need for should 
actually be more effort on the part of the community (not just PMC 
members) to ensure that we are all aware of the responsibilities of a 
committer to the community.

For example, this thread started on the PMC list but was moved here at 
the insistence of some of our more experienced PMC members, who pointed 
out that this is a community issue not a private issue. Without this 
positive mentoring from experienced PMC members we would never have 
heard Addi's excellent contribution to the thread.

(I call it excellent because it is well reasoned and community focused. 
It is a coincidence that I agree with his views. I am sure others will 
agree with Thorstens proposal so please don't stay quiet, read Addi's 
words and recognise that the focus is on community contributions - we 
need you contributions to make this thread even more valuable - 
especially if you stand on the other "side" of the debate)

---

One last point not raise yet. One of the dangers of giving early commit 
access is that you can end up with lots of code that is not supported. 
This is OK if it goes into the whiteboard where we can retire it easily. 
But full commit access means people are free to add stuff to trunk, 
often too early. The ANT project had a big problem with this and, as a 
result, they made it harder to become a committer.

Ross


Mime
View raw message