<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 31, 2014 at 12:21 PM, matt <span dir="ltr"><<a href="mailto:matt@nycresistor.com" target="_blank">matt@nycresistor.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Incentives is a very interesting question.<br><br>What sort of incentives exist for devs?  <br>

<br>Acknowledged as Contributor ( ATC ) to OpenStack -- ( resume fodder, free ticket to summit )<br></div>
Voting in PTL, TC<br><br></div><div>I guess those are the official benefits.  There are the unofficial ones such as being saught after in the job market. <br><br></div><div>What sort of incentives do you envision for operators?<br>


<br></div><div>I mean with ATCs it's easy to set a barrier... did you contribute code.  How do you quantify an operators contribution to OpenStack?  When an operator is distinguished as an active contributor do we provide them with the same abilities as an ATC in dev?  There is no PTL for operators... no need for voting for TC... though maybe they should?  <br>


<br></div><div>It raises interesting questions.  And I think it starts with, do we want to create a role for an ATC outside of development ( I think we already do for documentation contributors ). </div></div></blockquote>

<div><br></div><div>Documentation contributors also use the git/gerrit method for updates, so it's easy to track ATC status. Same with the Security Group, they are now housing the Security Notes in a git repo under the openstack org held under the Documentation Program so that they can integrate with docs and get ATC status. </div>

<div><br></div><div>I think the Security team's model is a good one to investigate for operators, though I share Jay's concern about the combination of operator and admin. Still noodling on that one a little bit. </div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div> If so, are they an ATC or an ATC*.  Then comes the question of quantifying contribution.<br>

</div></div></blockquote><div><br></div><div>I think we only have an ATC carrot at the moment. Would like to explore additional carrots but the governance in place is not easy to re-mold. It'd be great to get an ops team going that contributes to the Ops Guide and Admin Guides so work within the existing system while we continue to discuss possible additions to the governance. </div>

<div><br></div><div>In other words, I think that the incentives for engineers could be the same as for devs.</div><div><br></div><div>Great discussion all.</div><div><br></div><div>Anne</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr"><div>
<br></div><div>What are your thoughts?<span class="HOEnZb"><font color="#888888"><br><br></font></span></div><span class="HOEnZb"><font color="#888888"><div>-Matt<br></div><div><div><div><br><br></div></div></div></font></span></div>

<div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 31, 2014 at 12:29 PM, Narayan Desai <span dir="ltr"><<a href="mailto:narayan.desai@gmail.com" target="_blank">narayan.desai@gmail.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Matt. <div><br></div><div>I guess that I slice the problem a little bit differently. while I think that it would be useful to have an advocate on the TC, I think that would probably only fuel the culture mismatch. </div>



<div><br></div><div>I'm a big believer in incentives; I think in this case, all of the project level incentives are structured around development contributions, making unit tests pass, etc. There aren't any incentives explicitly built around reporting operational issues, helping devs get down to root cause, etc. I think that motivation from the top in this regard would help a lot more than having a ops advocate on the TC.</div>



<div> -nld</div></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 31, 2014 at 10:26 AM, matt <span dir="ltr"><<a href="mailto:matt@nycresistor.com" target="_blank">matt@nycresistor.com</a>></span> wrote:<br>



<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Narayan I guess the first fundamental question, as I see it is, do operators deserve a seat at the TC table?<br>



<br></div>I can see the value of having that insight available at that level.  But, the same can be said of users, and security engineering / policy wonks.  And that opens a door to further pollution of what is supposed to be a fairly agile team intended to be focused on engineering rather than politics.  <br>




<br>As with any large organization finding that happy medium for working with other departments is difficult.  I don't think that managerially we will find a total solution.  In fact, I think operators, users, and security folks should NOT be involved in the TC.  I think that the TC should be focused inwards on the engineering effort surrounding the development needs of OpenStack.  If we want to engage at a higher level, then a foundation seat I think makes more sense.<br>




<br></div><div>And, while I think it's important for operators, users, and security wonks to have buy in at the top of the organization helping to steer over all direction, I don't think that addresses what most of the operators really want.  Which is the ability to action change more directly.  The only analog I've seen that works for accomplishing this, is embeds.  What openstack needs is full fledged developers who are targeting operator needs.  We need operators who can code embedded in the standard development process. The reason we need this, is because any effort to contribute to OpenStack engineering, is going to require it.  There is just no way around that.  There's nothing wrong with that either.  This does work.<br>




<br></div><div>However, obviously not everyone gets to be able to contribute.  As stated previously, many of us have day jobs.  We're not given the same levity some of the community contributor show ponies are.  Someone has to go unclog the tubes and clean up after dazzling forays into user excess.  That's where I see an OSOG ( operators group ) coming into play.  The OSOG can set goals for the contributors or just contribute bugs / blueprints more effectively.  If operators want a seat at the table, I think the best way to do that is distill the operators needs in a closed group and then reach out into existing development methods as a unified front.  At that point, embedded operators who contribute can take the ball and run with it, and developers additionally can assist.  <br>




<br></div><div>That's the model I think makes the most sense for us in the long term.  And I say this based on experience developing for openstack products and as an operator on two large openstack clouds.<span><font color="#888888"><br>



<br></font></span></div><span><font color="#888888">
<div>-Matt<br></div></font></span></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 31, 2014 at 10:54 AM, Narayan Desai <span dir="ltr"><<a href="mailto:narayan.desai@gmail.com" target="_blank">narayan.desai@gmail.com</a>></span> wrote:<br>




<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I spend some time about a year ago writing up some thoughts about the user committee, and the major goals I thought it should have. The start of that thread is here:<div>




<a href="http://lists.openstack.org/pipermail/foundation/2012-December/001292.html" target="_blank">http://lists.openstack.org/pipermail/foundation/2012-December/001292.html</a><br>
</div><div>but it continues into the January archives as well:</div><div><a href="http://lists.openstack.org/pipermail/foundation/2013-January/001293.html" target="_blank">http://lists.openstack.org/pipermail/foundation/2013-January/001293.html</a><br>





</div><div><br></div><div>tl;dr I think that the most important problem for the user committee to solve is to figure out a dynamic where operators can fully participate in the project in a deep sense. Openstack has a very developer-centric ethos and structure, which clashes to a substantial extent with the operator community. We need to figure out how to productively marry ops culture (which doesn't focus on writing code, rather on building systems, figuring out how they break, what features they need, etc) with the development mission of the project. </div>





<div><br></div><div>I think that Tim's (& co) work on the user summit is a good step in this direction, but figuring out this culture issue is still the most important issue to solve. </div><div><br></div><div>I'm not lucky enough to have the gift of brevity; several of the mails in the thread above are quite long, and I think both describe the problems I see in detail, and also illustrate how the focus on developer culture doesn't necessarily get the project where it needs to go.</div>





<div> -nld</div><div><br></div></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 31, 2014 at 9:35 AM, Jonathan Proulx <span dir="ltr"><<a href="mailto:jon@jonproulx.com" target="_blank">jon@jonproulx.com</a>></span> wrote:<br>





<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Some Monday morning pre-coffee thoughts<br>
<div><br>
On Sun, Mar 30, 2014 at 10:15 PM, Tom Fifield <<a href="mailto:tom@openstack.org" target="_blank">tom@openstack.org</a>> wrote:<br>
<br>
> So, my reading is we already have such governance established - but rather<br>
> than being an individual, it is a committee - the user committee. We'll need<br>
> to tweak it a bit I guess, but in fact it is already set up such that the TC<br>
> _must_[1] listen to it ... for at least four hours per year ;)<br>
<br>
</div>That's definitely a front runner in my mind, cheers to all the hard<br>
work the existing committee have done around surveys, the expanded<br>
operations track and everything else.<br>
<br>
I do think it's a bit confusingly named & that this stems from a<br>
fundamental flaw in OpenStack community though, that there are two<br>
parts of the community, "Developers" and "Users" and that "User" means<br>
someone who deploys and maintains cloud infrastructure.<br>
<br>
As I see it there's (at least) three major community segments, from<br>
smallest to largest:<br>
<br>
* Developer, who write the code<br>
* Operators/Administrators/(pick your title), who build and maintain<br>
production clouds<br>
* Users who actually deploy applications on top of the cloud<br>
<br>
Obviously many individuals and organizations fall into multiple<br>
categories and within "Users" as writ above there's a variety of<br>
constituencies that could be broken out.<br>
<br>
In terms of Governance do the "User Committee" cover all that is not<br>
dev?  That's really a huge amount of ground to cover and I do think<br>
they've done a great job of it, especially on the ops side as<br>
evidenced by this discussion, and I can see they're reaching out more<br>
to the end users as well or starting to.<br>
<br>
I'd be interested to hear what those who've been doing the job think<br>
needs to be done to scale out and cover the whole constituency? More<br>
member, more volunteer staff, sub-committees, distinct operators and<br>
end user committees, or perhaps the existing structure is sufficient?<br>
<div><br>
> Thoughts? What would you see this group doing?<br>
<br>
</div>I think the user surveys have been very valuable in seeing how<br>
OpenStack is used in the wild, continuing that and refining the<br>
questions so we can identify community priorities is a worthy goal and<br>
an ongoing task that should definitely be continued.<br>
<br>
Facilitating the organization of summit tracks & possible inter-summit<br>
ops gatherings is another I think we have broad agreement on as that<br>
seems to be happening.<br>
<br>
Do we want to produce tangible best practices or example architectures<br>
possibly by inviting in existing configuration management tools?  That<br>
maybe a reach both in terms of our time availability and the interest<br>
of the people who are doing that work now to come in under a new<br>
umbrella.  If that, or something like that were our goal then a PTL<br>
type structure would probably make more sense.<br>
<br>
-Jon<br>
<div><div><br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">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>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">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>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div><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>
<br></blockquote></div><br></div></div>