|
|
| (16 intermediate revisions by 3 users not shown) |
| Line 1: |
Line 1: |
| ''This is a working document with a preliminary proposal, and has not been approved.''
| | {{MovedToTrac|RFC/1_ProjectSteeringCommitteeGuidelines}} |
| | |
| == RFC 1: Project Steering Committee Guidelines ==
| |
| : '''Author:''' GRASS Founding PSC
| |
| : '''Status:''' Proposed
| |
| | |
| The 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 administrative overhead as low as possible.
| |
| | |
| This document describes how the GRASS Project Steering Committee
| |
| determines membership and makes decisions on GRASS project issues.
| |
| | |
| The Geographic Resources Analysis Support System, commonly referred to as GRASS, is a Geographic Information System (GIS) used for geospatial data management and analysis, image processing, graphics/maps production, spatial modelling, and visualization. "The GRASS Project" is defined as the collection of community-managed source code, documentation, sample data sets, and related intellectual property which has been submitted under the terms of the projects license(s) for shared use.
| |
| | |
| = 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.
| |
| | |
| == Codebase Control ==
| |
| | |
| === 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.
| |
| | |
| === 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.
| |
| | |
| == 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.
| |
| | |
| = Operation of the PSC =
| |
| | |
| The PSC has its own public [http://grass.itc.it/mailman/listinfo/grass-psc Mailing List].
| |
| | |
| A dedicated [http://grass.itc.it/mailman/listinfo/grass-psc 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. The [[PSC Agenda]] lists all open motions.
| |
| 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). -> Can somebody please do that, potentially a link to the docuemnt is enough.
| |
| | |
| == Issues that must be voted by the PSC ==
| |
| | |
| 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
| |
| | |
| == Prevent Consensus Process from Stalement ==
| |
| | |
| 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.
| |
| | |
| == Resolving Deadlock or Break Down ==
| |
| The Chair is the ultimate adjudicator in case of deadlock or irretrievable
| |
| break down of decision-making, or in case of disputes over voting.
| |
| | |
| = Composition of the Committee =
| |
| ''This list could be replace by a link to the [[PSC]] page:''
| |
| | |
| 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]].
| |