Difference between revisions of "The Feature Requests Pipeline"

From Audacity Wiki
Jump to: navigation, search
m ("e-mail" => "email")
(More friendly for users to contribute to.)
Line 1: Line 1:
 +
{{intro|1='''This is how we get from ideas to new releases of Audacity'''|2=
 +
 +
[[Feature Requests|Feature Requests]]    -->   [[:Category:Proposal|Proposals]]    -->   [[Audacity Development Projects|Projects]]    -->   [[:Category:Release_Notes|Releases]]
 +
 +
}}
 +
 +
 +
==The Pipeline==
 +
* Users add their requests for new features to the [[Feature Requests|Feature Requests page]]. 
 +
* Developers create [[:Category:Proposal|Proposal pages]] for a feature to discuss the details.
 +
** [[Feature Requests]] get votes and are collected into related feature groups.
 +
** [[:Category:Proposal|Project proposals]] get reviewed and modified.
 +
* Development starts and is tracked in [[Audacity Development Projects|Projects pages]]. 
 +
* The new features are tested, refined, and released in a new Audacity release.
 +
 +
 +
__TOC__
 +
 +
 +
 +
===Adding Feature Requests===
 +
* On the [[Feature Requests]] page. 
 +
** We ask users to follow some fairly detailed [[Editing_Feature_Requests|instructions]] in editing and voting for features so that we can keep them in some order. 
 +
** We also receive some feature requests at our feedback email address, and on our [http://audacityteam.org/forum/ Forum].
 +
** We add these to the Feature Requests Wiki page too, although requests from the Forum are normally added to [[Pending Feature Requests]] for review before addition to Feature Requests itself.
 +
 +
 +
===Contributing to Proposals===
 +
* A small number of users create [[Use Cases]] which have groups of related features. 
 +
** Use Cases would make Audacity better suited to some specific application - such as wildlife recording.  These are particularly helpful in motivating the addition of bigger new features.
 +
** Sometimes the proposal pages are accompanied by background notes pages where comparison of options is done. 
 +
 +
 +
===Implementation, Testing and Release===
 +
* Developers write their feature with a conditional #define, so the feature can be turned on or off. 
 +
** The feature is enabled in experimental versions of Audacity long before it is available to users generally.
 +
** New features are tested, debugged, refined. 
 +
** The design may change quite a bit at this stage as the result of feedback.
 +
* After discussion, some of the features under development are incorporated into the [[Roadmap]] and slated for a definite Audacity release number.
 +
 +
 
==Minimality or Flexibility?==
 
==Minimality or Flexibility?==
  
Line 11: Line 52:
 
<br><br>
 
<br><br>
  
__TOC__
 
  
==The Pipeline==
+
 
* Users add their requests for new features to the [[Feature Requests]] page.  We ask them to follow some fairly detailed [[Editing_Feature_Requests|instructions]] in editing and voting for features so that we can keep them in some order.  We attempt to keep it reasonably organised, editing out inessential text, and factoring out the more detailed suggestions to [[:Category:Feature Planning|Feature Planning]] pages of their own.
+
==The GSoC Variation of the Pipeline==
* We also receive feature requests at our feedback email address, and on our [http://audacityteam.org/forum/ Forum]. We add these to the Feature Requests Wiki page too, although requests from the Forum are normally added to [[Pending Feature Requests]] for review before addition to Feature Requests itself.
+
 
* A small number of users create [[Use Cases]] which have groups of related features.  These would make Audacity better suited to some specific application - such as wildlife recordingThese are particularly helpful in motivating the addition of new features.
+
{{hint|1=We are not currently participating in Google Summer of CodeWhen we have, we use a variation on the pipeline for those projects}}
* Developers create [[Audacity Development Projects|Projects]] pages for a feature they are, or that they plan to be, working on.  Often these project progress pages are accompanied by background notes pages where comparison of options is done. 
 
* Developers write their feature with a conditional #define, so that it can be enabled in experimental versions.
 
* After discussion, some of the features under development are incorporated into the [[Roadmap]] and slated for a definite release number.
 
  
  
==The GSoC Variation==
 
 
* In [[:Category:GSoC|GSoC]] there are outline project proposals on the [[GSoC Ideas]] page. Less defined ideas or those with no obvious mentor currently live on [[More GSoC Ideas]]. Students use these proposals as a starting point for their own ideas.
 
* In [[:Category:GSoC|GSoC]] there are outline project proposals on the [[GSoC Ideas]] page. Less defined ideas or those with no obvious mentor currently live on [[More GSoC Ideas]]. Students use these proposals as a starting point for their own ideas.
 
* The students' proposals and ideas get detailed comment and refinement via the Google GSoC app.
 
* The students' proposals and ideas get detailed comment and refinement via the Google GSoC app.

Revision as of 10:01, 20 November 2017

This is how we get from ideas to new releases of Audacity
Feature Requests   -->   Proposals   -->   Projects   -->   Releases


The Pipeline



Adding Feature Requests

  • On the Feature Requests page.
    • We ask users to follow some fairly detailed instructions in editing and voting for features so that we can keep them in some order.
    • We also receive some feature requests at our feedback email address, and on our Forum.
    • We add these to the Feature Requests Wiki page too, although requests from the Forum are normally added to Pending Feature Requests for review before addition to Feature Requests itself.


Contributing to Proposals

  • A small number of users create Use Cases which have groups of related features.
    • Use Cases would make Audacity better suited to some specific application - such as wildlife recording. These are particularly helpful in motivating the addition of bigger new features.
    • Sometimes the proposal pages are accompanied by background notes pages where comparison of options is done.


Implementation, Testing and Release

  • Developers write their feature with a conditional #define, so the feature can be turned on or off.
    • The feature is enabled in experimental versions of Audacity long before it is available to users generally.
    • New features are tested, debugged, refined.
    • The design may change quite a bit at this stage as the result of feedback.
  • After discussion, some of the features under development are incorporated into the Roadmap and slated for a definite Audacity release number.


Minimality or Flexibility?

On the audacity-devel  mailing list we have discussed two strategies:

  • Attempting to keep Audacity lean, simple and efficient. Not branching out into new applications. A focus on quality, stability and speed.
  • Turning Audacity into a more general purpose application. Adding new features for specific applications and interests. Experimental possibly problematic features in Beta releases and stability but fewer features in the stable releases.

If Audacity were a one person effort, keeping the focus of Audacity narrow would be possible. As it is a team effort, and different people have different ideas about what the essentials are, we don't have a choice. We have to keep Audacity open to new features. Most people's motivation for working on the software is to get it to do new things.

This brings with it some problems. We need it to be easier to add experimental features without destabilising the core functionality. The roadmap has us moving towards a more modular architecture. To go with that, more functions for customising the user interface are being written, building on theming. These changes will in many ways make Audacity more like CLAM, Praat, PD and MAX in its structure, but with a particular strength for audio applications that need to view and edit sound.


The GSoC Variation of the Pipeline

We are not currently participating in Google Summer of Code. When we have, we use a variation on the pipeline for those projects


  • In GSoC there are outline project proposals on the GSoC Ideas page. Less defined ideas or those with no obvious mentor currently live on More GSoC Ideas. Students use these proposals as a starting point for their own ideas.
  • The students' proposals and ideas get detailed comment and refinement via the Google GSoC app.
  • The students must maintain a project progress page during the GSoC period whereas this is optional for other developers.
  • Students write their feature with a conditional #define, so that it can be enabled in experimental versions.
  • Depending on maturity of the feature, after GSoC is complete, the feature is enabled in the next beta release after GSoC.