Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Date: Mon, 8 Aug 2005 14:38:23 +1000
From: David Crossley <crossley@apache.org>
To: dev@forrest.apache.org
Subject: Re: Simple committership
Message-ID: <20050808043823.GA11466@igg.indexgeo.com.au>
References: <dcdb1g$fjj$1@sea.gmane.org>
 <1123336758.5440.77.camel@localhost.localdomain>
 <20050807131932.GA10815@igg.indexgeo.com.au>
 <42F6161B.9000101@rocktreesky.com> <42F63A72.1090301@apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <42F63A72.1090301@apache.org>
User-Agent: Mutt/1.4i

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