[haiku-development] Another way to decide on commit access( was: Voting procedure (was: Checking consistency of used strings))
- From: Niels Reedijk <niels.reedijk@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 16 Dec 2009 10:10:49 +0100
Hi,
Splitting this off to another thread to please future mailing list etiquette.
2009/12/15 Ingo Weinhold <ingo_weinhold@xxxxxx>:
> On 2009-12-15 at 22:22:40 [+0100], PulkoMandy <pulkomandy@xxxxxxxxx> wrote:
>>
>> For commit access, usually there are only +1 votes, I think that explains
>> the low interest : it should probably be presented as a "if you don't want
>> this guy to get commit access, tell us why now, or it will be too late".
>
> That wouldn't change anything. The problem with commit access votes is that
> you should only vote at all when you can judge the candidate's skills. I.e.
> if you've never read a patch from her/him, you shouldn't vote +1 (or -1 for
> that matter). Unfortunately that costs time and most people don't have or
> take it. Which kind of shifts the main responsibility to the developer
> proposing the candidate. I think no-one should propose to give someone
> commit access, unless she/he has very thoroughly read prior patches/work
> written by the candidate. Votes starting with "Hey, why not given X and Y
> commit access?" are simply a no-go, IMHO.
>
> Also before actually starting a commit access vote, it should first be
> asked whether there are general concerns. Otherwise those will be raised
> after half a dozen people have already cast their perfunctory vote, which
> is a somewhat awkward situation.
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.
> 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.'
N>
Other related posts:
