Open Stack

On Sat, Jan 26, 2013 at 5:48 PM, Monty Taylor <mordred at inaugust.com> wrote:

>
>
> On 01/27/2013 04:28 AM, Mark McLoughlin wrote:
> > On Thu, 2013-01-24 at 17:44 +0100, Thierry Carrez wrote:
> >
> >> The PTL is much more influential than a TC member. The PTL has ultimate
> >> (and *unshared*) say on what happens over his project. He takes precise
> >> day-to-day technical decisions, and can do all by himself.
> >>
> >> Comparing that to just one vote on a committee of 13 members that
> >> address cross-project issues and express their opinion on a handful of
> >> issues every 6 months... I'm pretty sure it's clear what position ends
> >> up being more influential.
> >
> > This is a pretty crucial point, I think.
> >
> > I find it really, really sad that people could think that any project's
> > interests would be ignored if their PTL doesn't have a vote on the TC.
>
> I agree - I think this is the important point.
>
> In fact, in areas where a decision by the TC had a clear dissent that
> directly affected one of the projects, that dissent has been accounted
> for (see the swift-exception to the release model)
>
> It turns out we all want the entire project, and each of its
> sub-projects individually to be really good.
>
> > We place far too much emphasis on voting in the Technical Committee. The
> > TC should instead be about building cross-project consensus. Close-run
> > votes on any matter is not a healthy basis to proceed with anything. The
> > fact that TC members have the option of voting against something without
> > blocking it means that members can avoid the responsibility of engaging
> > with the rest of the TC to find a consensus position that works for
> > them.
>
> Totally agree. I never want to use a vote on the TC as a way to force
> people to bend to my will. At times it's the easiest forum to get
> attention for a thing that needs some consensus - and a vote on a thing
> can get someone to speak up in opposition that might otherwise have not
> been heard. Other than that - I much prefer less-active cycles for the
> TC than more.
>
> > Switching to an all-elected committee would give us the opportunity to
> > show that the consensus building model can work. Because an all-elected
> > TC that doesn't work to build consensus which involves all PTLs just
> > will not work.
>
> Agree again.
>
> > Keeping the status quo and adding more PTLs will mean more PTLs fearful
> > of their project being ignored by an all-elected TC - i.e. I'm skeptical
> > we'll ever be brave enough to give all-elected a shot if we decide not
> > to now.
>
> I'm in favor of all-elected TC. If the motion is presented, I will vote
> for it. I also won't die without one.
>
> My main concern, however it's addressed, is that project inclusion and
> make up can be an issue of technical design, not one that's tied to
> concerns about making a governance body have too many people.
>
> I'm not sure that the direct-election and the categories approaches are
> even necessarily at odds. What if we direct-elect TC members, institute
> categories and then have a PTL per-category instead of per-project?
>
> I bring that up because we already have categories. One is called Nova
> and it includes the project nova and the project python-novaclient.
> Moving forward - there were discussions at the last summit about whether
> or not LBaaS and DNSaaS should be separate projects or part of quantum.
> What if they were both "part of quantum" - but lived as separate code
> bases in separate repos? Why would splitting code into two different git
> repos _necessarily_ have anything to do with leadership of the code base?
>
>
Yes, this question is where I also see a disconnect between
per-project-technical-committee-members and purpose-based technical
committee members.


> For that matter, does anyone other than me think it's weird that nobody
> thinks that the TC needs to weigh in on Quantum adding DNS and
> Load-balancing as features, yet we _do_ think the TC needs to get
> involved if someone thinks those features should be added but want to do
> it in a separate git repository?
>
>

Yes, the definition of projects based on code bases which are really
features has always struck me as strange -- mostly from the perspective of
"who's the technical leader who also understands the varied audiences" when
I have docs questions.


> If we move to an all-elected TC right now, we've split the issue of PTLs
> from the issue of project structure. That should give us the space and
> freedom to ACTUALLY think about how project categories and organization
> might be better arranged. Then, whether we keep our current PTL model,
> or we develop some other self-organization strategy that we feel like
> we'd like more directly reflected in the TC structure, it probably
> wouldn't be crazy to get the all-elected TC to change to another model.
>
>
Thanks for summarizing all this Monty, I think you've been able to state
more clearly what I've been trying to uncover in my emails. I also think
that the incubation work will help us think clearly about defining the
makeup of the TC so I'm glad to delay a motion to gather more info and
input.

Anne


> Monty
>
> _______________________________________________
> 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/20130128/3d2bbfed/attachment.html>