Open Stack

> For example, the extended maintenance resolution [2] was purely 
> birthed from frustration about talking about LTS and stable branch EOL 
> every time we get together. It's also the responsibility of the 
> operator and user communities to weigh in on proposed release goals, 
> but the TC should be actively trying to get feedback from those 
> communities about proposed goals, because I bet operators and users 
> don't care about mox removal [3].

As the TC is currently vouching for the goals of a cycle, I strongly 
agree that there is need for the TC to be in-line with the what our 
users are asking, and those converting business requirements to 
technical decisions. I strongly agree the TC should be in contact with 
the UC and SIGs, as both are representing user focuses (the former one 
is more global, while the latter is more contextual).

> I want to see the TC be more of a cross-project project management 
> group, like a group of Ildikos and what she did between nova and 
> cinder to get volume multi-attach done, which took persistent 
> supervision to herd the cats and get it delivered. Lance is already 
> trying to do this with unified limits. Doug is doing this with the 
> python3 goal. I want my elected TC members to be pushing tangible 
> technical deliverables forward.

Multiple points in that.
1) I agree with the "I want my elected TC members to be pushing tangible 
technical deliverables forward.".
2) I acknowledge the fact that not all the TC members are in a position 
like Ildikos or Doug. I am glad I am in an employer that believe in 
contributing upstream and lets me enough room to do so, being given a 
good incentive to do so.
3) "Necessity" + "sufficiency" vs expectations. I'd like TC members to 
give their times to push technical changes forward. But I would also 
hope non TC members would doing so.
So, I am fine with Dan's opinion: _expected_ to work on improving 
technically OpenStack, and therefore helping PTLs (and other people) to 
focus on their work/"other side of the pond".
4) If you are to think TC as companies' project managers, I would think 
this view is incomplete. At best it would be program managers and/or 
product owners that can/should take a project manager role.

The problem with that notion is that project managers have 3 axis to 
play with (time, scope, and cost), where TC members only have one with 
community goals (scope, as time is constrained to a cycle, and cost is 
unclear/outside PM hands). If you've been to that position for a long 
time, you know this cannot be healthy and very demoralizing.

For me, there is a small link that can _wrongly_ be done: as the TC is 
an official "organism" of OpenStack, it could as some point be expected 
to deliver these projects intact in a timely fashion without having the 
resources to do so.

So, for me, the best way to think the goals should be a 'best effort' 
work, and everyone championing is expected to do their best. I think we 
are good at that for now, and doesn't need change.

If you change the mindset into being expected to deliver (as this could 
become a very strong force for openstack), I'd say there are two risks:
- More time involved in PM duties to gather resources upfront
- Less deliverables proposed, as some could be higher risk and therefore 
not tried.
- Possible finger pointing to "this champion didn't manage to achieve 
its goals" or diluted goals when no resource available.

I am therefore not sure we'll able to go to that mindset in the current 
way OpenStack and companies are organized.

> I don't find any value in the TC debating ad nauseam about visions and 
> constellations and "what is openstack?".

Agree. I have an opinion of what OpenStack is, but I don't believe 
discussing it over the mailing list in this message would be helpful in 
any way. We can have this chat over drinks to see if we are aligned, but 
I am not sure it matters :p

> So I encourage all elected TC members to work directly with the 
> various SIGs to figure out their top issue and then work on managing 
> those deliverables across the community because the TC is particularly 
> well suited to do so given the elected position.
Agreed.
> I realize political and bureaucratic "how should openstack deal with 
> x?" things will come up, but those should not be the priority of the TC.
Your question is unclear to me. If users want x, this is a good feedback 
for TC, and therefore should be passed to projects. If x is 'how things 
are done technically in a project', I do not believe TC have to deal 
with that: maybe some tc members would deal with it, but not as tc 
members, more said projects contributors. if x is a governance of 
OpenStack topic, I would hope tc would get involved the earliest possible.
> So instead of philosophizing about things like, "should all compute 
> agents be in a single service with a REST API" for hours and hours, 
> every few months - immediately ask, "would doing that get us any 
> closer to achieving top technical priority x?" Because if not, or it's 
> so fuzzy in scope that no one sees the way forward, document a 
> decision and then drop it.
That rises a point of having global design document and decisions, so 
that we learn better. There is still a lot of tribal knowledge in 
OpenStack, and we should remove that over time by setting up the right 
processes. I'd be happy to discuss that with you to have a real/more 
complete understanding of what you mean there.

Jean-Philippe Evrard (evrardjp)