Open Stack

Well hello good friend! esponses inline :)

Apologies to all but I've stopped wrapping my answers because they were 
coming through to the list formatted in the most odd ways. Working on it.

On 25/02/2019 09:28, 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!).
Never! Always good vibes :)
>
> 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?

Very interesting question. To answer directly: I believe the TC should 
focus on both - but it's not that simple.

I believe, first and foremost, that technical debt is a huge issue that 
we sweep under the carpet, much like the original issues themselves that 
have been rolled up into technical debt, and it's a weird 
self-perpetuating cycle. Everyone actively works from cycle-to-cycle to 
better the project and the product, clearing out the backlog and 
focusing on new improvements - but it has been very easy in the past to 
avoid smaller, as you say, "less interesting" issues because it's not 
new and exciting. But this is a lot of what OpenStack is now - we're a 
stable product. While the TC can and should focus on helping guide 
discussions and decisions on the hard OpenStack-wide issues (the TC is 
elected to have the experience to do so), I do believe a lot of the 
focus should be around smaller issues to avoid the little things being 
swept under the carpet and forgotten about.

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

Health is key. I do believe we are all in a weird transition phase; 
evolving from being the newest, hottest, open source product on the 
market to a stable, reliable product that people flock towards to 
actively work on. Project activity is important, but we have set up a 
system of PTLs and liaisons that monitor that activity and work with the 
TC to inform of any major changes. As I said above, the TC should be 
looking at the smaller aspects of a project, and health is often 
considered one of those.

> 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?

Empowerment is an interesting word - and I'm unsure if you used it 
deliberately or not - because the term refers to an increase in 
autonomy. Defining a word is very 1990's wedding speech stereotype 
(sorry sorry), but it's important to note in this case. There has in the 
past, and now, been a lot of discussion surrounding the TC's role and 
how much they empower teams vs. the TC making key decisions on behalf of 
everyone else. Anyway back on track - as Sylvain rightly pointed out, 
this question is entirely pertinent to the size of a team. I find this 
particularly interesting, having been the documentation PTL that was 
empowered by the TC.

This relationship can 100% go two ways and I believe it does now. You 
asked above if the TC must check and actively follow all the official 
project's health and activities. In my experience, it was up to me as 
PTL to reach out to the TC and inform them of the documentation team's 
situation, like many have done before me. By informing them of the 
team's current situation, I was able to engage in a consistent dialog 
with the TC to get proper help to ensure the project did not die in a 
tire fire (like it very nearly did - thank you everyone!).

> 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'll be honest - no. I think this links back up to your point earlier; 
backlogs can lead to technical debt. Placing time restrictions seem just 
that, restrictive, but it helps encourage teams to ensure they have met 
minimum OpenStack-wide requirements per-cycle. Perhaps these time 
restrictions are increased, but I do not believe they should be erased 
and placed into a backlog-style bucket of "To do's".

However, it has been evident in the past (and my experience) that 
project teams cannot complete all the community goals per-cycle because 
of resource constraints, or an unexplained bug that takes up the whole 
cycle. Perhaps this means that evaluation of resources per team, per the 
amount of work a community goal would take for a larger/smaller team 
should occur each cycle.

> 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?

Again, I'll be honest: No. Do I think that potentially generalising our 
tags could be more helpful to new comers? Absolutely. But I see nothing 
wrong with adding [storage] to our preexisting tags rather than 
replacing. We have generic channels such as #openstack-dev and 
#openstack-doc for newbies to get involved. And we now have the First 
Contact SIG which I have noticed do an amazing job at picking up new 
comers out of the lists and point them in the right direction.

> 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?

I was thinking about this the other day. It's an election, like all 
elections, and I think if we're all a bit honest with ourselves the 
results have more to do with the respect garnered in the community 
(maybe by something you implemented) and how well you're known than it 
is about your technical prowess. I don't believe changing the election 
or group format will change the outcome.

I am standing for election because I believe there need to be new voices 
in the room that stand outside the "development" mindset and provide a 
different perspective to OpenStack-wide issues. Not every challenge that 
OpenStack faces is about RabbitMQ and how much we like it, there are a 
lot of social, cultural, and communication issues that impact on 
technical decisions that need to be dealt with and I hope to be that 
person bringing that voice.

>
> Thanks for your patience, and thanks for your application!
>
> Regards,
> Jean-Philippe Evrard (evrardjp)
Happy Monday!