Hi, I really like what Mike proposed. It will help us to keep milestone clean and accurate.
-- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Wed, Aug 6, 2014 at 11:26 AM, Mike Scherbakov <mscherba...@mirantis.com> wrote: > As we are before next milestone, let's get back to this excellent (in my > opinion) proposal from Dmitry. Current situation is the following: there > are 121 blueprints targeted for 6.0. Most of them miss a header with > QA/reviewers/developers information, basically those are incomplete > blueprints initially. Many of them have such a cryptic description, that it > is impossible to understand the main idea. > > My suggestion for immediate actions, strictly following original email > from Dmitry, is the following: > > 1. Move all 6.0 blueprints to "next" milestone and clear up assignee > (so others know that it's not taken by anyone) > 2. Start adding blueprints to 6.0 only if they satisfy criteria of > clarity and filled information: > > > Each blueprint in a milestone should contain information about > feature lead, design reviewers, developers, qa, acceptance criteria. > > Once we know who is going to work on the blueprint, who commit for it, > then the blueprint can be added. We know that behind every engineer is the > company, so feature lead should negotiate first with the management of the > company to get allocated for the particular feature. Same applies to a team > of developers working on a feature. > > Fuelers, any objections? > > > On Fri, Jul 4, 2014 at 8:26 PM, Dmitry Pyzhov <dpyz...@mirantis.com> > wrote: > >> Do not cheat. If we need to add functionality after feature freeze, then >> let add functionality after feature freeze. No reason for additional >> obfuscation. It will make our workflow for blueprints harder, but it will >> help us. We will see what we are really going to do and plan our work >> better. >> >> Also we can create a beta iso with all features in 'beta available' >> status. It will help to make sure that small improvements are not break >> anything and can be merged without any fear. >> >> >> On Tue, Jul 1, 2014 at 3:00 PM, Vladimir Kuklin <vkuk...@mirantis.com> >> wrote: >> >>> I have some objections. We are trying to follow a strict development >>> workflow with feature freeze stage. In this case we will have to miss small >>> enhancements that can emerge after FF date and can bring essential benefits >>> along with small risks of breaking anything (e.g. changing some config >>> options for galera or other stuff). We maintained such small changes as >>> bugs because of this FF rule. As our project is growing, these last minute >>> calls for small changes are going to be more and more probable. My >>> suggestion is that we somehow modify our workflow allowing these small >>> features to get through FF stage or we are risking to have an endless queue >>> of enhancements that users will never see in the release. >>> >>> >>> On Thu, Jun 26, 2014 at 8:07 PM, Matthew Mosesohn < >>> mmoses...@mirantis.com> wrote: >>> >>>> +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 <dpyz...@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@lists.openstack.org >>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> > >>>> >>>> _______________________________________________ >>>> OpenStack-dev mailing list >>>> OpenStack-dev@lists.openstack.org >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>> >>> >>> >>> -- >>> Yours Faithfully, >>> Vladimir Kuklin, >>> Fuel Library Tech Lead, >>> Mirantis, Inc. >>> +7 (495) 640-49-04 >>> +7 (926) 702-39-68 >>> Skype kuklinvv >>> 45bk3, Vorontsovskaya Str. >>> Moscow, Russia, >>> www.mirantis.com <http://www.mirantis.ru/> >>> www.mirantis.ru >>> vkuk...@mirantis.com >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > Mike Scherbakov > #mihgen > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
