+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 <[email protected]> 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
