[Sugar-devel] Feature Process for Activities was (Re: Sugar Digest 2009-11-30)

[Gary C Martin]

Hi Simon,

On 4 Dec 2009, at 11:14, Simon Schampijer wrote:

> On 11/30/2009 10:56 PM, Simon Schampijer wrote:
>> On 11/30/2009 09:28 PM, Walter Bender wrote:
>> [snip]
>>> 2. Simon Schampijer, the Sugar Release Manager, has put together a
>>> detailed set of pages in the wiki outlining our policy
>>> [[http://wiki/sugarlabs.org/go/Features/Policy]] and process
>>> [[http://wiki/sugarlabs.org/go/Features/Feature_Template]] for
>>> proposing new Sugar features. "The main goal of the feature policy is
>>> to make systematic and predictable the process by which community
>>> ideas on how Sugar should evolve get transformed into actionable
>>> proposals."
>>> 
>>> Simon and I have been discussing the scope of this policy in IRC. It
>>> is appropriate and customary for the Release Manager to set policy,
>>> but I would like to see the process followed more generally, as it
>>> provides a structure that the Activity Team can also leverage as part
>>> of the on-going Sugar activity update process. Activities updates
>>> wouldn't be tied to Sucrose release cycle, but it provides a nice
>>> framework for community feedback and makes clear the roles of
>>> ideation, implementation, and packaging and maintenance.
>> 
>> Of course I am happy if the Feature Process Framework will be used as
>> well by the activity team. So far I only thought about the Sucrose
>> release using the Framework. A process gets to be something useful - the
>> moment it is used. For the Sucrose release we have been seen use and it
>> has delivered some value, too.
>> 
>> Is the activity community interested in using the Framework, too?
>> 
>> If yes)
>> There is the part in the wiki, where we describe what is needed to get a
>> Feature in a a Sucrose release [1]. How would the activity team describe
>> that part? What is the policy for getting an activity Feature into an
>> activity release?
>> 
>> Please discuss here, and/or use the talk page to describe the activity
>> team policy. We can merge it then in the main page. Direct edits are not
>> that easy for me to keep a track on.
>> 
>> Thanks,
>>     Simon
>> 
>> [1]
>> http://wiki.sugarlabs.org/go/Features/Policy#Propose_a_feature_for_addition_into_the_release_cycle
> 
> I moved the activity feature specific part out from the main policy 
> page. As it was only described for proposing a feature and all the rest 
> of the page was about "how to get a Feature included into a Sucrose 
> release", i found it a bit confusing (activities are not part of Sucrose).
> 
> As I said, there might be some value for the activity team to use the 
> Feature Framework, too. As the main goal is: "The main goal of the 
> feature policy is to make systematic and predictable the process by 
> which community ideas on how Sugar should evolve get transformed into 
> actionable proposals."
> 
> However we need to define the process on how to get the Feature into an 
> activity release. I sketched something up here on the talk page:
> 
> http://wiki.sugarlabs.org/go/Talk:Features/Policy
> 
> Activity maintainers please comment,

Hmmm, I'm not sure what value is added by trying to formally document this. I understand the need for a strict process in Sucrose as there are many authors working on different components that have to end up forming a whole product. For activities, most have an individual author, or perhaps several interested individuals (forming ad-hoc teams when needed e.g. Asaf, Brian, and myself pooled together to work on the last couple of releases of Physics).

As an activity maintainer, I watch the mail-lists/blogs for useful feedback, try to keep an eye on where Sucrose and other activities are going (e.g new toolbar support to improve usability, Journal "send to feature" requiring that activities to set a MIME type for their objects), and use bugs.sl.org trac tickets to work through formally reported bugs and feature suggestions.

Something like Browse is perhaps an exception. It's a critical activity for Sugar as it is part of so many users work flows – downloading assets, external research & communication, and uploading of final work – any major changes/additions to it's features may impact many users. In such a case it is likely in the activity author's interest to seek community feedback on an idea before making a significant change. That could be via the mail-lists, or a wiki page if that's more appropriate.

Regards,
--Gary