<div dir="ltr">><span style="font-size:12.8000001907349px">The Neutron drivers team, on the other hand, </span><span style="font-size:12.8000001907349px">don't have a clear incentive (Or I suspect the will) to spend enormous amounts of time doing 'product management', </span><span style="font-size:12.8000001907349px">as being a driver is essentially your third or fourth job by this point, and are the same people </span><span style="font-size:12.8000001907349px">solving gate issues, merging code, triaging bugs and so on.</span><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">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. </span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">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?</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 9, 2015 at 7:52 AM, Assaf Muller <span dir="ltr"><<a href="mailto:amuller@redhat.com" target="_blank">amuller@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The Neutron specs process was introduced during the Juno timecycle. At the time it<br>
was mostly a bureaucratic bottleneck (The ability to say no) to ease the pain of cores<br>
and manage workloads throughout a cycle. Perhaps this is a somewhat naive outlook,<br>
but I see other positives, such as more upfront design (Some is better than none),<br>
less high level talk during the implementation review process and more focus on the details,<br>
and 'free' documentation for every major change to the project (Some would say this<br>
is kind of a big deal; What better way to write documentation than to force the developers<br>
to do it in order for their features to get merged).<br>
<br>
That being said, you can only get a feature merged if you propose a spec, and the only<br>
people largely proposing specs are developers. This ingrains the open source culture of<br>
developer focused evolution, that, while empowering and great for developers, is bad<br>
for product managers, users (That are sometimes under-presented, as is the case I'm trying<br>
to make) and generally causes a lack of a cohesive vision. Like it or not, the specs process<br>
and the driver's team approval process form a sort of product management, deciding what<br>
features will ultimately go in to Neutron and in what time frame.<br>
<br>
We shouldn't ignore the fact that we clearly have people and product managers pulling the strings<br>
in the background, often deciding where developers will spend their time and what specs to propose,<br>
for the purpose of this discussion. I argue that managers often don't have the tools to understand<br>
what is important to the project, only to their own customers. The Neutron drivers team, on the other hand,<br>
don't have a clear incentive (Or I suspect the will) to spend enormous amounts of time doing 'product management',<br>
as being a driver is essentially your third or fourth job by this point, and are the same people<br>
solving gate issues, merging code, triaging bugs and so on. I'd like to avoid to go in to a discussion of what's<br>
wrong with the current specs process as I'm sure people have heard me complain about this in<br>
#openstack-neutron plenty of times before. Instead, I'd like to suggest a system that would perhaps<br>
get us to implement specs that are currently not being proposed, and give an additional form of<br>
input that would make sure that the development community is spending it's time in the right places.<br>
<br>
While 'super users' have been given more exposure, and operators summits give operators<br>
an additional tool to provide feedback, from a developer's point of view, the input is<br>
non-empiric and scattered. I also have a hunch that operators still feel their voice is not being heard.<br>
<br>
I propose an upvote/downvote system (Think Reddit), where everyone (Operators especially) would upload<br>
paragraph long explanations of what they think is missing in Neutron. The proposals have to be actionable<br>
(So 'Neutron sucks', while of great humorous value, isn't something I can do anything about),<br>
and I suspect the downvote system will help self-regulate that anyway. The proposals are not specs, but are<br>
like product RFEs, so for example there would not be a 'testing' section, as these proposals will not<br>
replace the specs process anyway but augment it as an additional form of input. Proposals can range<br>
from new features (Role based access control for Neutron resources, dynamic routing,<br>
Neutron availability zones, QoS, ...) to quality of life improvements (Missing logs, too many<br>
DEBUG level logs, poor trouble shooting areas with an explanation of what could be improved, ...)<br>
to long standing bugs, Nova network parity issues, and whatever else may be irking the operators community.<br>
The proposals would have to be moderated (Closing duplicates, low quality submissions and implemented proposals<br>
for example) and if that is a concern then I volunteer to do so.<br>
<br>
This system will also give drivers a 'way out': The last cycle we spent time refactoring this and that,<br>
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,<br>
friction will rise and the process will reveal its flaws.<br>
<br>
Something to consider: Maybe the top proposal takes a day to implement. Maybe some low priority bug is actually<br>
the second highest proposal. Maybe all of the currently marked 'critical' bugs don't even appear on the list.<br>
Maybe we aren't spending our time where we should be.<br>
<br>
And now a word from our legal team: In order for this to be viable, the system would have to be a<br>
*non binding*, *additional* form of input. The top proposal *could* be declined for the same reasons<br>
that specs are currently being declined. It would not replace any of our current systems or processes.<br>
<br>
<br>
Assaf Muller, Cloud Networking Engineer<br>
Red Hat<br>
<br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div>Kevin Benton</div></div>
</div>