[tc][election] New series of campaign questions
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?
B) Do you think the TC must check and actively follow all the official projects' health and activities? Why?
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?
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)
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?
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?
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?
Thanks for your patience, and thanks for your application!
Regards, Jean-Philippe Evrard (evrardjp)
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)
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!
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.
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!).
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?
Both - the TC should be helping to highlight where work needs to be done, and that can include debt cleanup, and cross project features.
(that said, tech debt is probably one of the hardest OpenStack wide problems).
I think I have seen this said somewhere in the mountain of election emails sent this year, but the TC needs to be a group that enables the community to do things, be that debt cleanup like py3 support, user documentation like api-ref, or cross project features like volume multi attach.
B) Do you think the TC must check and actively follow all the official projects' health and activities? Why?
Yes, I think it is important to follow - we don't want the first time we know a project is in trouble is the "we have a single volunteer as a developer" email / blog post.
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?
Yes - but it is also to empower users and other people in the community.
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)
No. I think having these goals limited to a cycle means that there is a lot more of a chance that projects will actually get them done. If we allow for them to be 2,3,4 cycles long, I think we will loose the critical mass of projects completing them.
That is not to say we can't have things that are important that run for 2+ cycles, but I do not think they should be goals. They could definitely have a goal as an endpoint to finish off a larger effort, but not as a multi cycle goal.
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?
Abandon, no. Use in addition to the current set, yes. - See the bare metal SIG for how we can do cross project, focused development.
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?
This is a hard issue. Due to the size of the project, and differing priorities of each set of developers, getting a single unified roadmap for user requested features is hard.
Combine this with the criticality of what our software is used for, and you have a perfect storm of long pipelines for new versions (on the order of years, not cycles), and the feedback loop is too long for a "move fast and break things" mentality. By the time the users have the feature (even if we did get it completed in a cycle), the people who worked on the feature, documented it, tested it and guided it, are possibly moved on to something else, or have lost the short term context to deal with the feedback.
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 think what we have is the best of a bad selection. Lists are inherently exclusionary, and tend to make sure that views and groups are entrenched (see mainland EU parties).
While the current process can create name recognition based voting, the name recognition is usually associated with someone who did something cross project, or in a larger project, which can mean that they have a good view of how things are working.
Thanks for your patience, and thanks for your application!
Regards, Jean-Philippe Evrard (evrardjp)
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.
On 2019-02-26 16:28:00 -0500 (-0500), Zane Bitter wrote: [...]
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.
[...]
And not that it's the only possible example, but a good recent one is the Python 3 transition we've been undertaking for several cycles already and have at least a couple more ahead of us before it's done. We didn't say "switch to Python3 is a multi-cycle goal" and instead broke it up into goal phases each manageable with a cycle and with their own distinct completion criteria. This also provides increased opportunity for retrospection at the end of each phase and adjustment of the longer-term effort when we see a need.
participants (7)
-
Alexandra Settle
-
Graham Hayes
-
Jean-Philippe Evrard
-
Jeremy Stanley
-
Sylvain Bauza
-
Thierry Carrez
-
Zane Bitter