Open Stack

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 <blak111 at gmail.com
> <mailto: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
>     <mailto: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
>         <mailto: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://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
John Kasperski

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150410/3588ed20/attachment.html>