On Thu, Oct 24, 2002 at 02:35:15AM +0200, Martin van den Bemt wrote: > On Thu, 2002-10-24 at 01:53, Greg Stein wrote: > > On Tue, Oct 22, 2002 at 12:30:27AM -0700, Aaron Bannert wrote: >... > > > I agree. Karma and voting rights should always cover the same territory. > > > > Note that "karma" might be enforced via the 'avail' file, or it might simply > > be "we're adults here and know which codebases we have commit access to". > > In j-c it works like this : if you fix something in a project you never > fixed something in, add yourself to the status file and commit the fix. > (that's what the charter says). In real life it will be put up for > discussion first and then committed.
Then the charter should reflect "real life". > Allowing votes from people who are not directly involved has (in my > opinion) just benefits. It makes a community, since it can trigger you > to have a deeper look into the component and possibly provide extra > input. If a person is going to have a deeper look and provide extra input, then they can and will do that regardless of their commit ability. The active contributors to a code base or component (the committers) are the "stakeholders". They have a specific and personal interest in the development and advancement of that component. This is why they are they only people who get to vote -- they are, by definition, the people who care. If a new person arrives with their own interest in the component, and they start providing high quality patches, then after a while they have demonstrated they are, too, a stakeholder in the outcome of the component. By limiting vetos to the committers/stakeholders, you have a much higher guarantee that the veto is for constructive benefit. Since each person has a stake in the component, they are not going to be obstructionist. Allowing arbitrary people to come along and just commit stuff to CVS (after the minor bar of adding themselves to a STATUS file somewhere) simply invites problems. The commit might be against the desires of the people who have a serious interest in the component. The commit might interfere with plans, it might cause conflicts with a work in progress, it might not have a full understanding of the problem. If I arrive at the Apache Commons based on my ability to commit to the "serf" project, then I have zero rights to commit to other codebases. Not the Avalon components, not the J-C components, and not the XML components. I have to *earn* that right. And I earn it by providing a long term contribution to the component in the form of high quality patches, discussion, and demonstrated interest. At that point, I earn my ability to commit to the component in question, along with the related benefit of being able to vote on the direction and care of the component. > I suggest not "closing" a new community (apache-commons) in front, since > it is working in real life and the process doesn't need fixing (this > saying, assuming the apache-commons will be (partly) modeled after j-c I would maintain that it doesn't respect the rights of the stakeholders in the components. While j-c might be "working" in the sense of producing useful code, I don't believe that it is based on the fundamental model of merit. I also believe that it does not scale very well, particularly across different domains. A Java server component programmer should not have the ability to tweak a Perl-based GUI component... *unless* they have demonstrated competency and merit. > > Personally, I think it will be a pain to manage the avail file in too much > > detail, so punting would be nice, and just rely on people being adults. (and > > the fact that we have version control and can revert commits that were > > accidentally out of bounds) > > Agreed indeed ;) (I should read everything before I type.. > At least you have some feedback of how I experience the j-c as a > committer ;) Yes, thank you -- I appreciate hearing from J-C committers. The intent and hope of the Apache Commons was to get input from the existing Commons projects, in terms of the good and the bad. But to be clear: I was only advocating that we don't bother with fine-grained access control through the avail file. I *am* advocating that, as an adult, we refrain from committing to components for which we are not designated committers/stakeholders (even though we have the technical ability to make such a commit). Cheers, -g -- Greg Stein, http://www.lyra.org/
