Open Stack

On Mon, Feb 25, 2019 at 10:32 AM Jean-Philippe Evrard <
jean-philippe at 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190225/b3e2d505/attachment-0001.html>