<div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 25, 2019 at 10:32 AM Jean-Philippe Evrard <<a href="mailto:jean-philippe@evrard.me">jean-philippe@evrard.me</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
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!).<br>
<br></blockquote><div><br></div><div>Hola Jean-Philippe. No hard feelings, I actually think it's very important to ask us some difficult questions for knowing our opinions.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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.<br>
<br></blockquote><div><br></div><div>NP. As I said in some other thread, I think I don't have a magic wand, but I'll try ;)</div><div></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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?<br>
<br></blockquote><div><br></div><div>Heh, can I say "both" ? ;-)</div><div>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).</div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
B) Do you think the TC must check and actively follow all the official projects' health and activities? Why?<br>
<br></blockquote><div><br></div><div>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.</div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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?<br>
<br></blockquote><div><br></div><div> Oh, excellent question. Thanks for having said it. <br></div><div>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.</div><div>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.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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)<br>
<br></blockquote><div><br></div><div>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.</div><div>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.</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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?<br>
<br></blockquote><div><br></div><div>I don't think we should change the IRC channels names, if I understand this strawman :-)</div><div>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. </div><div>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.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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?<br>
<br></blockquote><div><br></div><div>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 ?".</div><div>Well, surely a controversial question, right? <br></div><div>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.</div><div>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. <br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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?<br>
<br></blockquote><div><br></div><div>How do you see the groups to be elected then ? :-)</div><div>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 ;-)</div><div>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.</div><div><br></div><div>Thanks for all your questions that were important :-)<br></div><div>-Sylvain</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Thanks for your patience, and thanks for your application!<br>
<br>
Regards,<br>
Jean-Philippe Evrard (evrardjp)<br>
<br></blockquote><div><br></div><div>[1] <a href="https://review.openstack.org/#/c/636956/">https://review.openstack.org/#/c/636956/</a> <br></div></div></div></div>