[haiku-development] Re: Another way to decide on commit access( was: Voting procedure (was: Checking consistency of used strings))

  • From: Stephan Assmus <superstippi@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Wed, 16 Dec 2009 16:04:12 +0100

Hi,

On 2009-12-16 at 10:10:49 [+0100], Niels Reedijk <niels.reedijk@xxxxxxxxx> 
wrote:
> I very much agree with the fact that the quality of the work is at issue. 
> I also agree that people not familiar with the work are not in the 
> position to vote.
> 
> That's why we should consider going to a model which is not based on a 
> majority vote (which is not representative of quality) to another model 
> where a new contributor has to ask for endorsement by two or three 
> contributors that are familiar with his/her work.

This makes things more complicated without any benefit: It is possible to 
find three people who give endorsement, but nobody guarantees those people 
really looked at the patches throughroughly (theoretically). On the other 
hand, it must be possible for people to object, for example, someone may 
have looked at the patches and doesn't find them nice, but is not among the 
people who give endorsement... That means back to some kind of voting.

What Ingo proposed seems to achieve the goal in a much easier/flexible way.


> > Whether formal metrics might help, I don't know. It probably doesn't 
> > harm to have a rough guideline, to prevent people from being suggested 
> > for commit access who have only committed a few minor patches. But I 
> > don't think their should be any kind of automatism, that someone is 
> > suggested, just because the minimum patch count or whatever has been 
> > reached.
> 
> The formal metrics will set a standard for a minimal body of work. They 
> help setting a standard to which a potential new developer will have to 
> at least adhere to. It will also give devs (that are asked to endorse 
> someone) some backing to say 'no, you did not do enough yet.'

Unfortunately, the number of patches does not tell you how much time and 
skill was invested. Sometimes you can track down a bug, be exposed to and 
understand tons of code, and then finally send a one line patch with the 
fix. On the other hand, you can commit 10 patches which correct spelling in 
comments or fix coding style issues -- which is of course also appreciated, 
but doesn't tell you anything about that persons coding skills when he is 
going to use his commit access to write new code.

Bottom line again: What Ingo said already addresses this problem: There 
have to be some people familiar with that persons patches and coding 
skills, a short discussion should happen, and then a vote that gives people 
a chance to object.

Best regards,
-Stephan

Other related posts: