You are viewing a plain text version of this content. The canonical link for it is here.
Posted to community@apache.org by Ted Husted <hu...@apache.org> on 2002/10/27 17:11:00 UTC
Welcome to Apache Letter
On Jakarta, we have a sample letter that can be sent to
Contributors when we are ready to nominate them as Committers.
It occurred to me that we should also have a follow-up letter
welcome them as a Committer. This would be a good place to
insert some of points that have come up over Reorg and
Community lately.
Please see the updated page at
<http://jakarta.apache.org/site/roles.html> for a sample "Dear
(new) Committer" letter.
The letter refers to a "Newbie Committer FAQ". I did not link
in the newbie FAQ, since I thought it warranted a second by a
current member of the Jakarta PMC.
The proposed Newbie FAQ can be viewed at
<http://jakarta.apache.org/site/newbie.html>.
It also occurs to me that something the incubator project can
do is provide a template set of guidelines and procedures for
the projects. In the way of guidelines, we have a draft set
that includes several "clarifications" , in case anyone in the
incubator project is interested in this idea.
<http://jakarta.apache.org/site/proposal.html>
-Ted.
Re: Welcome to Apache Letter
Posted by Stephen McConnell <mc...@apache.org>.
Ted Husted wrote:
>On Jakarta, we have a sample letter that can be sent to
>Contributors when we are ready to nominate them as Committers.
>It occurred to me that we should also have a follow-up letter
>welcome them as a Committer. This would be a good place to
>insert some of points that have come up over Reorg and
>Community lately.
>
>Please see the updated page at
><http://jakarta.apache.org/site/roles.html> for a sample "Dear
>(new) Committer" letter.
>
>The letter refers to a "Newbie Committer FAQ". I did not link
>in the newbie FAQ, since I thought it warranted a second by a
>current member of the Jakarta PMC.
>
>The proposed Newbie FAQ can be viewed at
><http://jakarta.apache.org/site/newbie.html>.
>
>It also occurs to me that something the incubator project can
>do is provide a template set of guidelines and procedures for
>the projects. In the way of guidelines, we have a draft set
>that includes several "clarifications" , in case anyone in the
>incubator project is interested in this idea.
>
><http://jakarta.apache.org/site/proposal.html>
>
>
There is some good stuff here - a lot of clarification over and
above the current Jakarta procedures.
There are some questions detailed below:
> If a Committer believes the explanation for a veto is
> invalid, an affirmation of the veto can be requested.
> If some other Committer does not affirm that the
> explanation for the veto is valid, the veto shall be
> void.
What is the timeframe within which the affirmation is
required? To be consitent with the other caveats, perhaps
a 5 day ceiling would be appropriate?
> If a dispute over a veto becomes intractable, the PMC
> may consent to arbitrate the matter, and, if appropriate,
> rescind the veto with a 3/4 majority vote of the PMC
> members.
3/4 majority seems too high - typically a 3/4 majority is
reserved for things like modification of the procedures
whereas 1/2 is used for establishment of concensus of the
PMC on a subject dealing with the property of the PMC.
Aside from the above - I like the document a lot (with just a
sneaking suspision thet the voting procedures read more like
a series of amendements and could possibly do with some sort
of refactoring of the current content). I'm willing to
provide whatever help I can.
Cheer, Steve.
>-Ted.
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: community-unsubscribe@apache.org
>For additional commands, e-mail: community-help@apache.org
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
Re: Welcome to Apache Letter
Posted by "Andrew C. Oliver" <ac...@apache.org>.
from www.m-w.com -
2: right something to which one has a just claim: as *a* *:* the power
or privilege to which one is justly entitled *b *(1) *:* the interest
that one has in a piece of property -- often used in plural <mineral
/right//s/> (2) /plural/ *:* the property interest possessed under law
or custom and agreement in an intangible thing especially of a literary
and artistic nature <film /right//s/of the novel>
*1 privilege:* a right or immunity granted as a peculiar benefit,
advantage, or favor *: PREROGATIVE
<http://www.m-w.com/cgi-bin/dictionary?book=Dictionary&va=prerogative>*;
/especially/ *:* such a right or immunity attached specifically to a
position or an office
---------------------
Generally the distinction is that rights can be defended and privileges
cannot. So in exchange for my contributions and stewardship over a
project I'm granted the right to help determine its direction. In the
event I feel my rights are violated I have the abillity to take my
cookies and go home, and hence ceasing my contributions and stewardship,
fork the codebase and continue on with a competing project. (good
example: openBSD freeBSD netBSD....)
Granted the seriousness of my doing this depends on the value of my
contributions (which is actually supports this more than weakens)..
I know I'm not supposed to even say such a thing, but the point is not
that I'm planning to do such a thing but that committers do have
"rights" that can be defended. Hence it is both a right and a privilege.
-Andy
Stefano Mazzocchi wrote:
> Peter Donald wrote:
>
>> On Wed, 30 Oct 2002 11:48, Stefano Mazzocchi wrote:
>>
>> >Peter Donald wrote:
>> >
>> >>Committers have no rights, just privlidges.
>> >
>> >What about the right to place a binding vote and propose somebody for
>> >commit access? aren't they rights?
>>
>>
>> Anyone can propose somebody for commit access (they may not be able
>> to vote
>> but that is besides the point) :)
>>
>> But a "binding vote" is a privlidge. If that privlidge is abused then it
>> should be reoved. ie Technically I believe I could still vote on Cocoon
>> (unless 6 months "retiring" has been acted on) when I shouldn't be
>> allowed
>> to. If I came in and decided that I didn't want cocoon to do something
>> because;
>> * I had my own pet xml framework that I wanted to promote above Cocoon
>> or
>> * I wanted to hurt some Cocoon committer because they had pissed me off
>> or
>> * I wanted to force cocoon to adopt my pet toolkit
>> or
>> ... ...
>>
>> And lets also assume I can come up with a valid technical reason
>> (should not
>> be hard). Do I still get to vote on this? Or to be more precise -
>> should I
>> get a vote on this?
>>
>> Or an even simpler example. When the ECM was being developed I
>> pointed out
>> several design decisions that I believed were mind numbingly stupid.
>> I could
>> quite easily figure out technical reasons to block its development and I
>> certainly helped enough to be classified as participating (I suspect
>> me and
>> leif have been the most active on it over last couple of months).
>> Even then -
>> do you think I have the "right" to veto changes for some petty
>> vindictive
>> reasons?
>>
>> Nope. Voting is definetly a privlidge, not a right. People who abuse
>> it by
>> using it as a weapon should have their privs yoinked.
>
>
> Gotcha.
>
> You're right, I was wrong. Voting is definately a priviledge :)
>
> Just one thing, if the voting rules remain the same since I wrote them
> in the java.apache constitution, technically, only committers can
> propose a person for commit access.
>
> In practice, there is probably no difference, but I think it's a good
> statement of IoC there as well and I like it.
>
Re: Welcome to Apache Letter
Posted by Stefano Mazzocchi <st...@apache.org>.
Peter Donald wrote:
> On Wed, 30 Oct 2002 11:48, Stefano Mazzocchi wrote:
>
> >Peter Donald wrote:
> >
> >>Committers have no rights, just privlidges.
> >
> >What about the right to place a binding vote and propose somebody for
> >commit access? aren't they rights?
>
>
> Anyone can propose somebody for commit access (they may not be able to
> vote
> but that is besides the point) :)
>
> But a "binding vote" is a privlidge. If that privlidge is abused then it
> should be reoved. ie Technically I believe I could still vote on Cocoon
> (unless 6 months "retiring" has been acted on) when I shouldn't be
> allowed
> to. If I came in and decided that I didn't want cocoon to do something
> because;
> * I had my own pet xml framework that I wanted to promote above Cocoon
> or
> * I wanted to hurt some Cocoon committer because they had pissed me off
> or
> * I wanted to force cocoon to adopt my pet toolkit
> or
> ... ...
>
> And lets also assume I can come up with a valid technical reason
> (should not
> be hard). Do I still get to vote on this? Or to be more precise -
> should I
> get a vote on this?
>
> Or an even simpler example. When the ECM was being developed I pointed
> out
> several design decisions that I believed were mind numbingly stupid. I
> could
> quite easily figure out technical reasons to block its development and I
> certainly helped enough to be classified as participating (I suspect
> me and
> leif have been the most active on it over last couple of months). Even
> then -
> do you think I have the "right" to veto changes for some petty vindictive
> reasons?
>
> Nope. Voting is definetly a privlidge, not a right. People who abuse
> it by
> using it as a weapon should have their privs yoinked.
Gotcha.
You're right, I was wrong. Voting is definately a priviledge :)
Just one thing, if the voting rules remain the same since I wrote them
in the java.apache constitution, technically, only committers can
propose a person for commit access.
In practice, there is probably no difference, but I think it's a good
statement of IoC there as well and I like it.
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
Re: Welcome to Apache Letter
Posted by Peter Donald <pe...@apache.org>.
On Wed, 30 Oct 2002 11:48, Stefano Mazzocchi wrote:
> Peter Donald wrote:
> > Committers have no rights, just privlidges.
>
> What about the right to place a binding vote and propose somebody for
> commit access? aren't they rights?
Anyone can propose somebody for commit access (they may not be able to vote
but that is besides the point) :)
But a "binding vote" is a privlidge. If that privlidge is abused then it
should be reoved. ie Technically I believe I could still vote on Cocoon
(unless 6 months "retiring" has been acted on) when I shouldn't be allowed
to. If I came in and decided that I didn't want cocoon to do something
because;
* I had my own pet xml framework that I wanted to promote above Cocoon
or
* I wanted to hurt some Cocoon committer because they had pissed me off
or
* I wanted to force cocoon to adopt my pet toolkit
or
... <insert some other personal reason> ...
And lets also assume I can come up with a valid technical reason (should not
be hard). Do I still get to vote on this? Or to be more precise - should I
get a vote on this?
Or an even simpler example. When the ECM was being developed I pointed out
several design decisions that I believed were mind numbingly stupid. I could
quite easily figure out technical reasons to block its development and I
certainly helped enough to be classified as participating (I suspect me and
leif have been the most active on it over last couple of months). Even then -
do you think I have the "right" to veto changes for some petty vindictive
reasons?
Nope. Voting is definetly a privlidge, not a right. People who abuse it by
using it as a weapon should have their privs yoinked.
--
Cheers,
Peter Donald
-----------------------------------------------
"You can't depend on your eyes when your
imagination is out of focus." -Mark Twain
-----------------------------------------------
Re: Welcome to Apache Letter
Posted by Peter Royal <pr...@apache.org>.
On Tuesday, October 29, 2002, at 07:48 PM, Stefano Mazzocchi wrote:
> Peter Donald wrote:
>
>> Committers have no rights, just privlidges.
>
> What about the right to place a binding vote and propose somebody for
> commit access? aren't they rights?
Nope, privileges too :) Privileges bestowed upon someone after
attaining commit access.
To weight my thoughts on the open/closed nature of the list...
Having an open list is fine, but I think having a closed list is also
beneficial. Perhaps we need a general@apache.org to serve the
public-list need.
-pete
--
peter royal -> proyal@apache.org
Re: Welcome to Apache Letter
Posted by Stefano Mazzocchi <st...@apache.org>.
Peter Donald wrote:
> Committers have no rights, just privlidges.
What about the right to place a binding vote and propose somebody for
commit access? aren't they rights?
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
Re: Welcome to Apache Letter
Posted by Peter Donald <pe...@apache.org>.
On Mon, 28 Oct 2002 05:49, Stephen McConnell wrote:
> The proposal document outlines an enhancement to semantics of the +1,
> +-0 and -1 voting model as described below:
>
> Each vote on an action item can be made in one of three four flavors:
>
> +1 The action should be performed, and I will help.
> +0 Abstain, I support the action but I can't help.
> -0 Abstain, I don't support the action but I can't help with an
> alternative.
> -1 The action should not be performed and I am offering an
> explanation or alternative.
>
> I think the addition of the qualification "and I will help" or "I can't
> help" is orthoginal to the expression of support for something.
They are othogonal but linked. You can not try and block something that you
don't have any intention of participating in. Or else we get twats who try
and block their "competition" by just -1'ing any change or improvement.
> In the
> case of the addition of a new committer - its not about suplying help or
> not,
yes it is. Everyone who votes +1 is responsible for helping that committer
become accustomed to the new project and making sure that they follow the
protocols etc.
> its aboout taking a position if a committer should be granted
> rights or not.
Committers have no rights, just privlidges.
> If its about code change - its possible for someone to
> express an valid and informed opinion and contribute a binding vote (+1
> or -1) without implication of a willingness to "help".
yep and the vote is called invalid.
--
Cheers,
Peter Donald
*------------------------------------------------*
| The student who is never required to do what |
| he cannot do never does what he can do. |
| - John Stuart Mill |
*------------------------------------------------*
Re: Welcome to Apache Letter
Posted by Stephen McConnell <mc...@apache.org>.
Ted Husted wrote:
>It also occurs to me that something the incubator project can
>do is provide a template set of guidelines and procedures for
>the projects. In the way of guidelines, we have a draft set
>that includes several "clarifications" , in case anyone in the
>incubator project is interested in this idea.
>
><http://jakarta.apache.org/site/proposal.html>
>
>
The proposal document outlines an enhancement to semantics of the +1,
+-0 and -1 voting model as described below:
Each vote on an action item can be made in one of three four flavors:
+1 The action should be performed, and I will help.
+0 Abstain, I support the action but I can't help.
-0 Abstain, I don't support the action but I can't help with an
alternative.
-1 The action should not be performed and I am offering an
explanation or alternative.
I think the addition of the qualification "and I will help" or "I can't
help" is orthoginal to the expression of support for something. In the
case of the addition of a new committer - its not about suplying help or
not, its aboout taking a position if a committer should be granted
rights or not. If its about code change - its possible for someone to
express an valid and informed opinion and contribute a binding vote (+1
or -1) without implication of a willingness to "help".
I would suggest re-phrasing the above as:
Each vote on an action item can be made in one of three four flavors:
+1 The action should be performed.
+0 Abstain, positive abstention.
-0 Abstain, negative abstention
-1 The action should not be performed (explanation or alternative
is required)
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
Re: Welcome to Apache Letter
Posted by Stephen McConnell <mc...@apache.org>.
Ted Husted wrote:
>On Jakarta, we have a sample letter that can be sent to
>Contributors when we are ready to nominate them as Committers.
>It occurred to me that we should also have a follow-up letter
>welcome them as a Committer. This would be a good place to
>insert some of points that have come up over Reorg and
>Community lately.
>
>Please see the updated page at
><http://jakarta.apache.org/site/roles.html> for a sample "Dear
>(new) Committer" letter.
>
>The letter refers to a "Newbie Committer FAQ". I did not link
>in the newbie FAQ, since I thought it warranted a second by a
>current member of the Jakarta PMC.
>
>The proposed Newbie FAQ can be viewed at
><http://jakarta.apache.org/site/newbie.html>.
>
>It also occurs to me that something the incubator project can
>do is provide a template set of guidelines and procedures for
>the projects. In the way of guidelines, we have a draft set
>that includes several "clarifications" , in case anyone in the
>incubator project is interested in this idea.
>
><http://jakarta.apache.org/site/proposal.html>
>
>
> Release Plan
> A release plan is used to keep all volunteers aware of
> when a release is desired, who will be the Release Manager,
> when the repository will be frozen to create a release, and
> other assorted information to keep volunteers from tripping
> over each other. Lazy majority decides each issue in a
> release plan, or lazy consensus if the issue involves a
> product change.
Under the current wording there is no obligation of a sub-project to
notify its PMC of a release. Based on all of the reorg traffic it seems
to me that a release is a sufficiently significant even that there
should be something in the procedures that requires explicit
notification of a release to the responsible PMC.
Cheers, Steve.
>-Ted.
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: community-unsubscribe@apache.org
>For additional commands, e-mail: community-help@apache.org
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net