Open Stack

On Tue, Jan 15, 2013 at 9:52 AM, Thierry Carrez <thierry at openstack.org>wrote:

> Hi everyone,
>
> The OpenStack Technical Committee, representation of the technical
> contributors to the project, is currently composed of 13 members, the 8
> "core" projects PTLs and 5 directly-elected members.
>
> We are considering adding more projects in the integrated release in the
> future, but adding more PTLs with guaranteed TC seats doesn't really
> scale, quickly leading to committee bloat (personally I think 13 is the
> maximum workable number). There is even resistance to accepting new
> projects due to the fear of inefficiency in the TC, and fear of dilution
> of key TC members influence. That shouldn't be what drives our decisions
> on graduating from incubation.
>
> We should solve that before we consider the addition of new projects,
> and before we run the next TC elections. There are a number of ways to
> address that, and some of them were expressed at a recent TC meeting:
>
> 1/ Keep the same setup, but refrain from adding new projects
>
> 2/ Keep the same setup, but only have some PTLs have guaranteed seats
> (special-case some ("inner core") projects)
>
> 3/ Limit the TC to 13 members, and have them all directly-elected (the
> most significant PTLs will get elected anyway)
>
> 4/ Limit the TC to 13 members, have them all directly-elected, *and*
> guarantee that a minimum of 8 PTLs end up in the committee
>
> Thoughts ? Other potential solutions ?
>


Is the number 8 significant now due to the number of projects we have? Why
not an odd number, 7 or 9, to encourage consensus-building towards a
majority?

More thinking on another potential solution. PTLs are project technical
leads. We could add a lot of projects in the next two years and want to be
sure they're represented. So, turning "project" around a bit, is there
another role, such as a representative Technical Lead for multiple projects
to go under some day? I'm thinking this way due to previous requests around
establishing a "common libraries" coordinator, an API coordinator, etc.
Here are some categories:

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?

I worry about under-representation of a category, happening just because
there isn't a "project" that's well-known enough to have an elected
representative. Then again, I can be swayed by "if they don't care enough
to create a technical project the OpenStack way, why should we represent
them on a TC?"

Would this type of committee be useful in representing the broad technical
contributor community?

For elections, projects would be placed under a category and only those who
contribute could vote for their representative.

Thoughts?
Anne



>
> Personally, I think (1) is not a solution: we shouldn't limit what is
> part of the integrated release based on fear of committee bloat or
> influence dilution. (2) doesn't sound very fair (who gets to define
> which project should be special-cased) and doesn't prevent bloat (it
> only slows it down).
>
> I like (3) but I agree that there is a risk in Condorcet that people
> having horizontal functions will get overrepresented, and we'd end up
> with less PTLs (vertical functions) than we'd like. So I think (4) is a
> good middle ground: prevents bloat, accommodates further growth in a
> relatively-fair way while ensuring we get PTLs in the final committee.
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130115/10935c9d/attachment.html>