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 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-operat...@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-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:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- > John Kasperski > > > __________________________________________________________________________ > 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
