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)
