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
