Re: [openstack-dev] [Fuel] Blueprints process
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
Re: [openstack-dev] [Fuel] Blueprints process
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
Re: [openstack-dev] [Fuel] Blueprints process
On 06 Aug 2014, at 10:41, Sergii Golovatiuk sgolovat...@mirantis.com wrote: Hi, I really like what Mike proposed. It will help us to keep milestone clean and accurate. +1 for Mike’s proposal. New members will also benefit from that move: clean picture will make easier to pick up features to work on. Regards, -- Tomasz Napierala Sr. OpenStack Engineer tnapier...@mirantis.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Blueprints process
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
Re: [openstack-dev] [Fuel] Blueprints process
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
Re: [openstack-dev] [Fuel] Blueprints process
+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
