Re: [openstack-dev] [Openstack-operators] [Neutron] The specs process, effective operators feedback and product management

[Miguel Angel Ajo Pelayo]

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  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  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

[Assaf Muller]

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  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

[Maru Newby]

> On Apr 10, 2015, at 11:04 AM, 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. 
> 
> 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

[Kevin Benton]

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" 
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  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  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 addi

Re: [openstack-dev] [Openstack-operators] [Neutron] The specs process, effective operators feedback and product management

[John Kasperski]

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  > 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  > 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 i

Re: [openstack-dev] [Openstack-operators] [Neutron] The specs process, effective operators feedback and product management

[Salvatore Orlando]

On 9 April 2015 at 17:04, Kyle Mestery  wrote:

> On Thu, Apr 9, 2015 at 9:52 AM, Assaf Muller  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 

Re: [openstack-dev] [Openstack-operators] [Neutron] The specs process, effective operators feedback and product management

[Kyle Mestery]

On Thu, Apr 9, 2015 at 9:52 AM, Assaf Muller  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