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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> 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 > [email protected] > <mailto:[email protected]> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > > > > -- > Kevin Benton > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > [email protected]?subject:unsubscribe > <http://[email protected]?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- John Kasperski
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
