Open Stack

On 25/02/19 4:28 AM, Jean-Philippe Evrard wrote:
> Hello,
> 
> Here are my questions for the candidates. Keep in mind some might overlap with existing questions, so I would expect a little different answer there than what was said. Most questions are intentionally controversial and non-strategic, so please play this spiritual game openly as much as you can (no hard feelings!).
> 
> The objective for me with those questions is not to corner you/force you implement x if you were elected (that would be using my TC hat for asking you questions, which I believe would be wrong), but instead have a glimpse on your mindset (which is important for me as an individual member in OpenStack). It's more like the "magic wand" questions. After this long introduction, here is my volley of questions.
> 
> A) In a world where "general" OpenStack issues/features are solved through community goals, do you think the TC should focus on "less interesting" technical issues across projects, like tech debt reduction? Or at the opposite, do you think the TC should tackle the hardest OpenStack wide problems?

The purpose of community goals to me is to co-ordinate stuff that 
*everyone* has to do before *anyone* can get the benefit. That's a 
necessary thing to have, but probably most of the hardest OpenStack-wide 
problems don't necessarily fall into that category (at least at first). 
Neither does tech debt reduction for the most part, because reducing 
tech debt is often its own reward.

I do think that the TC has a role to play in co-ordinating the community 
to tackle the hardest problems, but project-wide goals are not going to 
be the only mechanism.

> B) Do you think the TC must check and actively follow all the official projects' health and activities? Why?

We've been experimenting with this for nearly a year, and to be honest I 
am personally yet to see any value from it. I'm not even sure we know 
what a success would look like from it. It's time-consuming (and, at 
least for me, highly unenjoyable) to do well and pointless to do 
perfunctorily. So I wouldn't be sad if we called time on the experiment.

> C) Do you think the TC's role is to "empower" project and PTLs? If yes, how do you think the TC can help those? If no, do you think it would be the other way around, with PTLs empowering the TC to achieve more? How and why?

I don't want to suggest that projects shouldn't be "empowered" - they 
should. But if the TC didn't exist, projects would already be completely 
empowered. The purpose of the TC is that projects relinquish some power 
to it in exchange for the support of the Foundation.

> D) Do you think the community goals should be converted to a "backlog"of time constrained OpenStack "projects", instead of being constrained per cycle? (with the ability to align some goals with releasing when necessary)

I don't. It's hard enough to co-ordinate 60ish projects as it is, I 
think a long-running tasks without a release cadence to discipline them 
is a recipe for unhappy surprises at the end. If goal champions can't 
break them down into chunks manageable in a release cycle then they're 
probably not going to happen.

What I *do* think we need is to be able to have a roadmap for chunks of 
larger goals, to say we're going to do this chunk in T, this one in U, 
this one in V and it's going to deliver X benefit at the end even if the 
first part doesn't seem that useful.

> E) Do you think we should abandon projects' ML tags/IRC channels, to replace them by focus areas? For example, having [storage] to group people from [cinder] or [manila]. Do you think that would help new contributors, or communication in the community?

No, I don't. I know it's just an example but there's no actual 
similarity between Cinder and Manila. They don't share common code, 
common people, common use cases... the only similarity is that they both 
can be considered types of 'storage'. That's pure sophistry. Labels mean 
nothing.

> F) There can be multiple years between a "user desired feature across OpenStack projects", and its actual implementation through the community goals. How do you think we can improve?

There's probably a different answer for every feature.

I really like where Rico's suggestions about making SIGs more visible in 
the community have been leading: get each SIG to pick their #1 priority 
and give them a chance to publicise it to a captive audience (e.g. give 
them each a 3 minute speaking slot during lunch at the PTG).

> G) What do you think of the elections process for the TC? Do you think it is good enough to gather a team to work on hard problems? Or do you think electing person per person have an opposite effect, highlighting individuals versus a common program/shared objectives? Corollary: Do you think we should now elect TC members by groups (of 2 or 3 persons for example), so that we would highlight their program vs highlight individual ideas/qualities?

So, political parties? General those arise when you have electoral 
systems that are constrained by the need to be able to count votes by 
hand. I'm actually very happy with Condorcet as a system.

cheers,
Zane.