You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Nicola Ken Barozzi <ni...@apache.org> on 2004/07/01 12:16:19 UTC
Re: [DRAFT] Forrest Project Guidelines
Clay Leeds wrote:
> (from the perspective of being just a 'user'--I think--at this point :-))
>
> On Jun 30, 2004, at 5:22 AM, David Crossley wrote:
>
>>> David Crossley wrote:
>>>
>>>> Nicola Ken Barozzi wrote:
>>>> ... but now that I have seen it I don't read in it
>>>> the fact that simple committers cannot vote
>>>> (as instead I would prefer).
...
> I concur with Nicola Ken Barozzi. A non-voting committer doesn't make
> sense to me. To me it's not unlike having a soldier in the military with
> a 'license' to kill, but who can't legally drink (in U.S.A. you can join
> the military at 18, but you can't legally drink until you are 21).
In fact I meant the opposite, but I've not been clear, sorry.
The fact is that having commit access does not mean that you can
necessarily vote. Having commit access is not a license to kill, as we
can easily revert changes. It's just like getting into the camp, and be
able to work there, but without taking long-term decisions.
Note that usual decisions should take place without the tedious process
of formal votes if possible.
...
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [DRAFT] Forrest Project Guidelines
Posted by David Crossley <cr...@apache.org>.
Clay Leeds wrote:
> In my case, I was recently voted to have COMMITTER status, even though
> I'm not a java developer (I've got other responsibilities[1] <cough>get
> http://xml.apache.org/fop/ properly forrest-ed to output Whole Site
> PDF</cough> ;-)). The fact that I've got VOTE'ing responsibilities--in
> my mind--gives me the feeling that I've got more ownership of the
> project. All this does, is give me the feeling that I want to 'care'
> even more for FOP than I already did. I suspect similar feelings by
> other VOTE'ing members.
Similar feelings yes, but not because of the ability
to vote. I believe that this dedication stems from
the fact that a group of fellows who we admire have
acknowledged our commitment and put trust in us.
> Dave Brondsema wrote:
> > Moreover, if we did have non-voting committers to work on a certain
> > feature, we need to define another process for "graduation" to voting
> > committership. I don't like having so many levels of stratification,
> > it makes the community feel less open.
>
> Defining how to 'graduate' sounds like a reasonable solution if forrest
> decides to have non-voting committers.
>
> Another possibility, is that the PMC have either some sort of special
> voting powers (+2? only PMC can VETO? extra helping of fruit cup?)
>
> Which brings to mind what I *think* is desired in the non-voting
> committer: a way of getting procedural issues resolved without having
> to 'bother' the entire community. This is what I thought the PMC was
> for.
Some people need to be left to get on with work. The PMC
would shield them from the nasty mundane management stuff.
That is why i think Cocoon just lets those committers who
so desire, participate on their PMC, while all of them
are working committers who vote on general project direction.
> If I'm off-base, perhaps the classifications of community members needs
> to be spelled out once again, but using better descriptions.
It is hard. We need to refine those words.
--
David Crossley
Re: [DRAFT] Forrest Project Guidelines
Posted by Clay Leeds <cl...@medata.com>.
On Jul 1, 2004, at 5:12 AM, Dave Brondsema wrote:
> On Thu, 1 Jul 2004, Nicola Ken Barozzi wrote:
>> Clay Leeds wrote:
>>> I concur with Nicola Ken Barozzi. A non-voting committer doesn't make
>>> sense to me. To me it's not unlike having a soldier in the military
>>> with
>>> a 'license' to kill, but who can't legally drink (in U.S.A. you can
>>> join
>>> the military at 18, but you can't legally drink until you are 21).
>>
>> In fact I meant the opposite, but I've not been clear, sorry.
>>
>> The fact is that having commit access does not mean that you can
>> necessarily vote. Having commit access is not a license to kill, as we
>> can easily revert changes. It's just like getting into the camp, and
>> be
>> able to work there, but without taking long-term decisions.
>>
>> Note that usual decisions should take place without the tedious
>> process
>> of formal votes if possible.
>
> Just because we can have a distinction between voting committers and
> non-voting committers doesn't mean we should. What are the reasons we
> would want a committer that can't vote? Task-based access is the only
> one
> I know of. But I consider that like taking one step into the realm
> full
> involvement.
+1
> Consider me: I became a committer because I wanted to work on
> forrestbot
> and make some fixes to the windows .bat files. Those were
> task-oriented.
> But I have now become involved in many parts of forrest.
>
> Even if we give someone commit access for the purpose of a specific
> task,
> we give them access to the whole tree. This means we're letting them
> be
> fully involved if they want to. Even if they choose to work only on
> one
> feature, they should be a voting committer so that they can vote on
> issues
> related to that feature, and they should abstain from votes unrelated
> to
> their work.
In my case, I was recently voted to have COMMITTER status, even though
I'm not a java developer (I've got other responsibilities[1] <cough>get
http://xml.apache.org/fop/ properly forrest-ed to output Whole Site
PDF</cough> ;-)). The fact that I've got VOTE'ing responsibilities--in
my mind--gives me the feeling that I've got more ownership of the
project. All this does, is give me the feeling that I want to 'care'
even more for FOP than I already did. I suspect similar feelings by
other VOTE'ing members.
> Moreover, if we did have non-voting committers to work on a certain
> feature, we need to define another process for "graduation" to voting
> committership. I don't like having so many levels of stratification,
> it
> makes the community feel less open.
Defining how to 'graduate' sounds like a reasonable solution if forrest
decides to have non-voting committers.
Another possibility, is that the PMC have either some sort of special
voting powers (+2? only PMC can VETO? extra helping of fruit cup?)
Which brings to mind what I *think* is desired in the non-voting
committer: a way of getting procedural issues resolved without having
to 'bother' the entire community. This is what I thought the PMC was
for.
If I'm off-base, perhaps the classifications of community members needs
to be spelled out once again, but using better descriptions.
> --
> Dave Brondsema : dave@brondsema.net
> http://www.brondsema.net : personal
> http://www.splike.com : programming
> http://csx.calvin.edu : student org
>
Respectfully,
Web Maestro Clay
[1]
http://xml.apache.org/fop/team.html#cl
Re: [DRAFT] Forrest Project Guidelines
Posted by David Crossley <cr...@apache.org>.
Dave Brondsema wrote:
> Nicola Ken Barozzi wrote:
>
> Just because we can have a distinction between voting committers and
> non-voting committers doesn't mean we should. What are the reasons we
> would want a committer that can't vote? Task-based access is the only one
> I know of. But I consider that like taking one step into the realm full
> involvement.
Well put. I too would like to reduce distinction.
Either people are committed or are part-time developers.
> Consider me: I became a committer because I wanted to work on forrestbot
> and make some fixes to the windows .bat files. Those were task-oriented.
> But I have now become involved in many parts of forrest.
My experience is similar. Cocoon was my first opensource foray
then Forrest. At Cocoon i wanted to implement the entity resolver.
I sent clumsy java patches, and was keen on helping with docs.
Two tasks that are very far from serious java/xml app development.
I demonstrated commitment to the project and was invited.
Then got sucked in further, and now look what happened.
> Even if we give someone commit access for the purpose of a specific task,
> we give them access to the whole tree. This means we're letting them be
> fully involved if they want to. Even if they choose to work only on one
> feature, they should be a voting committer so that they can vote on issues
> related to that feature, and they should abstain from votes unrelated to
> their work.
That is what i do - just silently abstain from some votes
that have i no hope of understanding. While on others i try
to add constructive comments, to throw ideas into the pot.
> Moreover, if we did have non-voting committers to work on a certain
> feature, we need to define another process for "graduation" to voting
> committership. I don't like having so many levels of stratification, it
> makes the community feel less open.
Me too. With our draft guidelines i tried to not have
any words like "promotion", reward", "graduation" because
that implies strata and clubs.
--
David Crossley
Re: [DRAFT] Forrest Project Guidelines
Posted by David Crossley <cr...@apache.org>.
Nicola Ken Barozzi wrote:
> Dave Brondsema wrote:
> ...
> > That explanation helped.
>
> :-)
I too am glad, the whole discussion helped.
> > What about this: committers cannot vote, unless
> > they are a PMC member. After the committer demonstrates he/she can work
> > well with us, we can propose they join the PMC. The only people who stay
> > "just committers" would be most Lenya & Cocoon committers and
> > task-oriented committers who don't want to be more involved.
> >
> > This keeps the committing roles to 2 instead of 3.
>
> This is what I was proposing...
Great. Perhaps it just took time to get the message across.
Thanks Dave, that is a good summary.
> I'll have to update the voting doc to reflect this:
> http://incubator.apache.org/learn/voting.html
>
> The notion of "developer" is not something we normally use,
> but that is defined.
Not sure what you mean here. We have a "dev" mailing
list, so we must have developers.
> http://www.apache.org/foundation/roles.html
>
> These are users
>
> - User (that are on the user list)
> - Developer (that are on the dev list,
> we usually still call them users, as our users are
> mostly also developers)
I would call them developers rather than users.
> These are committers (*):
>
> - Committer (non core group)
> - PMC member (core group that can vote)
>
> Then we have a step further that is about greater involvement in Apache:
>
> - Apache Member
> - Board of Directors
> - Officers
Meritocracy at work.
--
David Crossley
Re: [DRAFT] Forrest Project Guidelines
Posted by "Scherler, Thorsten" <th...@apache.org>.
Nicola Ken Barozzi wrote:
> Dave Brondsema wrote:
>
> ...
>
>> That explanation helped.
>
>
> :-)
>
>> What about this: committers cannot vote, unless
>> they are a PMC member. After the committer demonstrates he/she can work
>> well with us, we can propose they join the PMC. The only people who stay
>> "just committers" would be most Lenya & Cocoon committers and
>> task-oriented committers who don't want to be more involved.
>>
>> This keeps the committing roles to 2 instead of 3.
>
>
> This is what I was proposing...
>
> I'll have to update the voting doc to reflect this:
> http://incubator.apache.org/learn/voting.html
>
> The notion of "developer" is not something we normally use, but that is
> defined.
>
> http://www.apache.org/foundation/roles.html
>
> These are users
>
> - User (that are on the user list)
> - Developer (that are on the dev list,
> we usually still call them users, as our users are
> mostly also developers)
>
> These are committers (*):
>
> - Committer (non core group)
> - PMC member (core group that can vote)
>
For me following the thread I do not see the need for more roles but
more to define the procedures for the project clearer.
In terms of strategic management a strategy can be formulated on three
different levels [2]:
* corporate level
[2] Corporate level strategy fundamentally is concerned with the
selection of businesses in which the company should compete and with the
development and coordination of that portfolio of businesses.
[1] The Project Management Committee (PMC) is a group of committers who
take responsibility for the long-term direction of the projects in their
area.
* business unit level
[2]At the business unit level, the strategic issues are less about the
coordination of operating units and more about developing and sustaining
a competitive advantage for the goods and services that are produced.
[1]Frequent and valuable contributers to a project are granted write
access to the source code repository. These committers are the people
who make the day-to-day decisions about what changes will be made to the
software.
* functional or departmental level
[1]The strategic issues at the functional level are related to business
processes and the value chain. Functional level strategies in marketing,
finance, operations, human resources, and R&D involve the development
and coordination of resources through which business unit level
strategies can be executed efficiently and effectively.
[2]A user who contributes to a project in the form of code or
documentation becomes a developer. Developers usually subscribe to the
project development mailing list and contribute by sending patches to
the list.
I see user more as the client of a traditional company. The goal of a
strategy is to define a set of rules to competing and surviving in the
market.
Like a company wants to create a good product with the help of the right
strategy to get new or keep the loyal customer. Forrest tries to create
a good software product and the loyal user are telling us what they like
and what not.
[1] The most important participants are the people who use our software.
The majority of our developers start out as users and guide their
development efforts from the user's perspective.
In my opion everybody has the right to vote on a subject as an
expression of *his/her* *personal* *opinion* about it. We can
differentiate between binding and non-binding votes. We can further
define the strategic level of the topic to define when a vote have
binding power:
* corporate level - PMC
* business unit level - committer
* functional or departmental level - dev
Then we can go ahead and use the nice voting mechanism from
commons-httpclient-dev@jakarta.apache.org
------------------------------------------------------------------------
Vote: TOPIC OF VOTE
[ ] +1 I am in favor of the release, and will help support it.
[ ] +0 I am in favor of the release, but am unable to help support it.
[ ] -0 I am not in favor of the release.
[ ] -1 I am against this proposal (must include a reason).
------------------------------------------------------------------------
This would give information to manage the project because more or less
we will know where our ressources are.
my 0.02€
king regards
thorsten
[1]http://www.apache.org/foundation/roles.html
[2]http://www.quickmba.com/strategy/levels/
--
<thorsten>
<name>Thorsten Scherler</name>
<country>Spain</country>
<@m...@mail>
<@c...@cocoon-WIKI>
<http>http://www.target-x.de</http>
<acronymfinder>http://www.acronymfinder.com</acronymfinder>
<motto>
"My task which I am trying to achieve is,
by the power of the written word,
[...] to make you see."
*Joseph Conrad (1857-1924)*
</motto>
</thorsten>
Re: [VOTE] Forrest Project Guidelines
Posted by Nicola Ken Barozzi <ni...@apache.org>.
David Crossley wrote:
> I reckon that the draft guidelines are now ready.
...
> So please vote.
+1
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [VOTE] Forrest Project Guidelines
Posted by Antonio Gallardo <ag...@agssa.net>.
On Lun, 31 de Enero de 2005, 20:45, David Crossley dijo:
> So please vote.
+1
Best Regards,
Antonio Gallardo
[VOTE] Forrest Project Guidelines
Posted by David Crossley <cr...@apache.org>.
I reckon that the draft guidelines are now ready.
The ASF Board Resolution that created the Forrest project
http://www.apache.org/foundation/records/minutes/2004/board_minutes_2004_05_26.txt
assigned our PMC the task of creating project guidelines
"intended to encourage open development and increased
participation in the Forrest Project".
We have had this document in preparation for a long time,
so we all had plenty opportunity to affect it.
In general, code/documentation does not require voting.
However, this is such an important document that we
should be sure that everyone is happy with it.
So please vote.
--David
On 2004-11-01 David Crossley wrote:
>
> If we don't hear some feedback in the next few days,
> then we can assume that the project bylaws are ready
> to be voted into being.
>
> On 2004-09-22 David Crossley wrote:
> >
> > Expose the link in site.xml and see what you think.
> > Send any comments here to the dev mailing list please.
Re: [DRAFT] Forrest Project Guidelines
Posted by David Crossley <cr...@apache.org>.
If we don't hear some feedback in the next few days,
then we can assume that the project bylaws are ready
to be voted into being.
--David
On 2004-09-22 David Crossley wrote:
> The "Draft Guidelines" were just now updated to add
> sections about "Decision making" and "Voting" and "PMC".
>
> Expose the link in site.xml and see what you think.
> Send any comments here to the dev mailing list please.
Re: [DRAFT] Forrest Project Guidelines
Posted by David Crossley <cr...@apache.org>.
The "Draft Guidelines" were just now updated to add
sections about "Decision making" and "Voting" and "PMC".
Expose the link in site.xml and see what you think.
Send any comments here to the dev mailing list please.
--
David Crossley
Re: [DRAFT] Forrest Project Guidelines
Posted by David Crossley <cr...@apache.org>.
Nicola Ken Barozzi wrote:
>
> Hence I have updated a doc on the main Apache site and I'll be
> converting also the voting doc.
So with the rationalisation of those docs, there is
very little needed in our project guidelines document.
It can state our mission and point to those. Nice.
--
David Crossley
Re: [DRAFT] Forrest Project Guidelines
Posted by David Crossley <cr...@apache.org>.
Nicola Ken Barozzi wrote:
> David Crossley wrote:
> > Nicola Ken Barozzi wrote:
> >
> >>Dave Brondsema wrote:
> >>
> >>>What about this: committers cannot vote, unless
> >>>they are a PMC member. After the committer demonstrates he/she can work
> >>>well with us, we can propose they join the PMC. The only people who stay
> >>>"just committers" would be most Lenya & Cocoon committers and
> >>>task-oriented committers who don't want to be more involved.
> >>>
> >>>This keeps the committing roles to 2 instead of 3.
> >>
> >>This is what I was proposing...
> >
> > The part that i was stuck with in writing the current
> > Guidelines is that we were trying to introduce a role
> > that just does their work in the SVN repository and
> > does not have a person<AT>apache.org UNIX/mail account.
> > So that makes them a different type of committer.
>
> I got a reply on the member mailing list: committers have no binding votes.
Yes i saw that. It is great to start to get some consistency
across projects in this regard.
> Hence I have updated a doc on the main Apache site and I'll be
> converting also the voting doc.
>
> Take a look here in the meantime and see how it looks like.
>
> http://www.apache.org/foundation/how-it-works.html#meritocracy
Nice evolution. Soon we will be able to link to them and
minimise our guidelines. Thanks.
--
David Crossley
Re: [DRAFT] Forrest Project Guidelines
Posted by Nicola Ken Barozzi <ni...@apache.org>.
David Crossley wrote:
> Nicola Ken Barozzi wrote:
>
>>Dave Brondsema wrote:
>>
>>>What about this: committers cannot vote, unless
>>>they are a PMC member. After the committer demonstrates he/she can work
>>>well with us, we can propose they join the PMC. The only people who stay
>>>"just committers" would be most Lenya & Cocoon committers and
>>>task-oriented committers who don't want to be more involved.
>>>
>>>This keeps the committing roles to 2 instead of 3.
>>
>>This is what I was proposing...
>
> The part that i was stuck with in writing the current
> Guidelines is that we were trying to introduce a role
> that just does their work in the SVN repository and
> does not have a person<AT>apache.org UNIX/mail account.
> So that makes them a different type of committer.
I got a reply on the member mailing list: committers have no binding votes.
Hence I have updated a doc on the main Apache site and I'll be
converting also the voting doc.
Take a look here in the meantime and see how it looks like.
http://www.apache.org/foundation/how-it-works.html#meritocracy
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [DRAFT] Forrest Project Guidelines
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Scherler, Thorsten wrote:
> David Crossley wrote:
>
>> Nicola Ken Barozzi wrote:
>>
>>> Dave Brondsema wrote:
>>>
>>>> What about this: committers cannot vote, unless
>>>> they are a PMC member. After the committer demonstrates he/she can
>>>> work
>>>> well with us, we can propose they join the PMC. The only people who
>>>> stay
>>>> "just committers" would be most Lenya & Cocoon committers and
>>>> task-oriented committers who don't want to be more involved.
>>>>
>>>> This keeps the committing roles to 2 instead of 3.
>>>
>>> This is what I was proposing...
>>
>> The part that i was stuck with in writing the current
>> Guidelines is that we were trying to introduce a role
>> that just does their work in the SVN repository and
>> does not have a person<AT>apache.org UNIX/mail account.
>> So that makes them a different type of committer.
>>
> I think that can be the developer. Remember:
> A user who contributes to a project in the form of code or documentation
> becomes a developer.
> So giving him karma to certain areas of the svn-tree would help reduce
> patches that are voted positiv. He could apply that by himself.
This is a step further from developer, as he can commit -> committer.
The more I think of it, the more I understand that the fact that ewmany
projects call 'committer' all the voters is wrong.
> ...why are we not using a auth-mechanism at apache? I mean every user of
> the mailing list can have an apache account (user and devs only does not
> have a person<AT>apache.org UNIX/mail account). This login could be used
> for wiki, jira, svn, ... The account information can be stored in LDAP,
> etc.. Helps as well the guys from infrastructure to easily look up user
> infos for changes in karma. Having doco in mind I reckon we would need
> such a mechanism anyway!
They are discussing about it on the infrastructure list, but it will
take some time to get it running.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [DRAFT] Forrest Project Guidelines
Posted by "Scherler, Thorsten" <th...@apache.org>.
David Crossley wrote:
> Nicola Ken Barozzi wrote:
>
>>Dave Brondsema wrote:
>>
>>>What about this: committers cannot vote, unless
>>>they are a PMC member. After the committer demonstrates he/she can work
>>>well with us, we can propose they join the PMC. The only people who stay
>>>"just committers" would be most Lenya & Cocoon committers and
>>>task-oriented committers who don't want to be more involved.
>>>
>>>This keeps the committing roles to 2 instead of 3.
>>
>>This is what I was proposing...
>
>
> The part that i was stuck with in writing the current
> Guidelines is that we were trying to introduce a role
> that just does their work in the SVN repository and
> does not have a person<AT>apache.org UNIX/mail account.
> So that makes them a different type of committer.
>
I think that can be the developer. Remember:
A user who contributes to a project in the form of code or documentation
becomes a developer.
So giving him karma to certain areas of the svn-tree would help reduce
patches that are voted positiv. He could apply that by himself.
...why are we not using a auth-mechanism at apache? I mean every user of
the mailing list can have an apache account (user and devs only does not
have a person<AT>apache.org UNIX/mail account). This login could be used
for wiki, jira, svn, ... The account information can be stored in LDAP,
etc.. Helps as well the guys from infrastructure to easily look up user
infos for changes in karma. Having doco in mind I reckon we would need
such a mechanism anyway!
King regards
thorsten
--
<thorsten>
<name>Thorsten Scherler</name>
<country>Spain</country>
<@m...@mail>
<@c...@cocoon-WIKI>
<http>http://www.target-x.de</http>
<acronymfinder>http://www.acronymfinder.com</acronymfinder>
<motto>
"My task which I am trying to achieve is,
by the power of the written word,
[...] to make you see."
*Joseph Conrad (1857-1924)*
</motto>
</thorsten>
Re: [DRAFT] Forrest Project Guidelines
Posted by David Crossley <cr...@apache.org>.
Nicola Ken Barozzi wrote:
> Dave Brondsema wrote:
> > What about this: committers cannot vote, unless
> > they are a PMC member. After the committer demonstrates he/she can work
> > well with us, we can propose they join the PMC. The only people who stay
> > "just committers" would be most Lenya & Cocoon committers and
> > task-oriented committers who don't want to be more involved.
> >
> > This keeps the committing roles to 2 instead of 3.
>
> This is what I was proposing...
The part that i was stuck with in writing the current
Guidelines is that we were trying to introduce a role
that just does their work in the SVN repository and
does not have a person<AT>apache.org UNIX/mail account.
So that makes them a different type of committer.
--
David Crossley
Re: [DRAFT] Forrest Project Guidelines
Posted by Clay Leeds <cl...@medata.com>.
On Jul 1, 2004, at 7:56 AM, Nicola Ken Barozzi wrote:
> This is what I was proposing...
>
> I'll have to update the voting doc to reflect this:
> http://incubator.apache.org/learn/voting.html
>
> The notion of "developer" is not something we normally use, but that
> is defined.
>
> http://www.apache.org/foundation/roles.html
>
> These are users
>
> - User (that are on the user list)
> - Developer (that are on the dev list,
> we usually still call them users, as our users are
> mostly also developers)
>
> These are committers (*):
>
> - Committer (non core group)
> - PMC member (core group that can vote)
>
> Then we have a step further that is about greater involvement in
> Apache:
>
> - Apache Member
> - Board of Directors
> - Officers
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
Thank you for your clear explanation. This makes sense to me.
+1 (so to speak ;-))
Re: [DRAFT] Forrest Project Guidelines
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Dave Brondsema wrote:
...
> That explanation helped.
:-)
> What about this: committers cannot vote, unless
> they are a PMC member. After the committer demonstrates he/she can work
> well with us, we can propose they join the PMC. The only people who stay
> "just committers" would be most Lenya & Cocoon committers and
> task-oriented committers who don't want to be more involved.
>
> This keeps the committing roles to 2 instead of 3.
This is what I was proposing...
I'll have to update the voting doc to reflect this:
http://incubator.apache.org/learn/voting.html
The notion of "developer" is not something we normally use, but that is
defined.
http://www.apache.org/foundation/roles.html
These are users
- User (that are on the user list)
- Developer (that are on the dev list,
we usually still call them users, as our users are
mostly also developers)
These are committers (*):
- Committer (non core group)
- PMC member (core group that can vote)
Then we have a step further that is about greater involvement in Apache:
- Apache Member
- Board of Directors
- Officers
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [DRAFT] Forrest Project Guidelines
Posted by Dave Brondsema <da...@brondsema.net>.
On Thu, 1 Jul 2004, Nicola Ken Barozzi wrote:
> Dave Brondsema wrote:
> ...
> > Moreover, if we did have non-voting committers to work on a certain
> > feature, we need to define another process for "graduation" to voting
> > committership. I don't like having so many levels of stratification, it
> > makes the community feel less open.
>
> I understand.
>
> Let me try to explain again what I'm trying to solve instead of
> discussing on the solution :-)
>
> Let's say that all committers can VOTE. This sets a high bar on
> committership, as one needs to demonstrate that he can work well
> together. Some project set this as high as 6 months of continuous and
> good patches. The fact is that a voter can veto changes (even if they
> have to be explained), and this can have a big impact on the community.
>
> In this way, the distinction between PMC members and committers is moot,
> as all committers become PMC members. If they can vote, then they are
> steering the project, so they are de facto part of the PMC and must take
> responsibility.
>
> Because of this, we cannot have people helping out on a certain feature
> for a limited set of time or for a particular part of the code. For
> example, let's say that we put a XYZ skin in Forrest and that a certian
> person wants to maintain it. Shall we make him part of the PMC? I say
> no. Shall we have him send in patches continually, just to have that
> skin up to date? Would not partial commit access be a solution?
>
> Note that partial commit access is not a step to PMC membership. It's an
> alternative for some cases.
>
> Another use case is that we wouldn't have Lenya or Cocoon committers
> with access to the CVS, as they would have to be PMC members, which has
> to be voted based on merit. How would we treat this?
>
That explanation helped. What about this: committers cannot vote, unless
they are a PMC member. After the committer demonstrates he/she can work
well with us, we can propose they join the PMC. The only people who stay
"just committers" would be most Lenya & Cocoon committers and
task-oriented committers who don't want to be more involved.
This keeps the committing roles to 2 instead of 3.
--
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
http://csx.calvin.edu : student org
Re: [DRAFT] Forrest Project Guidelines
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Dave Brondsema wrote:
...
> Moreover, if we did have non-voting committers to work on a certain
> feature, we need to define another process for "graduation" to voting
> committership. I don't like having so many levels of stratification, it
> makes the community feel less open.
I understand.
Let me try to explain again what I'm trying to solve instead of
discussing on the solution :-)
Let's say that all committers can VOTE. This sets a high bar on
committership, as one needs to demonstrate that he can work well
together. Some project set this as high as 6 months of continuous and
good patches. The fact is that a voter can veto changes (even if they
have to be explained), and this can have a big impact on the community.
In this way, the distinction between PMC members and committers is moot,
as all committers become PMC members. If they can vote, then they are
steering the project, so they are de facto part of the PMC and must take
responsibility.
Because of this, we cannot have people helping out on a certain feature
for a limited set of time or for a particular part of the code. For
example, let's say that we put a XYZ skin in Forrest and that a certian
person wants to maintain it. Shall we make him part of the PMC? I say
no. Shall we have him send in patches continually, just to have that
skin up to date? Would not partial commit access be a solution?
Note that partial commit access is not a step to PMC membership. It's an
alternative for some cases.
Another use case is that we wouldn't have Lenya or Cocoon committers
with access to the CVS, as they would have to be PMC members, which has
to be voted based on merit. How would we treat this?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [DRAFT] Forrest Project Guidelines
Posted by Dave Brondsema <da...@brondsema.net>.
On Thu, 1 Jul 2004, Nicola Ken Barozzi wrote:
> Clay Leeds wrote:
>
> > (from the perspective of being just a 'user'--I think--at this point :-))
> >
> > On Jun 30, 2004, at 5:22 AM, David Crossley wrote:
> >
> >>> David Crossley wrote:
> >>>
> >>>> Nicola Ken Barozzi wrote:
> >>>> ... but now that I have seen it I don't read in it
> >>>> the fact that simple committers cannot vote
> >>>> (as instead I would prefer).
> ...
> > I concur with Nicola Ken Barozzi. A non-voting committer doesn't make
> > sense to me. To me it's not unlike having a soldier in the military with
> > a 'license' to kill, but who can't legally drink (in U.S.A. you can join
> > the military at 18, but you can't legally drink until you are 21).
>
> In fact I meant the opposite, but I've not been clear, sorry.
>
> The fact is that having commit access does not mean that you can
> necessarily vote. Having commit access is not a license to kill, as we
> can easily revert changes. It's just like getting into the camp, and be
> able to work there, but without taking long-term decisions.
>
> Note that usual decisions should take place without the tedious process
> of formal votes if possible.
Just because we can have a distinction between voting committers and
non-voting committers doesn't mean we should. What are the reasons we
would want a committer that can't vote? Task-based access is the only one
I know of. But I consider that like taking one step into the realm full
involvement.
Consider me: I became a committer because I wanted to work on forrestbot
and make some fixes to the windows .bat files. Those were task-oriented.
But I have now become involved in many parts of forrest.
Even if we give someone commit access for the purpose of a specific task,
we give them access to the whole tree. This means we're letting them be
fully involved if they want to. Even if they choose to work only on one
feature, they should be a voting committer so that they can vote on issues
related to that feature, and they should abstain from votes unrelated to
their work.
Moreover, if we did have non-voting committers to work on a certain
feature, we need to define another process for "graduation" to voting
committership. I don't like having so many levels of stratification, it
makes the community feel less open.
--
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
http://csx.calvin.edu : student org