<div dir="ltr">If fixing a typo in a document is considered a technical contribution, then I think we've already cast the net far and wide. ATC as used has become a name implying you're trying to make OpenStack better, more useable, and more functional for those who would use/deploy (and fix, update, enhance) it. And somehow that's been connected to touching the codebase directly. This implies that an architectural discussion that changes OpenStack, but doesn't initiate a code change is not an ATC worthy event.<div><br></div><div>So let's fix this, and if a proposal is needed how about:</div><div><br></div><div>Active Technical Contributions are those that improve OpenStack either directly by impacting the code base, or indirectly by making OpenStack useable.</div><div><br></div><div>Robert</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 4, 2016 at 10:07 AM, Jonathan Proulx <span dir="ltr"><<a href="mailto:jon@csail.mit.edu" target="_blank">jon@csail.mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Mar 04, 2016 at 12:20:44PM +0000, Jeremy Stanley wrote:<br>
<span class="">:On 2016-03-04 10:02:36 +0100 (+0100), Thierry Carrez wrote:<br>
:[...]<br>
:> Upstream contributors are represented by the Technical Committee<br>
:> and vote for it. Downstream contributors are represented by the<br>
:> User Committee and (imho) should vote for it.<br>
:[...]<br>
:<br>
:Right, this brings up the other important point I meant to make. The<br>
:purpose of the "ATC" designation is to figure out who gets to vote<br>
:for the Technical Committee, as a form of self-governance. That's<br>
:all, but it's very important (in my opinion, far, far, far more<br>
:important than some look-at-me status on a conference badge or a<br>
:hand-out on free admission to an event). Granting votes for the<br>
:upstream technical governing body to people who aren't involved<br>
:directly in upstream technology decisions makes little sense, or at<br>
:least causes it to cease being self-governance (as much as letting<br>
:all of OpenStack's software developers decide who should run the<br>
:User Committee would make it no longer well represent downstream<br>
:users).<br>
<br>
</span>At the risk of drifting off topic that concern "letting all of<br>
<span class="">OpenStack's software developers decide who should run the User<br>
</span>Committee (UC)" is largely why the UC hasn't expanded to include<br>
elected positions.<br>
<br>
As currently written bylaws define the UC as 3 appointed positions. !<br>
appointed by TC one by the board and the third by thte other two (FYI<br>
I'm currently sitting in the TC apointed seat). The by laws further<br>
allow the UC to add seats elected by all foundation members. In<br>
Tokyo summit sessions where expantion was discussed the consensus was<br>
to encourage more volunteer participation but not to add more formal<br>
seats because there was no way to properly define the voting<br>
constituency. Personally I can see both sides of that argument, but<br>
the sense of the room was not to add elected positions untill we can<br>
better deifne the constituency (that discussion could be reopened but<br>
if you'd like to do so please start a new thread)<br>
<br>
Perhaps nailing down this definition for recognition can actually have<br>
broader implications and help to define who elects the UC. It would<br>
take a by-law change of course, but atleast we'd actually have a good<br>
proposal (which we currently don't).<br>
<br>
-Jon<br>
<div class="HOEnZb"><div class="h5"><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" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</div></div></blockquote></div><br></div>