You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@commons.apache.org by Greg Stein <gs...@lyra.org> on 2002/10/24 01:50:10 UTC
veto rights (was: Naming issues)
On Tue, Oct 22, 2002 at 12:34:27AM -0700, Aaron Bannert wrote:
>...
> When a veto is cast, it must be accompanied by technical justification
> and should also include an alternative proposal. I just don't think
> that people who aren't involved in a project at a code level can
> make valid technical justifications. Maybe that is the beauty of
> the system, since if non-contributors can't make valid technical
> justifications, then we don't have to worry about spurrious vetos. :)
This is a *very* important point. There has been significant talk about
improper veto usage in some projects. To prevent that kind of misuse, a veto
*must* have technical justification.
The veto must also come from somebody with voting rights on the change (or
proposed code change) in question. Voting rights are based on merit. If you
are a regular contributor (read: patch supplier or similar), then you get
commit access to a component. At that point, you get a vote on changes to
that component.
Note the contrast with the "all j-c committers have voting rights on all j-c
components." I do not believe that works, and will not vote-for/support such
a model for the Apache Commons. I think the model will be multiple
components within the Commons, with associated groups of committers and
voters.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: veto rights (was: Naming issues)
Posted by Morgan Delagrange <md...@yahoo.com>.
--- Greg Stein <gs...@lyra.org> wrote:
> On Wed, Oct 23, 2002 at 06:20:05PM -0700, Morgan
> Delagrange wrote:
[snip]
> > I'm also not necessarily attached to the free
> voting
> > part of j-c except insofar as it doesn't restrict
> > people from contrtibuting to all components
> without
> > calling some sort of karma vote.
>
> Hmm... I'm not sure how to parse that sentence.
> Could you rephrase?
Sorry, I think the lack of clarity here gave my email
the wrong connotation. Let's rephrase it as "I
supported allowing any j-c committer to vote on any
component, because it simplified (removed, actually)
the barriers between components". All my subsequent
statements were with regard to committers (people who
had already obtained commit access via substantial
code contributions).
> > The problem is where to draw the line.
> >
> > Someone who edits a single javadoc shouldn't vote,
> but
> > someone who cleans up all the documentation
> should.
> > Someone who fixes a typo in an excecption
> shouldn't,
> > someone who fixes exception handling should.
> Someone
> > who fixes a single significant bug should,
> shouldn't,
> > who knows?
>
> Merit answers all of these. If somebody supplies you
> with single-line
> patches for a long and consistent period, then give
> them commit access.
> Presumably, they'll continue applying the same kinds
> of changes. If they
> just send a single patch, then they wouldn't get the
> commit privs, so you've
> already answered your question on where the line is.
My fault for not being clear. I'm referring to people
who are _already_ committers, but are making
contributions to a new component. It's more difficult
to track their contributions because they're already
"in", and in any event it becomes awkward to say with
every vote, "ok, who's _really_ helped out, and who
just sort of helped out."
> If somebody is sending in big patches that really
> hit everything or show a
> critical understanding of the code, then give them
> commit access so they can
> directly apply their energy.
Yup I don't dispute that we should have high standards
for commit access. However once they've become a
committer, I think they should work on any components
they choose which (I think) you support too.
> > It's a difficult issue on which we punted
> > at j-c, erring on the side of inclusion. If you
> want
> > to take it on, then find that magic formula to
> figure
> > out when a contributor "counts". I'm not saying
> it
> > can't be done, but make sure you make an informed
> > choice. And be aware that someone who is truly
> petty
> > will find a way to subvert any rule you formulate.
>
> > That's why we chose to just trust people's
> judgement.
>
> If somebody subverts the rules, then you bust them.
> Pretty darned simple.
I agree. Sometimes I wish there was a little more
busting going on.
> The "magic formula" is have the committers on a
> component determine when a
> prospect appears to "get it" and is given commit
> privs. Human judgement is
> involved in that decision, and gives you a way to
> decied when a contributor
> really "counts".
>
> Of course, there is the possibility that an existing
> set of committers won't
> give a consistent contributor their own commit
> privs. That can be a problem
> and would be something for the PMC to deal with
> ("this person appears to be
> a solid contributor. why don't they have commit
> access?")
>
> If you want to err on the side of inclusion, then
> set the bar low for commit
> access. But that gate should be there.
Just to be clear, is there one bar for commit access
to all components, or a bar for each component? If
it's the former, then I agree. I also _may_ agree in
slightly finer gradations, like one bar per language.
But having to gain commit access to each Apache
Commons component despite having commit access to
other components is too restrictive.
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> general-unsubscribe@commons.apache.org
> For additional commands, e-mail:
> general-help@commons.apache.org
>
=====
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org
http://jakarta.apache.org/watchdog
__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/
Re: veto rights (was: Naming issues)
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Oct 23, 2002 at 06:20:05PM -0700, Morgan Delagrange wrote:
>...
> > The 'intent' (IMHO, of course) of the j-c commit
> > model, was that everyone had avail access to all
> > code, but you had to add yourself as a member of the
> > project before you committed to it. This was
> > ultimately end run where people would just add
> > themselves and then veto,
Yup, I can see that, and your comment that it actually occurred causes me
worry. The merit-based approach that I described is designed specifically to
inhibit such behaviors.
[ well, "designed" is a bit strong... you could say it evolved and is part
of the basis for that nebulous term "Apache Way" -- you only get to vote
if you're an active participant ]
> > but I think the general
> > idea of gaining access to a project is a good idea.
It does tend to work well :-)
> > The most useful thing here is that since j-c has so
> > many smaller projects (in terms of code size), that
> > anyone willing to review and commit a patch is a
> > good thing. If you don't know much about the
> > component, you don't commit the patch, but if you
> > have a good idea about, but just not the bandwidth
> > to completly participate, commit the patch. Some
> > may disagree with this, but I am a firm beleiver, as
> > the codebase size approaches zero.
Yes, this can be handy for small codebases. I might respond that the correct
answer is to aggregate those codebases. You end up turning 10 small bits,
each with one committer, into a larger group where patch review and
application can be shared by 10 people.
Let's look at your comment in a bit more detail:
* "anyone willing to review and commit a patch is a good thing"
The more, the merrier, yes. And anybody *can* review a patch. You don't
have to be a committer to do that. In fact, doing this is a step towards
earning your commit rights. It can show how you work with others, that you
have interest in the codebase, that you be constructive, and that you're
willing to spend the time.
The part about committing is trickier, though. "anyone" can create real
problems, as I've explained elsewhere. A drive-by committer might not
understand enough to be responsible for the commit. Worse, they might not
realize that, think they know what is up, and commit away...
* "if you don't know much about the component, ..."
This rule is easily handled by the merit-to-commit rule. Your demonstrated
knowledge of the component gets your commit privs. If you don't know
anything about the component, then you're already denied the ability to
commit patches.
* "if you have a good idea about, but just not the bandwidth to participate,
commit the patch"
This one is a bit tougher. If you've earned the commit privs in the past,
but aren't participating much any more, then this can be a good thing.
You have one more person who can help the project. Of course, lack of
active participation might also mean you suffer bit rot, and fall into
the "not knowing" category, but it is best to assume that any previous
committer is still competent. (i.e. once you're in, then you're in for
life :-)
The harder problem is the relatively inactive person who probably knows
their stuff, but hasn't demonstrated particular interest/merit for the
given component. How do you take advantage of their time and inclination
to apply patches?
a) too bad, the patch just sits idle
b) lower your bar for officially granting commit privs (the PHP people do
this to great effect)
c) depending upon the karma setup (CVSROOT/avail), the person might have
the technical ability (but not the Right) to do the patch; but a real
committer might say, "looks good. can you handle applying it?"
The Subversion team does this well; we have a lot of committers that
are "scoped" to only work in particular areas, but they can
technically commit anywhere; if they come up with a patch "out of
their area", then they sent the patch to the list and get a +1 on
applying it. This allows the main devs to apply some control and
though to what goes in, yet distributes the load of patch application.
> I'm also not necessarily attached to the free voting
> part of j-c except insofar as it doesn't restrict
> people from contrtibuting to all components without
> calling some sort of karma vote.
Hmm... I'm not sure how to parse that sentence. Could you rephrase?
> The problem is where to draw the line.
>
> Someone who edits a single javadoc shouldn't vote, but
> someone who cleans up all the documentation should.
> Someone who fixes a typo in an excecption shouldn't,
> someone who fixes exception handling should. Someone
> who fixes a single significant bug should, shouldn't,
> who knows?
Merit answers all of these. If somebody supplies you with single-line
patches for a long and consistent period, then give them commit access.
Presumably, they'll continue applying the same kinds of changes. If they
just send a single patch, then they wouldn't get the commit privs, so you've
already answered your question on where the line is.
If somebody is sending in big patches that really hit everything or show a
critical understanding of the code, then give them commit access so they can
directly apply their energy.
> It's a difficult issue on which we punted
> at j-c, erring on the side of inclusion. If you want
> to take it on, then find that magic formula to figure
> out when a contributor "counts". I'm not saying it
> can't be done, but make sure you make an informed
> choice. And be aware that someone who is truly petty
> will find a way to subvert any rule you formulate.
> That's why we chose to just trust people's judgement.
If somebody subverts the rules, then you bust them. Pretty darned simple.
The "magic formula" is have the committers on a component determine when a
prospect appears to "get it" and is given commit privs. Human judgement is
involved in that decision, and gives you a way to decied when a contributor
really "counts".
Of course, there is the possibility that an existing set of committers won't
give a consistent contributor their own commit privs. That can be a problem
and would be something for the PMC to deal with ("this person appears to be
a solid contributor. why don't they have commit access?")
If you want to err on the side of inclusion, then set the bar low for commit
access. But that gate should be there.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: veto rights (was: Naming issues)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> On Thu, 24 Oct 2002 11:20, Morgan Delagrange wrote:
>
>>Someone who edits a single javadoc shouldn't vote, but
>>someone who cleans up all the documentation should.
>>Someone who fixes a typo in an excecption shouldn't,
>>someone who fixes exception handling should. Someone
>>who fixes a single significant bug should, shouldn't,
>>who knows?
>
> It is up to the components maintainers/developers.
Yes, now I agree.
It's not up to the committers.
> They are the people who are
> in the best position to judge whether a candidate should be given voting
> rights. Some may choose to be more exclusive and some may be a free for all -
> however it will always be the develoeprs who decide where their component
> evolves.
Yes, developers of the component, and mind me *not* the _original_
developers, but the ones active on it ATM and the ones that have more
heavily been involved in it.
For example, Stefano's -1s and committs in Cocoon are never seen as
intrusion even if lately he hasen't touched the code much, because of
the *massive* effort that he has put in it in all these years, not just
because he designed it.
Likewise, Peter rightly didn't like my stupid -1 on his code.
I dodn't help make it, I didn't even know it as he does, what right did
I have to stop him, *even* if I has what I *thought* was a better
technical alternative?
After all, it's not only about better technical stuff, it's also about
legacy, history of failed tried, and most important of who makes those
damn fixes and *maintains* them.
Before coming into Avalon
I had never worked in a multi-component project; the others I had been
in are mostly monolithic or I know them all for some time.
For the first time I found myself not knowing parts of the codebase in a
multi-component community, and got confused.
But gee, I think I got it well now! :-D
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: veto rights (was: Naming issues)
Posted by Morgan Delagrange <md...@yahoo.com>.
--- Rodent of Unusual Size <Ke...@Golux.Com> wrote:
> Morgan Delagrange wrote:
> >
> > See, that's what bugs me. If I contribute
> > significantly, I should be able to vote in my
> opinion.
>
> if by 'contribute' you mean you consistently submit
> patches that frequently get accepted, then you
> should be heading for commit status and a vote. if
> that doesn't happen, at least in this project, say
> so to the pmc.
>
> > Well, I don't quite agree, but I'm willing to
> concede
> > the point as long as once I gain commit access to
> > "Apache Commons", I can commit to all components
> and
> > not just the component(s) to which I've already
> > contributed.
>
> i'm hesitant about this, but i'm certainly willing
> to entertain
> it as an initial model. if it gets abused, though,
> it
> may change.
> --
> #ken P-)}
>
To me, it seems most in line with the long-term goals
of a reorg. Isn't one of the potential objections to
the Jakarta project the stratification (a bunch of
subprojects, each with its own karma and voters)? If
each Jakarta Commons component has its own karma and
voters as well, it seems that you've created
"subprojects" with a different name.
- Morgan
=====
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org
http://jakarta.apache.org/watchdog
__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/
Re: veto rights (was: Naming issues)
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Morgan Delagrange wrote:
>
> See, that's what bugs me. If I contribute
> significantly, I should be able to vote in my opinion.
if by 'contribute' you mean you consistently submit
patches that frequently get accepted, then you
should be heading for commit status and a vote. if
that doesn't happen, at least in this project, say
so to the pmc.
> Well, I don't quite agree, but I'm willing to concede
> the point as long as once I gain commit access to
> "Apache Commons", I can commit to all components and
> not just the component(s) to which I've already
> contributed.
i'm hesitant about this, but i'm certainly willing to entertain
it as an initial model. if it gets abused, though, it
may change.
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
"Millennium hand and shrimp!"
Carte blanche commit access, WAS: RE: veto rights
Posted by Sander Striker <st...@apache.org>.
> From: Morgan Delagrange [mailto:mdelagra@yahoo.com]
> Sent: 24 October 2002 18:35
> --- Peter Donald <pe...@apache.org> wrote:
>> On Thu, 24 Oct 2002 11:20, Morgan Delagrange wrote:
>> It is up to the components maintainers/developers.
>> They are the people who are in the best position
>> to judge whether a candidate should be given voting
>> rights. Some may choose to be more exclusive and
>> some may be a free for all - however it will always
>> be the develoeprs who decide where their component
>> evolves.
>
> See, that's what bugs me. If I contribute significantly,
> I should be able to vote in my opinion.
Vote on what? On the components you have _significantly_
contributed to (IOW, you should have commit privilidges)?
Or on any component? If the latter, I'd say, no, you
haven't earned the right to vote on those components
(that is, not cast binding votes, non-binding is ok).
> However in the absense of a reasonable metric for
> significant contributions, it's left to the judgement
> of established developers who may or may not be
> "exclusive". Again, I think you err on the side of
> inclusion.
Personally I think it works fine. If not, there is
always a PMC that can step in and ask why this significant
contributor still hasn't got commit privs.
> Well, I don't quite agree, but I'm willing to concede
> the point as long as once I gain commit access to
> "Apache Commons", I can commit to all components and
> not just the component(s) to which I've already
> contributed.
I'd say "forget it" personally. I don't think it is
a good idea to give people carte blanche once they
have contributed to one component. At least not
without the explicit permission of the developers of
that component.
If your patches are good, gaining commit privilidges
shouldn't be a problem. If it is, because the developers
on that component are being (overly) exclusive, the
PMC can step in and ask for clarification. [deja-vu]
I'm getting the feeling I'm rehashing something that
was said before though... And yes:
Message-ID: <20...@lyra.org>
Greg said it a lot better too ;)
Sander
Re: veto rights (was: Naming issues)
Posted by Morgan Delagrange <md...@yahoo.com>.
--- Peter Donald <pe...@apache.org> wrote:
> On Thu, 24 Oct 2002 11:20, Morgan Delagrange wrote:
> > Someone who edits a single javadoc shouldn't vote,
> but
> > someone who cleans up all the documentation
> should.
> > Someone who fixes a typo in an excecption
> shouldn't,
> > someone who fixes exception handling should.
> Someone
> > who fixes a single significant bug should,
> shouldn't,
> > who knows?
>
> It is up to the components maintainers/developers.
> They are the people who are
> in the best position to judge whether a candidate
> should be given voting
> rights. Some may choose to be more exclusive and
> some may be a free for all -
> however it will always be the develoeprs who decide
> where their component
> evolves.
See, that's what bugs me. If I contribute
significantly, I should be able to vote in my opinion.
However in the absense of a reasonable metric for
significant contributions, it's left to the judgement
of established developers who may or may not be
"exclusive". Again, I think you err on the side of
inclusion.
Well, I don't quite agree, but I'm willing to concede
the point as long as once I gain commit access to
"Apache Commons", I can commit to all components and
not just the component(s) to which I've already
contributed.
- Morgan
> --
> Cheers,
>
> Peter Donald
> A right is not what someone gives you; it's what no
> one can take from you.
> -- Ramsey Clark
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> general-unsubscribe@commons.apache.org
> For additional commands, e-mail:
> general-help@commons.apache.org
>
=====
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org
http://jakarta.apache.org/watchdog
__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/
Re: veto rights (was: Naming issues)
Posted by Peter Donald <pe...@apache.org>.
On Thu, 24 Oct 2002 11:20, Morgan Delagrange wrote:
> Someone who edits a single javadoc shouldn't vote, but
> someone who cleans up all the documentation should.
> Someone who fixes a typo in an excecption shouldn't,
> someone who fixes exception handling should. Someone
> who fixes a single significant bug should, shouldn't,
> who knows?
It is up to the components maintainers/developers. They are the people who are
in the best position to judge whether a candidate should be given voting
rights. Some may choose to be more exclusive and some may be a free for all -
however it will always be the develoeprs who decide where their component
evolves.
--
Cheers,
Peter Donald
A right is not what someone gives you; it's what no one can take from you.
-- Ramsey Clark
A "swami" perspective on communities
Posted by Martin van den Bemt <ml...@mvdb.net>.
Hi World of Apache ;)
> That's why we chose to just trust people's judgement.
The "freedom" adds the extra spark to j-c in my opinion.
The leads to one of the great wisdoms the swami in me picked up from
somewhere :
<swami_mode>
Freedom brings up responsibility and rules remove people from being
responsible. By accepting rules of any kind a community actually is
saying "we don't have a common sense".
If a community has a common sense, rules are not needed, period.
</swami_mode>
How does this statement apply to apache.
Let's assume apache is the world
<apache_is_the_world>
Apache doesn't need any rules.
Now say Big Bad Wolf (who is part of the community) does an rm -rf
/home/cvs (intentionally)
What actually happened here ?
1) Did Big Bad Wolf fail the community?
2) Did the community fail as a whole?
None of the above, since Big Bad Wolf failed himself.
Now the 3 piggies say : Hey someone deleted /home/cvs!!!
We want to have rules that it is not allowed!
Whoops what happened here ?
1) Did the 3 piggies fail themselves ?
2) Did the community fail as a whole ?
I hope you answered 1, since we are still a community.
The 3 piggies start a vote to get this rule in place
The 3 piggies of course say +1
When all votes are counted the majority decides to have the rule in
place.
1) Did the community fail as a whole ?
2) Did the community become stronger because of this rule ?
I hope you chose number 1
The effort of Big Bad Wolf to fail himself, has undermined a complete
community. The community now by default assumes that everybody is
capable of failing himself.
Mistrust grows between each other.
What else are people in my community capable of ?
What if...
More rules come in place, since what ifs can be scary ones.
Ego's take over the community and so the community is gone.
Some seek power to control the others and the community sense is further
removed.
Now we are just a bunch individuals who are having private agenda's and
private goals.
A couple of people however still have the community in mind. For the
greater good of the community they seperate themselves for the rest, to
not be distracted from the "spark" they still have.
If the community did not accept the rule in the first place, it would
still have the "spark" that comes with it and will still reside in
"heaven"..
</apache_is_the_world>
<apache_as_part_of_the_world>
I did the seperation between the two tags, because apache needs some
rules, because the bad scenario described above happened in the world
outside of apache (liability, etc,etc,etc).
Too bad, these rules need to be in place to be able to keep the
community in mind.
Any other rule needed within apache is just breaking up the community
and will stand in the way of any progress.
</apache_as_part_of_the_world>
They, them, those etc are all signs of possible seperation in
communities, which undermine the goals we want to achieve. If we just
accept the fact that the community can never fail, we will experience
greater achievements then anyone can imagine.
Mvgr,
Martin
NickName : Swami Baahmi ;)
A "swami" perspective on communities
Posted by Martin van den Bemt <ml...@mvdb.net>.
Hi World of Apache ;)
> That's why we chose to just trust people's judgement.
The "freedom" adds the extra spark to j-c in my opinion.
The leads to one of the great wisdoms the swami in me picked up from
somewhere :
<swami_mode>
Freedom brings up responsibility and rules remove people from being
responsible. By accepting rules of any kind a community actually is
saying "we don't have a common sense".
If a community has a common sense, rules are not needed, period.
</swami_mode>
How does this statement apply to apache.
Let's assume apache is the world
<apache_is_the_world>
Apache doesn't need any rules.
Now say Big Bad Wolf (who is part of the community) does an rm -rf
/home/cvs (intentionally)
What actually happened here ?
1) Did Big Bad Wolf fail the community?
2) Did the community fail as a whole?
None of the above, since Big Bad Wolf failed himself.
Now the 3 piggies say : Hey someone deleted /home/cvs!!!
We want to have rules that it is not allowed!
Whoops what happened here ?
1) Did the 3 piggies fail themselves ?
2) Did the community fail as a whole ?
I hope you answered 1, since we are still a community.
The 3 piggies start a vote to get this rule in place
The 3 piggies of course say +1
When all votes are counted the majority decides to have the rule in
place.
1) Did the community fail as a whole ?
2) Did the community become stronger because of this rule ?
I hope you chose number 1
The effort of Big Bad Wolf to fail himself, has undermined a complete
community. The community now by default assumes that everybody is
capable of failing himself.
Mistrust grows between each other.
What else are people in my community capable of ?
What if...
More rules come in place, since what ifs can be scary ones.
Ego's take over the community and so the community is gone.
Some seek power to control the others and the community sense is further
removed.
Now we are just a bunch individuals who are having private agenda's and
private goals.
A couple of people however still have the community in mind. For the
greater good of the community they seperate themselves for the rest, to
not be distracted from the "spark" they still have.
If the community did not accept the rule in the first place, it would
still have the "spark" that comes with it and will still reside in
"heaven"..
</apache_is_the_world>
<apache_as_part_of_the_world>
I did the seperation between the two tags, because apache needs some
rules, because the bad scenario described above happened in the world
outside of apache (liability, etc,etc,etc).
Too bad, these rules need to be in place to be able to keep the
community in mind.
Any other rule needed within apache is just breaking up the community
and will stand in the way of any progress.
</apache_as_part_of_the_world>
They, them, those etc are all signs of possible seperation in
communities, which undermine the goals we want to achieve. If we just
accept the fact that the community can never fail, we will experience
greater achievements then anyone can imagine.
Mvgr,
Martin
NickName : Swami Baahmi ;)
Re: veto rights (was: Naming issues)
Posted by Morgan Delagrange <md...@yahoo.com>.
--- Scott Sanders <sa...@apache.org> wrote:
> On Wed, Oct 23, 2002 at 04:50:10PM -0700, Greg Stein
> wrote:
[...]
>
> > Note the contrast with the "all j-c committers
> have voting rights on all j-c
> > components." I do not believe that works, and will
> not vote-for/support such
> > a model for the Apache Commons. I think the model
> will be multiple
> > components within the Commons, with associated
> groups of committers and
> > voters.
>
> The 'intent' (IMHO, of course) of the j-c commit
> model, was that everyone had avail access to all
> code, but you had to add yourself as a member of the
> project before you committed to it. This was
> ultimately end run where people would just add
> themselves and then veto, but I think the general
> idea of gaining access to a project is a good idea.
>
> The most useful thing here is that since j-c has so
> many smaller projects (in terms of code size), that
> anyone willing to review and commit a patch is a
> good thing. If you don't know much about the
> component, you don't commit the patch, but if you
> have a good idea about, but just not the bandwidth
> to completly participate, commit the patch. Some
> may disagree with this, but I am a firm beleiver, as
> the codebase size approaches zero.
>
I'm also not necessarily attached to the free voting
part of j-c except insofar as it doesn't restrict
people from contrtibuting to all components without
calling some sort of karma vote. The problem is where
to draw the line.
Someone who edits a single javadoc shouldn't vote, but
someone who cleans up all the documentation should.
Someone who fixes a typo in an excecption shouldn't,
someone who fixes exception handling should. Someone
who fixes a single significant bug should, shouldn't,
who knows? It's a difficult issue on which we punted
at j-c, erring on the side of inclusion. If you want
to take it on, then find that magic formula to figure
out when a contributor "counts". I'm not saying it
can't be done, but make sure you make an informed
choice. And be aware that someone who is truly petty
will find a way to subvert any rule you formulate.
That's why we chose to just trust people's judgement.
- Morgan
=====
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org
http://jakarta.apache.org/watchdog
__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/
Re: veto rights (was: Naming issues)
Posted by Scott Sanders <sa...@apache.org>.
On Wed, Oct 23, 2002 at 04:50:10PM -0700, Greg Stein wrote:
> On Tue, Oct 22, 2002 at 12:34:27AM -0700, Aaron Bannert wrote:
> >...
> > When a veto is cast, it must be accompanied by technical justification
> > and should also include an alternative proposal. I just don't think
> > that people who aren't involved in a project at a code level can
> > make valid technical justifications. Maybe that is the beauty of
> > the system, since if non-contributors can't make valid technical
> > justifications, then we don't have to worry about spurrious vetos. :)
>
> This is a *very* important point. There has been significant talk about
> improper veto usage in some projects. To prevent that kind of misuse, a veto
> *must* have technical justification.
>
Excellent. Thank you, I will reference this email many, many times ;)
> Note the contrast with the "all j-c committers have voting rights on all j-c
> components." I do not believe that works, and will not vote-for/support such
> a model for the Apache Commons. I think the model will be multiple
> components within the Commons, with associated groups of committers and
> voters.
The 'intent' (IMHO, of course) of the j-c commit model, was that everyone had avail access to all code, but you had to add yourself as a member of the project before you committed to it. This was ultimately end run where people would just add themselves and then veto, but I think the general idea of gaining access to a project is a good idea.
The most useful thing here is that since j-c has so many smaller projects (in terms of code size), that anyone willing to review and commit a patch is a good thing. If you don't know much about the component, you don't commit the patch, but if you have a good idea about, but just not the bandwidth to completly participate, commit the patch. Some may disagree with this, but I am a firm beleiver, as the codebase size approaches zero.
--
Scott Sanders - sanders@apache.org