Re: [openstack-dev] [all] [tc] A way for Operators/Users to submit feature requests
On 14 May 2015 at 21:55, Boris Pavlovic bo...@pavlovic.me wrote: Robert, So I think we should explicitly leave room for experimentation and divergence, but also encourage a single common path - don't be different to be different, be difference because it is important in this specific case. First of all feature request are the same process as specs (in other projects) Difference is what we are expecting to get in spec and feature request (and auditory) By the way feature request in Rally were introduced far far before backlogs in other Keystone and Nova. It strange from me that those projects are reinventing working mechanism from other project=( and not just use it. I am totally open standardising. Nova added backlogs after feedback after the cross project session I ran at the last summit. It looked at standardising the spec process between the different projects using specs: https://etherpad.openstack.org/p/kilo-crossproject-specs The consensus in that session was for projects to adopt the backlog approach, roughly similar to what keystone was using. My original email to the operators linked to this web page: http://specs.openstack.org/openstack/nova-specs/specs/backlog/index.html It explains backlog specs as: If you have a problem that needs solving, but you are not currently planning on implementing it, this is the place we can store your ideas. These specifications have the problem description completed, but all other sections are optional. I like how it puts queued developer specs and operator requests through the same process, to keep things simple. Rally's feature requests and Nova's backlog look very similar to me (except the name)? Is there something big I am missing here? Thanks, John __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [tc] A way for Operators/Users to submit feature requests
On May 14, 2015 12:50 PM, Maish Saidel-Keesing mais...@maishsk.com wrote: I just saw an email on the Operators list [1] that I think would allow a much simpler process for the non-developer community to submit a feature request. I understand that this was raised once upon a time [2] - at least in part a while back. Rally have have the option to submit a feature request (a.k.a. backlog) - which I think is straight forward and simple. I think this will be a good way for those who are not familiar with the way a spec should be written, and honestly would not know how to write such a spec for any of the projects, but have identified a missing feature or a need for an improvement in one of the Projects. They only need to specify 3 small things (a sentence / two for each) 1. Use Case 2. Problem description 3. Possible solution That is exactly what the backlog is supposed to be. These specifications have the problem description completed, but all other sections are optional. From: http://specs.openstack.org/openstack/nova-specs/specs/backlog/ As I am sure there is room for improvement, why not propose a change to the specs repo to improve the backlog spec process? I am not saying that each feature request should be implemented - or that each possible solution is the best and only way to solve the problem. That should be up to each and every project how this will be (or even if it should be) implemented. How important it will be for them to implement this feature and what priority this should receive. A developer then picks up the request and turns it into a proper blueprint with proper actionable items. Of course this has to be valid feature request, and not just someone looking for support - how exactly this should be vetted, I have not thought this through till the end. But I was looking to hear some feedback on the idea of making this a way for all of the OpenStack projects to allow them to collect actual feedback in a simple way. Your thoughts and feedback would be appreciated. [1] http://lists.openstack.org/pipermail/openstack-operators/2015-May/006982.html [2] http://lists.openstack.org/pipermail/openstack-dev/2014-August/044057.html -- Best Regards, Maish Saidel-Keesing __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [tc] A way for Operators/Users to submit feature requests
On 05/14/2015 03:48 PM, Maish Saidel-Keesing wrote: I just saw an email on the Operators list [1] that I think would allow a much simpler process for the non-developer community to submit a feature request. I understand that this was raised once upon a time [2] - at least in part a while back. Rally have have the option to submit a feature request (a.k.a. backlog) - which I think is straight forward and simple. I think this will be a good way for those who are not familiar with the way a spec should be written, and honestly would not know how to write such a spec for any of the projects, but have identified a missing feature or a need for an improvement in one of the Projects. They only need to specify 3 small things (a sentence / two for each) 1. Use Case 2. Problem description 3. Possible solution I am not saying that each feature request should be implemented - or that each possible solution is the best and only way to solve the problem. That should be up to each and every project how this will be (or even if it should be) implemented. How important it will be for them to implement this feature and what priority this should receive. A developer then picks up the request and turns it into a proper blueprint with proper actionable items. Of course this has to be valid feature request, and not just someone looking for support - how exactly this should be vetted, I have not thought this through till the end. But I was looking to hear some feedback on the idea of making this a way for all of the OpenStack projects to allow them to collect actual feedback in a simple way. Hi Maish, I would support this kind of thing for projects that wish to do it, but at the same time, I wouldn't want the TC to mandate all projects use this method of collecting feedback. Projects, IMHO, should be free to self-organize as they wish, including developing processes that make the most sense for the project team. Best, -jay Your thoughts and feedback would be appreciated. [1] http://lists.openstack.org/pipermail/openstack-operators/2015-May/006982.html [2] http://lists.openstack.org/pipermail/openstack-dev/2014-August/044057.html __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [tc] A way for Operators/Users to submit feature requests
On 05/14/2015 04:34 PM, Jay Pipes wrote: On 05/14/2015 03:48 PM, Maish Saidel-Keesing wrote: I just saw an email on the Operators list [1] that I think would allow a much simpler process for the non-developer community to submit a feature request. I understand that this was raised once upon a time [2] - at least in part a while back. Rally have have the option to submit a feature request (a.k.a. backlog) - which I think is straight forward and simple. I think this will be a good way for those who are not familiar with the way a spec should be written, and honestly would not know how to write such a spec for any of the projects, but have identified a missing feature or a need for an improvement in one of the Projects. They only need to specify 3 small things (a sentence / two for each) 1. Use Case 2. Problem description 3. Possible solution I am not saying that each feature request should be implemented - or that each possible solution is the best and only way to solve the problem. That should be up to each and every project how this will be (or even if it should be) implemented. How important it will be for them to implement this feature and what priority this should receive. A developer then picks up the request and turns it into a proper blueprint with proper actionable items. Of course this has to be valid feature request, and not just someone looking for support - how exactly this should be vetted, I have not thought this through till the end. But I was looking to hear some feedback on the idea of making this a way for all of the OpenStack projects to allow them to collect actual feedback in a simple way. Hi Maish, I would support this kind of thing for projects that wish to do it, but at the same time, I wouldn't want the TC to mandate all projects use this method of collecting feedback. Projects, IMHO, should be free to self-organize as they wish, including developing processes that make the most sense for the project team. Many projects, including at least keystone and nova (others too I believe), support the idea of a backlog spec. Which is exactly this kind of things. A feature, described in some detail as to why it's interesting, that has no current implementer. I can then live in the specs tree as good idea, and future implementers are encouraged to dive in. -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [tc] A way for Operators/Users to submit feature requests
On 15 May 2015 at 08:34, Jay Pipes jaypi...@gmail.com wrote: Hi Maish, I would support this kind of thing for projects that wish to do it, but at the same time, I wouldn't want the TC to mandate all projects use this method of collecting feedback. Projects, IMHO, should be free to self-organize as they wish, including developing processes that make the most sense for the project team. I think there is a balance to be struck. Where we tell users and operators to learn something different for every project, that has real impact. It makes it harder to engage with us, and it makes it harder to move between projects for contributors. Imagine if we had a spread of gerrit, github PR's, launchpad reviews, gitlab PRs and bitbucket PR's - say nova, swift, barbican, keystone and glance. That sounds silly because we all recognise the costs of switching there: I think we need to recognise the costs for other people even in things that as developers we don't interact with all that much. So I think we should explicitly leave room for experimentation and divergence, but also encourage a single common path - don't be different to be different, be difference because it is important in this specific case. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all] [tc] A way for Operators/Users to submit feature requests
I just saw an email on the Operators list [1] that I think would allow a much simpler process for the non-developer community to submit a feature request. I understand that this was raised once upon a time [2] - at least in part a while back. Rally have have the option to submit a feature request (a.k.a. backlog) - which I think is straight forward and simple. I think this will be a good way for those who are not familiar with the way a spec should be written, and honestly would not know how to write such a spec for any of the projects, but have identified a missing feature or a need for an improvement in one of the Projects. They only need to specify 3 small things (a sentence / two for each) 1. Use Case 2. Problem description 3. Possible solution I am not saying that each feature request should be implemented - or that each possible solution is the best and only way to solve the problem. That should be up to each and every project how this will be (or even if it should be) implemented. How important it will be for them to implement this feature and what priority this should receive. A developer then picks up the request and turns it into a proper blueprint with proper actionable items. Of course this has to be valid feature request, and not just someone looking for support - how exactly this should be vetted, I have not thought this through till the end. But I was looking to hear some feedback on the idea of making this a way for all of the OpenStack projects to allow them to collect actual feedback in a simple way. Your thoughts and feedback would be appreciated. [1] http://lists.openstack.org/pipermail/openstack-operators/2015-May/006982.html [2] http://lists.openstack.org/pipermail/openstack-dev/2014-August/044057.html -- Best Regards, Maish Saidel-Keesing __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [tc] A way for Operators/Users to submit feature requests
Robert, So I think we should explicitly leave room for experimentation and divergence, but also encourage a single common path - don't be different to be different, be difference because it is important in this specific case. First of all feature request are the same process as specs (in other projects) Difference is what we are expecting to get in spec and feature request (and auditory) By the way feature request in Rally were introduced* far far before backlogs in other Keystone and Nova.* It strange from me that those projects are reinventing working mechanism from other project=( and not just use it. Best regards, Boris Pavlovic On Thu, May 14, 2015 at 11:45 PM, Robert Collins robe...@robertcollins.net wrote: On 15 May 2015 at 08:34, Jay Pipes jaypi...@gmail.com wrote: Hi Maish, I would support this kind of thing for projects that wish to do it, but at the same time, I wouldn't want the TC to mandate all projects use this method of collecting feedback. Projects, IMHO, should be free to self-organize as they wish, including developing processes that make the most sense for the project team. I think there is a balance to be struck. Where we tell users and operators to learn something different for every project, that has real impact. It makes it harder to engage with us, and it makes it harder to move between projects for contributors. Imagine if we had a spread of gerrit, github PR's, launchpad reviews, gitlab PRs and bitbucket PR's - say nova, swift, barbican, keystone and glance. That sounds silly because we all recognise the costs of switching there: I think we need to recognise the costs for other people even in things that as developers we don't interact with all that much. So I think we should explicitly leave room for experimentation and divergence, but also encourage a single common path - don't be different to be different, be difference because it is important in this specific case. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [tc] A way for Operators/Users to submit feature requests
On 05/14/15 23:34, Jay Pipes wrote: On 05/14/2015 03:48 PM, Maish Saidel-Keesing wrote: I just saw an email on the Operators list [1] that I think would allow a much simpler process for the non-developer community to submit a feature request. I understand that this was raised once upon a time [2] - at least in part a while back. Rally have have the option to submit a feature request (a.k.a. backlog) - which I think is straight forward and simple. I think this will be a good way for those who are not familiar with the way a spec should be written, and honestly would not know how to write such a spec for any of the projects, but have identified a missing feature or a need for an improvement in one of the Projects. They only need to specify 3 small things (a sentence / two for each) 1. Use Case 2. Problem description 3. Possible solution I am not saying that each feature request should be implemented - or that each possible solution is the best and only way to solve the problem. That should be up to each and every project how this will be (or even if it should be) implemented. How important it will be for them to implement this feature and what priority this should receive. A developer then picks up the request and turns it into a proper blueprint with proper actionable items. Of course this has to be valid feature request, and not just someone looking for support - how exactly this should be vetted, I have not thought this through till the end. But I was looking to hear some feedback on the idea of making this a way for all of the OpenStack projects to allow them to collect actual feedback in a simple way. Hi Maish, I would support this kind of thing for projects that wish to do it, but at the same time, I wouldn't want the TC to mandate all projects use this method of collecting feedback. Projects, IMHO, should be free to self-organize as they wish, including developing processes that make the most sense for the project team. Best, -jay Thanks for the feedback Jay. There is a line between projects self organizing and providing a standard way that OpenStack does things. The TC (and the community as a whole) has decided on several guidelines for projects to be part of OpenStack. The way we gate, testing, security guidelines, naming conventions, etc.. These are mandated. A standard way of accepting feature requests will be a good thing in my opinion. -- Best Regards, Maish Saidel-Keesing __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
