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.
