| *** tetsuro has joined #openstack-tc | 00:13 | |
| *** openstackstatus has joined #openstack-tc | 00:44 | |
| *** ChanServ sets mode: +v openstackstatus | 00:44 | |
| *** diablo_rojo_phon has joined #openstack-tc | 01:22 | |
| *** diablo_rojo has quit IRC | 02:13 | |
| *** jamesmcarthur has joined #openstack-tc | 02:18 | |
| *** jamesmcarthur has quit IRC | 02:56 | |
| *** jamesmcarthur has joined #openstack-tc | 02:58 | |
| *** jamesmcarthur has quit IRC | 03:03 | |
| *** jamesmcarthur has joined #openstack-tc | 03:06 | |
| *** KeithMnemonic1 has joined #openstack-tc | 03:28 | |
| *** KeithMnemonic has quit IRC | 03:31 | |
| *** ricolin_ has joined #openstack-tc | 03:31 | |
| *** ricolin_ has quit IRC | 03:33 | |
| *** ricolin_ has joined #openstack-tc | 03:34 | |
| *** jamesmcarthur has quit IRC | 03:34 | |
| *** jamesmcarthur has joined #openstack-tc | 03:35 | |
| *** jamesmcarthur has quit IRC | 03:40 | |
| *** tetsuro has quit IRC | 03:41 | |
| *** tetsuro has joined #openstack-tc | 03:45 | |
| *** jamesmcarthur has joined #openstack-tc | 03:56 | |
| *** KeithMnemonic1 has quit IRC | 04:06 | |
| *** jamesmcarthur has quit IRC | 04:23 | |
| *** jamesmcarthur has joined #openstack-tc | 04:27 | |
| *** jamesmcarthur has quit IRC | 04:32 | |
| *** jamesmcarthur has joined #openstack-tc | 04:33 | |
| *** tetsuro_ has joined #openstack-tc | 05:23 | |
| *** tetsuro has quit IRC | 05:27 | |
| *** jamesmcarthur has quit IRC | 05:30 | |
| *** evrardjp has quit IRC | 05:35 | |
| *** evrardjp has joined #openstack-tc | 05:36 | |
| *** Luzi has joined #openstack-tc | 06:02 | |
| *** e0ne has joined #openstack-tc | 06:28 | |
| *** smcginnis has quit IRC | 07:03 | |
| *** smcginnis has joined #openstack-tc | 07:04 | |
| *** e0ne has quit IRC | 07:10 | |
| *** rpittau|afk is now known as rpittau | 07:17 | |
| *** e0ne has joined #openstack-tc | 07:19 | |
| *** e0ne has quit IRC | 07:23 | |
| *** tetsuro has joined #openstack-tc | 07:25 | |
| *** tetsuro_ has quit IRC | 07:29 | |
| *** tetsuro_ has joined #openstack-tc | 07:35 | |
| *** tetsuro has quit IRC | 07:37 | |
| *** slaweq has joined #openstack-tc | 08:02 | |
| *** tosky has joined #openstack-tc | 08:18 | |
| *** e0ne has joined #openstack-tc | 08:34 | |
| *** tetsuro_ has quit IRC | 08:44 | |
| *** tetsuro has joined #openstack-tc | 08:47 | |
| *** rpittau is now known as rpittau|bbl | 08:52 | |
| *** tetsuro_ has joined #openstack-tc | 08:53 | |
| *** tetsuro has quit IRC | 08:57 | |
| *** witek_ has joined #openstack-tc | 09:13 | |
| *** tetsuro has joined #openstack-tc | 09:14 | |
| *** tetsuro_ has quit IRC | 09:17 | |
| *** tetsuro_ has joined #openstack-tc | 09:20 | |
| *** tetsuro has quit IRC | 09:23 | |
| *** witek_ is now known as witek | 10:38 | |
| *** tetsuro_ has quit IRC | 10:39 | |
| *** e0ne_ has joined #openstack-tc | 10:50 | |
| *** e0ne has quit IRC | 10:51 | |
| *** tetsuro has joined #openstack-tc | 11:28 | |
| *** Luzi has quit IRC | 12:10 | |
| *** tetsuro has quit IRC | 12:22 | |
| *** rpittau|bbl is now known as rpittau | 13:02 | |
| *** ianychoi has quit IRC | 13:13 | |
| *** witek has quit IRC | 13:47 | |
| *** dklyle has quit IRC | 13:49 | |
| *** dklyle has joined #openstack-tc | 13:49 | |
| *** witek has joined #openstack-tc | 14:04 | |
| openstackgerrit | Michal Arbet proposed openstack/governance master: Add xstatic-* projects https://review.opendev.org/709211 | 14:21 |
|---|---|---|
| openstackgerrit | Thierry Carrez proposed openstack/governance master: No longer elect PTLs https://review.opendev.org/712696 | 14:33 |
| ttx | A strawman ^ | 14:33 |
| *** ricolin_ has quit IRC | 14:41 | |
| *** ricolin_ has joined #openstack-tc | 14:41 | |
| *** ricolin_ has quit IRC | 14:48 | |
| jungleboyj | o/ | 15:00 |
| njohnston | o/ | 15:01 |
| zaneb | o/ | 15:01 |
| mnaser | hola | 15:02 |
| openstackgerrit | Thierry Carrez proposed openstack/governance master: No longer elect PTLs https://review.opendev.org/712696 | 15:03 |
| ricolin | o/ | 15:04 |
| openstackgerrit | Mohammed Naser proposed openstack/governance master: No longer elect PTLs https://review.opendev.org/712696 | 15:10 |
| openstackgerrit | Mohammed Naser proposed openstack/governance master: Split OpenDev out of OpenStack Infra https://review.opendev.org/710020 | 15:11 |
| openstackgerrit | Mohammed Naser proposed openstack/governance master: No longer elect PTLs https://review.opendev.org/712696 | 15:11 |
| mnaser | just rebased bc opendev resolution was the first one of 2020 and so that zuul doesnt complain | 15:11 |
| mnaser | i added a resolution to ttx proposal. i think we should probably discuss that idea | 15:11 |
| ttx | mnaser: looks good. I would just remove the list of roles so that it does not duplicate what's in the charter, and does not make the resolution obsolete if we add a role in the future. | 15:14 |
| mnaser | ttx: wanna leave a comment with that just so folks can see review history of why id remove it | 15:15 |
| njohnston | I guess my first question about ttx's proposal is: is this an opt-in or opt-out approach? i.e. if a team does nothing will they still keep electing PTLs as usual because they haven't opted in to the new system? If a team wants to elect their slate of representatives will the elections team help facilitate that team-specific election? | 15:16 |
| njohnston | s/team/project/g | 15:16 |
| mnaser | njohnston: i think it becomes a team policy. if you wanna have elections every release, you have all the tooling you need to do so | 15:18 |
| njohnston | ok | 15:18 |
| njohnston | Is this proposed to take effect immediately upon ratification? | 15:21 |
| zaneb | btw when do TC members terms expire? | 15:23 |
| zaneb | because I think it's probably too late to do charter changes before the election | 15:24 |
| gmann | are we going with no PTL? i thought majority of team responded with PTL needed on ML. | 15:24 |
| mnaser | njohnston: i haven't thought that part through, maybe we can just decide starting from victoria for example | 15:25 |
| gmann | term expire in March which mean end of March ? | 15:25 |
| mnaser | zaneb: that's a good question... i dunno if this is something worth making an exception for and drive, or otherwise we may find ourselves with a bunch of ptl-less projects | 15:25 |
| mnaser | gmann: suggesting it and opening the discussion i guess | 15:26 |
| ttx | zaneb: I'd say the terms expire when we are replaced | 15:26 |
| ttx | In the past we have voted on stuff while the election was running | 15:27 |
| openstackgerrit | Michal Arbet proposed openstack/governance master: Add xstatic-* projects for vitrage-dashboard https://review.opendev.org/709211 | 15:27 |
| zaneb | ttx: bylaws say max 12 months unless we say longer in advance, which we neglected to do. that's why we changed the charter starting with the next election | 15:27 |
| ttx | but yeah, the reason I'm proposing now is that if that is where we want to go, it's silly to wait 6 months on a technicality | 15:28 |
| njohnston | ttx: commented on the change | 15:31 |
| fungi | probably the only real risk in approving changes to the charter treating expired seats as part of the quorum is that the decision could be considered nonbinding and would need to be reaffirmed by the new tc following election? | 15:32 |
| * fungi is not a lawyer | 15:32 | |
| ttx | well, the next TC can always revert the change | 15:33 |
| fungi | right | 15:33 |
| fungi | and could retroactively demand ptl elections for any teams which didn't hold them | 15:33 |
| ttx | but if that's as conflictual I bet we'd see that now | 15:33 |
| fungi | i expect the odds of that happening are low | 15:34 |
| ttx | Like if there is a "Keep the PTL" party there is no point in pursuing the urgent change | 15:34 |
| fungi | my point was it may be a good idea, if the charter is changed this close to the election, to have the new tc formally reaffirm that change once they take office | 15:34 |
| ttx | sure | 15:35 |
| fungi | just so there's no question that it's a legitimate change | 15:35 |
| fungi | rather than assuming that if they don't revert it they must have agreed | 15:35 |
| ttx | njohnston: I feel like a ptl-less flag would single out teams that opt to not have PTLs anymore. Which would put pressure on keeping them around, which would perpetuate the problem we are trying to solve. I'd like no-PTL to be the new normal, and in order to achieve that we need to not talk about it in governance documents | 15:36 |
| ttx | Saying teams can self-organize should be enough imho | 15:37 |
| njohnston | ttx: Understood, but I think that it could help the elections infrastructure since I think organizational inertia is such that unless we really push it, many teams will want to keep the current model because it isn't broken for them. | 15:38 |
| ttx | njohnston: I'd say that teams who want to keep elections would self-organize them rather than relying on a unique team of officials | 15:39 |
| evrardjp | I fail to see the urgency | 15:40 |
| jungleboyj | ttx: By self organize you mean that they would do their own elections? | 15:40 |
| evrardjp | we can take measures based on facts. Shouldn't we? | 15:41 |
| ttx | jungleboyj: no I'm saying they can do whatever they want to organize themselves | 15:41 |
| mnaser | the urgency is nova won't have a ptl | 15:41 |
| mnaser | congress won't have a ptl | 15:41 |
| mnaser | and some teams have reached out in private saying | 15:41 |
| mnaser | "we're sick of being ptls over and over again" | 15:41 |
| jungleboyj | So, for the teams that want to still have a PTL will continue to go through the official OpenStack PTL election process. | 15:42 |
| ttx | evrardjp: the "urgency" is that we have a round of elections coming up really soon now. So if we all agree that those are destructive, it's better not to hold them | 15:42 |
| evrardjp | my point is that those are already scheduled. | 15:42 |
| ttx | evrardjp: but not started? | 15:43 |
| ttx | jungleboyj: teams that still want to have a PTL would run a process similar to the old official PTL election process | 15:43 |
| ttx | or something else. Whatever works for them | 15:43 |
| evrardjp | so basically we need to do this real quick, so we have everyone voting before end of month. | 15:44 |
| jungleboyj | ttx: Ok, so they would have to run their own election. | 15:44 |
| evrardjp | for hypothetics with a large probability | 15:44 |
| jungleboyj | I am worried about going with a 'Do Whatever You Want' approach everyone will do nothing. | 15:44 |
| ttx | jungleboyj: yes, i think. I bet usual election victims^Wofficials could help them :) | 15:45 |
| evrardjp | that is reasonable, but I don't want rush things either. | 15:45 |
| ttx | jungleboyj: would that be a problem? | 15:45 |
| ricolin | So who release team will looking for the +1 when asking to review on a project release patch? | 15:45 |
| njohnston | I worry that people will feel like this is being railroaded through based on the short time schedule and how core the PTL concept is to how people perceive their OpenStack projects work. | 15:45 |
| ttx | The idea of the "roles" is to define what is really needed (example:release signoff) and get rid of all the baggage (magic contact person that will solve all our problems) | 15:46 |
| evrardjp | we need to sync with all the teams that make use of this information in their tooling before having a stance, shouldn't we? Like releases, maybe infra, etc. We don't want to be disruptive in the release process, do we? | 15:46 |
| ttx | njohnston: that's fair. I'd have preferred to have that discussion a month ago | 15:46 |
| jungleboyj | njohnston: ++ I don't like the idea of rushing this. | 15:46 |
| ttx | evrardjp: i don;t see how that can be disruptive to release process, since the change madates that we have a clear release liaison(s) | 15:47 |
| ttx | (which would be seeded by current release liaisons) | 15:47 |
| evrardjp | isn't the tooling loading info from governance to load ptls too? | 15:48 |
| evrardjp | I am merely looking for the side effects first before taking a decision/voting myself | 15:48 |
| ttx | I think it's a lot less disruptive than removing PTLs a month after they were elected for 6 months. | 15:48 |
| jungleboyj | Do we know that we aren't going to have a PTL for Nova? | 15:48 |
| njohnston | I also know of one person who in private has said they are willing to serve as nova ptl next cycle, so I hope that helps reduce urgency. | 15:49 |
| evrardjp | ttx: oh that's what you intended? I thought it would be acted on the next (not yet planned) elections. | 15:49 |
| evrardjp | with a decision to not appoint someone in the meantime for projects that don't want it | 15:49 |
| ttx | evrardjp: indeed there is a thing to change in the releae automation (only look at release liaison file, rather than query governance for PTLs too) | 15:49 |
| evrardjp | ttx: yes that's what I remember. But I don't have a full picture, which is why I am querying for others first :p | 15:50 |
| evrardjp | to others* | 15:50 |
| evrardjp | if that's the only place, that shouldn't be too bad to deal with | 15:50 |
| jungleboyj | I think if we have Nova covered and we can appoint someone from the TC to help others and take some time to work through this carefully, I think that would be a better approach. | 15:51 |
| ttx | I think *IF* we think PTLs should be replaced by more defined subroles to avoid the "default for everything" effect, it's stilly to run an election in two weeks that will choose some for the V cycle | 15:51 |
| njohnston | jungleboyj++ | 15:51 |
| ttx | Also i don;t want to be in a position to appoint a dozen PTLs *IF" we think it's silly to have them | 15:51 |
| njohnston | ttx: It's not silly, it's prudent, because a fundamental change should be deliberated carefully and have broad-based support. | 15:52 |
| ttx | So focusing on the idea, rather than the tense timing… Is having PTLs silly ? | 15:52 |
| jungleboyj | ttx: I still say that I don't think so. | 15:52 |
| ttx | Can we keep what we need (accountability on specific functions) while getting rid of the "default for everything" effect? | 15:53 |
| evrardjp | well we agreed that nova is a difficult case, but for the rest, we were also talking about putting those projects under maintenance mode | 15:53 |
| evrardjp | by removing the ptls, you remove a possible signal. | 15:53 |
| ttx | jungleboyj: ok | 15:53 |
| evrardjp | again, I am not against this, I just want to take an informed decision. | 15:54 |
| jungleboyj | evrardjp: ++ | 15:54 |
| njohnston | evrardjp: ++ | 15:54 |
| jungleboyj | I will admit that my experience is strong influenced by my Cinder experience. Other teams may feel different. | 15:54 |
| ttx | Personally I think we can get to the same point by encouraging delegation in teams. But I also recognize that it's what we've been doing for a while and it's still seen as a problem by most | 15:54 |
| ttx | Hence the idea of symbolically removing the "PTL" title, to remove all the baggage | 15:55 |
| ttx | while keepign all the needed accountability | 15:55 |
| ttx | evrardjp: my main objection to the change I myself proposed is that we fail to have some clear reaffirmation every 6 months | 15:57 |
| ttx | If names can stay forever in there, some may bitrot | 15:57 |
| evrardjp | for me deprecating projects that are on life support is more important than changing this. I haven't seen how we can convert the "absence of ptl" signal yet. | 15:57 |
| jungleboyj | Whatever change we make, I think we need to continue to keep some communication and oversight with the teams. | 15:57 |
| ttx | (mostly concerned by the release liaison) | 15:57 |
| evrardjp | ttx: that clear evaluation can be done by periodically removing things | 15:58 |
| evrardjp | that's not a big of a problem I think. | 15:58 |
| *** diablo_rojo has joined #openstack-tc | 15:58 | |
| evrardjp | in that case, the absence of response could be a signal | 15:58 |
| njohnston | I think we'd have to convert the signal to "no release proposed by release liaison in X time and nobody responds to a ML message asing about a release" | 15:59 |
| evrardjp | all of those should be in the change. | 15:59 |
| ttx | njohnston: yes we already have that. Failure to +1 from liaison in due time | 15:59 |
| evrardjp | njohnston: I would prefer abstain to give my position on that, given we asked for more automation around releases. | 15:59 |
| evrardjp | we've been asked for more automation* | 16:00 |
| gmann | jungleboyj: nova is in safe list now. | 16:00 |
| ttx | evrardjp: i think deprecating projects on life support is a separate problem. Here we would only be solvnig the "PTL role is just too much, so it's hard to find candidates even for (or in particular for) busy projects | 16:00 |
| zaneb | ttx: maybe we should have a 'last-updated' field and automatically time them out after 6 months | 16:00 |
| evrardjp | I don't disagree on the initial goal | 16:00 |
| evrardjp | again, I am trying to understand the side effects. | 16:01 |
| ttx | evrardjp: yes me too, which is why I pushed the strawman really | 16:01 |
| evrardjp | maybe it's because it's the end of day | 16:01 |
| gmann | i think i was reading the proposal wrongly by title. so we are giving option to team to adopt proposed model or continue PTL model ? | 16:01 |
| evrardjp | I will read this and evaluate, ask for more feedback if necessary. I encourage everyone to do the same, as early as possible. | 16:01 |
| ttx | zaneb: we kinda need to always have a name there though. But yes, there are mechanisms | 16:02 |
| ttx | gmann: no, we are just letting teams do whatever they want | 16:02 |
| fungi | we'll need clearer liaison tracking | 16:02 |
| zaneb | ttx: right, that would be when we start poking people. and looking seriously at the removal criteria if nobody responds | 16:02 |
| ttx | gmann: as long as they provide a minuimum number of roles to be filled that are actually critical | 16:02 |
| ttx | zaneb: ++ | 16:03 |
| * gmann need more coffee. hangout of having internal meeting till 3 AM :( | 16:03 | |
| clarkb | gmann: or a nap :) | 16:03 |
| ttx | The issue here is that the elephant in the room (the PTL) makes a very easy target for all external grievances. And that is what is tiring | 16:03 |
| njohnston | ttx: I think it's fairer to say "we are forcing teams to do whatever they want" because this would remove the mechanism for a central elections team to hold a single multi-project PTL election. So a team that wants to stay the same now has an additional oblication to determine it's voting base and conduct the election, now without the impartial third party. | 16:03 |
| fungi | just to understand the idea a little better, we say it's okay that teams have no volunteer for a ptl... how do we then handle them also not having any volunteers for liaison roles? | 16:03 |
| gmann | ttx: and that can be PTL, PTL for those roles if they continue with PTL model | 16:03 |
| gmann | clarkb: yeah. i should | 16:04 |
| mnaser | missed all the fun bc lunch, bummer | 16:05 |
| ricolin | fungi, +1 I got same question in my mind for mins. | 16:05 |
| fungi | yeah, i need to eat lunch too | 16:05 |
| mnaser | if there's no volunteers for liaison roles then they can either be empty/optional (aka event) | 16:05 |
| jungleboyj | ricolin: fungi That is when the project gets deprecated? | 16:05 |
| ttx | njohnston: we could still have a central election service team. But I'd call bullshit since we do not run that many real PTL elections those days | 16:05 |
| mnaser | so you'll never have a ptg room. | 16:05 |
| mnaser | yeah, that's the thing that's bothering me too, the election team sits and goes through tons of process | 16:05 |
| mnaser | and its just all pretty much noop with no elections | 16:05 |
| *** diablo_rojo has quit IRC | 16:06 | |
| fungi | and never have a release, and your vulnerability reports sit untended to, and you can't add new repos because the project-config reviewers don't know who has authority to speak for the team | 16:06 |
| ttx | So in the spirit of simplification, maybe we can make elections the oddity and acclamation the default | 16:06 |
| *** jamesmcarthur has joined #openstack-tc | 16:06 | |
| njohnston | ttx: fair point | 16:06 |
| mnaser | when's the last time we actually had an election for a project | 16:07 |
| fungi | acclamation is already the default, really | 16:07 |
| ttx | For U we did not run any | 16:08 |
| ttx | So the whole election is a red herring really | 16:08 |
| ttx | it's what I mean by "having too many systems compared to the numebr of people" | 16:09 |
| ttx | We tend to keep systems long after they are no longer needed. because those are gorgeous systems. I know, I built most of them | 16:09 |
| mnaser | 2 for T, 2 for S, 3 for R, 2 for Q, 5 for P, 6 for O | 16:09 |
| njohnston | mnaser: In Stein we had elections for tacker and senlin | 16:09 |
| fungi | basically switch from asking people to volunteer as ptl every ~6 months to asking them to update their liaisons lists? | 16:09 |
| ttx | 2 over 63 = 3% FTR | 16:09 |
| ttx | fungi: yes | 16:10 |
| *** diablo_rojo has joined #openstack-tc | 16:10 | |
| ttx | it really is what the change proposes | 16:10 |
| jungleboyj | Fair point. | 16:10 |
| mnaser | fungi: yes. and i think it will remove the PTL burden because no one needs to 'act' to speak on behalf of projects | 16:10 |
| ttx | and killing the sacred cow and all its implied baggage | 16:11 |
| mnaser | and also something talking with teams privately was | 16:11 |
| mnaser | having a "one throat to choke" | 16:11 |
| fungi | the liaisons need to "act" to speak on behalf of projects | 16:11 |
| mnaser | right, but if the gate is broken, or if a spec isn't landing, or if you cant get foo or bad. you talk to the team. | 16:11 |
| fungi | how is "the team" defined? | 16:11 |
| mnaser | the contributors of the project | 16:11 |
| mnaser | via ML, IRC, whatever. just like how we do | 16:12 |
| fungi | so join #openstack-senlin and shout into the wind | 16:12 |
| ricolin | IMO, indeed single PTL really makes single point of failure and not even mention huge burden on that single person like PTL for Nova. But to remove any specific team management might led to unreliable governance. | 16:12 |
| mnaser | fungi: or post on the ML. and if you don't get any feedback, maybe talk to the TC "hey i think this team or project is dead" | 16:12 |
| ttx | ricolin: it's not removed. It's reduced to where accountability is needed | 16:12 |
| mnaser | i _do_ think that you'll probably get a response at some point | 16:12 |
| fungi | mnaser: yep, wfm | 16:12 |
| mnaser | (hoping anyways) | 16:12 |
| fungi | hopefully by requiring projects to come up with a roster of half a dozen roles we can start closing them down as soon as they fail to meet that obligation | 16:13 |
| fungi | looking forward to shrinking openstack significantly in the coming year | 16:13 |
| ttx | IF we think having someone on point to "speak for the project" in keeping the gates up is necessary, then we should define a role for it. I'm not sure we need to have a specific person to "speak for the project" there | 16:13 |
| njohnston | One reason why I was hoping for an "opt-in to different governance" was that I was hoping Nova and perhaps a couple of projects could give this a try. Then after a cycle they could report on the unanticipated side-effects and challenges that they had and other projects could make an informed decision about the potential benefits and liabilities of making this change. | 16:14 |
| ttx | the trick is that the "event liaison"'s throat can't be choked to get a specific review done | 16:14 |
| fungi | from the vmt's perspective, a lot of our core projects are actually dead and should be removed, but we'll need to give the board a heads up before we can take them out of the trademark program | 16:14 |
| ricolin | ttx agree | 16:14 |
| ttx | while a PTL's can | 16:14 |
| ttx | fungi: re: VMT I almost added security liaison(s) as a subrole | 16:15 |
| * ricolin not even sure if there's possibility to get things out of trademark program | 16:15 | |
| ttx | since that is one area where having a clear sublist of vetted names can be useful to facilitate the horisontal team work | 16:16 |
| njohnston | ttx: I think security liaison would be a good addition, that is one case where we really need a chokable party | 16:16 |
| mnaser | i jsut worry that we'll end up with like | 16:16 |
| fungi | come may when i switch a bunch of embargoed vulnerability reports teams have been ignoring to public, i'll better be able to talk to the tc about what teams are basically not responsive any longer | 16:16 |
| mnaser | 14 different liasions | 16:16 |
| mnaser | so we have to be more understanding and clear with how we go about this | 16:16 |
| ttx | njohnston: the other one (as commented on the review) is Goal liaison... because it can be hard for goal champions to interact with 63 teams without having a gotoperson | 16:16 |
| ttx | "Meeting chair" could be removed to make room for those | 16:17 |
| ttx | I like "Event liaison" because it's a great way for new contributors to step up | 16:17 |
| mnaser | my struggle a little bit though is figuring out who the onus on is to get work done | 16:17 |
| ttx | (like help organize the team presence at PTG) | 16:17 |
| mnaser | if we keep starting to create liaisons to help make the life of X easy again | 16:17 |
| mnaser | we're doing that to have one throat to choke | 16:18 |
| ttx | mnaser: yeah, we need to keep teh list to a minimum | 16:18 |
| njohnston | ttx: Meh, I think goal liaisons can sometimes come out of the woodwork, so I think we could take care of that other ways. There's not really any guarantee that we'll have a community goal in every cycle so it's probably not a case to optimize for. | 16:18 |
| ttx | only where accountability ("a clear person habilitated to speak on behalf of the project on topic FOO) is necessary | 16:18 |
| mnaser | i think these _groups_ can have liaisons | 16:18 |
| mnaser | i dont know if we should actually put tehm in our governance | 16:19 |
| ricolin | sounds like we should have a role to have multiple person share the responsibility and accountability but not over expand roles | 16:19 |
| mnaser | goals should have liaisons but that can be maintained somewhere else, heck i even feel sometimes maybe release liaisons can be maintained inside openstack/releases | 16:19 |
| ttx | mnaser: I think release liaisons can be maintained in openstack/releases, meeting chairs in opendev/irc-meetings | 16:19 |
| ttx | and event liaisons on some wiki | 16:19 |
| njohnston | ttx: ++ | 16:19 |
| ttx | (they already are) | 16:19 |
| mnaser | so in a way i'm wondering/hoping if we can minimize the "tc-sponsored liaisons" to _openstack critical_ things | 16:20 |
| ttx | If we end up with more than 5 subroles, we'd have failed | 16:20 |
| *** jamesmcarthur has quit IRC | 16:20 | |
| mnaser | like releases is something i find is pretty key. event.. eh. if y'all don't answer to the ML post that diablo_rojo puts out, tough luck, no room | 16:20 |
| ttx | meeting chairs probably should not be mandated by governance | 16:20 |
| mnaser | but i think we should have at least more than 1. because if we have one, then it's back to "well YOU'RE THE RELEASE PERSON SO" | 16:21 |
| mnaser | "fix things" | 16:21 |
| ttx | mnaser: I just want to have more than one. Otherwise some might consider PTL has been renamed to "release liaison" | 16:21 |
| mnaser | ++ | 16:21 |
| njohnston | release liaison and security liaison are really the key roles from what I can see. Other than that we can let teams come up with different approaches. | 16:21 |
| ttx | So maybe... release liaison(s) and security contact(s) | 16:21 |
| ttx | nkget out of my head! | 16:21 |
| ttx | njohnston: get out of my head! | 16:21 |
| njohnston | never | 16:22 |
| njohnston | :-D | 16:22 |
| fungi | the reason the vmt has been needing ptls (or delegated vulnerability management liaisons) is to have a "throat to choke" when the security reviewers for the team are all missing in action | 16:22 |
| fungi | which happens a *lot* | 16:22 |
| mnaser | i think those are two pretty key things that can be maintained in governance | 16:22 |
| mnaser | the rest is optional | 16:22 |
| ttx | I'm borderline on goal liaison... but would like to hear about experienced goal champions to see if that would help them | 16:23 |
| njohnston | Failure to make releases and failure to respond to the VMT are both very objective criteria we could use for triggering a project health check preparatory to designating a project to be dead | 16:23 |
| fungi | though i do think defunct security review teams are less of a concern with the recent vulnerability management policy overhaul. we no longer need to wait for the team to okay ending an embargo, if they don't respond to us for 90 days we switch reports public without their consent | 16:24 |
| mnaser | i think we can just store goals in some goals repo and have people sign up to it, i dunno if it is tc mandated | 16:24 |
| njohnston | goals will have different champions based on their subject matter. The person who does the "docs to ODF" conversion may not be the same person who does "Move all client ops to OSC" | 16:24 |
| njohnston | 16:24 | |
| mnaser | s/subject matter/subject matter and interests/ (imho) | 16:24 |
| *** jamesmcarthur has joined #openstack-tc | 16:24 | |
| ricolin | to have contact window from teams for goal sounds like something we/champion can ask people to sign up during preview/WIP a goal | 16:26 |
| ricolin | also am I the only one think `hero` will be better term than liaison?:) | 16:26 |
| fungi | we've used the term "champion" successfully elsewhere | 16:27 |
| njohnston | ricolin: I think it encourages the wrong mindset, a hero is not necessarily a sustainable thing to be | 16:27 |
| fungi | but yeah, liaison implies a much lower level of effort | 16:28 |
| fungi | it's basically "person to talk to about this topic" | 16:28 |
| ricolin | "champion" works too:) | 16:28 |
| fungi | someone who knows the right people to get things to happen | 16:28 |
| fungi | not necessarily someone who needs to do those things themselves | 16:28 |
| *** Blinkiz has quit IRC | 16:30 | |
| *** Blinkiz has joined #openstack-tc | 16:31 | |
| mnaser | i added an eavesdrop link to todays discussions | 16:31 |
| mnaser | to the review | 16:31 |
| ricolin | will keep reading these when I awake 9 hours later | 16:32 |
| evrardjp | infra/qa liaison | 16:37 |
| gmann | evrardjp: except few project like nova, neutron which are active and great help to us (or few more but do not remember any active) there is no such thing called QA liaison except just name in wiki :) | 16:39 |
| jungleboyj | Sorry, got distracted and am catching up. | 16:40 |
| jungleboyj | I think we need to make sure to not have too many liaisons. I agree with that concern. | 16:40 |
| mnaser | do we need an infra liaison? if your stuff broke, you fix it inside your yaml file | 16:41 |
| mnaser | a team can have their own "infra" liaison or "lead" or whatever | 16:42 |
| mnaser | we don't need to define that | 16:42 |
| jungleboyj | mnaser: I don't think we need that. | 16:42 |
| jungleboyj | I think we need the security liaison, the release liaison are the most important. Event liaison is also important which could be combined with meeting chair as they are much the same work. | 16:43 |
| fungi | mnaser: jungleboyj: the infra liaison is to have someone who can speak for the team when it comes to things like adding or changing central project configuration | 16:45 |
| fungi | before we standardized that, we had far too many cases where someone would propose a change to a project, then someone else on the same project "team" would explode on us for approving it | 16:45 |
| fungi | because one team member proposing a change doesn't necessarily indicate team consensus | 16:46 |
| fungi | so we take a thumbs-up from the ptl or their delegated infra liaisons as a signal that a change is consensual for the team | 16:46 |
| jungleboyj | fungi: Ok. Trust you to speak about what is needed there. | 16:47 |
| fungi | also we don't want to have disagreements within teams spill over into becoming extra work/hassle/pressure on the infra reviewers | 16:47 |
| fungi | so we need some official names of people who "speak for the team" in those matters | 16:48 |
| njohnston | yes, I have been an infra liaison before; I wonder if release liaison and infra liaison could be combined to keep role count down | 16:48 |
| fungi | and then if there are disagreements, we refer them back to those folks | 16:48 |
| fungi | and keep our hands out of it | 16:48 |
| jungleboyj | njohnston: ++ | 16:49 |
| fungi | and standardizing those channels of communication is necessary, lest the reviewers need to consult a list of 70+ different ways every team has decided to implement their human interface to the infra team | 16:50 |
| jungleboyj | I need to get to an appointment. I will catch up on further discussion later. | 16:50 |
| njohnston | after all, the infra liaison doesn't need to propose the changes, they just need to ack them | 16:50 |
| fungi | +1 from a liaison means "i believe this represents the consensus decision of my team" | 16:50 |
| fungi | of course, that does naturally imply that the liaisons are selected in such a way as they can know and represent the opinions of the team as a whole | 16:51 |
| mnaser | fungi: but do we need to have that defined in governance or can teams just appoint that inside openstack/project-config | 16:52 |
| *** witek has quit IRC | 16:52 | |
| fungi | mnaser: i think we could say that if a team doesn't set a liaison in project-config then we don't review their changes | 16:52 |
| fungi | that would probably work | 16:52 |
| fungi | we do still need a way to handle in-absentia liaison turnover, which is the most common sort of liaison turnover i've seen in openstack to be honest | 16:53 |
| njohnston | so a dead project would have someone in the liaison column who never responds, or who asks for a replacement and never finds one | 16:53 |
| fungi | usually the way you get to be a liaison is that whoever was doing it before has disappeared for months and the work is no longer being done | 16:54 |
| mnaser | fungi: then you can borrow the fancy work that ttx did for openstack/releases and have it automatically do ptl+1 if liaisons review | 16:54 |
| fungi | so you can't easily ask the previous liaison to appoint a successor | 16:54 |
| *** jamesmcarthur has quit IRC | 16:54 | |
| fungi | what is the mechanism by which the project-config reviewers approve a change which updates the liaison for a team? | 16:55 |
| fungi | (assume that the most common case is that it's proposed because there is no longer an existing liaison to +1 that) | 16:55 |
| fungi | i suppose there could be a timeout where lack of objection means the newly proposed liaison gets to take the wheel | 16:56 |
| *** jamesmcarthur has joined #openstack-tc | 16:56 | |
| gmann | how much work in project-config needed on project related as all project specific jobs are moved to in-tree. | 16:56 |
| fungi | this challenge most likely applies to any liaison once there is no longer a ptl to delegate them | 16:56 |
| fungi | gmann: these days it's mostly finding out who has permission to add a project to a team | 16:57 |
| fungi | or to replace the core review team when none of them are around to update the group in gerrit and need a gerrit admin to add someone | 16:57 |
| mnaser | fungi: that can be 'tc sanctioned' at that point like "the tc said it was ok so if you are not happy then talk to them" | 16:58 |
| gmann | yeah that one is there. | 16:58 |
| mnaser | because generally that means there's all sorts of other troubles going on | 16:58 |
| gmann | but that is not so frequent or we can say rare like once in a year or cyclke | 16:59 |
| gmann | cycle | 16:59 |
| fungi | sure, a solution could be that a tc is now required to add a project to a team (they have to vote on a corresponding governance change anyway) | 16:59 |
| fungi | and that if a core review group is defunct, we temporarily add the tc to it so a tc member can work out the details | 16:59 |
| gmann | I feel we should continue with project approval on that along with TC. project should be agreed on what they can own/remove than only TC | 17:00 |
| fungi | and also make the tc the initial members of any new review group for an openstack project so they can decide who to add | 17:00 |
| mnaser | fungi: yeah that translates nicely to the whole opendev change | 17:00 |
| mnaser | and self-managing | 17:00 |
| *** witek has joined #openstack-tc | 17:05 | |
| njohnston | so did that sort out the two challenges of 1) how to confirm when a liaison replacement has the backing of a project team and 2) when to consider a wholesale replacement of a defunct core team as valid? | 17:05 |
| *** e0ne_ has quit IRC | 17:06 | |
| mnaser | fwiw i pinged the nova team about this | 17:09 |
| mnaser | i dont think i need to ping neutron :p | 17:09 |
| njohnston | :-) | 17:11 |
| fungi | njohnston: i think it has sorted out that it's *somehow* up to the tc to do those things | 17:12 |
| njohnston | fungi: if that is good enough for you, it is good enough for me | 17:13 |
| fungi | and not up to cross-project groups (infra, release, qa, vmt) to have to figure out when that's been done | 17:14 |
| njohnston | agreed | 17:14 |
| *** witek has quit IRC | 17:15 | |
| gmann | TC will/should not be able to add project to team without project confirmation. | 17:17 |
| njohnston | the tc members that liaise with each project will have an added imperative to be in touch with the state of the project community as part of this, I think | 17:17 |
| *** jamesmcarthur has quit IRC | 17:19 | |
| fungi | gmann: the challenge becomes, how does the tc assess "project confirmation"? | 17:21 |
| gmann | which again need someone from project to give green signal. either TC liasion talk to project or project appoint someone to infa | 17:21 |
| fungi | ask random people on the team? run a poll? hold an election? | 17:22 |
| fungi | if there's a tc liaison, that's just another name for a ptl right? | 17:22 |
| gmann | that is more work than having infa liaison from team :) who can have very less work to do which is on-demand not always | 17:22 |
| gmann | ok, if we keeping 'tc liaison' that works fine. | 17:23 |
| njohnston | fungi: other direction, tc liaison is a tc member who is responsible for being a contact person for a project team’s tc concerns | 17:25 |
| gmann | i think project member to give green signal and ok-go-ahead to TC from project side | 17:25 |
| *** rpittau is now known as rpittau|afk | 17:27 | |
| fungi | njohnston: oh, you mean the tc members who are randomly assigned to be liaisons to teams | 17:28 |
| njohnston | yes | 17:29 |
| fungi | for some reason i thought we'd stopped doing that, but i guess we kept assigning the liaisons, just dropped the rest of the health process | 17:30 |
| fungi | anyway, that's still sort of kicking the can... how does a tc liaison for a team assess the team's consensus? | 17:31 |
| fungi | the tc liaisons are not elected by the teams, they're appointed by the tc | 17:31 |
| fungi | but maybe then it's not consensus, it's just expecting the assigned liaison to make a judgement call as to what they believe is right for that team | 17:32 |
| gmann | yeah we have those liaisons in tc project.yaml. recently i contacted my assignee projects was for py2 drop signal. other than that i have not contacted them about any other required-from-tc or any other isuse but that's might be only me | 17:32 |
| njohnston | I try to attend meetings but that is just me | 17:33 |
| fungi | when we dropped the health assessment process it was because having the tc liaisons be anything more than someone the teams could reach out to if they needed the tc's help was more work than a lot of tc members had time for | 17:34 |
| *** evrardjp has quit IRC | 17:35 | |
| *** evrardjp has joined #openstack-tc | 17:36 | |
| njohnston | ok | 17:39 |
| *** jamesmcarthur has joined #openstack-tc | 17:47 | |
| *** e0ne has joined #openstack-tc | 18:48 | |
| *** e0ne has quit IRC | 18:52 | |
| *** gmann is now known as gmann_lunch | 19:00 | |
| *** jamesmcarthur has quit IRC | 19:15 | |
| *** jamesmcarthur has joined #openstack-tc | 19:35 | |
| *** e0ne has joined #openstack-tc | 19:36 | |
| *** gmann_lunch is now known as gmann | 20:01 | |
| *** e0ne has quit IRC | 21:19 | |
| *** slaweq has quit IRC | 22:28 | |
| *** jamesmcarthur has quit IRC | 22:30 | |
| *** slaweq has joined #openstack-tc | 22:40 | |
| *** slaweq has quit IRC | 22:44 | |
| *** jamesmcarthur has joined #openstack-tc | 23:22 | |
| *** jamesmcarthur has quit IRC | 23:27 | |
| *** jamesmcarthur has joined #openstack-tc | 23:37 | |
| *** jamesmcarthur has quit IRC | 23:49 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!