Simple committership

[Nicola Ken Barozzi <ni...@apache.org>]

Over time, some seem to recurringly ask that Forrest creates a "simple
committer" role used as a step between being a developer and a PMC member.

Here is an explanation of what I think I have learned in this respect.
Other people might have different views and recollections.

AFAIK Apache was not made to have the "simple committer" role. Since the
beginning, there were two roles: Apache members and PMC members, and PMC
members were to become relatively soon also Apache members. The
reasoning is that if someone can commit, he is part of the group that
trusts him in committing, and thus has the same voting privileges.

But then Jakarta came to life, and real life started changing the way of
doing things that had started in HTTPD land.

In essence, Jakarta became a small Apache, creating sub-roles where the
PMC members were like Apache members, and committers were like PMC
members. In Jakarta it's usual that committers can vote, but in fact
their vote is not legally valid, and they *cannot* release code without
a PMC vote. For some time, this wasn't even known by most Jakarta
committers AFAIK.
This created a big disconnect between the Board of Directors and
Jakarta, and most projects were having little or no active oversight,
and the number of Jakarta committers that was an Apache member was
extremely low.

As a result, Apache members started a mailing list for discussing
reorganization of Apache (reorg@apache.org IIRC, now closed), and the
conclusion was to push sub-projects to top level, making them resurface
and deal with the board directly.
The process is still continuing to the present day, as Tomcat has just
gone top-level, and it seems to be working. Recently there have been
also discussions that there are too many PMC members that are not Apache
members, so that will probably have some impact.

If we want to include "simple committership" as a role, I would like to
hear someone explain how simple committership will solve more
issues than it may cause, especially given the above. In particular, I
would like to have some real-life examples that show how simple
committership would have been useful.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)
---------------------------------------------------------------------

Re: Simple committership

[Nicola Ken Barozzi <ni...@apache.org>]

Ross Gardler wrote:
...
> 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.

A personal note.

I have done some some contributions to Ant, like the <xmlproperty> task,
the <import> task, and other bugfixes. They never invited me in. Why?

I don't know, but I know that I have never sent in unit tests, and not
always documentation. Furthermore I started the highly controversial
Centipede project, and have been stupidly aggressive myself in proposing
it and in attacking Maven.

To be honest, I really think that they did the right thing. My
dedication to Ant has always been of an avid user, and not of a core
developer, and I never really felt I wanted to become an Ant committer.
I don't know how, but they managed to understand that, and I think that
they did the right thing for Ant.

Probably, if they would have invited me in early, I would have given
them a lot of problems, so I can see the value in a higher barrier to
entry.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)
---------------------------------------------------------------------

Re: Simple committership

[Ross Gardler <rg...@apache.org>]

David Crossley wrote:
> Ross Gardler wrote:
> 
>>Addi wrote:
>>
>>>David Crossley wrote:
>>>
>>>>Thorsten Scherler 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". ...
> 
> 
> (I need to clarify Ross' statements, so i split this
> paragraph apart. Also it is good to build upon this,
> to ensure that everyone who cares can know our background.)
> 
> The PMC as a whole does have additional responsibilities:
> http://forrest.apache.org/guidelines.html#roles

Yes, bad wording on my part. Thanks for the clarification.

What I meant to say was that being a PMC member does not bring any 
additional __demands on the time of the member__. However as David 
points out, there are additional responsibilities which will sometimes 
(not always) see a little extra time being committed to the project.

The important thing is there is no additional *expectation*, just more 
*opportunity* for earning karma through the meritocracy system.

Ross

Re: Simple committership

[David Crossley <cr...@apache.org>]

Ross Gardler wrote:
> Addi wrote:
> >David Crossley wrote:
> >>Thorsten Scherler 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". ...

(I need to clarify Ross' statements, so i split this
paragraph apart. Also it is good to build upon this,
to ensure that everyone who cares can know our background.)

The PMC as a whole does have additional responsibilities:
http://forrest.apache.org/guidelines.html#roles

> The only 
> reason for a PMC is that some things need to be discussed in private. 

That is creating confusion between "the PMC" and the
"private pmc mailing list". Ross is talking about the
reasons for the private mailing list. The PMC does
as much business as possible on the dev mailing list.

The main reason for a PMC is the Apache Software Foundation,
being a corporation, needs to meet statutory requirements
and also have a mechanism for oversight of communities
and software distributions. The board establishes various
committees to have such management oversight, with each
PMC chair having primary responsibility. I don't dare to
explain further. We carefully evolved this document to
say it as well as possible:
http://www.apache.org/foundation/how-it-works.html#structure

Back to the reasons for a private discussion list:

> These things are few and far between, votes for new committers, reports 
> to the Board, security issues etc.

Mainly for a place to discuss private things when
necessary, e.g. personal and security issues.
At Apache Forrest we decided to also conduct votes for
new PMC members/committers in private so that we can
speak frankly and any one of us can say, "No we need
to wait a while for this person, for these reasons".
We feel that such stuff is not good to do in public.
Other ASF projects do it differently.

You mention "Board report" as being a private issue.
Not really. The quarterly board report is entirely
my responsibility as the PMC chair. I don't need
to discuss it with anyone beforehand. However i do
seek the input of the Forrest PMC, as that is the way
that i do things. Until now i have been doing that on
the private PMC mailing list. I reckon that will change.

Of course the board minutes become public anyway:
http://www.apache.org/foundation/board/calendar.html
(Forrest reports start May 2004, then Aug, Nov, Feb.)

> (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

You are so insightful. That is spot on.
Committed people create their own internal pressure
by virtue of their dedication. Being able to manage
one's personal pressure is life's art.

This is the perfect point to ask everyone to read
these two important messages about what it means
to be committed and then managing one's energy and
dealing with volunteeritis.
http://www.apache.org/dev/committers.html#volunteer
As usual, Roy's messages cut straight to the point
and there is no need for any reply.

> 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
> 
[ snip a stack of good stuff ]
> 
> 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.

You are absolutely right Addison. The project's public
mailing lists are the real community. The dev list is
the place where such "incubation" should happen.

We already do such mentoring as individuals (no need
for specific hats).

We need to do more such reminders and discussion
about the ASF community ways. You will notice that
my technique is to deliberately over-describe when
people ask a question and i make an example out of
the situation. The receiver needs to know that the
target is really the wider community.

Sometimes i manage to go the extra step and re-use
those words in documentation, e.g. our project guidelines
and where possible raise topics to the top-level
documentation at w.a.o/dev/ and /foundation/
Hint: Anyone can contribute: www.apache.org/dev/infra-site.html

These topics seem to need to be discussed over and over,
e.g. new people need the background. The repetiton
does take time to read for the old hands, but we learn
something new each time and the way evolves. Oftentimes
we should be able to refer to documentation.

Ross continued:
>
> 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)

Hear, hear. We don't intend to squash anyone's concerns.
We need more talking to get to the core of this thread's topic.
Identifying the perceived pressure situation is one step closer.

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

That is another key observation. Thanks.

David

Re: Simple committership

[Ross Gardler <rg...@apache.org>]

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

Re: Simple committership

[Addi <ad...@rocktreesky.com>]

David Crossley wrote:

>Thanks so much for taking the time to reply to
>this important topic. A big effort, i can see.
>
>I am going to reply to this in bits and pieces
>i.e. not all at once tonight.
>
>Please would other members of our community
>(everyone, not just PMC members) also add their view.
>  
>
OK, well, I don't speak much but I do think this is an important topic 
and my work pulling the committer doc together has got my mind wrapped 
around this these days anyway, so here goes.

>More below ...
>
>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.
>>    
>>
>
>But it is a never-ending process. We are all continually
>learning. And most important, that "way" is evolving.
>So for "newbies" (all of us actually), the only way
>is to start walking. There should not be a fence across
>the path which causes us to wait until deemed capable.
>
>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).

>The more committers we have, the more pairs of eyes
>are watching the svn diff emails. But every committer
>cannot be expected to notice every problem. Unlax, doc.
>Let the averages work for us. As long as each of us
>do make some little effort, then the whole will work.
>
>  
>
>>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.
>  
>
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.

>... snip more stuff ...
>  
>
>>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.

I see the value in where Thorsten is coming from but it is interesting 
that the focus is on allowing commits but not allowing PMC activity.  If 
the PMC is going to invite someone in as a committer, 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. 

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. 

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.  Basically in the 
end noone gets a sense of how a place runs until they step through the 
front door.  The more transparent you make the entrance, by exposing and 
explaining as much as you can on the list, the easier it may be, but it 
will always be a learn as you go thing.

That's my little shout from the peanut gallery.
- Addi

>  
>
>>One thing that helped me is that the PMC normally watch the committs of
>>new committer more careful to ensure that e.g. all legal issues are
>>meet. 
>>
>>PMC membersnot only have to help new committers to learn the duty of a
>>PMC member in the specific project (b) but also like the incubator teach
>>the values of an ASF project and its duties (a). There have been a
>>thread on all PMC lists about the duties (around 10 points) of a PMC
>>member by Davanum Srinivas. 
>>
>>I was given committership to apply my own patches for cocoon, forrest
>>and xml. That leveraged this project (faster process) because other PMC
>>members do not had to do that. Then especially David taught me as well
>>the PMC duties and I became a PMC member. 
>>    
>>
>
>The main reason that there was a delay with you becoming
>a PMC member, was because we had to spend many months
>discussing our project guidelines before we could get
>any new people as PMC members/committers.
>
>Pulling in one of my comments from earlier in this thread:
>  
>
>>>When we look for new committers, we need to see a few
>>>qualities. They should be helping other users and
>>>developers, able to work co-operatively, be a mentor,
>>>and be repectful of others opinions. Essentially be      
>>>committed people who understand the Apache way.
>>>      
>>>
>
>Rather than "understand", i meant: show that they
>have at least some clues and have the potential
>to learn the way. Not expected to know it all yet.
>
>Some people have no idea how to behave in a co-operative
>manner and only have respect for themselves. We do not
>encourage those types.
>
>  
>
>>The important point is that new committer are generally
>>overwhelmed by the information and infrastructure of the project and the
>>ASF. Some learn better step by step understanding what is ASF all about
>>and what a PMC member have to do (I consider myself as such a
>>somebody). 
>>
>>I was lucky and made my experience in the incubator *and* here but the
>>committers we vote in normally do not have this "incubator" experience
>>which I consider most valuable. 
>>    
>>
>
>Take me as a different case. Cocoon was my first real opensource
>project. I had no Incubator to go through. The Cocoon people
>were nice and helpful all the way. But still i had to figure
>most of it out for myself, before and after becoming a committer.
>That is still the case being an ASF member. I still stumble
>in the dark. It is ongoing, and only the committed remain.
>
>  
>
>>>In essence, Jakarta became a small Apache, creating sub-roles where
>>>the
>>>PMC members were like Apache members, and committers were like PMC
>>>members. In Jakarta it's usual that committers vote, but in fact their
>>>vote is not legally valid, and they *cannot* release code without a
>>>PMC
>>>vote.
>>>This also created a big disconnect between the Board of Directors and
>>>Jakarta, and most projects were having little or no oversight, and the
>>>number of Jakarta committers that was an Apache member was extremely
>>>low.
>>>      
>>>
>>The point you are maybe up to is that we can create a closed group that
>>new committer are not able to enter. We limit the PMC membership to a
>>certain group of people for whatever particular reason.
>>
>>The downside is that committers cannot be responsible for the projects
>>because they are not in the "management" PMC. That will slow down the
>>progress of this project(s) because it slow down their processes.
>>
>>I guess it happened because many projects emerged from Jarkata (e.g.
>>tomcat, struts,...) and people felt better in having a good working team
>>then to better leverage their pmc duties in teaching new committer this
>>duties. 
>>
>>One sentence of [2] seems very interesting at this point:
>>"Section 6.3. Project Management Committees.
>>...
>>Each Project Management Committee shall be responsible for the active
>>management of one or more projects identified by resolution of the Board
>>of Directors which may include, without limitation, the creation or
>>maintenance of "open-source" software for distribution to the public at
>>no charge."
>>
>>Now *one or more projects* means that is thought of leveraging not only
>>e.g. jarkata but all sub projects that may emerge. That needs a good
>>working PMC team that can trust each other (most important on legal
>>issues etc.). 
>>    
>>
>
>Sorry i don't understand what you mean about Jakarta.
>
>The "one or more" in the ASF bylaws was to allow scope.
>However the umbrella project concept seems to be
>discouraged now. One PMC, and many committers that are
>not on that PMC, just does not work.
>
>  
>
>>Why are we not adding to the committer role the 'PMC-incubation' label
>>and apply similar rules (we have in the incubator for exiting the
>>incubator cp [3]) to become a PMC member. That will as well make sure
>>that new members will *definitely* enter after "incubation" and overcome
>>the jarkata phenomenon.
>>    
>>
>
>I do not see how we could make such "exit rules".
>It is okay to make rules for projects, but rules
>for measuring people is fraught with difficulty.
>
>  
>
>>In another thread you wrote about becoming PMC/committer:
>>    
>>
>>>"...But we should not try to measure this with an absolute metric:
>>>merit does not earn membership, it earns trust of others members. If
>>>other members trust him based on the contributions, then IMHO there is
>>>all there is to it."
>>>      
>>>
>>I develop trust with time. ...but I can trust somebody to make chances
>>(contributions) and I can trust someone making decisions. 
>>
>>That is a different level of trust we are talking.
>>    
>>
>
>I will need to ponder that before answering.
>
>-David
>
>  
>
>>I consider a clean
>>process of learning about the ASF as better. I started in incubator
>>(with lenya) to learn about the ASF and I still learn everyday.
>>
>>Going from dev to committer and after "PMC-incubation" into the PMC is
>>IMO the best way to develop trust in someone. I think it is better as
>>limited committership or directly enter in the PMC (which normally takes
>>a good amount of time).
>>
>>I hope this "real life" use case shows, that there are persons that will
>>welcome a guided process that as well contain a simple committership
>>"PMC-incubation" role.
>>
>>[1] http://incubator.apache.org/
>>[2] http://www.apache.org/foundation/bylaws.html
>>[3]
>>http://incubator.apache.org/incubation/Incubation_Policy.html#Exitting
>>+the+Incubator
>>-- 
>>thorsten
>>
>>"Together we stand, divided we fall!" 
>>Hey you (Pink Floyd)
>>    
>>
>
>
>
>  
>

Re: Simple committership

[David Crossley <cr...@apache.org>]

Thanks so much for taking the time to reply to
this important topic. A big effort, i can see.

I am going to reply to this in bits and pieces
i.e. not all at once tonight.

Please would other members of our community
(everyone, not just PMC members) also add their view.

More below ...

Thorsten Scherler wrote:
> Nicola Ken Barozzi wrote:
> <snip valuable background information/>
> > 
> > If we want to include "simple committership" as a role, I would like to
> > hear someone explain how simple committership will solve more
> > issues than it may cause, especially given the above. In particular, I
> > would like to have some real-life examples that show how simple
> > committership would have been useful.
> 
> Like David and Nicola stated the Forrest project normally votes all
> committer directly into the PMC as well. I personally see special
> occasions (besides GSoC) where I would like to see a "simple
> committership" or like I would call it "PMC incubation".

Here you say "special occasions". We do already have
the capability to add people as committers which are
not being PMC members also. However you are actually
talking below about this being the normal course.

> It should
> follow the basic idea of the Apache Incubator [1] which is for new
> projects at Apache.
>
> "A large part of the Incubator's effort will be devoted to providing
> documentation on how the Foundation works, and how to get things done
> within its framework. As a consequence, it is expected that the
> Incubator will also become a reference for new contributors to any of
> the Apache projects."

Unfortunately not much of that documentation
has arisen. People seem to rush onwards and forget.
People coming afterward need to learn all over again.

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

But it is a never-ending process. We are all continually
learning. And most important, that "way" is evolving.
So for "newbies" (all of us actually), the only way
is to start walking. There should not be a fence across
the path which causes us to wait until deemed capable.

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.

The more committers we have, the more pairs of eyes
are watching the svn diff emails. But every committer
cannot be expected to notice every problem. Unlax, doc.
Let the averages work for us. As long as each of us
do make some little effort, then the whole will work.

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

> Now it was asked for a "real-life example".
> 
> That could be myself. ;-)
> 
> I have been a Wyona CMS committer before it became an official Apache
> Incubator project. The company Wyona donated then the code base to the
> ASF as cocoon subproject in incubation called Apache Lenya. I had
> "general" experience in how a open source project and community is
> working but that have been quite different from the ASF way that I had
> to learn. 
> 
> Within the one year where Apache Lenya has been in the incubator I
> learned the basics (IMO learning) on "how the Foundation works" (a)
> (never stops). As Apache Lenya committer we were given not only
> committing rights to lenya but as well to cocoon, forrest and xml.

That was not the usual way. Normally one only becomes
a committer for the specific project that you are directly
involved with.

This thing about Cocoon committers being given commit
access to Forrest, happened a long time ago, before Forrest
was a project of its own. We have already said that the
situation needs review, now that we are a top-level project.

It was an experiment to attempt to boost the Forrest base.
At one stage the project was floundering with not enough
developers. Interesting that it did not attract many people
from the Cocoon community.

I am sure glad that you are here, but i reckon that you
would be here even if we did not have that arrangement.
You would have contributed patches, and we would have
noticed your commitment and made you a PMC member.

Also it would have been only for "xml-commons", not for
every project at xml.apache.org e.g. Xerces.

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

> One thing that helped me is that the PMC normally watch the committs of
> new committer more careful to ensure that e.g. all legal issues are
> meet. 
> 
> PMC membersnot only have to help new committers to learn the duty of a
> PMC member in the specific project (b) but also like the incubator teach
> the values of an ASF project and its duties (a). There have been a
> thread on all PMC lists about the duties (around 10 points) of a PMC
> member by Davanum Srinivas. 
> 
> I was given committership to apply my own patches for cocoon, forrest
> and xml. That leveraged this project (faster process) because other PMC
> members do not had to do that. Then especially David taught me as well
> the PMC duties and I became a PMC member. 

The main reason that there was a delay with you becoming
a PMC member, was because we had to spend many months
discussing our project guidelines before we could get
any new people as PMC members/committers.

Pulling in one of my comments from earlier in this thread:
>>
>> When we look for new committers, we need to see a few
>> qualities. They should be helping other users and
>> developers, able to work co-operatively, be a mentor,
>> and be repectful of others opinions. Essentially be      
>> committed people who understand the Apache way.

Rather than "understand", i meant: show that they
have at least some clues and have the potential
to learn the way. Not expected to know it all yet.

Some people have no idea how to behave in a co-operative
manner and only have respect for themselves. We do not
encourage those types.

> The important point is that new committer are generally
> overwhelmed by the information and infrastructure of the project and the
> ASF. Some learn better step by step understanding what is ASF all about
> and what a PMC member have to do (I consider myself as such a
> somebody). 
> 
> I was lucky and made my experience in the incubator *and* here but the
> committers we vote in normally do not have this "incubator" experience
> which I consider most valuable. 

Take me as a different case. Cocoon was my first real opensource
project. I had no Incubator to go through. The Cocoon people
were nice and helpful all the way. But still i had to figure
most of it out for myself, before and after becoming a committer.
That is still the case being an ASF member. I still stumble
in the dark. It is ongoing, and only the committed remain.

> > In essence, Jakarta became a small Apache, creating sub-roles where
> > the
> > PMC members were like Apache members, and committers were like PMC
> > members. In Jakarta it's usual that committers vote, but in fact their
> > vote is not legally valid, and they *cannot* release code without a
> > PMC
> > vote.
> > This also created a big disconnect between the Board of Directors and
> > Jakarta, and most projects were having little or no oversight, and the
> > number of Jakarta committers that was an Apache member was extremely
> > low.
> 
> The point you are maybe up to is that we can create a closed group that
> new committer are not able to enter. We limit the PMC membership to a
> certain group of people for whatever particular reason.
> 
> The downside is that committers cannot be responsible for the projects
> because they are not in the "management" PMC. That will slow down the
> progress of this project(s) because it slow down their processes.
> 
> I guess it happened because many projects emerged from Jarkata (e.g.
> tomcat, struts,...) and people felt better in having a good working team
> then to better leverage their pmc duties in teaching new committer this
> duties. 
> 
> One sentence of [2] seems very interesting at this point:
> "Section 6.3. Project Management Committees.
> ...
> Each Project Management Committee shall be responsible for the active
> management of one or more projects identified by resolution of the Board
> of Directors which may include, without limitation, the creation or
> maintenance of "open-source" software for distribution to the public at
> no charge."
> 
> Now *one or more projects* means that is thought of leveraging not only
> e.g. jarkata but all sub projects that may emerge. That needs a good
> working PMC team that can trust each other (most important on legal
> issues etc.). 

Sorry i don't understand what you mean about Jakarta.

The "one or more" in the ASF bylaws was to allow scope.
However the umbrella project concept seems to be
discouraged now. One PMC, and many committers that are
not on that PMC, just does not work.

> Why are we not adding to the committer role the 'PMC-incubation' label
> and apply similar rules (we have in the incubator for exiting the
> incubator cp [3]) to become a PMC member. That will as well make sure
> that new members will *definitely* enter after "incubation" and overcome
> the jarkata phenomenon.

I do not see how we could make such "exit rules".
It is okay to make rules for projects, but rules
for measuring people is fraught with difficulty.

> In another thread you wrote about becoming PMC/committer:
> > "...But we should not try to measure this with an absolute metric:
> > merit does not earn membership, it earns trust of others members. If
> > other members trust him based on the contributions, then IMHO there is
> > all there is to it."
> 
> I develop trust with time. ...but I can trust somebody to make chances
> (contributions) and I can trust someone making decisions. 
> 
> That is a different level of trust we are talking.

I will need to ponder that before answering.

-David

> I consider a clean
> process of learning about the ASF as better. I started in incubator
> (with lenya) to learn about the ASF and I still learn everyday.
> 
> Going from dev to committer and after "PMC-incubation" into the PMC is
> IMO the best way to develop trust in someone. I think it is better as
> limited committership or directly enter in the PMC (which normally takes
> a good amount of time).
> 
> I hope this "real life" use case shows, that there are persons that will
> welcome a guided process that as well contain a simple committership
> "PMC-incubation" role.
> 
> [1] http://incubator.apache.org/
> [2] http://www.apache.org/foundation/bylaws.html
> [3]
> http://incubator.apache.org/incubation/Incubation_Policy.html#Exitting
> +the+Incubator
> -- 
> thorsten
> 
> "Together we stand, divided we fall!" 
> Hey you (Pink Floyd)

Re: Simple committership

[Anil Ramnanan <li...@peppersauce.org>]

Ross Gardler wrote:

> I also agree. It would be interesting to hear Anils take on this since
> some projects have given their GSoC people "simple committership".  I
> did check with Anil that he understood why we were not doing that, but
> it was a private discussion so I don't want to repeat his words.
>
> Anil, perhaps you can give us a sentence or two on your take on this.
> Do you feel that it would be better for you to have simple
> committership or to work, as you are doing.
>
> Ross
>
I agree that everyone should have to follow the same track. In my case,
even though other GSoC people have gotten "simple commitership", I don't
think that such a privilege is necessary for me to work.

As I understand it, part of the GSoC experience was not only writing
code but getting to know how an open source community works. In such a
case, part of my learning experience is how someone can start from the
ground up, contributing to a project and building from there. If I was
give "simple commitership", it would have been because I was part of
GSoC and not because of the contributions that  I was making. I would
have missed a step (probably one of the most important ones) in the
community. Without the simple commitership, it means that I am earning
my place in the community just like everyone else.

Anil

Re: Simple committership

[Ross Gardler <rg...@apache.org>]

Nicola Ken Barozzi wrote:
> Tim Williams wrote:
> ...
> 
>>On a side note, not that we should necessarily consider this... but
>>it's worth mentioning that there's a social factor to all this as
>>well, right?  I mean, let's be honest, it'd suck to be the new guy/gal
>>voted in as a committer-only to Forrest knowing that all before you
>>are PMC members as well.  I suppose I bring this up because whatever
>>course is taken, it should probably be all or nothing -- in other
>>words, we either say everyone goes through the commitership->pmc
>>incubation->pmc track or everyone goes directly to PMC as it is now;
>>there's not enough objective criteria to distinguish between the two
>>on an individual-by-individual basis.
> 
> 
> This is an interesting point, I agree with it.

I also agree. It would be interesting to hear Anils take on this since 
some projects have given their GSoC people "simple committership".  I 
did check with Anil that he understood why we were not doing that, but 
it was a private discussion so I don't want to repeat his words.

Anil, perhaps you can give us a sentence or two on your take on this. Do 
you feel that it would be better for you to have simple committership or 
to work, as you are doing.

Ross

Re: Simple committership

[Nicola Ken Barozzi <ni...@apache.org>]

Tim Williams wrote:
...
> On a side note, not that we should necessarily consider this... but
> it's worth mentioning that there's a social factor to all this as
> well, right?  I mean, let's be honest, it'd suck to be the new guy/gal
> voted in as a committer-only to Forrest knowing that all before you
> are PMC members as well.  I suppose I bring this up because whatever
> course is taken, it should probably be all or nothing -- in other
> words, we either say everyone goes through the commitership->pmc
> incubation->pmc track or everyone goes directly to PMC as it is now;
> there's not enough objective criteria to distinguish between the two
> on an individual-by-individual basis.

This is an interesting point, I agree with it.

This is why we still *can* make someone a _temporary_ committer if we
have a specific work he has to do that cannot easily be done with
patches, but this is never to be intended as a preferred path to the
PMC, exactly for the reasons you state above.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)
---------------------------------------------------------------------

Re: keep private emails private (Was: Improving our welcome docs pitiful)

[Diwaker Gupta <di...@apache.org>]

On Tuesday 09 August 2005 11:20 pm, David Crossley wrote:
> Diwaker Gupta wrote:
> > This is changing. Here's an excerpt from "News from the infrastructure
> > list" sent out on committers@a.o on 2005/07/18:
>
> Please do not take private emails into a public forum.
> http://www.apache.org/foundation/how-it-works.html#confidential

Sorry, my bad. I should have realized this when I couldn't find this email in 
a public archive and had to dig it out of my mailbox... :-(

> > The easy solution right now is to use mail.apache.org as your outgoing
> > mail server. ...
>
> Are you sure that Infra@ wants that to happen?

I don't really know. I figured that if Apache _is_ hosting an SMTP server 
thats accepts connections on port 25 from anywhere, combined with the fact 
that its hard to get other SMTP servers to relay @a.o emails, then it was 
probably intended to be used that way. But I could be wrong.

Yep, I think its best to pursue this with infra directly, thanks for the note.

-- 
Web/Blog/Gallery: http://floatingsun.net

keep private emails private (Was: Improving our welcome docs pitiful)

[David Crossley <cr...@apache.org>]

Diwaker Gupta wrote:
> This is changing. Here's an excerpt from "News from the infrastructure list" 
> sent out on committers@a.o on 2005/07/18:

Please do not take private emails into a public forum.
http://www.apache.org/foundation/how-it-works.html#confidential

Thanks for trying to explain the email issues,
but a better approach would be as i suggested in
my previous reply - get the whole story straight
on the infrastructure mailing list then patch the
doc that was referred to.

> The easy solution right now is to use mail.apache.org as your outgoing mail 
> server. ...

Are you sure that Infra@ wants that to happen?

-David

Re: Improving our welcome docs pitiful(wasRe: Simple committership)

[Diwaker Gupta <di...@apache.org>]

On Tuesday 09 August 2005 9:40 am, Tim Williams wrote:
> > > I personally wasn't overwhelmed.  The docs are fairly good except for
> > > the pitiful email situation.

I had problems setting up email myself a few weeks back (mostly SMTP related) 
and I had asked on the dev-list as well, and also exchanged a few mails with 
David off line. Comments inline.

> 1.  The preferred way of sending with @apache.org address is
> apparently header mangling.  My problem is that gmail doesn't yet
> support alternate from addresses as far as I can tell.

This is changing. Here's an excerpt from "News from the infrastructure list" 
sent out on committers@a.o on 2005/07/18:

> Email services
> --------------
> We are being flooded with spam. We've already set up a second mail server
> and we will be setting up two more. We plan to start delivering mail that is
> sent to your @apache.org e-mail addresses directly from those machines to
> your chosen forwarding address. We also plan to offer secured SMTP on these
> machines so that you can send e-mail using your @apache.org account. We will
> not be setting up POP nor IMAP.

Like you, my preferred solution would have been to use GMail, if GMail allowed 
alternative from addresses. However, moving forward, I think thats highly 
unlikely. As SPF and DomainKeys gain momentum, its more and more unlikely 
that you will be allowed to send email from an address thats different that 
the one your mail host is actually authenticated to provide email services 
for.

The easy solution right now is to use mail.apache.org as your outgoing mail 
server. As the above mail suggests, at some point we will have secured SMTP 
hosted by Apache, so that'll end all problems.

Another easy solution is to just use your ISP's mail server, or setup your own 
(thats what I do right now).

> 2.  Setting up client for it with ssh tunneling.  I read some mail
> posts about setting up an ssh tunneling using port forwarding but
> after an hour or so with PUTTY, I abandoned that solution. (may very
> well be a firewall issue that I'm unable to figure out).
>
> 3.  PINE.  Pine seems to be the only user-friendly client loaded on
> minotaur but I wasn't able to receive email to it, but I could send
> successfully.

I don't understand why reading mail should be any problem. If you are using 
pine/mutt only for the convinience of being able to send mails from your a.o 
address, hopefully one of the solutions I listed above will work. For 
reading, you are free to choose where you want the mail to go.

> Numbers 2 and 3 could use some documentation that I'm not smart enough
> to write.

I'm happy to write this up if it seems a lot of people are running into this 
problem.

> All this just seems unclean to me.  I suppose it just seems somewhat
> ironic that apache, where everything is accomplished through email,
> has such a cludgey approach.  I've never looked at James but it seems
> that since we have our own mail system we should be able to come up
> with a secure email approach that "just works" without "figuring it
> out".  I realize documentation would help ease the burden but I guess
> I've got to wonder why (given how mature a technology email is) there
> is such a burden that needs easing?

Yes. But the infrastructure team is really small, and they have tons to do. 
We're getting there, slow but steady :-)

> As I write this, it is apparent how dumb it was of me to stumble
> through some of this without at least asking a question on the list,
> so hopefully I didn't miss something simple and obvious.

I was surprised too... apparently it seems a lot of people just use their ISP 
server to begin with and therefore don't face that problem :-)

Diwaker
-- 
Web/Blog/Gallery: http://floatingsun.net

Re: Improving our welcome docs pitiful(wasRe: Simple committership)

[Nicola Ken Barozzi <ni...@apache.org>]

Tim Williams wrote:
...
> I've never looked at James but it seems
> that since we have our own mail system we should be able to come up
> with a secure email approach that "just works" without "figuring it
> out". 

Just a pointer.

http://wiki.apache.org/james/HostApacheOnJames
http://wiki.apache.org/james/JamesByTheNumbers

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)
---------------------------------------------------------------------

Re: Improving our welcome docs pitiful(wasRe: Simple committership)

["Gav...." <br...@brightontown.com.au>]

----- Original Message ----- 
From: "David Crossley" <cr...@apache.org>
| 
| I don't use Putty, but i heard people talk on Infra@ that
| you now need to use ssh v2. However see below.

I don't know about the others, but I find Putty fairly
straight forward to use. I have version 0.58 so that
version and above uses SSH 2 by default, reverting
to 1 if 2 is not available.

I have not used Putty for Forrest, but if someone wants
to give me details to try with, then I will do so I report
back with a HowTo if this will be of any use.

Gav...


-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.10.5/67 - Release Date: 9/08/2005

Re: Improving our welcome docs pitiful(wasRe: Simple committership)

[David Crossley <cr...@apache.org>]

Tim Williams wrote:
> Ross Gardler wrote:
> > Tim Williams wrote:
> > >
> > > I personally wasn't overwhelmed.  The docs are fairly good except for
> > > the pitiful email situation.
> > 
> > Tim, can you explain what you mean by "pitiful email situation". I see
> > an opportunity to improve the learning process.
> 
> Ok, pitiful may have been a bit too strong;) 
> 
> Here are the issues I faced while setting things up.
> 
> 1.  The preferred way of sending with @apache.org address is
> apparently header mangling.  My problem is that gmail doesn't yet
> support alternate from addresses as far as I can tell.
> 
> 2.  Setting up client for it with ssh tunneling.  I read some mail
> posts about setting up an ssh tunneling using port forwarding but
> after an hour or so with PUTTY, I abandoned that solution. (may very
> well be a firewall issue that I'm unable to figure out).

I don't use Putty, but i heard people talk on Infra@ that
you now need to use ssh v2. However see below.

> 3.  PINE.  Pine seems to be the only user-friendly client loaded on
> minotaur but I wasn't able to receive email to it, but I could send
> successfully.

Perhaps mutt. However see below.

> My current state of affairs:  If I really want to send from my apache
> address, I'll just ssh to minotaur and use PINE.  All
> twilliams((at))apache.org mail now forwards to my gmail account,
> meaning if I do reply to it, it will be from my gmail account. 
> Alternate "from" addresses is on the gmail wishlist so hopefully this
> won't be an issue any for long because I do like using gmail for all
> mailing list stuff because of its labels and "conversation" views --
> don't know how I got along without it honestly.
> 
> Numbers 2 and 3 could use some documentation that I'm not smart enough
> to write.

No need. See the last paragraph at
[1] http://www.apache.org/dev/user-email.html

The ASF does not encourage either of those methods.
I am not entirely sure of the reason. I gather that
we don't want to get into managing mail accounts,
backing-up personal spaces, and other resaons.
Probably the Infra volunteers would rather spend
their time on other things. (I am not joking.)

Actually someone needs to go to Infra@ and work out
the exact reasons and then add that to [1]. Then work
out how to provide, or explain, alternatives.

Even though not encouraged, the ssh and pine/mutt
methods were once documented at apache.org. Try the
Waybackmachine.org, or our SVN, for dev/committers.html

> All this just seems unclean to me.  I suppose it just seems somewhat
> ironic that apache, where everything is accomplished through email,
> has such a cludgey approach.  I've never looked at James but it seems
> that since we have our own mail system we should be able to come up
> with a secure email approach that "just works" without "figuring it
> out".

Until now we have not been able to run dynamic
apps at a.o due to many reasons: too many services
on one machine, cannot risk dynamic apps gobbling
the resources, not enough volunteers, too much else
to attend to. Gradually this is being fixed.

>  I realize documentation would help ease the burden but I guess
> I've got to wonder why (given how mature a technology email is) there
> is such a burden that needs easing?

This is brilliant, Tim. You have identified a
huge impediment for new committers. If we can
clear this up, then there will be a big benefit
for all of us.

> As I write this, it is apparent how dumb it was of me to stumble
> through some of this without at least asking a question on the list,
> so hopefully I didn't miss something simple and obvious.

Always ask, don't stumble. Start here on dev. If we can't
answer or point to ASF doco, then someone can take it to Infra@

-David

Re: Improving our welcome docs pitiful(wasRe: Simple committership)

[Tim Williams <wi...@gmail.com>]

On 8/8/05, Ross Gardler <rg...@apache.org> wrote:
> Tim Williams wrote:
> > On 8/6/05, Thorsten Scherler <th...@apache.org> wrote:
> 
> 
> >>The important point is that new committer are generally
> >>overwhelmed by the information and infrastructure of the project and the
> >>ASF. Some learn better step by step understanding what is ASF all about
> >>and what a PMC member have to do (I consider myself as such a
> >>somebody).
> >
> >
> > I personally wasn't overwhelmed.  The docs are fairly good except for
> > the pitiful email situation.
> 
> Tim, can you explain what you mean by "pitiful email situation". I see
> an opportunity to improve the learning process.

Ok, pitiful may have been a bit too strong;) 

Here are the issues I faced while setting things up.

1.  The preferred way of sending with @apache.org address is
apparently header mangling.  My problem is that gmail doesn't yet
support alternate from addresses as far as I can tell.

2.  Setting up client for it with ssh tunneling.  I read some mail
posts about setting up an ssh tunneling using port forwarding but
after an hour or so with PUTTY, I abandoned that solution. (may very
well be a firewall issue that I'm unable to figure out).

3.  PINE.  Pine seems to be the only user-friendly client loaded on
minotaur but I wasn't able to receive email to it, but I could send
successfully.

My current state of affairs:  If I really want to send from my apache
address, I'll just ssh to minotaur and use PINE.  All
twilliams((at))apache.org mail now forwards to my gmail account,
meaning if I do reply to it, it will be from my gmail account. 
Alternate "from" addresses is on the gmail wishlist so hopefully this
won't be an issue any for long because I do like using gmail for all
mailing list stuff because of its labels and "conversation" views --
don't know how I got along without it honestly.

Numbers 2 and 3 could use some documentation that I'm not smart enough
to write.

All this just seems unclean to me.  I suppose it just seems somewhat
ironic that apache, where everything is accomplished through email,
has such a cludgey approach.  I've never looked at James but it seems
that since we have our own mail system we should be able to come up
with a secure email approach that "just works" without "figuring it
out".  I realize documentation would help ease the burden but I guess
I've got to wonder why (given how mature a technology email is) there
is such a burden that needs easing?

As I write this, it is apparent how dumb it was of me to stumble
through some of this without at least asking a question on the list,
so hopefully I didn't miss something simple and obvious.

--tim

Improving our welcome docs pitiful(wasRe: Simple committership)

[Ross Gardler <rg...@apache.org>]

Tim Williams wrote:
> On 8/6/05, Thorsten Scherler <th...@apache.org> wrote:


>>The important point is that new committer are generally
>>overwhelmed by the information and infrastructure of the project and the
>>ASF. Some learn better step by step understanding what is ASF all about
>>and what a PMC member have to do (I consider myself as such a
>>somebody).
> 
> 
> I personally wasn't overwhelmed.  The docs are fairly good except for
> the pitiful email situation. 

Tim, can you explain what you mean by "pitiful email situation". I see 
an opportunity to improve the learning process.

Ross

Re: Simple committership

[Tim Williams <wi...@gmail.com>]

On 8/6/05, Thorsten Scherler <th...@apache.org> wrote:
> On Fri, 2005-07-29 at 15:30 +0200, Nicola Ken Barozzi wrote:
> <snip valuable background information/>
> >
> > If we want to include "simple committership" as a role, I would like to
> > hear someone explain how simple committership will solve more
> > issues than it may cause, especially given the above. In particular, I
> > would like to have some real-life examples that show how simple
> > committership would have been useful.
> >
> 
> Like David and Nicola stated the Forrest project normally votes all
> committer directly into the PMC as well. I personally see special
> occasions (besides GSoC) where I would like to see a "simple
> committership" or like I would call it "PMC incubation". It should
> follow the basic idea of the Apache Incubator [1] which is for new
> projects at Apache.
> 
> "A large part of the Incubator's effort will be devoted to providing
> documentation on how the Foundation works, and how to get things done
> within its framework. As a consequence, it is expected that the
> Incubator will also become a reference for new contributors to any of
> the Apache projects."

The analogy to the Incubator breaks down past a superficial level I
think.  I personally feel that everything (i.e. how Foundation works,
how to get things done, in general, the Apache Way) in the above
paragraph are, for an existing project, the responsibility of existing
committers/PMC members.  People *get* Apache because of other People,
not because of roles, responsibilities, or other stuff.  The Incubator
exists as a way to allow those People to connect, whereas, in an
existing project, that way to connect already exists.  "Being a PMC
member," much like being a developer in general, is a continuum rather
than a goal.  Meaning it's a learning process and picking out a point
an individual is on along the process is subjective.  My understanding
is that our way to resolve that "degree of understanding" issue is by
way "trust", meaning I don't know where exactly they are or if they
are far enough along the learning process, but I *trust* that they'll
get there.

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

I'm probably more laid back than most but I feel absolutely no
pressure.  Learning it to it's "fullest" is too subjective.  We have
to trust that the person is committed to learning it rather than
already knows it.  I guess I think of it the same way as when
interviewing to hire someone -- I don't care as much for what they've
*already* accomplished as much as I do for what I think their
*potential* for accomplishing things are.  In our case, through
patches and community discussion we've got a better idea for what that
potential might be than does a normal prospective employer.

> 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). Now it was asked for a "real-life example".

Again, I'd suggest that your a and b are the responsibilities of the
PMC and existing committers.  I think the way the project works will
probably already have been learned by the time someone feels ready to
vote a person in.  The way the foundation works is, again, a
continuum.  Because of the nature of the foundation, it's just not a
binary thing -- I'm comforted by the fact that there are some
experienced foundation folks still asking some tough questions on the
community list -- if the foundation was "knowable" in a binary sense
this likely wouldn't be happening.

> That could be myself. ;-)
> 
> I have been a Wyona CMS committer before it became an official Apache
> Incubator project. The company Wyona donated then the code base to the
> ASF as cocoon subproject in incubation called Apache Lenya. I had
> "general" experience in how a open source project and community is
> working but that have been quite different from the ASF way that I had
> to learn.
> 
> Within the one year where Apache Lenya has been in the incubator I
> learned the basics (IMO learning) on "how the Foundation works" (a)
> (never stops). As Apache Lenya committer we were given not only
> committing rights to lenya but as well to cocoon, forrest and xml.
> 
> 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.
> 
> One thing that helped me is that the PMC normally watch the committs of
> new committer more careful to ensure that e.g. all legal issues are
> meet.
> 
> PMC membersnot only have to help new committers to learn the duty of a
> PMC member in the specific project (b) but also like the incubator teach
> the values of an ASF project and its duties (a). There have been a
> thread on all PMC lists about the duties (around 10 points) of a PMC
> member by Davanum Srinivas.
> 
> I was given committership to apply my own patches for cocoon, forrest
> and xml. That leveraged this project (faster process) because other PMC
> members do not had to do that. Then especially David taught me as well
> the PMC duties and I became a PMC member.
> 
> The important point is that new committer are generally
> overwhelmed by the information and infrastructure of the project and the
> ASF. Some learn better step by step understanding what is ASF all about
> and what a PMC member have to do (I consider myself as such a
> somebody).

I personally wasn't overwhelmed.  The docs are fairly good except for
the pitiful email situation.  Again, I'm comforted knowing that there
are existing folks to ask and will be responsive to my questions.  I
can't imagine that I would be more overwhelmed or 'pressured' by
simply knowing that the +/- 1 that I would cast anyway is binding or
not -- I trust it would be considered seriously either way.

> I was lucky and made my experience in the incubator *and* here but the
> committers we vote in normally do not have this "incubator" experience
> which I consider most valuable.

Not formally, but I think we *do* have our own little version of it by
way of the mentoring that goes on via existing PMC/committers.

> > In essence, Jakarta became a small Apache, creating sub-roles where
> > the
> > PMC members were like Apache members, and committers were like PMC
> > members. In Jakarta it's usual that committers vote, but in fact their
> > vote is not legally valid, and they *cannot* release code without a
> > PMC
> > vote.
> > This also created a big disconnect between the Board of Directors and
> > Jakarta, and most projects were having little or no oversight, and the
> > number of Jakarta committers that was an Apache member was extremely
> > low.
> 
> The point you are maybe up to is that we can create a closed group that
> new committer are not able to enter. We limit the PMC membership to a
> certain group of people for whatever particular reason.
> 
> The downside is that committers cannot be responsible for the projects
> because they are not in the "management" PMC. That will slow down the
> progress of this project(s) because it slow down their processes.
> 
> I guess it happened because many projects emerged from Jarkata (e.g.
> tomcat, struts,...) and people felt better in having a good working team
> then to better leverage their pmc duties in teaching new committer this
> duties.
> 
> One sentence of [2] seems very interesting at this point:
> "Section 6.3. Project Management Committees.
> ...
> Each Project Management Committee shall be responsible for the active
> management of one or more projects identified by resolution of the Board
> of Directors which may include, without limitation, the creation or
> maintenance of "open-source" software for distribution to the public at
> no charge."
> 
> Now *one or more projects* means that is thought of leveraging not only
> e.g. jarkata but all sub projects that may emerge. That needs a good
> working PMC team that can trust each other (most important on legal
> issues etc.).
> 
> Why are we not adding to the committer role the 'PMC-incubation' label
> and apply similar rules (we have in the incubator for exiting the
> incubator cp [3]) to become a PMC member. That will as well make sure
> that new members will *definitely* enter after "incubation" and overcome
> the jarkata phenomenon.
> 
> In another thread you wrote about becoming PMC/committer:
> > "...But we should not try to measure this with an absolute metric:
> > merit does not earn membership, it earns trust of others members. If
> > other members trust him based on the contributions, then IMHO there is
> > all there is to it."
> 
> I develop trust with time. ...but I can trust somebody to make chances
> (contributions) and I can trust someone making decisions.
> 
> That is a different level of trust we are talking. I consider a clean
> process of learning about the ASF as better. I started in incubator
> (with lenya) to learn about the ASF and I still learn everyday.
> 
> Going from dev to committer and after "PMC-incubation" into the PMC is
> IMO the best way to develop trust in someone. I think it is better as
> limited committership or directly enter in the PMC (which normally takes
> a good amount of time).
> 
> I hope this "real life" use case shows, that there are persons that will
> welcome a guided process that as well contain a simple committership
> "PMC-incubation" role.

While your path has clearly worked well for you, I don't think it's
necessary.  I personally think we're better off considering folks time
as developers/contributors as their implied "incubation" period.  If
you feel they've incubated then nominate them; otherwise, don't.  In
other words, we've either learned enough about contributors to trust
them completely or not. And by "trusting them," I mean we trust they
care enough to continue in earnest to learn the Apache Way.

On a side note, not that we should necessarily consider this... but
it's worth mentioning that there's a social factor to all this as
well, right?  I mean, let's be honest, it'd suck to be the new guy/gal
voted in as a committer-only to Forrest knowing that all before you
are PMC members as well.  I suppose I bring this up because whatever
course is taken, it should probably be all or nothing -- in other
words, we either say everyone goes through the commitership->pmc
incubation->pmc track or everyone goes directly to PMC as it is now;
there's not enough objective criteria to distinguish between the two
on an individual-by-individual basis.
--tim

Re: Simple committership

[Thorsten Scherler <th...@apache.org>]

On Fri, 2005-07-29 at 15:30 +0200, Nicola Ken Barozzi wrote:
<snip valuable background information/>
> 
> If we want to include "simple committership" as a role, I would like to
> hear someone explain how simple committership will solve more
> issues than it may cause, especially given the above. In particular, I
> would like to have some real-life examples that show how simple
> committership would have been useful.
> 

Like David and Nicola stated the Forrest project normally votes all
committer directly into the PMC as well. I personally see special
occasions (besides GSoC) where I would like to see a "simple
committership" or like I would call it "PMC incubation". It should
follow the basic idea of the Apache Incubator [1] which is for new
projects at Apache.

"A large part of the Incubator's effort will be devoted to providing
documentation on how the Foundation works, and how to get things done
within its framework. As a consequence, it is expected that the
Incubator will also become a reference for new contributors to any of
the Apache projects."

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.

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). Now it was asked for a "real-life example". 

That could be myself. ;-)

I have been a Wyona CMS committer before it became an official Apache
Incubator project. The company Wyona donated then the code base to the
ASF as cocoon subproject in incubation called Apache Lenya. I had
"general" experience in how a open source project and community is
working but that have been quite different from the ASF way that I had
to learn. 

Within the one year where Apache Lenya has been in the incubator I
learned the basics (IMO learning) on "how the Foundation works" (a)
(never stops). As Apache Lenya committer we were given not only
committing rights to lenya but as well to cocoon, forrest and xml.

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. 

One thing that helped me is that the PMC normally watch the committs of
new committer more careful to ensure that e.g. all legal issues are
meet. 

PMC membersnot only have to help new committers to learn the duty of a
PMC member in the specific project (b) but also like the incubator teach
the values of an ASF project and its duties (a). There have been a
thread on all PMC lists about the duties (around 10 points) of a PMC
member by Davanum Srinivas. 

I was given committership to apply my own patches for cocoon, forrest
and xml. That leveraged this project (faster process) because other PMC
members do not had to do that. Then especially David taught me as well
the PMC duties and I became a PMC member. 

The important point is that new committer are generally
overwhelmed by the information and infrastructure of the project and the
ASF. Some learn better step by step understanding what is ASF all about
and what a PMC member have to do (I consider myself as such a
somebody). 

I was lucky and made my experience in the incubator *and* here but the
committers we vote in normally do not have this "incubator" experience
which I consider most valuable. 

> 
> In essence, Jakarta became a small Apache, creating sub-roles where
> the
> PMC members were like Apache members, and committers were like PMC
> members. In Jakarta it's usual that committers vote, but in fact their
> vote is not legally valid, and they *cannot* release code without a
> PMC
> vote.
> This also created a big disconnect between the Board of Directors and
> Jakarta, and most projects were having little or no oversight, and the
> number of Jakarta committers that was an Apache member was extremely
> low.

The point you are maybe up to is that we can create a closed group that
new committer are not able to enter. We limit the PMC membership to a
certain group of people for whatever particular reason.

The downside is that committers cannot be responsible for the projects
because they are not in the "management" PMC. That will slow down the
progress of this project(s) because it slow down their processes.

I guess it happened because many projects emerged from Jarkata (e.g.
tomcat, struts,...) and people felt better in having a good working team
then to better leverage their pmc duties in teaching new committer this
duties. 

One sentence of [2] seems very interesting at this point:
"Section 6.3. Project Management Committees.
...
Each Project Management Committee shall be responsible for the active
management of one or more projects identified by resolution of the Board
of Directors which may include, without limitation, the creation or
maintenance of "open-source" software for distribution to the public at
no charge."

Now *one or more projects* means that is thought of leveraging not only
e.g. jarkata but all sub projects that may emerge. That needs a good
working PMC team that can trust each other (most important on legal
issues etc.). 

Why are we not adding to the committer role the 'PMC-incubation' label
and apply similar rules (we have in the incubator for exiting the
incubator cp [3]) to become a PMC member. That will as well make sure
that new members will *definitely* enter after "incubation" and overcome
the jarkata phenomenon.

In another thread you wrote about becoming PMC/committer:
> "...But we should not try to measure this with an absolute metric:
> merit does not earn membership, it earns trust of others members. If
> other members trust him based on the contributions, then IMHO there is
> all there is to it."

I develop trust with time. ...but I can trust somebody to make chances
(contributions) and I can trust someone making decisions. 

That is a different level of trust we are talking. I consider a clean
process of learning about the ASF as better. I started in incubator
(with lenya) to learn about the ASF and I still learn everyday.

Going from dev to committer and after "PMC-incubation" into the PMC is
IMO the best way to develop trust in someone. I think it is better as
limited committership or directly enter in the PMC (which normally takes
a good amount of time).

I hope this "real life" use case shows, that there are persons that will
welcome a guided process that as well contain a simple committership
"PMC-incubation" role.

[1] http://incubator.apache.org/
[2] http://www.apache.org/foundation/bylaws.html
[3]
http://incubator.apache.org/incubation/Incubation_Policy.html#Exitting
+the+Incubator
-- 
thorsten

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)