Open Stack

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.


Best regards,
Boris Pavlovic

On Fri, Apr 10, 2015 at 7:34 PM, Kevin Benton <blak111 at 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 <amuller at 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 heard.
>>
>> 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.
>>
>> This system will also give drivers a 'way out': The last cycle we spent
>> time refactoring this and that,
>> and developers love doing that so it's easy to get behind. I think that
>> as in the next cycles we move back to features,
>> friction will rise and the process will reveal its flaws.
>>
>> Something to consider: Maybe the top proposal takes a day to implement.
>> Maybe some low priority bug is actually
>> the second highest proposal. Maybe all of the currently marked 'critical'
>> bugs don't even appear on the list.
>> Maybe we aren't spending our time where we should be.
>>
>> And now a word from our legal team: In order for this to be viable, the
>> system would have to be a
>> *non binding*, *additional* form of input. The top proposal *could* be
>> declined for the same reasons
>> that specs are currently being declined. It would not replace any of our
>> current systems or processes.
>>
>>
>> Assaf Muller, Cloud Networking Engineer
>> Red Hat
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>
>
>
> --
> Kevin Benton
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150410/e3e1a838/attachment-0001.html>