GRASS-Wiki - User contributions [en]

GRASS promotion team

2007-06-01T07:35:06Z

⚠️Seven: /* GRASS Promotion */ where to get funding

=GRASS Promotion=
Here can the GRASS promotion team coordinate its work.

; Where can we get some resources (financial or support) to print the brochures
: Ideally you get yourself a corporate sponsor who either does the printing (Autodesk has been very helpful in this respect and they have offices everywhere) or sponsors the printing costs. In Germany you can also directly request for OSGeo funds through [[GAV]] e.V.. Describe what event you need the brochures for and add an estimate of the printing costs. For larger international events you should contact OSGeo's [http://www.osgeo.org/visibility Visibility and Promotion Committee], they have no budget but can help coordinate. --[[User:Seven|Seven]] 09:35, 1 June 2007 (CEST)

= Todo (add yourself) =
== As soon as possible ==
1. [[Grassbrochure]]
*a multipage brochure, maybe someting like: [http://www.esri.com/library/brochures/pdfs/avgisbro.pdf Example of the market leader]
* Maybe same layout as OSGeo brochure, contact with OSGeo Viscom

2. <strike>GRASS Flyer</strike> (done)

2. <strike>Technical Data sheet</strike>
*Done, 2nd page of flyer

3. Newbie friendly tutorial
* Update Lorzeno Moretti's "''[http://wwwamb.bologna.enea.it/forgrass/documents/Grass-6-Visual-Tutorial.pdf Visual Tutorial for GRASS 6]''"?
* [[GRASS_Help#First_Day_Documentation|First day documentation]]

4. Live CD (maintenance to keep uptodate,)
* OSGeo viscom team hopes that they will have a fancy promo CD soon ''We should wait for that one''
* Maybe together with OSGEo Viscom to create a FOSSGIS presentation CD
* [http://ldap.telascience.org/foss4g/ FOSS4G2006 Lausanne/Switzerland ''GRASS Workshop LiveCD 2006'']
* Others: http://grass.ibiblio.org/download/cdrom.php

5. Find some funding for printing the flyer / brochure

* How much is needed?

''Depends on the quality & number of flyers we want to order''
''I found one shop where we can get 2500 flyer for about 170 - 270 € (aprox. 225 - 355 US $. depending on paper/colors...)''
* Find a way to spread the flyer

== Later or synchronous ==
* Translation of the GRASS-Flyer (Latex-file available on the Grass-Addons SVN [https://grasssvn.itc.it/grasssvn/grassaddons/trunk/grassaddons/ GRASS-ADDONS-SVN)
* <strike>Newbie Forum</strike> (done)
* [[Contact Databases]]
* Case Histories of GRASS adoption (?)
** [[Publications|Publications made with GRASS]]: on this page publications made with GRASS should be listened
** [[Use Cases|Use Cases successful applications with GRASS]]
* Nice Posters with applications where GRASS hass been adopted
* <strike>workaround of [http://www.osgeo.org/grass http://www.osgeo.org/grass]</strike> ''done''
* Maybe offer some stuff on coffeepress / spreadshirt
** for Germany / Europe in progress (thx to Martin Wegmann)
* Stickers, just an idea: [http://www.perlomat.de/headlogo_bg.png www.perlomat.de/headlogo_bg.png]

= People (add yourself here) =
* Malte Halbey-Martin (maltehalbey on irc): email malte [at] geog.fu-berlin.de
* Ominiverdi ( doktoreas or ominoverde on irc ) : email info [at] ominiverdi.org
* Chip Mefford (cpm on irc) : email cpm [at] daviswv.net or cpm [at] well.com
* Carlos Grohmann: email carlos.grohmann [at] gmail.com

[[Category:Promotion]]

RFC1

2007-04-10T22:39:47Z

⚠️Seven: reference to original document in CVS

''This page was the working copy of [http://freegis.org/cgi-bin/viewcvs.cgi/grass6/rfc/RFC1_PSC.dox?rev=HEAD&content-type=text/vnd.viewcvs-markup RFC1]. Please always refer to the original in the CVS, this page is now only here for documentary reasons. Someone with adminitrative powers should consider protecting it to prevent further changes.''

== RFC1: Project Steering Committee Guidelines ==
: '''Author:''' GRASS Founding PSC
: '''Status:''' Adopted

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 the GPL-licenced GIS software known as the
Geographic Resources Analysis Support System, together with the surrounding
development, distribution and promotion infrastructure currently headquarted
at FBK-irst (formerly ITC-irst), Trento, Italy.

= 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 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 in general limited to enforcing the
quality control mechanisms outlined above.

However, if consensus fails to emerge naturally, an issue 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.

Removal of write access to the source code repository is handled as a
proposal to the committee as described below in the \ref operation section.

=== 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 responsible for developing rules and procedures to cover this. These are outlined in a separate document: [http://mpa.itc.it/markus/grass63progman/rfc/rfc2_psc.html 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 [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. Any member may call a vote on any proposal. The voting procedure is outlined in a separate document: rfc3_psc "RFC 3: PSC Voting Procedures".

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

= Composition of the Committee =
Initial PSC membership was decided based on a nomination and informal voting period on the community's mailing lists. 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 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.

[[Category: PSC]]

RFC1

2007-04-10T22:37:12Z

⚠️Seven: updated to match RFC1 in CVS, please freeze

== RFC1: Project Steering Committee Guidelines ==
: '''Author:''' GRASS Founding PSC
: '''Status:''' Adopted

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 the GPL-licenced GIS software known as the
Geographic Resources Analysis Support System, together with the surrounding
development, distribution and promotion infrastructure currently headquarted
at FBK-irst (formerly ITC-irst), Trento, Italy.

= 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 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 in general limited to enforcing the
quality control mechanisms outlined above.

However, if consensus fails to emerge naturally, an issue 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.

Removal of write access to the source code repository is handled as a
proposal to the committee as described below in the \ref operation section.

=== 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 responsible for developing rules and procedures to cover this. These are outlined in a separate document: [http://mpa.itc.it/markus/grass63progman/rfc/rfc2_psc.html 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 [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. Any member may call a vote on any proposal. The voting procedure is outlined in a separate document: rfc3_psc "RFC 3: PSC Voting Procedures".

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

= Composition of the Committee =
Initial PSC membership was decided based on a nomination and informal voting period on the community's mailing lists. 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 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.

[[Category: PSC]]

RFC1

2007-03-11T02:48:17Z

⚠️Seven: /* Operation of the PSC */ typo

''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 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 project's license(s) (see [[Project:Copyrights]] for details) 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 document 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 =
Founding members of the Project Steering Committee have been declared to be
Michael Barton, Dylan Beaudette, Hamish Bowman, Massimiliano Cannata, Brad
Douglas, Paul Kelly, Helena Mitasova, Scott Mitchell, Markus Neteler, and
Maciej Sieczka.

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 and update the [[PSC | PSC Member List]] accordingly.

RFC1

2007-03-11T02:47:40Z

⚠️Seven: /* Composition of the Committee */ reworded, link to current list

''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 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 project's license(s) (see [[Project:Copyrights]] for details) 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 =
Founding members of the Project Steering Committee have been declared to be
Michael Barton, Dylan Beaudette, Hamish Bowman, Massimiliano Cannata, Brad
Douglas, Paul Kelly, Helena Mitasova, Scott Mitchell, Markus Neteler, and
Maciej Sieczka.

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 and update the [[PSC | PSC Member List]] accordingly.

RFC1

2007-03-09T08:21:49Z

⚠️Seven: /* Operation of the PSC */ added link to mailing list, and PSC Agenda

''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 =

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]].

PSC Agenda

2007-03-09T08:18:03Z

⚠️Seven: /* Motions */ typo

''This page contains the agenda of the [[PSC | GRASS Project Steering Commitee]].''

=== Open issues ===

==== Motions ====

''These entries need a vote from each committee member.''

* March 21 vote: [[RFC1 Development Page | RFC1]] (working copy). Please edit and post major changes with a short explanation to the [[PSC]] mailing list so that it can incorporated with the CVS version [http://freegis.org/cgi-bin/viewcvs.cgi/grass6/rfc/RFC1_PSC.dox?rev=HEAD&content-type=text/vnd.viewcvs-markup RFC1] (Request For Comment).

==== Discussions ====

''These entries do not need a formal vote.''

* License issues of translation support through [https://launchpad.net/products/grass6 Rosetta]

---------------

=== Resolved issues ===

==== Motions ====
<strike>
* CVS write access to S. Pallecchi (granted, 12 Dec 2006)
* PSC Chair motion (chair: M Neteler, 9 Dec 2006, [http://grass.itc.it/pipermail/grass-psc/2006-December/000143.html see related email message])
* CVS write access to R. Antolin (granted, 8 Dec 2006)
* [http://freegis.org/cgi-bin/viewcvs.cgi/grass6/rfc/RFC2_PSC.dox?rev=HEAD&content-type=text/vnd.viewcvs-markup RFC2] - Legal aspects of code contributions (adopted 8 Dec 2006)
</strike>

==== Discussions ====
<strike>
* GRASS on koders.com: recommendation to do so. A friend of MN has submitted the code.
</strike>

PSC

2007-03-09T08:17:16Z

⚠️Seven: added link to working coument version of RFC1, added link to mailing list

''See [[GRASS Project Steering Commitee]] for the process of how this team came into exitence. Operation of the PSC is currently undergoing revision, see [[RFC1 Development Page]]''

'''The GRASS Project Steering Committee (PSC)'''

* '''Michael Barton''' (michael barton * asu edu)
* '''Dylan Baudette''' (debeaudette * ucdavis edu)
* '''Hamish Bowman''' (hamish_nospam * yahoo com)
* '''Massimiliano Cannata''' (massimiliano cannata * supsi ch)
* '''Brad Douglas''' (rez * touchofmadness com)
* '''Paul Kelly''' (paul-grass stjohnspoint co uk)
* '''Helena Mitasova''' (hmitaso * unity ncsu edu)
* '''Scott Mitchell''' (smitch * mac com)
* '''Markus Neteler''' (neteler * itc it) (chair)
* '''Maciej Sieczka''' (tutey * o2 pl)

(see also [http://grass.itc.it/community/team.php GRASS team page])

The PSC has its own public [http://grass.itc.it/mailman/listinfo/grass-psc Mailing List]. The Project Steering Committee maintains the [[PSC Agenda]] with dates for issues that need voting.

PSC Agenda

2007-03-09T08:11:54Z

⚠️Seven: reworded, RFC1 Wiki page as primary workspace

''This page contains the agenda of the [[PSC | GRASS Project Steering Commitee]].''

=== Open issues ===

==== Motions ====

''These entries need a vote from each committee member.''

* March 21 vote: [[[[RFC1 Development Page | RFC1]] (working copy). Please edit and post major changes with a short explanation to the [[PSC]] mailing list so that it can incorporated with the CVS version [http://freegis.org/cgi-bin/viewcvs.cgi/grass6/rfc/RFC1_PSC.dox?rev=HEAD&content-type=text/vnd.viewcvs-markup RFC1] (Request For Comment).

==== Discussions ====

''These entries do not need a formal vote.''

* License issues of translation support through [https://launchpad.net/products/grass6 Rosetta]

---------------

=== Resolved issues ===

==== Motions ====
<strike>
* CVS write access to S. Pallecchi (granted, 12 Dec 2006)
* PSC Chair motion (chair: M Neteler, 9 Dec 2006, [http://grass.itc.it/pipermail/grass-psc/2006-December/000143.html see related email message])
* CVS write access to R. Antolin (granted, 8 Dec 2006)
* [http://freegis.org/cgi-bin/viewcvs.cgi/grass6/rfc/RFC2_PSC.dox?rev=HEAD&content-type=text/vnd.viewcvs-markup RFC2] - Legal aspects of code contributions (adopted 8 Dec 2006)
</strike>

==== Discussions ====
<strike>
* GRASS on koders.com: recommendation to do so. A friend of MN has submitted the code.
</strike>

PSC Agenda

2007-03-09T08:09:00Z

⚠️Seven: /* Motions */

''This page contains the agenda of the [[PSC | GRASS Project Steering Commitee]].''

=== Open issues ===

==== Motions ====

''These entries need a vote from each committee member.''

* March 21 vote: Until then please revise [http://freegis.org/cgi-bin/viewcvs.cgi/grass6/rfc/RFC1_PSC.dox?rev=HEAD&content-type=text/vnd.viewcvs-markup RFC1] (Request For Comment). A working copy as been set up as a Wiki page: [[RFC1 Development Page]]. Please edit and post major changes with a short explanation to the [[PSC]] mailing list.

==== Discussions ====

''These entries do not need a formal vote.''

* License issues of translation support through [https://launchpad.net/products/grass6 Rosetta]

---------------

=== Resolved issues ===

==== Motions ====
<strike>
* CVS write access to S. Pallecchi (granted, 12 Dec 2006)
* PSC Chair motion (chair: M Neteler, 9 Dec 2006, [http://grass.itc.it/pipermail/grass-psc/2006-December/000143.html see related email message])
* CVS write access to R. Antolin (granted, 8 Dec 2006)
* [http://freegis.org/cgi-bin/viewcvs.cgi/grass6/rfc/RFC2_PSC.dox?rev=HEAD&content-type=text/vnd.viewcvs-markup RFC2] - Legal aspects of code contributions (adopted 8 Dec 2006)
</strike>

==== Discussions ====
<strike>
* GRASS on koders.com: recommendation to do so. A friend of MN has submitted the code.
</strike>

RFC1

2007-03-09T08:04:39Z

⚠️Seven: /* Terms of Reference */ formatting

''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). -> 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]].

User:Seven

2007-03-09T07:59:57Z

⚠️Seven: added link to about me

My name is [http://www.mapbender.org/index.php/User:Arnulf_Christl Arnulf Christl] and I have volunteered and was then appointed Mentor of The GRASS Project's OSGeo incubation process. You can find me as seven or sevenof9 on OSGeo IRC channel.

RFC1

2007-03-09T07:47:51Z

⚠️Seven: /* Operation of the PSC */ included Scott Mitchell's post on preventing stalement

''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). -> 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]].

RFC1

2007-03-09T07:44:16Z

⚠️Seven: /* Operation of the PSC */ moved deadlock section down, makes sense to do this after selecting chair

''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). -> 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

== 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]].

RFC1

2007-03-09T07:43:05Z

⚠️Seven: /* Operation of the PSC */ formatting of Paul Kelley's input done

''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). -> Can somebody please do that, potentially a link to the docuemnt is enough.

== 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.

== 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

= 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]].

RFC1

2007-03-09T07:39:05Z

⚠️Seven: reformatting

''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.
</pre>

GRASS Project Steering Commitee

2007-03-09T07:10:07Z

⚠️Seven: /* Status September 2006 */ added link to new PSC page

This page discusses the need for a GRASS Project Steering Commitee (PSC), preferably at a low level of complication.

==1st Letter to GRASS mailing lists==

<pre>
02/10/2006 06:15 PM
Dear GRASS community,

in the Chicago meeting the GRASS project was suggested to
as one of the initial OSGeo foundation projects.

So far I only received positive feedback on the idea of
moving GRASS more formally to the foundation (while the
individual authors are keeping their copyright which is
a major difference to the Apache Foundation.)

A couple of things will have to be sorted out in the
coming months to make GRASS's membership possible (below
list is inspired by Frank's mail to the GRASS project):

o We will need to form a "GRASS Project Steering Committee"
(PSC). Foundation projects need a formalized management
which may be desired in any case. I would be glad to
receive suggestions of names for this committee. For
inspiration, please look at the MapServer Technical
Steering Committee as described here:

http://mapserver.gis.umn.edu/development/rfc/ms-rfc-1

o One benefit of the foundation is some degree of legal
support and protection for the project. The flip side of that
is that the foundation needs to ensure some degree of
rigor and process in how code comes into the project. One
part of that is getting committers to sign a legal agreement
indicating that they agree that changes they commit will
be under the license of GRASS (GPL) and that they have
the right to submit the code (they wrote it, it is not
patented, have permission from their employer, etc).

o We will have to review the existing code base (which is
huge - more than 500000 lines of source code in GRASS 6).
Luckily a major code review was already done for GRASS 5.
Also the "Debianization" process was performed for GRASS
5 and GRASS 6.

o It is suggested to move the support infrastructure for GRASS
to new foundation systems. Stuff like CVS (maybe SVN then),
and bugtracker and mailing lists. The web site will also
likely appear under a foundation subdomain (ie. grass.osgeo.org)
with hopefully the known mirror site structure as before
with grass.itc.it, grass.ibiblio.org etc as principal mirror
sites. If so, the web site will be migrated into a contents
management system (CMS) in a harmonized "foundation style".
A CMS will hopefully solve the problem to get more people
involved in the Web site contents management.

o We hope to establish options to enable sponorship for the
foundation - be as direct funding or for selected foundation
projects. Details have to be worked out. My suggestion is to
create national tax-exempt organizations (such as the
German GRASS Anwender-Vereinigung e.V. which already exists)
which may offer to receive donations.

o For now we should think about nominating people with
recognized contribution to the GRASS project, to
free data, to whatever deems significant. A small paragraph
describing why the candidate is proposed as member to
the foundation is needed as well. This will be announced
more formally soon. Please see ongoing discussions here:
http://lists.osgeo.org/mailman/listinfo/discuss

(Nearly) nothing is set in stone yet.
More details will follow, a couple of official documents
are being currently prepared

Your feedback is welcome.

Markus
</pre>
______

==2nd Letter to GRASS mailing lists==

<pre>
02/11/2006 12:16 AM
Dear all,

while I already received two suggestions for a GRASS
Project Steering Committee (PSC), I suggest to post the
nominations in public, if there are no objections.
I would like to have that transparent to everyone.

Nominations should contain the name and a short paragraph
why it is a good candidate. We also have to decide,
how many members the PSC should have.

It is worth reading
- http://www.apache.org/foundation/how-it-works.html
(they are very successful, and the document applies much
to the GRASS project culture)

- http://mapserver.gis.umn.edu/development/rfc/ms-rfc-1/
(MS RFC 1: Technical Steering Committee Guidelines)
apparently 7 members there.

- http://lists.maptools.org/pipermail/gdal-dev/2006-February/thread.html#7881
(GDAL PSC to be formed)

- http://mapserver.gis.umn.edu/development/rfc/ms-rfc-10/
(MS RFC 10: Joining the Open Source Geospatial Foundation)

Related:
- https://sourceforge.net/mailarchive/forum.php?thread_id=9682788&forum_id=475
(Community MapBuilder PMC membership nomination)
- https://sourceforge.net/mailarchive/forum.php?thread_id=9673493&forum_id=475
(MapBuilder & Mapbender and the OSGeo Foundation)

In fact, there is lot of material to digest in these days..

Markus
</pre>

==3rd Letter to GRASS Dev mailing list==

<pre>
Markus Neteler neteler at itc.it Sun, 23 Apr 2006 18:10:25 +0200

On Sat, Apr 22, 2006 at 01:00:01PM +0100, Glynn Clements wrote:
...
> Alpha support in the current display architecture isn't going to
> happen (I reverted the last attempt to add it, and will do likewise in
> future).

... this is why I really suggest to get interested in a project
steering committee [1], [2].

Instead of recursively reverted changes of other developers,
we should come up with a design discussion and then *vote* on it.
At least for such crucidal pieces of the code I would like to
see less anarchy and a more formal approach. This will render
development more transparent to everybody. The scope cannot be to
have two display management systems in parallel, one without
and one with alpha support.

Existing steering committees, to get inspired from:
Mapserver: http://mapserver.gis.umn.edu/development/rfc/ms-rfc-1
GDAL: http://www.gdal.org/rfc1_pmc.html
Mapbender: http://www.mapbender.org/index.php/Mapbender_PSC
...

Please think about it!

Thanks

Markus

[1] http://grass.itc.it/pipermail/grass5/2006-February/021178.html
[2] http://grass.itc.it/pipermail/grass5/2006-April/022185.html

</pre>

Answers:

* http://grass.itc.it/pipermail/grass5/2006-April/022429.html

== Nominations ==

''The comments were copied from the related emails.''

# Brad Douglas (nominated by 1): for clone removal and code refactoring
# Cedric Shock (nominated by 1): various code contributions
# Dylan Beaudette (nominated by 1): deep commitment to community, publishes useful tips
# Glynn Clements (nominated by 1): for his vast knowledge of standards, practices and compatibility
# Hamish Bowman (nominated by 1): for documentation, integration, and various modules
# Helena Mitasova (nominated by 1): for the obvious
# Maciej Sieczka
# Markus Neteler (nominated by 2): for the obvious. :-)
# Michael Barton (nominated by 1): very responsive to comments and questions; various code contributions
# Paolo Zatelli (nominated by 1 ): no reason given
# Paul Kelly (nominated by 1): for PROJ and platform support
# Radim Blazek (nominated by 1): for his extensive GRASS work including vector and DBMS support
# Roger Bivand (nominated by 1): no reason given
# Venkatesh Raghavan (nominated by 1):

Declined (please reconsider =])
# Radim Blazek (nominated by 1): for his extensive GRASS work including vector and DBMS support

== Status September 2006 ==

'''The GRASS Project Steering Committee ([[PSC]])'''

* '''Michael Barton''' (michael barton * asu edu)
* '''Dylan Baudette''' (debeaudette * ucdavis edu)
* '''Hamish Bowman''' (hamish_nospam * yahoo com)
* '''Massimiliano Cannata''' (massimiliano cannata * supsi ch)
* '''Brad Douglas''' (rez * touchofmadness com)
* '''Paul Kelly''' (paul-grass stjohnspoint co uk)
* '''Helena Mitasova''' (hmitaso * unity ncsu edu)
* '''Scott Mitchell''' (smitch * mac com)
* '''Markus Neteler''' (neteler * itc it) (chair)
* '''Maciej Sieczka''' (tutey * o2 pl)

(see also [http://grass.itc.it/community/team.php GRASS team page])

Next step: Revise [http://freegis.org/cgi-bin/viewcvs.cgi/grass6/rfc/RFC1_PSC.dox?rev=HEAD&content-type=text/vnd.viewcvs-markup RFC1] (Request For Comment) for the GRASS community to consider

== Status November 2006 ==

A [http://grass.itc.it/mailman/listinfo/grass-psc dedicated GRASS-PSC mailing list] has been created. It is open to the public.

== Status December 2006 ==

We have a [[PSC|PSC Agenda]].

PSC Agenda

2007-03-09T07:04:06Z

⚠️Seven: /* Motions */ added link to RFC1 work page

''This page contains the agenda of the [[PSC | GRASS Project Steering Commitee]].''

=== Open issues ===

==== Motions ====

''These entries need a vote from each committee member.''

* Revise [http://freegis.org/cgi-bin/viewcvs.cgi/grass6/rfc/RFC1_PSC.dox?rev=HEAD&content-type=text/vnd.viewcvs-markup RFC1] (Request For Comment) for the GRASS community to consider. Lot's of comments have to be merged in. For this purpose the Wiki page [[RFC1 Development Page]] has been set up. Please edit and post major changes with a short explanation to PSC mailing list.

==== Discussions ====

''These entries do not need a formal vote.''

* License issues of translation support through [https://launchpad.net/products/grass6 Rosetta]

---------------

=== Resolved issues ===

==== Motions ====
<strike>
* CVS write access to S. Pallecchi (granted, 12 Dec 2006)
* PSC Chair motion (chair: M Neteler, 9 Dec 2006, [http://grass.itc.it/pipermail/grass-psc/2006-December/000143.html see related email message])
* CVS write access to R. Antolin (granted, 8 Dec 2006)
* [http://freegis.org/cgi-bin/viewcvs.cgi/grass6/rfc/RFC2_PSC.dox?rev=HEAD&content-type=text/vnd.viewcvs-markup RFC2] - Legal aspects of code contributions (adopted 8 Dec 2006)
</strike>

==== Discussions ====
<strike>
* GRASS on koders.com: recommendation to do so. A friend of MN has submitted the code.
</strike>

RFC1

2007-03-09T07:02:02Z

⚠️Seven: link to revised PSC page

''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

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.
</pre>

PSC

2007-03-09T07:01:28Z

⚠️Seven: added link to process page

''See [[GRASS Project Steering Commitee]] for the process of how this team came into exitence''

'''The GRASS Project Steering Committee (PSC)'''

* '''Michael Barton''' (michael barton * asu edu)
* '''Dylan Baudette''' (debeaudette * ucdavis edu)
* '''Hamish Bowman''' (hamish_nospam * yahoo com)
* '''Massimiliano Cannata''' (massimiliano cannata * supsi ch)
* '''Brad Douglas''' (rez * touchofmadness com)
* '''Paul Kelly''' (paul-grass stjohnspoint co uk)
* '''Helena Mitasova''' (hmitaso * unity ncsu edu)
* '''Scott Mitchell''' (smitch * mac com)
* '''Markus Neteler''' (neteler * itc it) (chair)
* '''Maciej Sieczka''' (tutey * o2 pl)

(see also [http://grass.itc.it/community/team.php GRASS team page])

Next step: Revise [http://freegis.org/cgi-bin/viewcvs.cgi/grass6/rfc/RFC1_PSC.dox?rev=HEAD&content-type=text/vnd.viewcvs-markup RFC1] (Request For Comment) for the GRASS community to consider

PSC Agenda

2007-03-09T06:59:09Z

⚠️Seven: moved from PSC

''This page contains the agenda of the [[PSC | GRASS Project Steering Commitee]].''

=== Open issues ===

==== Motions ====

''These entries need a vote from each committee member.''

* Revise [http://freegis.org/cgi-bin/viewcvs.cgi/grass6/rfc/RFC1_PSC.dox?rev=HEAD&content-type=text/vnd.viewcvs-markup RFC1] (Request For Comment) for the GRASS community to consider. Lot's of comments have to be merged in.

==== Discussions ====

''These entries do not need a formal vote.''

* License issues of translation support through [https://launchpad.net/products/grass6 Rosetta]

---------------

=== Resolved issues ===

==== Motions ====
<strike>
* CVS write access to S. Pallecchi (granted, 12 Dec 2006)
* PSC Chair motion (chair: M Neteler, 9 Dec 2006, [http://grass.itc.it/pipermail/grass-psc/2006-December/000143.html see related email message])
* CVS write access to R. Antolin (granted, 8 Dec 2006)
* [http://freegis.org/cgi-bin/viewcvs.cgi/grass6/rfc/RFC2_PSC.dox?rev=HEAD&content-type=text/vnd.viewcvs-markup RFC2] - Legal aspects of code contributions (adopted 8 Dec 2006)
</strike>

==== Discussions ====
<strike>
* GRASS on koders.com: recommendation to do so. A friend of MN has submitted the code.
</strike>

PSC

2007-03-09T06:58:23Z

⚠️Seven:

'''The GRASS Project Steering Committee (PSC)'''

* '''Michael Barton''' (michael barton * asu edu)
* '''Dylan Baudette''' (debeaudette * ucdavis edu)
* '''Hamish Bowman''' (hamish_nospam * yahoo com)
* '''Massimiliano Cannata''' (massimiliano cannata * supsi ch)
* '''Brad Douglas''' (rez * touchofmadness com)
* '''Paul Kelly''' (paul-grass stjohnspoint co uk)
* '''Helena Mitasova''' (hmitaso * unity ncsu edu)
* '''Scott Mitchell''' (smitch * mac com)
* '''Markus Neteler''' (neteler * itc it) (chair)
* '''Maciej Sieczka''' (tutey * o2 pl)

(see also [http://grass.itc.it/community/team.php GRASS team page])

Next step: Revise [http://freegis.org/cgi-bin/viewcvs.cgi/grass6/rfc/RFC1_PSC.dox?rev=HEAD&content-type=text/vnd.viewcvs-markup RFC1] (Request For Comment) for the GRASS community to consider

RFC1

2007-03-09T06:54:46Z

⚠️Seven: added notice: not approved yet

''This is a working document with a preliminary proposal, and has not been approved.''

<pre>
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.
</pre>

RFC1

2007-03-09T06:53:22Z

⚠️Seven: initial check in

<pre>
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.
</pre>

PSC Agenda

2007-03-07T22:58:54Z

⚠️Seven: added redirect

#redirect[[PSC]]