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)
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
