Open Stack

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" <jckasper at 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 <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
>>
>>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>  --
> John Kasperski
>
>
> __________________________________________________________________________
> 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/8b95c1a8/attachment.html>