openstack-poc team mailing list archive

[Jan Drake <jan_drake@xxxxxxxxxxx>]

Fascinating.  The tension between community driven and committee driven technical direction, it seems.

Justin, I would have been way more comfortable had your example been more vision and architecture focused instead of consequence-control focused.

I could see the role of the TC as bringing a perspective on highest value road-mapping across the projects and assisting in aligning decisioning to that. I can see it as a group that makes smart decisions on the boundary between core and satellite projects.  I can see it as a driver for encouraging integrations with other open source ecosystems.

But, in trademarked Jan form, if you think you can add a control function, you're likely off your chum.  (pardon my use of that obscure colloquialism).

After all, "Supreme executive power derives from a mandate from the masses!  Not from some farcical aquatic ceremony!"

Less playfully, however, there is no question that a collaboration the size of OpenStack could benefit from vision and architecture perspective outside of the individual projects involved.  That said, the intersection of such strategic and visionary thinking requires integration with (instead of management or separate direction of) the leadership of the projects.

Creating this integration oriented approach rather than an implicitly confrontational approach is, I believe, Mr Heck's fine intent.  

Joe you may publicly lambast me and my perspective if I am off target here.  

Providing additional color, IMNSHOYBNI, an integrated approach will go a long way in keeping the community from telling the TC to "fork off"... which is better for the entire effort and certainly for us customers.

Discuss.



Jan



On Jun 22, 2012, at 12:45 PM, Justin Santa Barbara <justin@xxxxxxxxxxxx> wrote:

> 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
> 
> _______________________________________________
> Foundation mailing list
> Foundation@xxxxxxxxxxxxxxxxxxx
> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation