On Mon, Feb 25, 2019 at 10:32 AM Jean-Philippe Evrard < jean-philippe@evrard.me> 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!).

Hola Jean-Philippe. No hard feelings, I actually think it's very important to ask us some difficult questions for knowing our opinions. 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.

NP. As I said in some other thread, I think I don't have a magic wand, but I'll try ;) 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?

Heh, can I say "both" ? ;-) No, to be clear, I think it's probably one of the main priorities for the TC to discuss with the community about goals that should be helping to fix some hard and wide problems (like for example Py3). But it's also important for the TC to leave projects be discussing about technical issues they have and see how the TC can help those projects for this. Tech debt reduction is actually a good example. It's difficult for a project to find resources working on fixing tech debt reduction (and I know about it from my Nova scheduler expertise...). Here, the role of the TC could be to find ways to 'magically' find resources (heh, I finally found a magic wand \o/ ) for those projects. For example, the Padawan proposal [1] could be one way for the projects to bring to light their technical concerns. B) Do you think the TC must check and actively follow all the official

projects' health and activities? Why?

Oh yeah, 100% this. If the TC should be only doing one thing, that should be this. The TC is the guardian of OpenStack health, making sure that all projects go into the same direction by the same page as much as possible. We now have a situation were there are ways different healthes between projects, and one of my main priorities if I was accepted for TC would be to see how all the projects can eventually be having the same technical health.

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?

Oh, excellent question. Thanks for having said it. Well, it depends on the project, right ? Say, large projects don't really need the TC to "empower" their respective contributors, or even the PTL. In general, even if we now have less resources with a glass pane, most of the respective projects have their own sub-community where the PTL doesn't need some 'blessing'. On that case, the PTL can actually help the TC by instructing it about all the issues the project faces, and possibly ask it other projects have the same issues. On the other way, the TC could help this PTL by either helping to say it's a priority for the project, or just thinking it could be a nice goal. For small projects, it's sometimes different. Most of the times, the project doesn't have a lot of contributors and the PTL is just one of them. In that case, the TC could empower this PTL by giving his/her a way to ask some resources, or just having a way to discuss with other projects. For example, Cyborg and Nova are two different projects with not the same contributors, but thanks to the TC, we have ways to discuss between us. 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)

Hum, good question. I don't have an opinion about it if it's about the fact whether a goal can only be for a cycle or not. Maybe we could enlarge the goals to be for more than one cycle, but I'd rather prefer to discuss it by the Denver Forum first and see what people think about this.

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?

I don't think we should change the IRC channels names, if I understand this strawman :-) We already have #openstack-dev where people can ping folks unrelated to a specific project. That said, if project contributors from both cinder and manila think they really want to have a #openstack-storage channel because it helps them, I don't think the TC should disagree. For ML threads, same goes. We have tags for projects because it's important for project contributors to just look at the tag before the title for knowing whether it's related to what they work, but if projects really want a larger tag for *good reasons*, I'm not opposed to. 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?

First, I'm not sold on the idea that a user-desired feature needs to go thru a community goal to be implemented. I guess you probably wanted to ask "how the TC can help having ideas transformed into code quickier ?". Well, surely a controversial question, right? The best way to have a feature is to have a contributor implementing this feature. No magic wand here. As I said elsewhere, you can have the best idea, it won't be automatically turned into the killing feature you want just because you explain us how crucial and important this idea is. What the TC can do tho is to help users and developers to discuss and see if common goals (in terms of achievement) can be shared. I already gave the example of the Public WG. Most of the public cloud operators share the same pain so providing a good way to merge all concerns into one deliverable document and sharing it to the corresponding project teams can help seeing whether some contributors can dedicate a bit of time. It won't magically happen because those contributors are nice, just because they probably have the same problems internally or know about this and want to fix them. 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?

How do you see the groups to be elected then ? :-) It's like politicals right? Either you make an election with individuals (for example for the French president), or you have an election with two or more lists (like European elections). But those lists are actually created by another internal election ;-) See, I'm not against discussing this strawman, but I'm not very happy with it at the moment. At least, we need more than just one conversation here for that I guess. Thanks for all your questions that were important :-) -Sylvain Thanks for your patience, and thanks for your application!

Regards, Jean-Philippe Evrard (evrardjp)

[1] https://review.openstack.org/#/c/636956/

Jean-Philippe Evrard wrote:

[...] 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?

I'd say both. Community goals can be used to achieve a common level for "OpenStack" -- one way is to use them for user-visible change, but the other is to use them to set basic standards. Ideally it should always been ultimately beneficial to the user.

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

I found the "health check" exercise a bit time consuming, but interesting, especially for projects I'm not deeply familiar with. Maybe having two people assigned to every project every 6 months is a bit too much though.

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 believe in servant leadership -- I think the part of the TC's role is to empower everyone else to do their part. By setting standards, resolving conflicts, adapting systems and processes to changing conditions.

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 personally prefer to keep reasonable goals tied to release cycles, rather than have a constant backlog of TC-dictated objectives.

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?

If the focus area is important enough, it should probably be a SIG and use that as the channel / ML subject tag. For example, as bare metal concerns grew larger than just Ironic, a "Bare Metal" SIG was created. If there is a need to discuss common "storage" topics beyond "manila", "cinder" and "swift" topics, I suspect we'd use [storage] naturally.

[...] 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?

The general idea of behind electing individuals was to get a plurality of views. I feel like if we elected groups of people under a similar "party" or "program" that would (1) reduce the diversity of views and (2) encourage party politics instead of consensus decisions. -- Thierry Carrez (ttx)

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.