== Meeting information == * #ubuntu-meeting: Technical Board meeting, started by rbasak, 22 Feb at 20:05 — 21:39 UTC. * Full logs at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-02-22-20.05.log.html == Meeting summary == === Action review === Discussion started by rbasak at 20:06. === Definition of our third party repository policy === Discussion started by rbasak at 20:07. === Discuss DMB inactivity expiration policy (all of the TB) === Discussion started by rbasak at 20:08. * ''AGREED:'' The TB moves to remove the two absentee DMB members in principle, with the specifics yet to be agreed (rbasak, 20:22) * ''AGREED:'' We will contact the members as best as we can, and wait a minimum of one week before removing them from the LP team and sending out a call for nominations (rbasak, 20:37) * ''ACTION:'' rbasak will send out the private removal emails (rbasak, 20:45) * ''LINK:'' https://lists.ubuntu.com/archives/technical-board/2022-February/002607.html (rbasak, 20:47) === Scan the mailing list archive for anything we missed (standing item) === Discussion started by rbasak at 21:36. === Check up on community bugs (standing item) === Discussion started by rbasak at 21:38. === Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members) === Discussion started by rbasak at 21:38. * Next chair will be cyphermox with vorlon as backup (rbasak, 21:38) === === Discussion started by rbasak at 21:38. === AOB === Discussion started by rbasak at 21:38. == Action items, by person == * rbasak * rbasak will send out the private removal emails == People present (lines said) == * rbasak (131) * vorlon (59) * sil2100 (31) * ddstreet (30) * meetingology (6) * sarnold (1) == Full log == 20:05 #startmeeting Technical Board 20:05 Meeting started at 20:05:41 UTC. The chair is rbasak. Information about MeetBot at https://wiki.ubuntu.com/meetingology 20:05 Available commands: action, commands, idea, info, link, nick 20:06 #topic Action review 20:06 * rbasak formal ratification of third party seeded snap security policy, depends on: (rbasak, 19:06) 20:06 Let's discuss that in a separate topic 20:06 * rbasak vorlon to circle around with store, snapcraft, et all, and revise the snap source revision policy to be more clear with regards to rebuildability and GPL compliance. (rbasak, 19:06) 20:06 Same as above? 20:06 * rbasak sil2100 to start a draft summarizing the OEM archive portion of the meeting which x-nox and TB will review, edit, and ratify before we move on to figuring out the next step (rbasak, 19:08) 20:06 Apologies... 20:06 OK, carry over 20:06 * rbasak Review and leave feedback on the first version of the preamble and three first requirements https://pad.ubuntu.com/third-party-repository-requirements (all of the TB) (sil2100, 20:09) 20:06 In the next topic 20:07 * rbasak Discuss DMB inactivity expiration policy (all of the TB) (sil2100, 20:27) 20:07 We should have a separate topic later for that too. 20:07 #topic Definition of our third party repository policy 20:07 I requested feedback on my initial drafts in https://pad.ubuntu.com/third-party-repository-requirements 20:07 rbasak: carry-over on my action 20:08 OK, and for sil2100 too I guess 20:08 Yes, apologies for that, I didn't have too much time recently 20:08 #topic Discuss DMB inactivity expiration policy (all of the TB) 20:09 #chair vorlon 20:09 Current chairs: rbasak, vorlon 20:09 Speaking for myself and not as the chair, the DMB seems paralyzed on this currently. 20:09 I'd appreciate getting it resolved quickly. 20:09 right, so 20:09 vorlon: did you manage to consult with non-DMB on the TB as you were seeking? 20:10 I have not; the non-DMB members on the TB having been cyphermox who has unfortunately been inactive, and mdeslaur who has stepped down 20:11 I have failed to reach out directly to cyphermox, which I can still do, but at the end of the day I think it's going to largely come down to us three again 20:11 unless the three of us don't actually agree I guess :) 20:12 OK, so how do you want to proceed? 20:13 well, as a metapoint, I recognize the desire to have a quick resolution but I think it is not possible for there to be a quick removal of any current members of the DMB. Given my position that the DMB doesn't have the authority to set a policy for removing its own members, this has to go through TB discussion (which I've myself failed to move forward promptly), vote, and execution 20:14 given this reality, how should this be managed with respect to the frustrations of the active members of the DMB 20:14 I think the DMB's position that members who have been inactive for some time should be removed is in general completely reasonable. 20:15 I agree 20:15 If procedurally the DMB can't do this themselves, then sure, ask the TB to agree. 20:15 Same 20:15 no disagreement with this principle. Only flagging the concern that I don't think we can actually put this in practice fast enough to address current DMB frustrations 20:16 If the TB agrees (sounds like it does) then the question of procedure of who makes the decision shouldn't matter. We can decide it here and be done. 20:16 A nuance is *how* the removal ought to be done. 20:16 so you would like to move forward on a vote to remove specific members of the DMB for inactivity, without first formalizing a policy? 20:16 But maybe we can make progress by agreeing that it should be done, and then worry about how? 20:16 (we can decide how afterwards in this meeting too) 20:17 vorlon: yes, if that sounds good to you and sil2100 20:17 ok 20:17 But let's make it clear that it is pending further discussion on how to do it, which we will discuss shortly 20:18 You mean deciding on removal of individual inactive DMB members right now and later working on the actual policy, yes? 20:18 When I say how I'm referring to my request that they be contacted privately first 20:19 So I'm saying: 1) the TB agrees to remove the two (previously absent) members now. 20:19 That will presumably need a vote. 20:20 And it would be in principle only, because 2) the TB discusses how to approach doing this (in terms of whether to contact them privately first or not, and how long to wait after sending those emails before actually removing them from the LP team) 20:20 of specific concern to me is Simon's statement that he wishes to continue to serve; if he is not actively participating in the work of the DMB but also not stepping back, that's not good. Wouldn't change my vote, just means a harder conversation. AIUI there would've been another DMB meeting since then, did he attend? 20:20 He did not, and we were unable to reach quorum 20:21 I had hoped that he would after the e-mail he has sent 20:21 IMHO, that ship has sailed, and it isn't sufficient just to reappear after missing so many meetings, including the discussions the DMB had about absentee members, and the vote the DMB had that passed. 20:21 But yeah 20:21 * vorlon nods 20:22 I'm +1 on the plan that rbasak outlined 20:22 yes, I'm fine with it 20:22 #agreed The TB moves to remove the two absentee DMB members in principle, with the specifics yet to be agreed 20:22 AGREED: The TB moves to remove the two absentee DMB members in principle, with the specifics yet to be agreed 20:23 OK, so next, I requested that before the removal we privately contact the members to explain why they are being removed and thank them for their contributions. 20:23 +1 20:24 +1 20:24 And that this be done before sending out a call for nominations with the idea being that the members are not suprised to see the call for nominations for their own seats first. 20:25 I suggested therefore to wait a minimum of a week after sending the emails before (removing them from the LP team and sending a call for nominations) 20:26 However ddstreet objected very vocally to do this, and that's the point in contention for which this item got escalated to the TB in the first place. 20:26 right 20:26 Obviously I think we should do this anyway, and I've explained in the email thread why I think it's not appropriate to recuse myself. 20:26 I am ok with a 1-week timeline. It's not clear to me that ddstreet will be, but OTOH 2 weeks have already passed since the escalation so that ship may have sailed 20:26 So it's down to you two really. 20:27 my apologies for having let this continue for yet another DMB meeting cycle 20:28 In principle I'm +1 with waiting a week, my earlier stance of not waiting was caused by the fact that the policy that we decided on did not require that 20:29 But since the policy is moot, because of what is mentioned above, I'm good with going with the 1 week approach now 20:30 I don't feel strongly that there be any particular waiting period. I think the ordering matters (contacting them before a public call for nominations). 20:31 and I don't think 1 week significantly changes the impact on the DMB in either direction, due to the realities of an election timeline 20:31 so I am +1 20:31 That being said, I'd like this to be resolved as soon as possible. So I'd even propose trying to contact the members that will be removed by means other than e-mail 20:31 (additionally to sending the e-mail) 20:34 is this agreed then? 20:36 +1! 20:36 OK great 20:37 #agreed We will contact the members as best as we can, and wait a minimum of one week before removing them from the LP team and sending out a call for nominations 20:37 AGREED: We will contact the members as best as we can, and wait a minimum of one week before removing them from the LP team and sending out a call for nominations 20:38 FWIW, if we get an ack from both of them sooner, then I am happy to get moving sooner. I assume nobody will object to that. 20:38 There are still some loose ends to tie up though. 20:39 One member of the DMB resigned privately, and has removed themselves from the LP team. So there will be three seats up for election now, and the other four in May I think. 20:39 I assume that's fine? Are we running one election, or two? 20:39 What if, for example, we opened all seats for election in a week, and the top three would start immediately and the other four would start in May? That might save a bunch of admin. 20:40 what if the top three are candidates who are standing for reelection 20:41 doesn't help you any 20:41 Good point. Pick the top three who are actually eligible then? 20:41 I would just aim for two elections 20:41 OK fine 20:41 Second, ddstreet did escalate a second issue to the TB wrt. my conduct 20:42 btw we have agreement to contact the DMB members, who is taking the action 20:42 I am happy to do it. 20:42 I didn't before because I didn't think ddstreet would wait before sending a call for nominations, which he later confirmed. 20:43 But now the TB has decided the way it will be done, I am happy to take the action. 20:44 Are you both happy for me to take the action or would you prefer that I didn't? 20:44 I think it's fine - just wanted to be clear about action assignment 20:45 sil2100? 20:45 +1 20:45 #action rbasak will send out the private removal emails 20:45 * meetingology rbasak will send out the private removal emails 20:45 Also, who will run the election? 20:45 in the past the DMB have run them 20:46 So let the DMB decide for themselves? 20:46 which I have no objection to, as I mentioned on list this is administrative work so I see no conflict of interest 20:46 rbasak: what part of it is deciding? 20:46 The actual person who does the admin work. 20:46 yeah 20:46 OK, so we'll leave that to the next DMB meeting then. 20:46 I'm not worried someone elected to the DMB is going to rig the election in their favor 20:47 ;) 20:47 So finally on this topic I think 20:47 https://lists.ubuntu.com/archives/technical-board/2022-February/002607.html 20:47 ddstreet said: " 20:47 The bigger problem is that a single DMB member is able to block the 20:47 team from following explicitly written policies because they do not 20:47 agree with the policies. That is what I would ask the TB to clarify. I 20:47 think it's unfortunate that we even need to state something like that 20:47 in writing, but here we are." 20:47 This relates to my conduct, so I think I must recuse myself from any TB decision. 20:48 understood 20:48 I'm unsure what clarification we can satisfactorily offer here 20:48 I think there was a clear disagreement about the interpretation of a policy 20:48 Speaking for myself personally, obviously I think that it's entirely appropriate that when we couldn't resolve a disagreement we escalated to the TB. That is IMHO the correct process and is even defined as such by the CoC. 20:48 interpretation and application 20:49 So, I don't think any single person should be able to block anything - if a policy is defined and ratified correctly, then no one objection (if not part of the policy) should block anything 20:49 I had a good faith disagreement on how to interpret the policy. 20:49 and again, there's also the fundamental that the policy in question was out of order 20:50 Yeah, indeed 20:50 i will mention that there are 2 members of the TB that participated in the DMB policy discussion, and NEITHER brought up its invalidity during discussion 20:51 ddstreet: hi 20:51 yello 20:51 ddstreet: hello! It never occured to me as I am quite 'fresh' to the TB, only vorlon actually noticed this fact 20:52 just pointing out that the invalidity of the policy is really irrelevant to the issue 20:52 This thought never occured to me before that indeed the DMB should not be the authoritative body 20:52 I felt that the discussion was not permitted to proceed properly. It was rushed and was never brought to a meeting for discussion. 20:52 fair; important from my perspective but irrelevant to the actual circumstances of blocking 20:52 It did cross my mind that it probably needed to go to the TB, but I didn't think it mattered much because I didn't see the TB objecting, and I didn't want to block progress. 20:53 But in case where such a policy as we agreed on had been properly ratified, I would just follow the policy 20:54 But, where your wording said that the members would be removed, I did assume that meant that we'd be asking the TB to do that removal. 20:54 And therefore if the TB objected, they could do so at that time. 20:54 I don't see how it could be interpreted any differently since LP ACLs do not allow a non-TB person to remove people from the team. 20:55 If the ratified policy did not mention any wait period or any e-mail to be sent beforehand, to me this is not a breach of CoC personally. The CoC "Be respectful" is very vague and can mean a lot, and I don't like making decisions on something that is not as much expicitly defined as possible 20:55 ddstreet: so, I'm unsure how the TB can help with this. Personally, I value your service on the DMB. I'm unsure if I'm misinterpreting your email, which reads to me like an ultimatum that if the TB doesn't agree with you that it was wrong for rbasak to block things from moving forward on the timeline you sought, you would step back from the DMB. I can't agree with that; I do think this was a 20:55 good-faith difference of interpretation of a policy, that escalating to the TB was reasonable under the circumstances 20:56 vorlon no I don't "require" you to agree with me - I just want the TB to address this; specifically, if a DMB member can block implementation of written policy 20:56 and I do absolutely understand your frustration with absenteeism blocking the work 20:56 ok 20:57 if the answer is 'yes they can' then I can work with that, but I can't work with 'who knows!' 20:57 ok, thanks 20:58 and, if the answer is 'the DMB should decide this specific policy' that's fine with me, as well 20:58 ('this policy' being how/if exactly members can block policy implementation) 20:59 IMHO, it should *always* be possible for any team in Ubuntu to escalate to leadership. Leadership can act quickly if the situation warrants (the need to do that is actually in the CoC) so that wouldn't really be blocking anything. And if leadership decides that the person was behaving in bad faith, then they can sanction that person. 20:59 quick off-the-cuff wording of a draft statement, let me know whether this would address your concern: "in matters of disagreement within the DMB over the interpretation of a DMB-ratified policy, it is appropriate to escalate to the TB for a decision" 21:00 to be clear, from my perspective it was also not rbasak's intention to block moving forward under the policy; there was disagreement about what moving forward looked like 21:00 rbasak: escalation, agreed. If someone objects with some policy it is the right thing to do. But until the policy is invalidated, I don't think an objection should block any policy from being executed, right? 21:00 Just want to make sure we all have the same baseline 21:01 well if you are *asking* me for my opinion, I think fortnightly meetings, at which some members don't always show up, can *really* cause delays in progress if things get 'official'. I'd much prefer *defaulting* to following the written policy, while at the same time leaving the option to any team member to escalate to the TB to reverse any decision 21:01 i.e. JFDI and the TB can revert if needed 21:01 sil2100: I think it depends. If the objection is on the principle of preventing harm, then it's appropraite to wait for a leadership decision. And I think that applied here. 21:01 You can't just revert removing someone, since the harm is social, not the membership of the team itself. 21:02 that's something that should be brought up during discussion of individual policies 21:02 Also, in this case, it was about how the written policy was to be interpreted. You say you wanted to follow the policy, I say I wanted to follow the policy. But we were talking about two different things. 21:02 * ddstreet stops discussion this specific policy 21:02 For example, how exactly was a DMB member going to remove other DMB members from the LP team without asking a TB member to do it? 21:03 this isn't about this specific policy 21:03 It's never too late to ask to prevent harm. 21:03 If someone notices something harmful long after a policy was decided, it's not appropriate just to blindly follow the policy. 21:03 Even if there were no question about its interpretation. 21:05 rbasak: so in my personal opinion the particular situation was not really harmful - since as I said, 'respect' is a very vague term, some actions might feel respectful for some, for others less. It's very open to interpretation. Though I do agree that contacting beforehand would be a good gesture 21:05 But yes, in the end the policy was not quite fully correct, as you mentioned with actually regulating the membership status (requiring the TB) 21:05 right, so for the specific question ddstreet asked, narrowly described, can a single member of the DMB veto the application of the DMB's policies: no. But I don't think a 'no' answer to that question helps anything 21:06 So I think in the end we'd still be in this situation, as we'd have to go to the TB to actually execute the policy 21:09 possibly the DMB needs to figure out a more structured arrangement to its meetings and implementations of policy (which, as i said, is unfortunate that we need to go to) 21:09 i think my point is that, if the TB needs to arbitrate 100% of DMB disagreements, I'm not sure what the point of the DMB is at all 21:09 or i should say, what the point of having DMB rules/policies is 21:10 I think this was the first time where TB arbitration was required, right? Or did something similar happened before? 21:11 well, what i mean is that we spent ~1 month discussing the policy, then ~3 months waiting for the policy period, then at the point of implementation there was disagreement that needed escalation 21:12 so do the dmb 'policies' actually mean anything? 21:12 I'll say again that we never properly discussed the policy. It was rushed through on the ML during a very busy time for regular applications. Normally the meetings aren't so busy. 21:12 So as a result it was ill thought out. 21:13 I think it's good to have a third party help resolving conflicts or making sure policies are correct. Sometimes that's even necessary. I don't think disagreements like this should be blocking. 21:13 If you don't want that to happen, I'll ask that you be patient, put things on the meeting agenda, and wait until we actually have time to discuss them properly. 21:13 just a quick time check, we are 13 minutes over 21:14 Then we'll have fewer disagreements about interpretation because we'll actually have had the opportunity to make sure we all understand the details. 21:14 from my side I don't need to stop discussing, but I also want to make sure people feel discussing this now is the best continued use of time 21:15 i'm not on the TB, but IMHO i'd like to see an answer to 'are DMB policies valid, as written, until modified'? 21:15 I also understand ddstreet's frustration here, since I think the policy was proposed and I felt that we did discuss it to some extent. Maybe such a on-DMB-meeting discussion as proposed by rbasak could be helpful, but we know how things look with the DMB attendance 21:17 from my perspective: I spent way too much time pedantically writing, proposing, and discussing this policy, then finally gathering votes for it, adding it to the DMB KB, waiting 3 months, and then finally at the time of implementation, rbasak decided we should not follow its specific wording. 21:17 if that seems ok, then ok. if not, maybe clarify things. 21:17 ddstreet: I feel I can say "yes" to that question as posed, but that this again doesn't help you? Because the disagreement was about the part that wasn't written when it came time to implement 21:18 from my perspective: I appreciated ddstreet working on driving this until he suddenly got impatient and rushed it through, and then tripped up when it later turned out that ddstreet's interpretation of what he wrote didn't match rbasak's interpration of what he wrote. 21:18 (apologies everyone, but I have to drop now - I think my opinion is known on this topic already, if anything!) 21:19 just for clarification - and again, i wish we weren't focusing on this specific policy - here is the policy as i wrote in the KB https://wiki.ubuntu.com/DeveloperMembershipBoard/KnowledgeBase#Board_Member_Attendance 21:19 thanks sil2100 21:19 I didn't think I could be *more* pedantic in the wording, but clearly I could have ;-) 21:20 I don't think I've got anything else to add. 21:20 I also don't see how the current thread of discussion is helpful. I don't see what ddstreet is trying to achieve by posing tautological questions. 21:21 I don't think ddstreet is being deliberately tautological but I also am uncertain how to move things forward satisfactorily from here 21:22 Teams can set their own policies. That's a given. Ubuntu has paths for escalation when there's a disagreement. That's also a given. 21:22 because it still seems to be a difference of framing 21:22 That is the structure in which we operate. 21:22 what i would like is some clear (in whatever meaning 'clear' might have) definition of what objections to written policies could possibly block policy implementation while escalated to the TB 21:22 Either this is acceptable to ddstreet or it is not, but that's how it is. 21:22 if the answer to that is 'anything' then, ok 21:23 well, yes, from my perspective the answer is 'anything' 21:23 My understanding is that leadership teams in Ubuntu can override everything. 21:23 I don't think we can draft a meta-policy that applies here 21:23 (that is within their scope) 21:23 exceptions are exceptional 21:24 It's also a principle of leadership to try not to interfere. 21:24 But obviously they have to, to some extent, if something is escalated to them. 21:24 My approach on the TB in dealing with other matters is to try as hard as possible to interfere as little as possible. 21:25 And that's it really. Everything else is case-by-case. 21:25 more specifically what i mean is, can a team member object to ANYTHING for ANY REASON and block its implementation until the TB resolves the dispute? Or, are there any cases where the implementation proceeds? Obviously, the TB can revert *any* decision 21:25 though the TB can't undo side-effects from implementations 21:25 I think the answer should be Yes. 21:26 yes, though like mushrooms being edible, it may be something an individual member can only do once 21:26 lol 21:26 oh you can definitely do that multiple times 21:26 i.e. if it's egregiously in bad faith (which I assert was not the case here), there may be consequences 21:27 The TB doesn't need to fully resolve a dispute before making some kind of interim decision, FWIW. 21:27 So something could be escalated, and the TB might say "proceed for now because it won't do any harm while we deal with some of the details" 21:28 It's also not really possible to make someone stop doing something, if that's what you're asking. 21:28 Like I couldn't stop you from sending a call for nominations. 21:28 I live too far away for that :) 21:29 But then whether that was a reasonable thing to do or not would be for the later judgement of the TB 21:30 Since we're talking generally, I'd expect parties to a dispute to try and act in good faith, do the thing that causes/results in the least harm, and leave it for leadership to decide how to proceed. 21:30 That may mean proceeding with something, or not proceeding with it, depending. 21:31 If there's a disagreement about what would cause the least harm, try to respect each other and figure it out? 21:33 We're at 90 minutes now 21:33 And I'm hungry 21:33 Where are we now? ddstreet, what more do you want from this topic? 21:33 if everyone is just continuing this for my benefit, please feel free to close :) 21:34 Close this topic for now, or close the escalation you raised? 21:35 re: absent member resolution, that's already been decided i think 21:35 re: general DMB policy process, yeah don't worry about me :) 21:35 OK thanks 21:36 #topic Scan the mailing list archive for anything we missed (standing item) 21:36 We need to organise an election following mdeslaur's resignication 21:36 resignation 21:37 Maybe given the time, we leave that for this week? 21:37 yeah I'm tapped out, sorry 21:37 I don't see anything else recent 21:37 Dimitri continued the ~ubuntu-archive thread but I'm don't think there's a TB action there. 21:38 #topic Check up on community bugs (standing item) 21:38 I don't see anything. 21:38 #topic Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members) 21:38 #info Next chair will be cyphermox with vorlon as backup 21:38 #topic 21:38 #topic AOB 21:38 AOB? 21:38 nothing from me 21:39 #endmeeting Generated by MeetBot 0.4.0 (https://wiki.ubuntu.com/meetingology)