Open Stack

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
<http://fuel-launchpad.mirantis.com/project/fuel>, 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 <https://launchpad.net/nova/future>
and create a fake milestone 'next' as nova does
<https://launchpad.net/nova/+milestone/next>. 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
<https://launchpad.net/fuel/+milestone/5.1> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140624/f902d19f/attachment.html>