[Openstack-operators] [openstack-community] Recognising Ops contributions

Matt Jarvis matt.jarvis at datacentred.co.uk
Fri Mar 4 17:30:41 UTC 2016


+1

On 4 March 2016 at 17:21, Robert Starmer <robert at kumul.us> wrote:

> 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.
>
> So let's fix this, and if a proposal is needed how about:
>
> Active Technical Contributions are those that improve OpenStack either
> directly by impacting the code base, or indirectly by making OpenStack
> useable.
>
> Robert
>
> On Fri, Mar 4, 2016 at 10:07 AM, Jonathan Proulx <jon at csail.mit.edu>
> wrote:
>
>> On Fri, Mar 04, 2016 at 12:20:44PM +0000, Jeremy Stanley wrote:
>> :On 2016-03-04 10:02:36 +0100 (+0100), Thierry Carrez wrote:
>> :[...]
>> :> Upstream contributors are represented by the Technical Committee
>> :> and vote for it. Downstream contributors are represented by the
>> :> User Committee and (imho) should vote for it.
>> :[...]
>> :
>> :Right, this brings up the other important point I meant to make. The
>> :purpose of the "ATC" designation is to figure out who gets to vote
>> :for the Technical Committee, as a form of self-governance. That's
>> :all, but it's very important (in my opinion, far, far, far more
>> :important than some look-at-me status on a conference badge or a
>> :hand-out on free admission to an event). Granting votes for the
>> :upstream technical governing body to people who aren't involved
>> :directly in upstream technology decisions makes little sense, or at
>> :least causes it to cease being self-governance (as much as letting
>> :all of OpenStack's software developers decide who should run the
>> :User Committee would make it no longer well represent downstream
>> :users).
>>
>> At the risk of drifting off topic that concern "letting all of
>> OpenStack's software developers decide who should run the User
>> Committee (UC)" is largely why the UC hasn't expanded to include
>> elected positions.
>>
>> As currently written bylaws define the UC as 3 appointed positions. !
>> appointed by TC one by the board and the third by thte other two (FYI
>> I'm currently sitting in the TC apointed seat).  The by laws further
>> allow the UC to add seats elected by all foundation members.  In
>> Tokyo summit sessions where expantion was discussed the consensus was
>> to encourage more volunteer participation but not to add more formal
>> seats because there was no way to properly define the voting
>> constituency. Personally I can see both sides of that argument, but
>> the sense of the room was not to add elected positions untill we can
>> better deifne the constituency (that discussion could be reopened but
>> if you'd like to do so please start a new thread)
>>
>> Perhaps nailing down this definition for recognition can actually have
>> broader implications and help to define who elects the UC.  It would
>> take a by-law change of course, but atleast we'd actually have a good
>> proposal (which we currently don't).
>>
>> -Jon
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>

-- 
DataCentred Limited registered in England and Wales no. 05611763
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20160304/0a6ebe1e/attachment.html>


More information about the OpenStack-operators mailing list