Changes to RFC1

[Paul Kelly]

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. Here's
the main ideas I've tried to incorporate in this:

  - The PSC as a body doesn't have a role in technical decisions about what
goes into the codebase. (Of course individual members exercise that
influence through their roles as developers, but not through their PSC
roles). This still goes through the developers mailing list. The way the
PSC can control the codebase in satisfaction of what OSGeo requires, is to
enforce the submitting guidelines and have ultimate control over who has
CVS write access. I used Frank's words from an e-mail to this list:
developers who've been granted CVS write access may make changes "as they
see fit". I think this is a good way of describing our current set-up, and
we have to realise that we trust people who have CVS write access to
discuss thoroughly any major or controversial changes they intend to make.

  - The PSC shares the workload of project management functions (as we've
been discussing recently in another thread). This was barely mentioned at
all in the original RFC and I felt it was important to include it, as that
is an area we need to put plenty of work into.

  - Consensus on decisions is reached through discussion of proposals,
anybody can call a vote if felt necessary, certain issues must be voted
on. I think "consensus" can easily be defined as everybody coming round to
a similar viewpoint, no disagreements - we shouldn't have to go through
the whole voting process with every proposal but if anybody wants to call
a vote, that is no problem at all. Read what I wrote below - I think it
explains it better.

I think we also need to define what the "GRASS project" is exactly.

Really looking forward to having some feedback on this. There's probably
things that have totally slipped my mind, also it may need fleshed out in
places, but I feel it describes the GRASS organisation much better than
the original RFC and hope it is a good basis to move forward towards
agreement on the PSC's role.

Paul

=======================================================

RFC 1: Project Steering Committee Guidelines
Author: GRASS Founding PSC
Status: Proposed

A GRASS Project Steering Committee (PSC) is proposed to formalize control
over the GRASS codebase and to facilitate GRASS project management issues.
It is desired to keep the administrational overhead as low as possible.

This document describes how the GRASS Project Steering Committee
determines membership and makes decisions on GRASS project issues.

"The GRASS Project" is defined as xxxxxxxxxxxxxxx

1.0 Terms of Reference
======================

The two primary functions of the PSC are:
1) To enforce control over the GRASS codebase. This can be summarised as:
    a) Enforce mechanisms to ensure quality control.
    b) Ensure compliance with all required legal measures.
2) Project Management and responsibility for the "public face" of GRASS.
The PSC is expected to be able to speak and act on behalf of the GRASS
project.

1.1 Codebase Control
====================

1.1.1 Quality Control Mechanisms
--------------------------------

The quality control mechanisms, which are the responsibility of the PSC,
currently include:
  * Maintaining submitter guidelines and making all developers aware of
them.
  * Granting write access to the source code repository for new developers.
  * Enforcing the submitter guidelines, with the ultimate sanction against
non-compliance being removal of write access to the source code repository.

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.

1.1.2 Compliance with Legal Measures
------------------------------------

Control over the codebase also extends to ensuring that it complies with
all relevant legal requirements. This includes copyright and licensing
amongst other issues. The PSC is resonsible for developing rules and
procedures to cover this. These are outlined in a separate document: "RFC
2: Legal aspects of code contributions". This document will be updated and
revised by the PSC as required.

1.2 Project Management
======================

The PSC will share responsibility and make decisions over issues related
to the management of the overall direction of the GRASS project and
external visibility, etc. These include, but are not limited to:
  * Release Cycles
  * Project infrastructure
  * Website Maintenance
  * Promotion and Public Relations
  * Other issues as they become relevant

It is the responsibility of the PSC to ensure that issues critical to the
future of the GRASS project are adequately attended to. This may involve
delegation to interested helpers.

2.0 Operation of the PSC
========================

A dedicated mailing list exists for the purpose of PSC discussions. When a
decision is required of the PSC, it will be presented by any member to the
mailing list in the form of a proposal. A decision will then be achieved
by discussion of the proposal on the mailing list until a consensus is
reached. Voting on issues is also permissable and may be used as a means
to reach a consensus or, only in case of extreme cases of disagreement, to
force a decision. Any member may call a vote on any proposal. That member
is then responsible for collating votes and presenting the result to the
PSC. The voting procedure is outlined in a separate document: XXXXXXX
(Copy all the +1/0- stuff in there).

The Chair is the ultimate adjudicator in case of deadlock or irretrievable
break down of decision-making, or in case of disputes over voting.

The following issue(s) *must* have a vote called before a decision is
reached:
  * Granting source code repository write access for new developers
  * Selection of a committee Chair

3.0 Composition of the Committee
================================

Michael Barton, Dylan Beaudette, Hamish Bowman, Massimiliano Cannata, Brad
Douglas, Paul Kelly, Helena Mitasova, Scott Mitchell, Markus Neteler, and
Maciej Sieczka are declared to be the founding Project Steering Committee.

Addition and removal of members from the committee, as well as selection
of a Chair is handled as a proposal to the committee as described above.

The Chair is responsible for keeping track of the membership of the PSC.

[Frank Warmerdam]

On 12/15/06, Paul Kelly <[hidden email]> 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. Here's
> the main ideas I've tried to incorporate in this:

Paul,

Congratulations on taking this bull by the horns!   While a bit
distinct from how some of the other projects are run, I think the
described approach would be just fine from an OSGeo point of
view.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

[Scott Mitchell-3]

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