Open Stack

On Thu, May 30, 2013 at 9:55 AM, Sean Dague <sean at dague.net> wrote:

> 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.
>

I'd agree for the most part, I only wonder if there should be a limit
regarding company affiliation?  In other words it doesn't seem like it
would be overly useful to have the majority of members all representing the
same company.  That's the only concern that I would have.

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