[GRASS-PSC] Voting

[Paul Kelly]

On Mon, 4 Feb 2008, Helena Mitasova wrote:
>
>> On Sunday 03 February 2008, Hamish wrote:
[...]
>>> our little development team works. In addition it gives PSC voters a
>>> chance to be confident in our votes rather than rubber stamping our
>>> approval on a mostly unknown entity.
>> 
[...]
> I would suggest something more like an incubation time - in our case
> the PSC developer  would motion that a new developer is up for SVN access
> vote so the PSC can look at what
> he has contributed, test the changes that he has submitted and after
> additional set of submissions that PSC has a chance to carefully monitor,
> the PSC developer would ask for a vote. PSC may decide that more time is

These comments from Hamish and Helena touch on an issue that has been 
bothering me for a long time; apologies for being annoying and bringing it 
up again but the time now seems right: PSC Voting!

I'm unhappy with the not-yet-adopted RFC3 and the system of voting +1, -1, 
0, +0 or -0. I don't think it suits our needs and the types of things we 
vote on at all. I share Hamish's concern about "rubber stamping" and add 
to that mine that no one ever seems to vote anything other than "+1" - I 
feel that is proof the system isn't working.

Quoting the relevant section of RFC3:
=====================================
3. Respondents may vote "+1" to indicate support for the proposal and a 
willingness to support implementation.

4. Respondents may vote "-1" to veto a proposal, but must provide clear 
reasoning and alternative approaches to resolving the problem within the 
period the issue is open for discussion/voting. Otherwise the veto will be 
considered invalid.

5. A vote of -0 indicates mild disagreement, but has no effect. A 0 
indicates no opinion. A +0 indicate mild support, but has no
effect.

6. A proposal will be accepted if it receives +2 (including the proposer) 
and no vetoes (-1).
=====================================

FWIW, here's how I feel the system was designed to work:
(Bearing in mind, AFAIK, it was originally used in the Apache project, 
where the PSC was intended to be a highly technical central core of 
developers voting on new ideas to be implemented in the software.)

A +1 means, as mentioned above "willingness to support implementation". 
This is a very strong vote which commits the voter to putting in effort to 
make sure the proposal becomes reality. Note that only two +1 votes are 
required for a proposal to pass. This could be perhaps the proposer who 
would do the bulk of the coding work on whichever new technical feature 
was proposed and someone else who would review it, offer encouragement and 
suggestions etc. -1 should be obvious, and the other votes are just a way 
of indicating consensus (is this a good idea or not?) without committing 
the voter to actually do anything. Personally I think consensus should be 
achieved through enough discussion that there is no need for voting and 
everyone is happy, but that's a separate issue...

If we try and apply this voting model to the current discussion about new 
SVN contributors (note that I feel it is very hard to do this; the voting 
model is really not suited to our PSC) then probably most people should 
vote +0 or 0; a new SVN contributor will not affect them much. If there is 
PSC member who is mentoring or supporting the new contributor in the way 
Helena has described then he/she would vote +1. One other +1 from someone 
else who would volunteer to check over the new contributor's 
contributions, make sure they're happy and answer their questions would be 
enough for the motion to pass.

But that's *if* we are trying to stretch the voting procedure in RFC3 to 
fit our PSC. I can't see it working for us. In my opinion, we need a new 
voting procedure. Maybe we could come up with some ideas here as to what 
we'd like to see in the voting procedure?

Paul

P.S. Sorry again about this - I know it is a very annoying topic and one 
that only uses up everyone's precious time for seemingly little gain. We 
do need to face up to it though.