Re: Contribution Guide / Rules for new features (Was: Propose additions to AnalyserNode for getting complex data)

I don't think it's important to have a test case to propose a feature; I do
think it's critical to have a strong use case / impact description, and a
code sample or two of how the proposal would work.

On the feature freeze - arguably, the particular PR that prompted this
discussion, as well as (say) all the DynamicProcessor and Oscillator
features I've mentioned, could all TECHNICALLY fall under the "we promised
we'd fix this already-existing component" rubric.  :)


On Tue, Oct 22, 2013 at 6:14 AM, Olivier Thereaux <
Olivier.Thereaux@bbc.co.uk> wrote:

> Hi all,
>
>
> On 22 Oct 2013, at 12:57, Paul ADENOT <notifications@github.com>
>  wrote:
>
> > I think a feature addition should be proposed together with a clear use
> case, which would take the form of a snippet of code, and/or an paragraph
> explaining why either this new feature makes authors's life easier, or the
> use-case is simply impossible to achieve using today's Web Audio.
>
> Updating our guidelines for contribution, and especially the rules by
> which we accept new features, has been on a todo list for a long time
> indeed. Spurred by your comment, I have had a go at it:
>
> http://www.w3.org/2011/audio/wiki/Contributing
>
> Note the simple rules for the addition of a new feature:
> http://www.w3.org/2011/audio/wiki/Contributing#Suggest_a_new_feature
>
> A new feature request
> * MUST have a clear use case
> * SHOULD include a code snippet
> * SHOULD (will be a MUST soon) include a test case
>
> Any opinion on SHOULD/MUST? I would like to allow people to suggest
> features even if they don't have it all, but a feature should have them all
> before we accept it in the backlog.
>
> This set of rules is a strawman at this point. If there is consensus we
> will start enforcing it.
>
> > Also, we should really discuss what should be the scope of a so-called
> v1 in a call.
>
> I'm not too keen to reopen this discussion unless there is a strong reason
> to do so.
>
> We recently resolved that our v1 should basically include all features in
> the API and no more. Corollary to this: 1) we can discuss feature requests
> but they will be put on a backlog regardless of whether there is consensus
> and 2) we should focus on fixing / testing the current feature set.
>
>
> http://www.w3.org/2011/audio/wiki/F2F_Mar_2013#Web_Audio_API_V1_.2F_Feature_freeze
>
> --
> Olivier
>
>
>
> -----------------------------
> http://www.bbc.co.uk
> This e-mail (and any attachments) is confidential and
> may contain personal views which are not the views of the BBC unless
> specifically stated.
> If you have received it in
> error, please delete it from your system.
> Do not use, copy or disclose the
> information in any way nor act in reliance on it and notify the sender
> immediately.
> Please note that the BBC monitors e-mails
> sent or received.
> Further communication will signify your consent to
> this.
> -----------------------------
>
>