[18:54] o/ [18:56] \o [19:01] o/ [19:02] o/ [19:02] are there people here? [19:03] yay [19:04] should we start? [19:04] If someone else could chair please. [19:04] The DST change has messed up my schedule a bit :-/ [19:05] as always, I can :) [19:05] #startmeeting Developer Membership Board [19:05] Meeting started at 19:05:51 UTC. The chair is utkarsh2102. Information about MeetBot at https://wiki.ubuntu.com/meetingology [19:05] Available commands: action, commands, idea, info, link, nick [19:06] hey, sorry for being a bit late! [19:06] #link https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda [19:06] #topic Ubuntu MOTU Developer Applications [19:07] Frank Heimes is still pending. [19:07] bdmurray: :) [19:07] I was out sick and then had some holidays [19:07] Will definitely get to it this week [19:08] should we just conclude that it, unfortunately, did not make it through? [19:08] as per the rules we have^ [19:08] I'm not sure I exactly follow the current set of rules, but I'm fine with that outcome. Better to stop it leaving hanging :-/ [19:08] I read somewhere in the wiki - but anyway, what do others think? [19:08] aah, okay [19:08] I just read it [19:09] thank you, bdmurray :) [19:09] keep well, too! \o/ [19:09] moving on.. [19:10] wait - my client is acting up [19:10] I am getting texts in weird fashion [19:10] what do we conclude? should we announce the unsuccessful application or wait a bit more? [19:11] if bdmurray really gets to it this week I would wait a few more days... [19:11] announce it by the end of the week one way or another? [19:11] thanks I'd appreciate the extra days [19:11] that works for me [19:11] okeydoke, sounds good [19:12] #agreed we'll announce the application status by EOW, whatever the outcome is. [19:12] AGREED: we'll announce the application status by EOW, whatever the outcome is. [19:12] thanks, let's move on [19:13] #topic AOB [19:13] #subtopic Vote on Proposal to change the maximum number of applicants per meeting. [19:13] #link https://lists.ubuntu.com/archives/devel-permissions/2022-September/002030.html [19:13] This thread is nearly three months old now :-( [19:13] bdmurray: you had something to add, no? if so, the stage is yours ;) [19:15] I really don't understand why we end up playing a game of quiz show with applicants for upload rights instead of putting more stock in the endorsements. [19:16] We've had a number of concerning applications recently where many DMB members were clearly concerned that the applicant wasn't ready; yet they had good endorsements. [19:17] That's something that we need to fix, I think, but in the meantime, I think the opinion of the DMB seems to be that they do want to ask these questions, and the answers do quite significantly affect their opinion. [19:18] The DMB is elected; each member decides for themselves what they want to ask (or not ask) during an application meeting. And we can of course share our opinions and influence each other on that. [19:19] But for now, clearly we need more time. Accepting more applicants than we are fitting into a meeting isn't going to help with that. [19:19] Alright, to speed up the voting process is there some way we can signal that we are ready to vote to avoid waiting for one person to have all of their questions answered? [19:19] could we also maybe ask those questions via email before the meeting? [19:20] rather having to sit and wait in front of IRC for ages for each answer, that's just really inefficient [19:20] bdmurray: I'm not sure I follow. How would signaling that you are ready to vote help speed up the voting process if others are still asking questions? [19:20] I guess it wouldn't because we don't know how they are going to vote. [19:20] I end up never asking questions because by the point of the meeting where I could it's the end of the hour or I've been bored enough sitting there waiting for things to happen that I can't be bothered anymore [19:20] seb128: I prefer to ask in realtime, so on IRC. Email-only applications have been discussed before, and I'm opposed to doing it that way because I think a realtime conversation does expose issues not obvious in a (slow) email thread. [19:21] One thing that does frustrate me is how long people in meetings take to respond. It's like they aren't paying attention during a meeting. But there's nothing I can do about that besides not do it myself. [19:21] +1 to that^ [19:21] what rbasak said. [19:21] IMHO, that's what really drags out the meeting times. [19:22] +1, again [19:22] But again, it's not something I can fix, and in the meantime, limiting meetings to one application each is going to make the experience immediately better for applicants. [19:22] I should add that the email vs. IRC application thing has long been a point of contention on the DMB. But that's OK - we're a board and are supposed to have different opinions. [19:23] could we maybe mix? [19:23] let those who want to ask via email earlier ask and then keep a live part? [19:23] I would note that when an application goes to email, it often takes *far, far longer* to reach a resolution anyway. [19:23] or are you concerned that giving thinking time to applicant skew what you want to know? [19:23] Oh, sure. By all means people should feel free to ask questions in an email thread in advance. I have no objection to that. [19:24] I would also recommend DMB members to have their questions prepared before the meeting even if they ask live [19:24] or maybe recommend is the wrong wording, but that would be nice [19:24] But I myself would like to continue asking in the IRC meeting, and I try not to hold things up there. [19:24] it would also help lowering the delays [19:24] Yes - I usually have things ready to copy and paste. [19:25] no objections, either. But certainly, they have time to look up, interact with colleagues or other people to answer something that they might not know (which might or might not be concerning), so there's always that. [19:25] rather than taking 3 min to word questions, copy/paste things prepared [19:25] that's why I prefer IRC, apart from it being quick. [19:25] so it saves time in the back and forth discussion whenever there's one. [19:25] But anyway, I think this is a bit orthogonal to my proposal. Yes, I agree that we should talk about and try to make meetings quicker. [19:25] utkarsh2102, that's also true from an IRC conversation, they could have a collegue in /query or someone sitting with them at the computer [19:26] But the fact is that right now they're not, and a step forward would be to limit the number of applicants further, regardless of what else we might want to do to make meeting times quicker. [19:26] right [19:26] so focussing on your point I'm +1 with limiting to 1 by meeting, manage expectations [19:27] it's not realistic that we do more with the current setup and delays [19:27] I'd like for us to agree on doing that, at least. I don't mean to dismiss other options to make meetings quicker, but I think we need to be talking about those separately. [19:27] ack [19:27] bdmurray: are you ready to vote? [19:27] Yes [19:27] sil2100: you, too? [19:28] Yeah [19:28] #vote on limiting to 1 applicant per meeting [19:28] Please vote on: on limiting to 1 applicant per meeting [19:28] Public votes can be registered by saying +1, -1 or +0 in channel (for private voting, private message me with 'vote +1|-1|+0 #channelname') [19:28] +1 [19:28] +1 received from rbasak [19:28] +1 [19:28] +1 received from bdmurray [19:29] #voters rbasak seb128 bdmurray utkarsh2102 sil2100 [19:29] Current voters: bdmurray, rbasak, seb128, sil2100, utkarsh2102 [19:29] +1 [19:29] +1 received from utkarsh2102 [19:29] +1 [19:29] +1 received from seb128 [19:30] +1 [19:30] +1 received from sil2100 [19:30] #endvote [19:30] Voting ended on: on limiting to 1 applicant per meeting [19:30] Votes for: 5, Votes against: 0, Abstentions: 0 [19:30] Motion carried [19:31] \o/ [19:31] rbasak: will you please announce that and put it in the wiki somewhere? [19:31] ack [19:32] I've updated the wiki already [19:32] #action rbasak to announce the results of this proposal and document this somewhere in the wiki. [19:32] ACTION: rbasak to announce the results of this proposal and document this somewhere in the wiki. [19:32] I think it's sufficient to just reply to the thread? Applicants adding themselves will presumably see the instructions in the wiki already, like they previous did. [19:32] We have some time left. [19:32] yep [19:32] If we'd like to discuss other ways of making meetings quicker? [19:32] nothing in the agenda that I see, at least. Anything else? [19:33] bdmurray: you had a thing you wanted to bring up last week (but I ended the meeting), do you want to bring that up now, maybe? [19:33] I would like to make the meeting less 'sit and wait', unsure if we can find improvements which can be enforced or at least recommendations [19:34] I do have another thing - about us using +0 whilst voting - but I am too tired to bring it up. So maybe next time, unless rbasak wants to bring that up? :) [19:34] Obviously thinking and typing takes time, but I don't understand why people seem to take longer than that to respond. [19:34] seb128: we all can try, by all means - being prepared for the meeting is a start. Do you have more such recommendations? [19:34] *yawns* what've i missed (other than my headache) [19:35] oooh, hi, teward! \o [19:35] I wonder if it would help if people could make it clear that a (slow) response is coming? [19:35] Oh, right I was talking to Paul Sladen at Ubuntu Summit and their coredev lapsed because they lost their single sign on information. In light of our decision regarding Scott Moser I wonder if there is a way for Paul to get their core dev ack. [19:35] Like maybe just "..." or something as a shorthand for that? [19:36] I'm in favour of giving their core dev back as long as there's a reasonable explanation and they're otherwise active in the community (showing up to the Ubuntu Summit counts, IMHO). [19:36] bdmurray: they are already approved till 2023-03-10 [19:36] I wonder if we should also have rules like 'if you take more than 3 minutes to reply something back then there is a problem and you are clearly not available to focus on the meeting and shouldn't delay it by pretending you are' [19:36] what do you mean? :) [19:36] But I think they should email devel-pemissions@ to ask, at least, so there's an easily searchable record of what decisions the DMB is taking and why. [19:36] rbasak: this 100% [19:36] (I know i'm late sorry) [19:37] seb128: we don't really have the ability to sanction each other, as each of us is individually elected. [19:37] utkarsh2102: Oh, I hadn't looked. [19:38] hehe [19:38] It's very similar to the problem we have had with DMB absenteeism in the past. [19:38] I think seb128 meant the candidates [19:38] I don't think the candidates are usually slow, are they? [19:38] either, candidate or DMB members [19:38] https://launchpad.net/~ubuntu-core-dev/+members#active [19:38] not really [19:38] My impression is that it's DMB members who vanish, not the applicants. [19:38] mostly us :/ [19:39] rbasak, we can't really 'sanction' but we can socially encourage people who aren't available to not waste everyone's time and just maybe not ask their question [19:39] bdmurray i assume that Paul has been in contact with SSO support to try and get access back. Unless they're stuck behind 2FA chaos in which case yeah good luck on that one [19:39] not having SSO is something that's a concern as well [19:39] it's easy to do 3 things at the same time and type and move to $other thing for 5 minutes [19:39] (for Launchpad, etc.) [19:39] seb128: especially when still doing $DAYJOB (which is my excuse) [19:40] seb128: sure, we can do that. Maybe we need to give more support to the chair to be able to move the meeting along. [19:40] (mostly because I am still at $dayjob xD) [19:40] but maybe reminding people that it was everyone's else time so nx5 minutes for the board would help them to fix it [19:40] Which in practice means less patience for slow-to-respond DMB members I guess. [19:41] teward[m], we all have good reasons when we are stepping away from the keyboard or the channel usually [19:41] I don't so much mind a DMB member being unavailable for a meeting, or saying that they're struggling to do two things at once. As long as they don't hold up a meeting. [19:41] it doesn't change the fact that's un-nice to everyone's else and that it might be better if people who aren't on capacity to focus on the meeting to not block others [19:42] rbasak, right, same [19:42] As long as we remain quorate, etc. [19:43] :P [19:43] I wonder what we do following this discussion that's actually actionable. [19:44] What if we say that if there's a three minute or longer delay in a DMB member responding, the chair should move on, assuming they're now unavailable? Unless they've excused themselves for a long thought, research, answer or similar. Which they can do just by saying "...". [19:45] That would mean ending a vote after three minutes, for example, even if we're not quorate. [19:45] We'll treat that member as absent from the vote, and do whatever we'd have done had they not been present. [19:45] I would be in favor of that [19:46] That would help set the culture that slow response isn't OK. [19:47] no objections though i would suggest we extend that to 5 minutes, etc. when the vote decision is on an application [19:47] because sometimes it takes a bit for us to get everything put together for long reasons [19:47] IMHO, five minutes is too long for *no* response at all. [19:47] sounds reasonable [19:47] But as I say, if you're going to take five minutes, just say "..." every three :-) [19:47] just for the voting bit, it's OK [19:47] the faster, the better [19:48] Take "..." to mean "I'm still here, working on an answer, extending my timeout by another three minutes, thanks" [19:48] hah, what rbasak said^ :) [19:48] DMB lingo :D [19:49] This would best be documented. I can write something up on the ML I guess. [19:49] thanks! [19:50] nice! \o/ [19:50] rbasak: before documenting, make sure everyone in the DMB is on the same page ;) [19:50] Yeah I'll write a suggestion to the ML first. [19:51] yep, perfect [19:51] anything else? [19:51] rbasak, 👍 [19:51] Nothing from me thanks. [19:52] I'm a bit puzzled by seb128's question though. Were you asking if I had anything else, or something else? [19:52] which question? [19:52] 19:51 rbasak, ? [19:52] oh, that was a thumb-up emoji [19:53] I guess your client doesn't like that [19:53] ? [19:53] Oh. [19:53] confirmed a thumbs up emoji here on matrix [19:53] Sorry, yes. My IRC unicode is broken. I need to fix it! [19:53] :) [19:53] Now you can understand why I was puzzled :-) [19:54] any other topic for the few minutes remaining? [19:54] nice, another minute and 3 minutes would've passed since I asked if there's anything else [19:54] I'm going to assume there's nothing more and I'll wrap up [19:54] did you have more to discuss on Sladen's renewal? [19:54] he's already "active" until March, 2023 :P [19:54] s/he/they/ :) [19:55] ah, right, someone said that :p [19:55] thanks [19:55] bah, s/he's/they're/ [19:55] I think we can wrap there then :) [19:55] \o/ [19:55] awesome! [19:55] #endmeeting [19:55] Meeting ended at 19:55:35 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-11-28-19.05.moin.txt [19:55] utkarsh2102, thanks for chairing again! [19:56] :D [19:56] Thanks utkarsh2102! [19:56] :D [19:57] *returns to the abyss*