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.
_______________________________________________
grass-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-psc
