Re: [openstack-dev] [Openstack-operators] [Neutron] The specs process, effective operators feedback and product management
The rally process (email based) doesn’t seem scalable enough for the neutron case IMHO, but I agree that a voting system doesn’t differ too much from launchpad and that it can be gamed. On 22/4/2015, at 1:21, Assaf Muller amul...@redhat.com wrote: Just to offer some closure, it seems like the voting idea was shot down with the energy of a trillion stars, yet the general idea of offering an easy way for users to request features makes sense. Expect to see ideas of how to implement this soon... - Original Message - On Apr 10, 2015, at 11:04 AM, Boris Pavlovic bo...@pavlovic.me wrote: Hi, I believe that specs are too detailed and too dev oriented for managers, operators and devops. They actually don't want/have time to write/read all the stuff in specs and that's why the communication between dev operators community is a broken. I would recommend to think about simpler approaches like making mechanism for proposing features/changes in projects. Like we have in Rally: https://rally.readthedocs.org/en/latest/feature_requests.html This is similar to specs but more concentrate on WHAT rather than HOW. +1 I think the line between HOW and WHAT are too often blurred in Neutron. Unless we’re able to improve our ability to communicate at an appropriate level of abstraction with non-dev stakeholders, meeting their needs will continue to be a struggle. Maru __ 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 Miguel Angel Ajo __ 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] [Openstack-operators] [Neutron] The specs process, effective operators feedback and product management
Just to offer some closure, it seems like the voting idea was shot down with the energy of a trillion stars, yet the general idea of offering an easy way for users to request features makes sense. Expect to see ideas of how to implement this soon... - Original Message - On Apr 10, 2015, at 11:04 AM, Boris Pavlovic bo...@pavlovic.me wrote: Hi, I believe that specs are too detailed and too dev oriented for managers, operators and devops. They actually don't want/have time to write/read all the stuff in specs and that's why the communication between dev operators community is a broken. I would recommend to think about simpler approaches like making mechanism for proposing features/changes in projects. Like we have in Rally: https://rally.readthedocs.org/en/latest/feature_requests.html This is similar to specs but more concentrate on WHAT rather than HOW. +1 I think the line between HOW and WHAT are too often blurred in Neutron. Unless we’re able to improve our ability to communicate at an appropriate level of abstraction with non-dev stakeholders, meeting their needs will continue to be a struggle. Maru __ 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] [Openstack-operators] [Neutron] The specs process, effective operators feedback and product management
On Apr 10, 2015, at 11:04 AM, Boris Pavlovic bo...@pavlovic.me wrote: Hi, I believe that specs are too detailed and too dev oriented for managers, operators and devops. They actually don't want/have time to write/read all the stuff in specs and that's why the communication between dev operators community is a broken. I would recommend to think about simpler approaches like making mechanism for proposing features/changes in projects. Like we have in Rally: https://rally.readthedocs.org/en/latest/feature_requests.html This is similar to specs but more concentrate on WHAT rather than HOW. +1 I think the line between HOW and WHAT are too often blurred in Neutron. Unless we’re able to improve our ability to communicate at an appropriate level of abstraction with non-dev stakeholders, meeting their needs will continue to be a struggle. Maru __ 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] [Openstack-operators] [Neutron] The specs process, effective operators feedback and product management
On 04/10/2015 01:04 PM, Boris Pavlovic wrote: Hi, I believe that specs are too detailed and too dev oriented for managers, operators and devops. They actually don't want/have time to write/read all the stuff in specs and that's why the communication between dev operators community is a broken. +1 I would recommend to think about simpler approaches like making mechanism for proposing features/changes in projects. Like we have in Rally: https://rally.readthedocs.org/en/latest/feature_requests.html Are any other OpenStack projects handling feature requests like this? I think a feature request process like this would be useful across more components than just Neutron. I'm sure there are some requests that would also require changes across multiple components. This is similar to specs but more concentrate on WHAT rather than HOW. Best regards, Boris Pavlovic On Fri, Apr 10, 2015 at 7:34 PM, Kevin Benton blak...@gmail.com mailto:blak...@gmail.com wrote: The Neutron drivers team, on the other hand, don't have a clear incentive (Or I suspect the will) to spend enormous amounts of time doing 'product management', as being a driver is essentially your third or fourth job by this point, and are the same people solving gate issues, merging code, triaging bugs and so on. Are you hinting here that there should be a separate team of people from the developers who are deciding what should and should not be worked on in Neutron? Have there been examples of that working in other open source projects where the majority of the development isn't driven by one employer? I ask that because I don't see much of an incentive for a developer to follow requirements generated by people not familiar with the Neutron code base. One of the roles of the driver team is to determine what is feasible in the release cycle. How would that be possible without actively contributing or (at a minimum) being involved in code reviews? On Thu, Apr 9, 2015 at 7:52 AM, Assaf Muller amul...@redhat.com mailto:amul...@redhat.com wrote: The Neutron specs process was introduced during the Juno timecycle. At the time it was mostly a bureaucratic bottleneck (The ability to say no) to ease the pain of cores and manage workloads throughout a cycle. Perhaps this is a somewhat naive outlook, but I see other positives, such as more upfront design (Some is better than none), less high level talk during the implementation review process and more focus on the details, and 'free' documentation for every major change to the project (Some would say this is kind of a big deal; What better way to write documentation than to force the developers to do it in order for their features to get merged). That being said, you can only get a feature merged if you propose a spec, and the only people largely proposing specs are developers. This ingrains the open source culture of developer focused evolution, that, while empowering and great for developers, is bad for product managers, users (That are sometimes under-presented, as is the case I'm trying to make) and generally causes a lack of a cohesive vision. Like it or not, the specs process and the driver's team approval process form a sort of product management, deciding what features will ultimately go in to Neutron and in what time frame. We shouldn't ignore the fact that we clearly have people and product managers pulling the strings in the background, often deciding where developers will spend their time and what specs to propose, for the purpose of this discussion. I argue that managers often don't have the tools to understand what is important to the project, only to their own customers. The Neutron drivers team, on the other hand, don't have a clear incentive (Or I suspect the will) to spend enormous amounts of time doing 'product management', as being a driver is essentially your third or fourth job by this point, and are the same people solving gate issues, merging code, triaging bugs and so on. I'd like to avoid to go in to a discussion of what's wrong with the current specs process as I'm sure people have heard me complain about this in #openstack-neutron plenty of times before. Instead, I'd like to suggest a system that would perhaps get us to implement specs that are currently not being proposed, and give an additional form of input that would make sure that the development community is spending it's time in the right places.
Re: [openstack-dev] [Openstack-operators] [Neutron] The specs process, effective operators feedback and product management
I like this idea. It leaves specs and implementation details to people familiar with the code base while providing a good place for users and devs to discuss feature requests. On Apr 10, 2015 2:04 PM, John Kasperski jckas...@linux.vnet.ibm.com wrote: On 04/10/2015 01:04 PM, Boris Pavlovic wrote: Hi, I believe that specs are too detailed and too dev oriented for managers, operators and devops. They actually don't want/have time to write/read all the stuff in specs and that's why the communication between dev operators community is a broken. +1 I would recommend to think about simpler approaches like making mechanism for proposing features/changes in projects. Like we have in Rally: https://rally.readthedocs.org/en/latest/feature_requests.html Are any other OpenStack projects handling feature requests like this?I think a feature request process like this would be useful across more components than just Neutron. I'm sure there are some requests that would also require changes across multiple components. This is similar to specs but more concentrate on WHAT rather than HOW. Best regards, Boris Pavlovic On Fri, Apr 10, 2015 at 7:34 PM, Kevin Benton blak...@gmail.com wrote: The Neutron drivers team, on the other hand, don't have a clear incentive (Or I suspect the will) to spend enormous amounts of time doing 'product management', as being a driver is essentially your third or fourth job by this point, and are the same people solving gate issues, merging code, triaging bugs and so on. Are you hinting here that there should be a separate team of people from the developers who are deciding what should and should not be worked on in Neutron? Have there been examples of that working in other open source projects where the majority of the development isn't driven by one employer? I ask that because I don't see much of an incentive for a developer to follow requirements generated by people not familiar with the Neutron code base. One of the roles of the driver team is to determine what is feasible in the release cycle. How would that be possible without actively contributing or (at a minimum) being involved in code reviews? On Thu, Apr 9, 2015 at 7:52 AM, Assaf Muller amul...@redhat.com wrote: The Neutron specs process was introduced during the Juno timecycle. At the time it was mostly a bureaucratic bottleneck (The ability to say no) to ease the pain of cores and manage workloads throughout a cycle. Perhaps this is a somewhat naive outlook, but I see other positives, such as more upfront design (Some is better than none), less high level talk during the implementation review process and more focus on the details, and 'free' documentation for every major change to the project (Some would say this is kind of a big deal; What better way to write documentation than to force the developers to do it in order for their features to get merged). That being said, you can only get a feature merged if you propose a spec, and the only people largely proposing specs are developers. This ingrains the open source culture of developer focused evolution, that, while empowering and great for developers, is bad for product managers, users (That are sometimes under-presented, as is the case I'm trying to make) and generally causes a lack of a cohesive vision. Like it or not, the specs process and the driver's team approval process form a sort of product management, deciding what features will ultimately go in to Neutron and in what time frame. We shouldn't ignore the fact that we clearly have people and product managers pulling the strings in the background, often deciding where developers will spend their time and what specs to propose, for the purpose of this discussion. I argue that managers often don't have the tools to understand what is important to the project, only to their own customers. The Neutron drivers team, on the other hand, don't have a clear incentive (Or I suspect the will) to spend enormous amounts of time doing 'product management', as being a driver is essentially your third or fourth job by this point, and are the same people solving gate issues, merging code, triaging bugs and so on. I'd like to avoid to go in to a discussion of what's wrong with the current specs process as I'm sure people have heard me complain about this in #openstack-neutron plenty of times before. Instead, I'd like to suggest a system that would perhaps get us to implement specs that are currently not being proposed, and give an additional form of input that would make sure that the development community is spending it's time in the right places. While 'super users' have been given more exposure, and operators summits give operators an additional tool to provide feedback, from a developer's point of view, the input is non-empiric and scattered. I also have a hunch that operators still feel their voice is not being
Re: [openstack-dev] [Openstack-operators] [Neutron] The specs process, effective operators feedback and product management
On 9 April 2015 at 17:04, Kyle Mestery mest...@mestery.com wrote: On Thu, Apr 9, 2015 at 9:52 AM, Assaf Muller amul...@redhat.com wrote: The Neutron specs process was introduced during the Juno timecycle. At the time it was mostly a bureaucratic bottleneck (The ability to say no) to ease the pain of cores and manage workloads throughout a cycle. Perhaps this is a somewhat naive outlook, but I see other positives, such as more upfront design (Some is better than none), less high level talk during the implementation review process and more focus on the details, and 'free' documentation for every major change to the project (Some would say this is kind of a big deal; What better way to write documentation than to force the developers to do it in order for their features to get merged). Right. Keep in mind that for Liberty we're making changes to this process. For instance, I've already indicated specs which were approved for Kilo but failed were moved to kilo-backlog. To get them into Liberty, you just propose a patch which moves the patch in the liberty directory. We already have a bunch that have taken this path. I hope we can merge the patches for these specs in Liberty-1. It was never meant to be a bureaucratic bottleneck, although the ability of moving out early in the process blueprint that did not fit in the scope of the current release (or in the scope of the project altogether) was a goal. However, it became a bureaucratic step - it has been surely been perceived as that. Fast tracking blueprints which were already approved makes sense. I believe the process should be made even slimmer, removing the deadlines for spec proposal and approval, and making the approval process simpler - with reviewers being a lot less pedant on one side, and proposer not expecting approval of a spec to be a binding contract on the other side. That being said, you can only get a feature merged if you propose a spec, and the only people largely proposing specs are developers. This ingrains the open source culture of developer focused evolution, that, while empowering and great for developers, is bad for product managers, users (That are sometimes under-presented, as is the case I'm trying to make) and generally causes a lack of a cohesive vision. Like it or not, the specs process and the driver's team approval process form a sort of product management, deciding what features will ultimately go in to Neutron and in what time frame. We haven't done anything to limit reviews of specs by these other users, and in fact, I would love for more users to review these specs. I think your analysis is correct. Neutron is a developer-led community, and that's why the drivers acting also as product managers approve specifications. I don't want to discuss here the merits of the drivers team - that probably deserves another discussion thread - but as Kyle says no-one has been discouraged for reviewing specs and influencing the decision process. The neutron-drivers meetings were very open in my opinion. However, if this meant - as you say - that users, operators, and product managers (yes, them too ;) ) were left off this process, I'm happy to hear proposals to improve it. We shouldn't ignore the fact that we clearly have people and product managers pulling the strings in the background, often deciding where developers will spend their time and what specs to propose, for the purpose of this discussion. I argue that managers often don't have the tools to understand what is important to the project, only to their own customers. The Neutron drivers team, on the other hand, don't have a clear incentive (Or I suspect the will) to spend enormous amounts of time doing 'product management', as being a driver is essentially your third or fourth job by this point, and are the same people solving gate issues, merging code, triaging bugs and so on. I'd like to avoid to go in to a discussion of what's wrong with the current specs process as I'm sure people have heard me complain about this in #openstack-neutron plenty of times before. Yes I have heard you complaining. Ideally I would borrow concepts from anarchism to define an ideal way in which various contributors should take over the different. However, I am afraid this will quickly translate in a sort of extreme neo-liberism which will probably lead the project with self destruction. But I'm all up for a change in the process since what we have now is drifting towards Soviet-style bureaucracy. Jokes apart, I think you are right, the process as it is just adds responsibilities to a subset of people who are already busy with other duties, increasing frustration in people who depends on them (being one of these people I am fully aware of that!) Instead, I'd like to suggest a system that would perhaps get us to implement specs that are currently not being proposed, and give an additional form of input that would make sure
Re: [openstack-dev] [Openstack-operators] [Neutron] The specs process, effective operators feedback and product management
On Thu, Apr 9, 2015 at 9:52 AM, Assaf Muller amul...@redhat.com wrote: The Neutron specs process was introduced during the Juno timecycle. At the time it was mostly a bureaucratic bottleneck (The ability to say no) to ease the pain of cores and manage workloads throughout a cycle. Perhaps this is a somewhat naive outlook, but I see other positives, such as more upfront design (Some is better than none), less high level talk during the implementation review process and more focus on the details, and 'free' documentation for every major change to the project (Some would say this is kind of a big deal; What better way to write documentation than to force the developers to do it in order for their features to get merged). Right. Keep in mind that for Liberty we're making changes to this process. For instance, I've already indicated specs which were approved for Kilo but failed were moved to kilo-backlog. To get them into Liberty, you just propose a patch which moves the patch in the liberty directory. We already have a bunch that have taken this path. I hope we can merge the patches for these specs in Liberty-1. That being said, you can only get a feature merged if you propose a spec, and the only people largely proposing specs are developers. This ingrains the open source culture of developer focused evolution, that, while empowering and great for developers, is bad for product managers, users (That are sometimes under-presented, as is the case I'm trying to make) and generally causes a lack of a cohesive vision. Like it or not, the specs process and the driver's team approval process form a sort of product management, deciding what features will ultimately go in to Neutron and in what time frame. We haven't done anything to limit reviews of specs by these other users, and in fact, I would love for more users to review these specs. We shouldn't ignore the fact that we clearly have people and product managers pulling the strings in the background, often deciding where developers will spend their time and what specs to propose, for the purpose of this discussion. I argue that managers often don't have the tools to understand what is important to the project, only to their own customers. The Neutron drivers team, on the other hand, don't have a clear incentive (Or I suspect the will) to spend enormous amounts of time doing 'product management', as being a driver is essentially your third or fourth job by this point, and are the same people solving gate issues, merging code, triaging bugs and so on. I'd like to avoid to go in to a discussion of what's wrong with the current specs process as I'm sure people have heard me complain about this in #openstack-neutron plenty of times before. Instead, I'd like to suggest a system that would perhaps get us to implement specs that are currently not being proposed, and give an additional form of input that would make sure that the development community is spending it's time in the right places. While these are valid points, the fact that a spec merges isn't an indication that hte code will merge. We have plenty of examples of that in the past two releases. Thus, there are issues beyond the specs process which may prevent your code from merging for an approved spec. That said, I admire your guile in proposing some changes. :) While 'super users' have been given more exposure, and operators summits give operators an additional tool to provide feedback, from a developer's point of view, the input is non-empiric and scattered. I also have a hunch that operators still feel their voice is not being heard. Agreed. I propose an upvote/downvote system (Think Reddit), where everyone (Operators especially) would upload paragraph long explanations of what they think is missing in Neutron. The proposals have to be actionable (So 'Neutron sucks', while of great humorous value, isn't something I can do anything about), and I suspect the downvote system will help self-regulate that anyway. The proposals are not specs, but are like product RFEs, so for example there would not be a 'testing' section, as these proposals will not replace the specs process anyway but augment it as an additional form of input. Proposals can range from new features (Role based access control for Neutron resources, dynamic routing, Neutron availability zones, QoS, ...) to quality of life improvements (Missing logs, too many DEBUG level logs, poor trouble shooting areas with an explanation of what could be improved, ...) to long standing bugs, Nova network parity issues, and whatever else may be irking the operators community. The proposals would have to be moderated (Closing duplicates, low quality submissions and implemented proposals for example) and if that is a concern then I volunteer to do so. Anytime you introduce a voting system you provide incentive to game the system. I am not in favor of a voting system
