Open Stack

+1

Keeping features separate as blueprints (even tiny ones with no spec)
really will let us focus on the volume of real bugs.

On Tue, Jun 24, 2014 at 5:14 PM, Dmitry Pyzhov <dpyzhov at mirantis.com> wrote:
> Guys,
>
> We have a beautiful contribution guide:
> https://wiki.openstack.org/wiki/Fuel/How_to_contribute
>
> However, I would like to address several issues in our blueprints/bugs
> processes. Let's discuss and vote on my proposals.
>
> 1) First of all, the bug counter is an excellent metric for quality. So
> let's use it only for bugs and track all feature requirement as blueprints.
> Here is what it means:
>
> 1a) If a bug report does not describe a user’s pain, a blueprint should be
> created and bug should be closed as invalid
> 1b) If a bug report does relate to a user’s pain, a blueprint should be
> created and linked to the bug
> 1c) We have an excellent reporting tool, but it needs more metrics: count of
> critical/high bugs, count of bugs assigned to each team. It will require
> support of team members lists, but it seems that we really need it.
>
>
> 2) We have a huge amount of blueprints and it is hard to work with this
> list. A good blueprint needs a fixed scope, spec review and acceptance
> criteria. It is obvious for me that we can not work on blueprints that do
> not meet these requirements. Therefore:
>
> 2a) Let's copy the nova future series and create a fake milestone 'next' as
> nova does. All unclear blueprints should be moved there. We will pick
> blueprints from there, add spec and other info and target them to a
> milestone when we are really ready to work on a particular blueprint. Our
> release page will look much more close to reality and much more readable in
> this case.
> 2b) Each blueprint in a milestone should contain information about feature
> lead, design reviewers, developers, qa, acceptance criteria. Spec is
> optional for trivial blueprints. If a spec is created, the designated
> reviewer(s) should put (+1) right into the blueprint description.
> 2c) Every blueprint spec should be updated before feature freeze with the
> latest actual information. Actually, I'm not sure if we care about spec
> after feature development, but it seems to be logical to have correct
> information in specs.
> 2d) We should avoid creating interconnected blueprints wherever possible. Of
> course we can have several blueprints for one big feature if it can be split
> into several shippable blocks for several releases or for several teams. In
> most cases, small parts should be tracked as work items of a single
> blueprint.
>
>
> 3) Every review request without a bug or blueprint link should be checked
> carefully.
>
> 3a) It should contain a complete description of what is being done and why
> 3b) It should not require backports to stable branches (backports are
> bugfixes only)
> 3c) It should not require changes to documentation or be mentioned in
> release notes
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>