Open Stack

On 28 October 2013 15:39, Anne Gentle <anne at openstack.org> wrote:
> On Mon, Oct 28, 2013 at 9:24 AM, John Garbutt <john at johngarbutt.com> wrote:
>> Here is a really bad attempt at codifying what I think about features vs
>> bugs:
>> 1) If its a new API call, or a change in behaviour, or a new config
>> setting, its a feature
>> 2) If its just refactoring or just adding tests, it is neither a
>> feature or a bug
>> 4) A bug is a change to ensure the system operates "as expected" by
>> the current documentation
>
> This line is the only one I have a little bit of concern with when looking
> across all projects. We just have to get better at documentation if we're
> going to make the docs the measure to log bugs against a project. John, your
> docs are really on target here, but I fear other projects would struggle to
> set expectations for how something is supposed to work. For example I don't
> think Hyper-V is documented much at all. So just be careful with this one,
> use good judgement, and keep this in mind when looking for docs to write.

Yes very good point. I was/am in two minds about that:

* Part of me wants to say: 5) if there is no documentation, it needs a
blueprint, so we can add some.
* The other part of me want's to say: "as expected" by the related
blueprint specification, documentation and current user expectations.

I am not sure which is best.

>>
>> 3) A bug should be changed to a feature if it matches case (1)
>>
>> If we don't approve the blueprint first, we may end up not having
>> enough information to create the required documentation, so I vote we
>> enforce that a blueprint should be approved before we merge code.
>>
>> Getting a blueprint approved as low priority, should be quicker and
>> easier than getting the associated code approved. Granted that might
>> not be the case today, but we need to fix that.
>>