Features/Policy - Revision history

Quozl: /* Who is responsible for this process? */

2017-09-08T22:51:02Z

Who is responsible for this process?

← Older revision		Revision as of 18:51, 8 September 2017
Line 13:		Line 13:

	=== Who is responsible for this process? ===		=== Who is responsible for this process? ===
	The person responsible for managing the Feature Process is our community-designated Release Manager. ~~(The current Release Manager is [[User:Godiard\|Gonzalo Odiard]].)~~		The person responsible for managing the Feature Process is our community-designated Release Manager.

	==== Roles ====		==== Roles ====

SAMdroid: /* Who is responsible for this process? */ Gonzalo did the last release

2014-08-31T07:46:25Z

Who is responsible for this process?: Gonzalo did the last release

← Older revision		Revision as of 03:46, 31 August 2014
Line 13:		Line 13:

	=== Who is responsible for this process? ===		=== Who is responsible for this process? ===
	The person responsible for managing the Feature Process is our community-designated Release Manager. (The current Release Manager is [~~http://wiki.sugarlabs.org/go/~~User:~~Erikos Simon Schampijer~~].)		The person responsible for managing the Feature Process is our community-designated Release Manager. (The current Release Manager is [[User:Godiard\|Gonzalo Odiard]].)

	==== Roles ====		==== Roles ====

Erikos: /* Propose a feature for addition into the release cycle */

2013-03-27T09:31:34Z

Propose a feature for addition into the release cycle

← Older revision		Revision as of 05:31, 27 March 2013
Line 90:		Line 90:
	# Community consensus: There should be more YES than NO in the community for this Feature.		# Community consensus: There should be more YES than NO in the community for this Feature.
	#* Send an email to sugar-devel mailing list with [FEATURE] tag in the subject asking for feedback. This is to give the community (deployments, developers, teachers etc) the chance to comment.		#* Send an email to sugar-devel mailing list with [FEATURE] tag in the subject asking for feedback. This is to give the community (deployments, developers, teachers etc) the chance to comment.
	#* If your feature adds UI or changes the current UI please add as well the [DESIGN] tag to the subject. Please add the flag as well work flow does change or new ones are added. The Design Team should be involved in the discussion to guarantee a consistent design and a consistent work flow in Sugar. When presenting the feature to the release manager the design ~~must~~ not be ~~ready~~ but the discussion should have been started.		#* If your feature adds UI or changes the current UI please add as well the [DESIGN] tag to the subject. Please add the flag as well if the work flow does change or new ones are added. The Design Team should be involved in the discussion to guarantee a consistent design and a consistent work flow in Sugar. When presenting the feature to the release manager the design does not have to be fully completed but the discussion should have been started.
	# Documentation: In order to be considered an official feature accepted for the next Sugar release, the feature should be formally documented on a separate wiki page. The wiki page is the same page than the one from above (a blank template is available at [[Features/Feature Template]]). Please make sure it includes the following information.		# Documentation: In order to be considered an official feature accepted for the next Sugar release, the feature should be formally documented on a separate wiki page. The wiki page is the same page than the one from above (a blank template is available at [[Features/Feature Template]]). Please make sure it includes the following information.
	#* Summary of the feature		#* Summary of the feature

FGrose: sort to top of Category:Feature

2011-11-22T21:28:58Z

sort to top of Category:Feature

← Older revision		Revision as of 17:28, 22 November 2011
Line 1:		Line 1:
	<noinclude>[[Category:Policy]]		<noinclude>[[Category:Policy]]
	[[Category:Feature\|<Policy]]		[[Category:Feature\|.Policy]]
	</noinclude>		</noinclude>

FGrose at 15:08, 1 November 2011

2011-11-01T15:08:18Z

← Older revision		Revision as of 11:08, 1 November 2011
Line 1:		Line 1:
	<noinclude>~~{{GoogleTrans-en}}{{TOCright}}~~		<noinclude>[[Category:Policy]]
	[[Category:Feature\|<Policy]]		[[Category:Feature\|<Policy]]
	</noinclude>		</noinclude>

Erikos: /* Propose a feature for addition into the release cycle */

2009-12-05T08:36:15Z

Propose a feature for addition into the release cycle

← Older revision		Revision as of 04:36, 5 December 2009
Line 90:		Line 90:
	# Community consensus: There should be more YES than NO in the community for this Feature.		# Community consensus: There should be more YES than NO in the community for this Feature.
	#* Send an email to sugar-devel mailing list with [FEATURE] tag in the subject asking for feedback. This is to give the community (deployments, developers, teachers etc) the chance to comment.		#* Send an email to sugar-devel mailing list with [FEATURE] tag in the subject asking for feedback. This is to give the community (deployments, developers, teachers etc) the chance to comment.
	#* If your feature adds UI or changes the current UI please add as well the [DESIGN] tag to the subject. The Design Team should be involved in the discussion to guarantee a consistent design and a consistent work flow in Sugar. When presenting the feature to the release manager the design must not be ready but the discussion should have been started.		#* If your feature adds UI or changes the current UI please add as well the [DESIGN] tag to the subject. Please add the flag as well work flow does change or new ones are added. The Design Team should be involved in the discussion to guarantee a consistent design and a consistent work flow in Sugar. When presenting the feature to the release manager the design must not be ready but the discussion should have been started.
	# Documentation: In order to be considered an official feature accepted for the next Sugar release, the feature should be formally documented on a separate wiki page. The wiki page is the same page than the one from above (a blank template is available at [[Features/Feature Template]]). Please make sure it includes the following information.		# Documentation: In order to be considered an official feature accepted for the next Sugar release, the feature should be formally documented on a separate wiki page. The wiki page is the same page than the one from above (a blank template is available at [[Features/Feature Template]]). Please make sure it includes the following information.
	#* Summary of the feature		#* Summary of the feature

Erikos: /* Why does this process matter or why should I care? */

2009-12-04T11:06:02Z

Why does this process matter or why should I care?

← Older revision		Revision as of 07:06, 4 December 2009
Line 9:		Line 9:

	We are currently in discussing on how this process can be used by activities, too. As Activities are not part of Sucrose (the Sugar platform), they do not need to follow the release cycle. Stay tuned on updates to the Feature process regarding activities.		We are currently in discussing on how this process can be used by activities, too. As Activities are not part of Sucrose (the Sugar platform), they do not need to follow the release cycle. Stay tuned on updates to the Feature process regarding activities.

			'''Note:''' For more background on FOSS project development, please refer to Karl Fogel's [http://producingoss.com/ Producing Open Source Software]

	=== Who is responsible for this process? ===		=== Who is responsible for this process? ===

Erikos: /* What do the feature owner need to do over the course of the release cycle? */

2009-12-04T10:49:37Z

What do the feature owner need to do over the course of the release cycle?

← Older revision		Revision as of 06:49, 4 December 2009
Line 153:		Line 153:
	* Complete the feature: The feature must be feature complete by the ''Feature Freeze''.		* Complete the feature: The feature must be feature complete by the ''Feature Freeze''.

	* Inclusion: The owner of the feature is responsible that the Feature is present at latest in the release at Feature Freeze. Please follow the [[Development_Team/Code_Review\|development team guidelines]] to make this happen.		* Inclusion: The owner of the feature is responsible that the Feature is present at latest in the release at Feature Freeze. The developer will work with the module maintainer (e.g. Tomeu for Sugar), who is ultimately responsible to review and merge the new feature. Please follow the [[Development_Team/Code_Review\|development team guidelines]] to make this happen.

	* Feature pages: The feature page should be updated to reflect the current status of the feature. At ''Feature Freeze'': The "How To Test" and "User Experience" section must be completed so that testing of that feature can begin. The section 'Release Notes' must be completed when the writing of the release notes begins.		* Feature pages: The feature page should be updated to reflect the current status of the feature. At ''Feature Freeze'': The "How To Test" and "User Experience" section must be completed so that testing of that feature can begin. The section 'Release Notes' must be completed when the writing of the release notes begins.

Erikos: /* What do the feature owner need to do over the course of the release cycle? */

2009-12-04T10:47:34Z

What do the feature owner need to do over the course of the release cycle?

← Older revision		Revision as of 06:47, 4 December 2009
Line 153:		Line 153:
	* Complete the feature: The feature must be feature complete by the ''Feature Freeze''.		* Complete the feature: The feature must be feature complete by the ''Feature Freeze''.

	* Inclusion: The owner of the feature is responsible that the Feature is latest ~~present into~~ the release at Feature Freeze. Please follow the [[Development_Team/Code_Review\|development team guidelines]] to make this happen.		* Inclusion: The owner of the feature is responsible that the Feature is present at latest in the release at Feature Freeze. Please follow the [[Development_Team/Code_Review\|development team guidelines]] to make this happen.

	* Feature pages: The feature page should be updated to reflect the current status of the feature. At ''Feature Freeze'': The "How To Test" and "User Experience" section must be completed so that testing of that feature can begin. The section 'Release Notes' must be completed when the writing of the release notes begins.		* Feature pages: The feature page should be updated to reflect the current status of the feature. At ''Feature Freeze'': The "How To Test" and "User Experience" section must be completed so that testing of that feature can begin. The section 'Release Notes' must be completed when the writing of the release notes begins.

Erikos: /* Propose a feature for addition into the release cycle */

2009-12-04T10:46:24Z

Propose a feature for addition into the release cycle

← Older revision		Revision as of 06:46, 4 December 2009
Line 83:		Line 83:

	=== Propose a feature for addition into the release cycle ===		=== Propose a feature for addition into the release cycle ===
	The final goal is to have a feature present in a stable release. There are three major steps needed on which the ~~release manager~~ bases his decision to accept a feature or not:		The final goal is to have a feature present in a stable release. There are three major steps needed on which the Release Manager bases his decision to accept a feature or not:

	# Owner: The Feature must have a clear owner (The proposer of the feature and the owner can be the same person).		# Owner: The Feature must have a clear owner (The proposer of the feature and the owner can be the same person).