← Back to team overview

openstack-poc team mailing list archive

Re: [OpenStack Foundation] Technical Committee: reserved seats for PTLs (or not)

 

It sounds like the heart of our differing views here is that there's a lack
of clarity on what the technical committee is.  That may because I'm not
intimately involved in drafting the legal docs etc, but I think it's
probably also due to a general lack of definition of those roles will be.
 In my mind I don't imagine the TC to be PTLs + user representatives; I see
them as having responsibility for the (technical) "bigger picture".  I
would definitely support a group that is focused on users, but I don't
think that's the TC.

I would venture that the hardest responsibility the TC will have is to say
"no" to the PTLs.  For example (and not to pick on you, just that gmail is
helpfully suggesting it): does v3 of the OpenStack Identity API advance
OpenStack enough to justify the resource requirements on downstream
projects?  Can we make changes to minimize the impact on everyone else,
while still letting Keystone advance?  Do the changes go far enough, or do
we want to minimize long-term pain by adding more to the API now, rather
than requiring a v4 in 12 months time?  Should we defer a significant
change until the next release, even if it is better for that one project to
include it now?

So I _want_ a division between the TC & the PTLs, that reflects their
different responsibilities.  There will be arguments, but hopefully they
will be constructive arguments like this one.  In other words, we should
expect healthy disagreement; it is a failure in my mind if we build a
second group comprised merely of "yes-men" for the existing groups.

Justin

---

Justin Santa Barbara
Founder, FathomDB





On Fri, Jun 22, 2012 at 12:12 PM, Joe Heck <Joe.Heck@xxxxxxxxxx> wrote:

>
> On Jun 22, 2012, at 11:53 AM, Justin Santa Barbara wrote:
> > In my mind, the PTL is responsible for moving their individual OpenStack
> sub-project forward.  The technical committee is responsible for OpenStack
> as a whole, and making sure that the individual projects are advancing
> OpenStack in the right direction.
> >
> > In other words, I see the PTLs' responsibilities as more day-to-day
> operations (code reviews, blueprints etc), whereas the Committee should be
> concerned with the technical vision and strategy (e.g. what overall
> features should be part of the N+2 release and do we need e.g. to add new
> projects to get there?)
> >
> > To use a startup analogy, I see the PTLs as "Director of Engineering"
> and the technical committee as "CTO".  Just as different people fill those
> roles in a company, I probably wouldn't vote the same way.  Obviously some
> people would be good in both roles, but we shouldn't mandate that the two
> be linked.  In particular, we shouldn't exclude someone from being a PTL
> because they wouldn't be a good "CTO".
>
> That sounds great, but the reality is that all of these projects today are
> evolving actively with each other, and very little is done in isolation.
> The assumption that anything other than basic project management could be
> done effectively in isolation is a misnomer.
>
> The PTLs today as a group are doing the duties you are ascribing to the
> technical committee. Where we are lacking in that operation is more getting
> more of a voice of people using the product in that same group. This is
> exactly why I think we should expand on the PTL set of people with
> additional elected positions from the community to fill out that need.
>
> Creating a separate group will simple introduce confusion and frustration
> when these groups diverge. Having a separate group asserting what others
> *should* do is fine in a company, but a recipe for disaster in an open
> source organization. As you're very aware, If you want something done, come
> with the code.
>
> Making a means of having separate groups in this respect is pre-seeding
> that division as soon as one of the PTLs *is not* elected to the technical
> committee. Why on earth would we want to set ourselves up for failure in
> that way?
>
> -joe
>

Follow ups

References