== Meeting information == * #ubuntu-meeting: Developer Membership Board meeting, started by rbasak, 16 May at 19:05 — 20:00 UTC. * Full logs at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-05-16-19.05.log.html == Meeting summary == === Review of previous action items === Discussion started by rbasak at 19:05. * ''ACTION:'' continue discussion on ubuntu-support-uploaders packageset request on ML (rbasak, 19:11) * ''ACTION:'' teward follow up to get all application process wiki/docs to explain the process to be able to edit wiki pages, for applicants who don't yet have wiki edit access (carried over) (rbasak, 19:12) * ''ACTION:'' sil2100 update application docs and possibly DMB checklist, to make sure candidates have signed CoC before applying and before DMB approves (carried over) (rbasak, 19:12) === Outstanding mailing list requests to assign === Discussion started by rbasak at 19:13. * No unanswered requests. (rbasak, 19:13) === Open TB bugs === Discussion started by rbasak at 19:14. * No Open TB bugs (rbasak, 19:14) === AOB === Discussion started by rbasak at 19:14. * ''AGREED:'' We will keep the private channel but public discussion is preferred when possible. Use of the private channel is discouraged except around the time of our public meetings, or when a private chat is specifically arranged, to avoid DMB members not online from missing out. (rbasak, 19:28) === sosreport delegated package set === Discussion started by teward at 19:30. * ''AGREED:'' We will generally only consider creating a packageset once we have two or more PPU uploaders to two or more related packages. (rbasak, 19:45) * ''ACTION:'' kanashiro to update our wiki documentation with respect to our agreed packageset creation criteria (rbasak, 19:46) == Action items, by person == * kanashiro * kanashiro to update our wiki documentation with respect to our agreed packageset creation criteria * sil2100 * sil2100 update application docs and possibly DMB checklist, to make sure candidates have signed CoC before applying and before DMB approves (carried over) * teward * teward follow up to get all application process wiki/docs to explain the process to be able to edit wiki pages, for applicants who don't yet have wiki edit access (carried over) * **UNASSIGNED** * continue discussion on ubuntu-support-uploaders packageset request on ML == People present (lines said) == * rbasak (107) * seb128 (56) * teward (53) * ddstreet (36) * kanashiro (14) * bdmurray (10) * meetingology (9) * sil2100 (9) * genii (2) * ubottu (1) == Full log == 19:05 #startmeeting Developer Membership Board 19:05 Meeting started at 19:05:41 UTC. The chair is rbasak. Information about MeetBot at https://wiki.ubuntu.com/meetingology 19:05 Available commands: action, commands, idea, info, link, nick 19:05 #topic Review of previous action items 19:05 ddstreet request discussion/voting on ubuntu-support-uploaders continue on ML 19:05 !coffee | teward 19:05 teward: Here's a topped up mug of delicious coffee at the perfect temperature for sipping, enjoy! 19:06 I don't feel like I've had enough meetings to do that yet, especially if we have an agenda and need to get going today but I will try to step up in one of the next meetings 19:06 * genii wanders back to work 19:06 I posted on the list on this earlier. Any further discussion items people want to raise? 19:06 oh hi 19:06 i think i did raise it on the ml 19:07 Has everyone managed to catch up on the ML? 19:07 I did 19:07 If so I suppose we can just decide now. If not, then maybe we need to give people an opportunity to catch up first. 19:08 I do think we should write down some guidelines on creating packagesets, like have more than one applicant and more than one package for instance 19:10 Since nobody else answered I assume they haven't had time to catch up? 19:10 So let's move on? 19:10 teward, bdmurray ? 19:11 *has caffeine* 19:11 took a while to brew sorry 19:11 #action continue discussion on ubuntu-support-uploaders packageset request on ML 19:11 * meetingology continue discussion on ubuntu-support-uploaders packageset request on ML 19:11 kanashiro: agreed! It's always good to document things we decide on 19:11 And I also agree it's good to determine a policy on this so we don't have to decide every time individually 19:11 teward follow up to get all application process wiki/docs to explain the process to be able to edit wiki pages, for applicants who don't yet have wiki edit access (carried over) 19:11 I think we need to review the ML items more in depth, I've been on the fence with regards to sosreport and such 19:12 rbasak: carry over 19:12 #action teward follow up to get all application process wiki/docs to explain the process to be able to edit wiki pages, for applicants who don't yet have wiki edit access (carried over) 19:12 * meetingology teward follow up to get all application process wiki/docs to explain the process to be able to edit wiki pages, for applicants who don't yet have wiki edit access (carried over) 19:12 and by 'review' i mean on our own not in the meeting necessarily 19:12 sil2100 update application docs and possibly DMB checklist, to make sure candidates have signed CoC before applying and before DMB approves (carried over) 19:12 *sips the coffee* 19:12 He's not here I think? 19:12 So I'll carry I guess 19:12 #action sil2100 update application docs and possibly DMB checklist, to make sure candidates have signed CoC before applying and before DMB approves (carried over) 19:12 * meetingology sil2100 update application docs and possibly DMB checklist, to make sure candidates have signed CoC before applying and before DMB approves (carried over) 19:12 sil2100 start discussion on process/rules for when to create packageset vs PPU (carried over) 19:13 I think that thread is effectively in progress. Let's decide it for the current sosreport question and a general policy at the same time. 19:13 I don't see any applicatoins 19:13 So 19:13 #topic Outstanding mailing list requests to assign 19:13 I don't see any unanswered requests. 19:13 #info No unanswered requests. 19:14 #topic Open TB bugs 19:14 #info No Open TB bugs 19:14 #topic AOB 19:14 AOB? 19:14 There are lots of ML threads in flight at the moment. 19:14 yes there are, do any of them need to be discussed here or should they stay on the ML for now? 19:15 right, I would be in favor of using some of the time now to make progress on some discussions we can 19:15 I suggest people carry on with those. Feel free to prompt for progress in the meetings and call for votes when the discussion is over. 19:15 Sure 19:15 Where to start? 19:15 do we have a preference to discuss on list rather than on IRC? 19:15 I think IRC is useful to draw things to a conclusion. 19:15 seb128: not really, there's some things that might be better on ML but the stuff that's in the air is more helpful here 19:16 For discussion, I don't mind either way, but it's helpful to clear things up in realtime sometimes. 19:16 can we maybe get the private channel topic to a conclusion? 19:16 Sure 19:17 just to pick one 19:17 I wrote up a load of reasons why I think we should keep it. 19:17 So obviously my preference is to keep it. 19:17 I meant to reply but I didn't have time yet 19:17 I'd just ask that people read my opinion to see what they agree and don't agree with. 19:17 I'm fine keeping it but I would prefer to not have it used for anything important or that is of use to the group 19:18 reason is that I'm more often not on IRC than connected since I don't have a proxy and go to coworking at times 19:18 Sure. I think the preference should to use public channels where possible. 19:18 and I feel like I'm not going to be able to pick up discussions without some sort of offline logging 19:18 o/ Sorry for being late everyone 19:18 somewhat a fail due to the fact that ubuntu is stuck on IRC than more modern solution 19:18 (although I am expired) 19:18 Although I think it's fine for stuff like "sorry I'll be ten minutes left" where there's no harm in it being private, and just convenient to do. 19:19 sil2100: you are reinstated! 19:19 I agree with what rbasak said in his email, it depends only on us whether we make a good use of the private channel. I am +1 to keep it, it might be useful in some cases 19:19 rbasak, you can also drop that not on #ubuntu-meeting ... 19:19 Oh oh! 19:19 note 19:19 \o/ 19:19 THere was a Telegram bridge at one point, for people without persistent IRC 19:19 but as said, I feel like I would miss out from a private channel just because I dont have a proxy and I'm not always online 19:20 so I would prefer for us to use a solution that doesn't exclude me (or others) 19:20 the mailing list is fine for me 19:20 I don't remember it being used much outside the context and around the time of a specific IRC meeting. 19:21 I think it's fine having a place where we can join for a private discussion if needed 19:21 I have not seen any important information flying there 19:21 but I would really prefer for us to discourage people to use it for talking about topic that might be of use to everyone if some are not online at the time of the discussion 19:22 seb128: would it be OK to flip that around and say that we discourage use of it except around the time of our public meetings? 19:22 I would be fine for that 19:22 around our meeting or in case of 'call for a discussion' 19:22 like you would create an hangout and ask people to join 19:22 but the text based equivalent 19:22 Thanks. I think that fits our previous usage of it anyway, so there shouldn't be much impact in specifying that. 19:23 Any other comments from anyone? Is that decided then? 19:23 sounds good 19:23 sil2100, bdmurray, teward, ddstreet ^ 19:23 Since it's IRC it might be worth putting that into the channel topic. 19:24 we all know ddstreet's opinion - which is to get rid of it. 19:24 sil2100, bdmurray, teward, ^ :p 19:24 i'm on the fence there could be times where it's useful to have the private chat as long as we don't use it as a primary discussion vector 19:24 well teward you probably shouldn't speak for me :) 19:24 I can see how it would be convenient 19:24 I don't have a strong opinion, so I would be +1 on that 19:25 "We will keep the private channel but public discussion is preferred when possible. Use of the private channel is discouraged except around the time of our public meetings, or when a private chat is specifically arranged, to avoid DMB members not online from missing out." 19:25 +1 from me 19:25 ^ is that agreed then? Anything I missed or should amend? 19:25 +1 19:26 ddstreet: I don't have to speak for you - https://lists.ubuntu.com/archives/devel-permissions/2022-April/001936.html - your emails do that enough. 19:26 I'm going to not autojoin to avoid having people defaulting to the channel 19:26 +1 as rbasak says 19:26 I don't even know / remember what the channel name is 19:26 FWIW, I do autojoin, but honestly it doesn't get used much anyway. It's just that on the rare occasion it does get used, it's useful! 19:26 bdmurray: #ubuntu-dmb 19:26 like I will join like I would join an hangout if someone pings me to discuss a topic 19:27 +1 19:27 It tends to happen in a middle of a meeting when an application interview isn't going well. 19:27 do we need a formal vote? 19:27 At that time, it's really helpful for everyone to be there already rather than having to ping around first. 19:27 But it's up to everyone individually what they want to do about that of course. 19:27 k, let's not discuss those details 19:27 I see no need for a formal vote. There seems to be enough agreement. 19:28 k 19:28 #agreed We will keep the private channel but public discussion is preferred when possible. Use of the private channel is discouraged except around the time of our public meetings, or when a private chat is specifically arranged, to avoid DMB members not online from missing out. 19:28 AGREED: We will keep the private channel but public discussion is preferred when possible. Use of the private channel is discouraged except around the time of our public meetings, or when a private chat is specifically arranged, to avoid DMB members not online from missing out. 19:28 We have time to discuss another topic if you'd like? 19:28 can we make also progress on the sosreport case? 19:28 Sure! 19:28 rbasak, will you set the channel topic with the message you mentioned? 19:28 what you wrote is sort of what I was trying to get as an answer by my previous questions 19:29 I have a question on this case 19:29 Can I delegate the setting of the channel topic to teward please? 19:29 I think the '1 member = ppu, next request -> packageset' makes sense as a rule 19:29 #chairs rbasak teward 19:29 !chair rbasak teward 19:29 ffs i hate the bot sometimes 19:29 #chair rbasak teward 19:29 Current chairs: rbasak, teward 19:30 I think it's more than one member AND more than one package 19:30 #topic sosreport delegated package set 19:30 is the bot dead today? 19:30 Many people individually having PPU to sosreport wouldn't necessitate it being a packageset. 19:30 here's my question on sosreport 19:30 how widely a group really needs upload privs on sosreport? 19:31 additionall,y if this is a debugging/support group as Robie said it seems it'd encompass more packages than we'd want it to 19:31 are you asking me? 19:31 it's a general question 19:31 i'm asking 'nobody in particular' 19:31 Currentlyl from what I can tell, from an ACL perspective, you ddstreet are the only person who would be in the group 19:31 I think the way to answer the question is to see the actual applications. Whether a PPU or a packageset we'd need the applications anyway. Then we'd understand the situation better and be able to answer the question. 19:32 but you're already coredev so it does nothing 19:32 i think we need to see the applications *before* we can decide, or decide "not at this time" and handle it later at the first time someone applies. 19:32 as well as the full scope of what packages would be in this 19:32 (right now, I don't see enough criterion personally to support creating a delegated group for one package) 19:32 I asked that question in the previous meeting, my understand was that ddstreet expect his team members to join this group 19:32 understanding 19:33 yes that's right 19:33 i'm actually trying to offload this application to team-mate(s) 19:33 but it's been slow to find 'volunteers' 19:33 define "team mates" 19:33 I think it would have helped to join a list of people who would be interested today to the request 19:33 make it more concrete 19:33 even if they work at Canonical they need a greater understanding of the processes, etc. that ascribe to packages 19:33 teward i'm on the Canonical Sustaining Engineering team 19:33 that's applicable to *everyone* at Canonical 19:33 Canonical employment does not mean you get rights to upload 19:34 i don't recall saying it did? 19:34 teward, I don't think that was implied there 19:34 seb128: it's a general observation that i'm stating that some people think it does 19:34 rather than his team has a bunch of members who do that on a daily basis 19:34 i would rather see the extent of the team first 19:34 and probably have the skills to request to join 19:34 ^^ correct 19:35 teward our LP team is actually private (it was before i joined, i don't know why) so i'm not sure if the team membership list is publicly viewable 19:35 but for sure not everyone on the team will apply 19:35 I'm +1 on that, having a list of 'those are the people who would apply today if the set was there" would be nice to decide 19:35 ^^ 19:35 ddstreet: until i see the full extent of the people, -1 from me on the request. Furhter, the scope needs better define 19:35 to quote robie: 19:35 as i said, i'm trying to hand this off to people who *would* benefit from being on the team (or have PPU) 19:36 > Separately, a description of "packages used for debugging and supporting Ubuntu" would seem to include gdb for example. 19:36 teward keep in mind that every person joining the team would need to apply 19:36 the scope needs to be better defined because gdb and a ton of other packages would be in this set 19:36 and i'd rather not have any non-coredevs mess with gdb because that can break other things. 19:36 delegated set or not 19:36 to be clear, this isn't asking for anything besides sosreport right now 19:36 For me, having a list of candidates isn't sufficient. I'd like to actually have a list of people the DMB have agreed _should_ be able to upload the package. IOW, I'd like to see those application succeed, and then we can decide if a packageset is appropriate, or if PPU will do. 19:37 +1 for rbasak's statement 19:37 i'm happy to carry any response back to the team; as i said i'm handing this off to someone else asap 19:37 the result here really makes no difference to me :-) 19:38 which "this" is being handed off? 19:38 the team/packageset application we're discussing 19:38 THe important thing is not to block people who are wanting to upload. But whichever way we need the actual applications to consider the actual mechanism to use. 19:38 or ppu 19:38 maybe we should step back and try to define the requirements to create a packageset as we were discussing, >= 2 people and >= 2 packages? 19:38 currently, i am the *only* person in my team who can upload sosreport to devel releases 19:38 i'd say this should be PPU for now rather than a packageset 19:38 if it's only one package, it doesn't warrant a packageset 19:39 so as long as i'm still on the team, there is no blockage 19:39 regardless of number of individuals who need to upload for now, until the wider 'do we need other packages?" question is answered 19:39 kanashiro yeah as i said i really don't care what the outcome is here, if the >=2 rule already existed i wouldn't have bothered to apply 19:40 yes, that's the point, if the rules were defined we wouldn't be discussing that :) 19:40 this discussion might be overthinking things :) 19:40 indeed 19:40 If you don't care about the outcome, why are we still discussing it? Can we just consider the request cancelled and move on? 19:41 sorry i mean, i don't care about the outcome as in, i'm fine with whatever decision is made 19:41 i don't mean that i don't care about it at all 19:41 I think there is an opportunity to define when package sets should be used. 19:41 if the decision is for individuals to reapply for PPU, that's fine 19:41 rbasak, I would like for us to define those rules if we can 19:41 if the decision is to create a pkgset/team, that's fine too 19:42 so we don't get the same unclear situation again next time 19:42 OK. How about we just say that for a packageset we expect a minimum of two approved uploaders to a set of two related packages before we'll consider it? 19:42 Exceptions can exist at any time of course. 19:42 two or more related packages* 19:42 +1 19:43 we need a minimum to justify the admin work to create the packageset 19:44 +1 19:44 +1 19:44 +1 19:44 Sounds like a reasonable compromise 19:44 i'm not sure i should even be voting so i'll +0 if that helps :) 19:45 #agreed We will generally only consider creating a packageset once we have two or more PPU uploaders to two or more related packages. 19:45 AGREED: We will generally only consider creating a packageset once we have two or more PPU uploaders to two or more related packages. 19:45 Does someone fancy taking the task to update the documentation on this please? 19:45 rbasak, I can do that 19:45 I think this needs cleaning up between https://wiki.ubuntu.com/UbuntuDevelopers/TeamDelegation and https://wiki.ubuntu.com/DeveloperMembershipBoard/KnowledgeBase#Packagesets 19:45 Thanks! 19:46 #action kanashiro to update our wiki documentation with respect to our agreed packageset creation criteria 19:46 * meetingology kanashiro to update our wiki documentation with respect to our agreed packageset creation criteria 19:47 Any other discussion on this topic? 19:47 not from me 19:47 Would anyone like to raise any other topics while we still have a few minutes left? 19:47 not me 19:48 None from me 19:48 Any other AOB? 19:48 What bout the election? 19:48 I'll start arranging that tomorrow. 19:48 But that does remind me (thanks) 19:48 I did have one thing for the DMB in general. 19:49 The documentation I wrote up when I first ran a DMB election is at https://wiki.ubuntu.com/DeveloperMembershipBoard/KnowledgeBase#Running_a_DMB_election 19:49 The call for nominations has these two sentences: 19:49 Candidates must expect to be able to attend the majority of DMB 19:49 meetings. Currently these take place on IRC, are scheduled on alternate 19:49 Mondays with each meeting alternating between 1500 UTC and 1900 UTC, and 19:49 last around an hour. 19:49 ddstreet sounded unhappy about the wording here. 19:50 i'd prefer the majority of the DMB business to happen on the ML, but that's just my opinion 19:50 The reason for the wording, which I think dates from 2020 or so, is that we were having a big problem with attendence at IRC meetings 19:50 I seem to recall one candidate who wasn't going to run because those times weren't great for them. 19:50 i think the DMB relies too heavily on IRC meetings and lets ML threads die 19:50 And the process had been (and still generally is) that if we're not quorate at an IRC meeting, we often don't consider an application, and so we don't make progress. 19:51 bdmurray, that was me :p 19:51 If we want to switch to ML interview of applicants, then that's within the DMB's remit to change, but is a whole separate discussion. 19:51 I got convinced people rbasak said we would renegociate the times after election if needed 19:51 but I've a feeling that often people are missing on IRC or busy with other things and not responsive 19:51 For now, I just want to know what to put in my call for nominations to run this immediate election 19:51 seb128: I knew that 19:51 ...that everyone will be happy with. 19:51 so I do think using more the mailing list might be a positive thing 19:52 IMHO, right now we still need good attendence at the IRC meetings, as we haven't agreed alternative arrangements. 19:53 rbasak, I'm fine with the wording if that's what is expected, I just fear that 'must expect to be able to attend the majority' is going to exclude people 19:53 However, we can change the IRC meeting times. We've done that in the past. And my wording in the call for nominations reflects that still I think. 19:53 I agree with using more the mailing list but for applications review I'd still prefer the IRC meetings 19:53 I think you could be more explicit about the times being changeable. 19:53 rbasak, as a non native speaker it didn't reflect that to me 19:54 Anyway, the point of me raising this here is to give the DMB the opportunity to amend my wording there, or change the sense of it entirely. 19:54 Suggestions appreciated. 19:54 But we need consensus for me to change the wording really. Otherwise I'll just be torn in different directions. 19:55 I would add a sentence that times are up to the board and can be regociated at any time if wanted by the members 19:55 just to clarify that it is an option 19:55 Sure, I can do that. 19:55 i'd suggest that we should expect candidates (and members) to *either* attend the meetings *or* perform their duties on the ML; i'm not sure why the timing isn't up to the individual 19:56 Right now, I don't think it'd be effective for a DMB member to participate only on the ML, since we hold application interview on IRC. 19:56 +1 for renegotiation. 19:57 personally i think each member should decide how they are best effective 19:57 If everybody started to do that, then application interviews would stop taking place. 19:57 i don't see that as a problem 19:57 Before we accept ML-only participation, I think we need to agree to change the application process. 19:57 but i also don't see continuing to hold irc interviews as a problem for members who prefer that 19:58 (and FWIW I prefer realtime application interviews and I don't think we should change that) 19:58 you can have both, of course 19:58 +1 for real time interviews 19:58 So I think for now, for my immediate question on what to put in the call for nominations, I should add a sentence as seb128 suggested. 19:59 The discussion of if/how to permit ML-only applications in general is a separate one and if you want to drive that please go ahead, but it's a separate discussion. 19:59 (I'd also ask that we not be trying to change too many things at once, since it's quite time consuming to deal with all the things) 19:59 Also we're out of time now. 19:59 Thank you for the discussion. I'll proceed as seb128 suggested then. 19:59 Any other comments? 20:00 -1 on ddstreet's opinion. for an application we need to have more discussion with the person, and ml is not enough in my opinion. 20:00 not from me 20:00 my own statement because there's more than just an 'email' lets you answer. 20:00 nothing more from me. 20:00 no, thanks for driving the election rbasak 20:00 teward that isn't my opinion at all 20:00 thanks rbasak for driving 20:00 Thanks all! 20:00 #endmeeting Generated by MeetBot 0.4.0 (https://wiki.ubuntu.com/meetingology)