RFC1 - Revision history

⚠️Landa: Replaced content with "{{MovedToTrac|RFC/1_ProjectSteeringCommitteeGuidelines}}"

2014-06-11T15:39:31Z

Replaced content with "{{MovedToTrac|RFC/1_ProjectSteeringCommitteeGuidelines}}"

← Older revision		Revision as of 15:39, 11 June 2014
Line 1:		Line 1:
	~~''This page is the working copy of RFC1. Please always refer to the original in the [http:~~//trac.osgeo.org/grass/browser/grass/trunk/rfc SVN] (or formatted [http://download.osgeo.org/grass/grass6_progman/rfc/rfc1_psc.html here]), this page is now only here for documentary reasons. This page is protected to prevent further changes.''		{{MovedToTrac\|RFC/1_ProjectSteeringCommitteeGuidelines}}

	~~== RFC1: Project Steering Committee Guidelines ==~~
	~~: '''Author:''' GRASS 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 'Operation of the PSC' 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 RFC2: 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: [http://mpa.itc.it/markus/grass63progman/rfc/rfc2_psc.html RFC3: 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]]~~

Neteler: urls updated

2008-01-29T07:57:54Z

urls updated

← Older revision		Revision as of 07:57, 29 January 2008
Line 1:		Line 1:
	''This page is the working copy of RFC1. Please always refer to the original in the [http://~~freegis~~.org/~~cgi-bin~~/~~viewcvs.cgi~~/~~grass6~~/rfc~~/RFC1_PSC.dox?rev=HEAD&content-type=text/vnd.viewcvs-markup CVS~~] (or [http://~~mpa~~.~~itc~~.it/~~markus~~/~~grass63progman~~/rfc/rfc1_psc.html here]), this page is now only here for documentary reasons. This page is protected to prevent further changes.''		''This page is the working copy of RFC1. Please always refer to the original in the [http://trac.osgeo.org/grass/browser/grass/trunk/rfc SVN] (or formatted [http://download.osgeo.org/grass/grass6_progman/rfc/rfc1_psc.html here]), this page is now only here for documentary reasons. This page is protected to prevent further changes.''

	== RFC1: Project Steering Committee Guidelines ==		== RFC1: Project Steering Committee Guidelines ==

Neteler: page protected now

2007-04-11T06:07:00Z

page protected now

← Older revision		Revision as of 06:07, 11 April 2007
Line 1:		Line 1:
	''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.''		''This page is the working copy of RFC1. Please always refer to the original in the [http://freegis.org/cgi-bin/viewcvs.cgi/grass6/rfc/RFC1_PSC.dox?rev=HEAD&content-type=text/vnd.viewcvs-markup CVS] (or [http://mpa.itc.it/markus/grass63progman/rfc/rfc1_psc.html here]), this page is now only here for documentary reasons. This page is protected to prevent further changes.''

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

Line 20:		Line 20:

	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.		:a) Enforce mechanisms to ensure quality control.
Line 32:		Line 33:
	=== Quality Control Mechanisms ===		=== 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.
	* Maintaining submitter guidelines and making all developers aware of		* Granting write access to the source code repository for new developers.
	them.* Granting write access to the source code repository for new		* Enforcing the submitter guidelines, with the ultimate sanction against non-compliance being removal of write access to the source code repository.
	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		In general, once write access has been granted, developers are allowed to
Line 57:		Line 54:

	Removal of write access to the source code repository is handled as a		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.		proposal to the committee as described below in the 'Operation of the PSC' section.

	=== Compliance with Legal Measures ===		=== 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.		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 RFC2: Legal aspects of code contributions]. This document will be updated and revised by the PSC as required.

	== Project Management ==		== Project Management ==
Line 78:		Line 75:

	= Operation of the PSC =		= 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".		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: [http://mpa.itc.it/markus/grass63progman/rfc/rfc2_psc.html RFC3: 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 Chair is the ultimate adjudicator in case of deadlock or irretrievable break down of decision-making, or in case of disputes over voting.
Line 87:		Line 84:

	= Composition of the Committee =		= 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,		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.
	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		Addition and removal of members from the committee, as well as selection

⚠️Seven: reference to original document in CVS

2007-04-10T22:39:47Z

reference to original document in CVS

← Older revision		Revision as of 22:39, 10 April 2007
Line 1:		Line 1:
			''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 ==		== RFC1: Project Steering Committee Guidelines ==
	: '''Author:''' GRASS Founding PSC		: '''Author:''' GRASS Founding PSC

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

2007-04-10T22:37:12Z

updated to match RFC1 in CVS, please freeze

← Older revision		Revision as of 22:37, 10 April 2007
Line 3:		Line 3:
	: '''Status:''' Adopted		: '''Status:''' Adopted

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

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

	"The GRASS Project" is defined as the GPL-licenced GIS software known as the		"The GRASS Project" is defined as the GPL-licenced GIS software known as the
Line 17:		Line 17:
	= Terms of Reference =		= 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.		:a) Enforce mechanisms to ensure quality control.
	: b) Ensure compliance with all required legal measures.		: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.
Line 32:		Line 32:
	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.		* Maintaining submitter guidelines and making all developers aware of
	* Granting write access to the source code repository for new developers.		them.* Granting write access to the source code repository for new
	* Enforcing the submitter guidelines, with the ultimate sanction against non-compliance being removal of write access to the source code repository.		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		In general, once write access has been granted, developers are allowed to
	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.		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.		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.		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 ===		=== 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 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.
	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 [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 ==		== 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
Line 61:		Line 70:
	* Promotion and Public Relations		* Promotion and Public Relations
	* Other issues as they become relevant		* 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
	future of the GRASS project are adequately attended to. This may involve		future of the GRASS project are adequately attended to. This may involve
Line 67:		Line 76:

	= Operation of the PSC =		= 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".

	~~A dedicated [http://grass.itc.it/mailman/listinfo/grass-psc Mailing List] exists for the purpose of PSC discussions. When a~~		The Chair is the ultimate adjudicator in case of deadlock or irretrievable break down of decision-making, or in case of disputes over voting.
	~~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. The voting procedure is outlined in a separate document, [http://mpa.itc.it/markus/grass63progman/rfc/rfc3_psc.html RFC3 - 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:		The following issue(s) '''must''' have a vote called before a decision is reached:
	* Granting source code repository write access for new developers		* Granting source code repository write access for new developers
	* Selection of a committee Chair		* Selection of a committee Chair

	= Composition of the Committee =		= 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,
	Initial PSC membership was decided based on a nomination and informal voting		Scott Mitchell, Markus Neteler, and Maciej Sieczka are declared to be the founding Project Steering Committee.
	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		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.		of Chair is handled as a proposal to the committee as described above.

	The Chair is responsible for keeping track of the ~~[[PSC \|~~ membership of the PSC]].		The Chair is responsible for keeping track of the membership of the PSC.


	[[Category: PSC]]		[[Category: PSC]]

Neteler: /* RFC 1: Project Steering Committee Guidelines */

2007-04-10T19:16:54Z

RFC 1: Project Steering Committee Guidelines

← Older revision		Revision as of 19:16, 10 April 2007
Line 1:		Line 1:
	== ~~RFC 1~~: Project Steering Committee Guidelines ==		== RFC1: Project Steering Committee Guidelines ==
	: '''Author:''' GRASS Founding PSC		: '''Author:''' GRASS Founding PSC
	: '''Status:''' Adopted		: '''Status:''' Adopted

Neteler: RFC1 Development Page moved to RFC1: reasonable new name since it is adopted

2007-04-10T19:16:31Z

RFC1 Development Page moved to RFC1: reasonable new name since it is adopted

← Older revision		Revision as of 19:16, 10 April 2007
(No difference)

⚠️Smitch: /* Operation of the PSC */

2007-04-07T18:51:25Z

Operation of the PSC

← Older revision		Revision as of 18:51, 7 April 2007
Line 75:		Line 75:
	to reach a consensus or, only in case of extreme cases of disagreement, to		to reach a consensus or, only in case of extreme cases of disagreement, to
	force a decision. The [[PSC Agenda]] lists all open motions.		force a decision. The [[PSC Agenda]] lists all open motions.
	Any member may call a vote on any proposal. The voting procedure is outlined in a separate document, [~~[RFC3 \|~~ RFC3 - PSC Voting Procedures]].		Any member may call a vote on any proposal. The voting procedure is outlined in a separate document, [http://mpa.itc.it/markus/grass63progman/rfc/rfc3_psc.html RFC3 - PSC Voting Procedures].

	The Chair is the ultimate adjudicator in case of deadlock or irretrievable		The Chair is the ultimate adjudicator in case of deadlock or irretrievable

⚠️Smitch: /* Compliance with Legal Measures */

2007-04-07T18:50:33Z

Compliance with Legal Measures

← Older revision		Revision as of 18:50, 7 April 2007
Line 48:		Line 48:
	all relevant legal requirements. This includes copyright and licensing		all relevant legal requirements. This includes copyright and licensing
	amongst other issues. The PSC is resonsible for developing rules and		amongst other issues. The PSC is resonsible for developing rules and
	procedures to cover this. These are outlined in a separate document: ~~[[RFC2 \|~~ RFC		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
	2: Legal aspects of code contributions]]. This document will be updated and
	revised by the PSC as required.		revised by the PSC as required.

⚠️Smitch: /* Compliance with Legal Measures */

2007-04-07T18:41:08Z

Compliance with Legal Measures

← Older revision		Revision as of 18:41, 7 April 2007
Line 48:		Line 48:
	all relevant legal requirements. This includes copyright and licensing		all relevant legal requirements. This includes copyright and licensing
	amongst other issues. The PSC is resonsible for developing rules and		amongst other issues. The PSC is resonsible for developing rules and
	procedures to cover this. These are outlined in a separate document: "RFC		procedures to cover this. These are outlined in a separate document: [[RFC2 \| RFC
	2: Legal aspects of code contributions". This document will be updated and		2: Legal aspects of code contributions]]. This document will be updated and
	revised by the PSC as required.		revised by the PSC as required.