RFC1: Difference between revisions
(link to revised PSC page) |
(reformatting) |
||
Line 14: | Line 14: | ||
"The GRASS Project" is defined as xxxxxxxxxxxxxxx | "The GRASS Project" is defined as xxxxxxxxxxxxxxx | ||
= Terms of Reference = | |||
The two primary functions of the PSC are: | The two primary functions of the PSC are: | ||
1) To enforce control over the GRASS codebase. This can be summarised as: | 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. | 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 | The PSC is expected to be able to speak and act on behalf of the GRASS | ||
project. | project. | ||
== Codebase Control == | |||
=== Quality Control Mechanisms === | |||
The quality control mechanisms, which are the responsibility of the PSC, | The quality control mechanisms, which are the responsibility of the PSC, | ||
currently include: | currently include: | ||
* Maintaining submitter guidelines and making all developers aware of | |||
them. | 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. | non-compliance being removal of write access to the source code repository. | ||
Line 48: | Line 45: | ||
control mechanisms outlined above. | control mechanisms outlined above. | ||
=== Compliance with Legal Measures === | |||
Control over the codebase also extends to ensuring that it complies with | Control over the codebase also extends to ensuring that it complies with | ||
Line 58: | Line 54: | ||
revised by the PSC as required. | revised by the PSC as required. | ||
== Project Management == | |||
The PSC will share responsibility and make decisions over issues related | The PSC will share responsibility and make decisions over issues related | ||
to the management of the overall direction of the GRASS project and | to the management of the overall direction of the GRASS project and | ||
external visibility, etc. These include, but are not limited to: | 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 | It is the responsibility of the PSC to ensure that issues critical to the | ||
Line 74: | Line 69: | ||
delegation to interested helpers. | delegation to interested helpers. | ||
= Operation of the PSC = | |||
A dedicated mailing list exists for the purpose of PSC discussions. When a | A dedicated mailing list exists for the purpose of PSC discussions. When a |
Revision as of 07:39, 9 March 2007
This is a working document with a preliminary proposal, and has not been approved.
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 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
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
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.