On 28 October 2013 15:39, Anne Gentle <a...@openstack.org> wrote: > On Mon, Oct 28, 2013 at 9:24 AM, John Garbutt <j...@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. >> _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
