Open Stack

+1

On Fri, Mar 4, 2016 at 12:30 PM, Matt Jarvis <matt.jarvis at datacentred.co.uk>
wrote:

> +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
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20160304/6232e85f/attachment.html>