[GRASS-PSC] Changes to RFC1

[Scott Mitchell]

On 15 Dec 2006, at 9:01, Paul Kelly wrote:

> Hello everyone
> As we discussed a few weeks ago I've proposed some modifications to  
> the document describing the PSC. In fact I tried to edit it and  
> then realised that really, I feel the existing one is totally wrong  
> for us and describes a completely different organisation from  
> GRASS. So I decided it was easier just to re-write it from scratch.  
> Hope that doesn't offend anybody who made edits to the other  
> version. Please let me know what you think

Looks great to me overall, I think you've captured the spirit of past  
discussions well.
I do wonder about the possibility of stalemate, though:

> In general, once write access has been granted, developers are  
> allowed to make changes to the codebase as they see fit. For  
> controversial or complicated changes consensus must be obtained on  
> the developers' mailing list as far as reasonably practicable. It  
> is recognised that the ultimate arbitration on technical issues  
> always lies with consensus on the developers' mailing list.  
> Specifically, it is not the role of the PSC to impose technical  
> solutions. Its role is limited to enforcing the quality control  
> mechanisms outlined above.

What about the extremely rare, hopefully never happens, case of no  
consensus developing on the main list?  Alternatively, can we give  
some guidance on what is meant by consensus?  I had a vague inkling  
that one role for a steering committee could be to decide what to do  
if two (or more?) distinct options ever come up and the list can't  
reach consensus.  The wording as it stands above heads part way down  
that path with "consensus must be obtained on the developer's mailing  
list as far as reasonably practicable", but we're missing what should  
happen if "reasonably practicable" doesn't happen.  Is there a way we  
can put in a mechanism without prejudging outcome/tying our hands to  
a particular approach?

How about:
====
It is recognised that the ultimate arbitration on technical issues  
should always lie with consensus on the developers' mailing list.  
Specifically, it is not the role of the PSC to impose technical  
solutions. Its role is limited to enforcing the quality control  
mechanisms outlined above. In general, once write access has been  
granted, developers are allowed to make changes to the codebase as  
they see fit. For controversial or complicated changes consensus must  
be obtained on the developers' mailing list as far as reasonably  
practicable. If consensus fails to emerge naturally, issues can be  
referred to the PSC for more structured efforts to build consensus.  
As a last resort, if lack of consensus continues, the developer  
community can request the PSC to choose options best preserving the  
quality of the GRASS project.
====
OK, I'm still not completely happy with that, but maybe it will  
stimulate suggestions?

Or, do people think I worry needlessly about the stalemate scenario?

Scott