Open Stack

Honestly, I think the flat (no category or PTL requirements) 11 has
the advantage of simplicity, and likelyhood of attracting / electing
people that touch more than one project, which helps the TC have a
more global project POV. It also means that as the scope of OpenStack
changes we don't have to keep redefining what's an important category
and/or project.

My $0.02 of preference.

On Thu, May 30, 2013 at 11:04 AM, Anne Gentle
<annegentle at justwriteclick.com> wrote:
>
>
>
> On Thu, May 30, 2013 at 9:17 AM, Doug Hellmann <doug.hellmann at dreamhost.com>
> wrote:
>>
>>
>>
>>
>> On Tue, May 28, 2013 at 5:18 PM, Anne Gentle
>> <annegentle at justwriteclick.com> wrote:
>>>
>>>
>>>
>>>
>>> On Tue, May 28, 2013 at 8:29 AM, Thierry Carrez <thierry at openstack.org>
>>> wrote:
>>>>
>>>> Hi everyone,
>>>>
>>>> Back in January we had a thread[1] about modifying how the Technical
>>>> Committee members[2] are selected, in order to cope with future expected
>>>> growth in the number of projects. Unfortunately there wasn't enough time
>>>> to properly discuss it before we had to look into incubated projects
>>>> graduation and setting up the Spring elections, so we decided to
>>>> postpone this to the Havana cycle.
>>>>
>>>> [1]
>>>>
>>>> http://lists.openstack.org/pipermail/openstack-dev/2013-January/004513.html
>>>> [2] https://wiki.openstack.org/wiki/Governance/TechnicalCommittee
>>>>
>>>> To kick off this second attempt, we had an interesting session at the
>>>> Design Summit where various goals were discussed and various solutions
>>>> proposed and compared. I summarized the current state of affairs on the
>>>> wiki at:
>>>>
>>>> https://wiki.openstack.org/wiki/TC_Membership_Models
>>>>
>>>> I'd like everyone interested with this discussion to have a look at this
>>>> page. If you see goals that we missed, please suggest them on the thread
>>>> here, along with how well each currently-proposed solution would score
>>>> against it. Same if you think some model was not scored fairly against
>>>> existing stated goals. Finally, if you have an alternate model which
>>>> you'd like to suggest, feel free to do so. I'll keep the wiki page
>>>> updated based on the ML discussion.
>>>
>>>
>>> Thanks for the draft write up. I have some thoughts for discussion.
>>>
>>> You point to an idea number of 11 for the group size, and I would like
>>> some citation for where that number comes from. I know of the two-pizza rule
>>> in tech, and there's group research around "ten-groups" (saying eight to
>>> fourteen people in a group is about right for overcoming human nature and
>>> collaborating effectively, citing book Corporation Man by Antony Jay
>>> (Pelican 1975)). What causes you to land on 11? Could we say 10 or a range
>>> of 8-14 instead?
>>>
>>> Defining the ideal group size will help with scoring. For example, I
>>> don't think the difference between 11 members and 13 members merits a +2 vs.
>>> a +1 score.
>>>
>>> I also think the ideal number of members will help determine whether
>>> categories are useful, and further defining categories to discover how many
>>> there may be will help score that one better.
>>
>>
>> The category model seems interesting, but I would like to be able to
>> consider a more concrete proposal. Should we work out a list of specific
>> categories?
>
>
>
> Yes! I was waiting for a range of values to see where my list from the old
> thread [1] might work inside a range.
>
> Storage
> Computing
> Networking
> Monitoring
> Operating
> Packaging
> Continuous Integration and Builds
> Doc
> QA
> Integration Testing
> API
> UI/CLI (Dashboard/clients)
>
> That's twelve, and I may not be including all the categories. Some do not
> have projects yet. There may be another category of "services on top of
> Computing" that I'm under-representing, thinking of Databases or Load
> Balancers or DNS that would rely on Compute to provide their service. How
> would we expand to include them?
>
> Anne
>
> 1.
> http://lists.openstack.org/pipermail/openstack-dev/2013-January/004539.html
>>
>>
>> Doug
>>
>>>
>>>
>>> Thanks,
>>> Anne
>>>
>>>>
>>>>
>>>> Hopefully we can all come up with a generally-consensual model able to
>>>> handle future growth of the project.
>>>>
>>>> Regards,
>>>>
>>>> --
>>>> Thierry Carrez (ttx)
>>>> Chair, OpenStack Technical Committee
>>>>
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>>
>>> --
>>> Anne Gentle
>>> annegentle at justwriteclick.com
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Anne Gentle
> annegentle at justwriteclick.com
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Sean Dague
http://dague.net