| rbasak | o/ | 18:58 |
|---|---|---|
| kanashiro | o/ | 18:59 |
| seb128 | hey | 18:59 |
| teward | *yawns* give me 1 minute to get more coffee | 19:02 |
| teward | #AllTheCaffeineRequired | 19:02 |
| teward | genii: where's my coffee :P #RunningGag | 19:02 |
| bdmurray | o/ | 19:03 |
| rbasak | Could someone volunteer to chair? | 19:05 |
| rbasak | I can do if nobody else is | 19:05 |
| rbasak | #startmeeting Developer Membership Board | 19:05 |
| meetingology | Meeting started at 19:05:41 UTC. The chair is rbasak. Information about MeetBot at https://wiki.ubuntu.com/meetingology | 19:05 |
| meetingology | Available commands: action, commands, idea, info, link, nick | 19:05 |
| rbasak | #topic Review of previous action items | 19:05 |
| rbasak | ddstreet request discussion/voting on ubuntu-support-uploaders continue on ML | 19:05 |
| genii | !coffee | teward | 19:05 |
| ubottu | teward: Here's a topped up mug of delicious coffee at the perfect temperature for sipping, enjoy! | 19:05 |
| seb128 | 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 | |
| rbasak | I posted on the list on this earlier. Any further discussion items people want to raise? | 19:06 |
| ddstreet | oh hi | 19:06 |
| ddstreet | i think i did raise it on the ml | 19:06 |
| rbasak | Has everyone managed to catch up on the ML? | 19:07 |
| seb128 | I did | 19:07 |
| rbasak | 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:07 |
| kanashiro | 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:08 |
| rbasak | Since nobody else answered I assume they haven't had time to catch up? | 19:10 |
| rbasak | So let's move on? | 19:10 |
| seb128 | teward, bdmurray ? | 19:10 |
| teward | *has caffeine* | 19:11 |
| teward | took a while to brew sorry | 19:11 |
| rbasak | #action continue discussion on ubuntu-support-uploaders packageset request on ML | 19:11 |
| meetingology | ACTION: continue discussion on ubuntu-support-uploaders packageset request on ML | 19:11 |
| rbasak | kanashiro: agreed! It's always good to document things we decide on | 19:11 |
| rbasak | 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 |
| rbasak | 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 |
| teward | 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:11 |
| teward | rbasak: carry over | 19:12 |
| rbasak | #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 | 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 |
| teward | and by 'review' i mean on our own not in the meeting necessarily | 19:12 |
| rbasak | 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 |
| teward | *sips the coffee* | 19:12 |
| rbasak | He's not here I think? | 19:12 |
| rbasak | So I'll carry I guess | 19:12 |
| rbasak | #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 | 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 |
| rbasak | sil2100 start discussion on process/rules for when to create packageset vs PPU (carried over) | 19:12 |
| rbasak | 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 |
| rbasak | I don't see any applicatoins | 19:13 |
| rbasak | So | 19:13 |
| rbasak | #topic Outstanding mailing list requests to assign | 19:13 |
| rbasak | I don't see any unanswered requests. | 19:13 |
| rbasak | #info No unanswered requests. | 19:13 |
| rbasak | #topic Open TB bugs | 19:14 |
| rbasak | #info No Open TB bugs | 19:14 |
| rbasak | #topic AOB | 19:14 |
| rbasak | AOB? | 19:14 |
| rbasak | There are lots of ML threads in flight at the moment. | 19:14 |
| teward | yes there are, do any of them need to be discussed here or should they stay on the ML for now? | 19:14 |
| seb128 | right, I would be in favor of using some of the time now to make progress on some discussions we can | 19:15 |
| rbasak | 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 |
| rbasak | Sure | 19:15 |
| rbasak | Where to start? | 19:15 |
| seb128 | do we have a preference to discuss on list rather than on IRC? | 19:15 |
| rbasak | I think IRC is useful to draw things to a conclusion. | 19:15 |
| teward | 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:15 |
| rbasak | For discussion, I don't mind either way, but it's helpful to clear things up in realtime sometimes. | 19:16 |
| seb128 | can we maybe get the private channel topic to a conclusion? | 19:16 |
| rbasak | Sure | 19:16 |
| seb128 | just to pick one | 19:17 |
| rbasak | I wrote up a load of reasons why I think we should keep it. | 19:17 |
| rbasak | So obviously my preference is to keep it. | 19:17 |
| seb128 | I meant to reply but I didn't have time yet | 19:17 |
| rbasak | I'd just ask that people read my opinion to see what they agree and don't agree with. | 19:17 |
| seb128 | 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:17 |
| seb128 | 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 |
| rbasak | Sure. I think the preference should to use public channels where possible. | 19:18 |
| seb128 | and I feel like I'm not going to be able to pick up discussions without some sort of offline logging | 19:18 |
| sil2100 | o/ Sorry for being late everyone | 19:18 |
| seb128 | somewhat a fail due to the fact that ubuntu is stuck on IRC than more modern solution | 19:18 |
| sil2100 | (although I am expired) | 19:18 |
| rbasak | 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:18 |
| rbasak | sil2100: you are reinstated! | 19:19 |
| kanashiro | 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 |
| seb128 | rbasak, you can also drop that not on #ubuntu-meeting ... | 19:19 |
| sil2100 | Oh oh! | 19:19 |
| seb128 | note | 19:19 |
| sil2100 | \o/ | 19:19 |
| rbasak | THere was a Telegram bridge at one point, for people without persistent IRC | 19:19 |
| seb128 | 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:19 |
| seb128 | so I would prefer for us to use a solution that doesn't exclude me (or others) | 19:20 |
| seb128 | the mailing list is fine for me | 19:20 |
| rbasak | I don't remember it being used much outside the context and around the time of a specific IRC meeting. | 19:20 |
| seb128 | I think it's fine having a place where we can join for a private discussion if needed | 19:21 |
| kanashiro | I have not seen any important information flying there | 19:21 |
| seb128 | 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:21 |
| rbasak | 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 |
| seb128 | I would be fine for that | 19:22 |
| seb128 | around our meeting or in case of 'call for a discussion' | 19:22 |
| seb128 | like you would create an hangout and ask people to join | 19:22 |
| seb128 | but the text based equivalent | 19:22 |
| rbasak | Thanks. I think that fits our previous usage of it anyway, so there shouldn't be much impact in specifying that. | 19:22 |
| rbasak | Any other comments from anyone? Is that decided then? | 19:23 |
| kanashiro | sounds good | 19:23 |
| seb128 | sil2100, bdmurray, teward, ddstreet ^ | 19:23 |
| rbasak | Since it's IRC it might be worth putting that into the channel topic. | 19:23 |
| teward | we all know ddstreet's opinion - which is to get rid of it. | 19:24 |
| seb128 | sil2100, bdmurray, teward, ^ :p | 19:24 |
| teward | 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 |
| ddstreet | well teward you probably shouldn't speak for me :) | 19:24 |
| bdmurray | I can see how it would be convenient | 19:24 |
| sil2100 | I don't have a strong opinion, so I would be +1 on that | 19:24 |
| rbasak | "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 |
| seb128 | +1 from me | 19:25 |
| rbasak | ^ is that agreed then? Anything I missed or should amend? | 19:25 |
| kanashiro | +1 | 19:25 |
| teward | 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 |
| seb128 | I'm going to not autojoin to avoid having people defaulting to the channel | 19:26 |
| teward | +1 as rbasak says | 19:26 |
| bdmurray | I don't even know / remember what the channel name is | 19:26 |
| rbasak | 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 |
| teward | bdmurray: #ubuntu-dmb | 19:26 |
| seb128 | like I will join like I would join an hangout if someone pings me to discuss a topic | 19:26 |
| sil2100 | +1 | 19:27 |
| rbasak | It tends to happen in a middle of a meeting when an application interview isn't going well. | 19:27 |
| seb128 | do we need a formal vote? | 19:27 |
| rbasak | At that time, it's really helpful for everyone to be there already rather than having to ping around first. | 19:27 |
| rbasak | But it's up to everyone individually what they want to do about that of course. | 19:27 |
| seb128 | k, let's not discuss those details | 19:27 |
| rbasak | I see no need for a formal vote. There seems to be enough agreement. | 19:27 |
| seb128 | k | 19:28 |
| rbasak | #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 |
| meetingology | 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 |
| rbasak | We have time to discuss another topic if you'd like? | 19:28 |
| seb128 | can we make also progress on the sosreport case? | 19:28 |
| rbasak | Sure! | 19:28 |
| kanashiro | rbasak, will you set the channel topic with the message you mentioned? | 19:28 |
| seb128 | what you wrote is sort of what I was trying to get as an answer by my previous questions | 19:28 |
| teward | I have a question on this case | 19:29 |
| rbasak | Can I delegate the setting of the channel topic to teward please? | 19:29 |
| seb128 | I think the '1 member = ppu, next request -> packageset' makes sense as a rule | 19:29 |
| teward | #chairs rbasak teward | 19:29 |
| teward | !chair rbasak teward | 19:29 |
| teward | ffs i hate the bot sometimes | 19:29 |
| teward | #chair rbasak teward | 19:29 |
| meetingology | Current chairs: rbasak, teward | 19:29 |
| rbasak | I think it's more than one member AND more than one package | 19:30 |
| teward | #topic sosreport delegated package set | 19:30 |
| teward | is the bot dead today? | 19:30 |
| rbasak | Many people individually having PPU to sosreport wouldn't necessitate it being a packageset. | 19:30 |
| teward | here's my question on sosreport | 19:30 |
| teward | how widely a group really needs upload privs on sosreport? | 19:30 |
| teward | 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 |
| ddstreet | are you asking me? | 19:31 |
| teward | it's a general question | 19:31 |
| teward | i'm asking 'nobody in particular' | 19:31 |
| teward | Currentlyl from what I can tell, from an ACL perspective, you ddstreet are the only person who would be in the group | 19:31 |
| rbasak | 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:31 |
| teward | but you're already coredev so it does nothing | 19:32 |
| teward | 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 |
| teward | as well as the full scope of what packages would be in this | 19:32 |
| teward | (right now, I don't see enough criterion personally to support creating a delegated group for one package) | 19:32 |
| seb128 | I asked that question in the previous meeting, my understand was that ddstreet expect his team members to join this group | 19:32 |
| seb128 | understanding | 19:32 |
| ddstreet | yes that's right | 19:33 |
| ddstreet | i'm actually trying to offload this application to team-mate(s) | 19:33 |
| ddstreet | but it's been slow to find 'volunteers' | 19:33 |
| teward | define "team mates" | 19:33 |
| seb128 | I think it would have helped to join a list of people who would be interested today to the request | 19:33 |
| seb128 | make it more concrete | 19:33 |
| teward | even if they work at Canonical they need a greater understanding of the processes, etc. that ascribe to packages | 19:33 |
| ddstreet | teward i'm on the Canonical Sustaining Engineering team | 19:33 |
| teward | that's applicable to *everyone* at Canonical | 19:33 |
| teward | Canonical employment does not mean you get rights to upload | 19:33 |
| ddstreet | i don't recall saying it did? | 19:34 |
| seb128 | teward, I don't think that was implied there | 19:34 |
| teward | seb128: it's a general observation that i'm stating that some people think it does | 19:34 |
| seb128 | rather than his team has a bunch of members who do that on a daily basis | 19:34 |
| teward | i would rather see the extent of the team first | 19:34 |
| seb128 | and probably have the skills to request to join | 19:34 |
| teward | ^^ correct | 19:34 |
| ddstreet | 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 |
| ddstreet | but for sure not everyone on the team will apply | 19:35 |
| seb128 | 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 |
| teward | ^^ | 19:35 |
| teward | ddstreet: until i see the full extent of the people, -1 from me on the request. Furhter, the scope needs better define | 19:35 |
| teward | to quote robie: | 19:35 |
| ddstreet | as i said, i'm trying to hand this off to people who *would* benefit from being on the team (or have PPU) | 19:35 |
| teward | > Separately, a description of "packages used for debugging and supporting Ubuntu" would seem to include gdb for example. | 19:36 |
| ddstreet | teward keep in mind that every person joining the team would need to apply | 19:36 |
| teward | the scope needs to be better defined because gdb and a ton of other packages would be in this set | 19:36 |
| teward | and i'd rather not have any non-coredevs mess with gdb because that can break other things. | 19:36 |
| teward | delegated set or not | 19:36 |
| ddstreet | to be clear, this isn't asking for anything besides sosreport right now | 19:36 |
| rbasak | 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:36 |
| teward | +1 for rbasak's statement | 19:37 |
| ddstreet | 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 |
| ddstreet | the result here really makes no difference to me :-) | 19:37 |
| bdmurray | which "this" is being handed off? | 19:38 |
| ddstreet | the team/packageset application we're discussing | 19:38 |
| rbasak | 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 |
| ddstreet | or ppu | 19:38 |
| kanashiro | 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 |
| ddstreet | currently, i am the *only* person in my team who can upload sosreport to devel releases | 19:38 |
| teward | i'd say this should be PPU for now rather than a packageset | 19:38 |
| teward | if it's only one package, it doesn't warrant a packageset | 19:38 |
| ddstreet | so as long as i'm still on the team, there is no blockage | 19:39 |
| teward | regardless of number of individuals who need to upload for now, until the wider 'do we need other packages?" question is answered | 19:39 |
| ddstreet | 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:39 |
| kanashiro | yes, that's the point, if the rules were defined we wouldn't be discussing that :) | 19:40 |
| ddstreet | this discussion might be overthinking things :) | 19:40 |
| ddstreet | indeed | 19:40 |
| rbasak | 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:40 |
| ddstreet | sorry i mean, i don't care about the outcome as in, i'm fine with whatever decision is made | 19:41 |
| ddstreet | i don't mean that i don't care about it at all | 19:41 |
| bdmurray | I think there is an opportunity to define when package sets should be used. | 19:41 |
| ddstreet | if the decision is for individuals to reapply for PPU, that's fine | 19:41 |
| seb128 | rbasak, I would like for us to define those rules if we can | 19:41 |
| ddstreet | if the decision is to create a pkgset/team, that's fine too | 19:41 |
| seb128 | so we don't get the same unclear situation again next time | 19:42 |
| rbasak | 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 |
| rbasak | Exceptions can exist at any time of course. | 19:42 |
| teward | two or more related packages* | 19:42 |
| kanashiro | +1 | 19:42 |
| kanashiro | we need a minimum to justify the admin work to create the packageset | 19:43 |
| seb128 | +1 | 19:44 |
| sil2100 | +1 | 19:44 |
| bdmurray | +1 | 19:44 |
| sil2100 | Sounds like a reasonable compromise | 19:44 |
| ddstreet | i'm not sure i should even be voting so i'll +0 if that helps :) | 19:44 |
| rbasak | #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 |
| meetingology | 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 |
| rbasak | Does someone fancy taking the task to update the documentation on this please? | 19:45 |
| kanashiro | rbasak, I can do that | 19:45 |
| rbasak | I think this needs cleaning up between https://wiki.ubuntu.com/UbuntuDevelopers/TeamDelegation and https://wiki.ubuntu.com/DeveloperMembershipBoard/KnowledgeBase#Packagesets | 19:45 |
| rbasak | Thanks! | 19:45 |
| rbasak | #action kanashiro to update our wiki documentation with respect to our agreed packageset creation criteria | 19:46 |
| meetingology | ACTION: kanashiro to update our wiki documentation with respect to our agreed packageset creation criteria | 19:46 |
| rbasak | Any other discussion on this topic? | 19:47 |
| seb128 | not from me | 19:47 |
| rbasak | Would anyone like to raise any other topics while we still have a few minutes left? | 19:47 |
| seb128 | not me | 19:47 |
| sil2100 | None from me | 19:48 |
| rbasak | Any other AOB? | 19:48 |
| bdmurray | What bout the election? | 19:48 |
| rbasak | I'll start arranging that tomorrow. | 19:48 |
| rbasak | But that does remind me (thanks) | 19:48 |
| rbasak | I did have one thing for the DMB in general. | 19:48 |
| rbasak | 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 |
| rbasak | The call for nominations has these two sentences: | 19:49 |
| rbasak | Candidates must expect to be able to attend the majority of DMB | 19:49 |
| rbasak | meetings. Currently these take place on IRC, are scheduled on alternate | 19:49 |
| rbasak | Mondays with each meeting alternating between 1500 UTC and 1900 UTC, and | 19:49 |
| rbasak | last around an hour. | 19:49 |
| rbasak | ddstreet sounded unhappy about the wording here. | 19:49 |
| ddstreet | i'd prefer the majority of the DMB business to happen on the ML, but that's just my opinion | 19:50 |
| rbasak | 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 |
| bdmurray | I seem to recall one candidate who wasn't going to run because those times weren't great for them. | 19:50 |
| ddstreet | i think the DMB relies too heavily on IRC meetings and lets ML threads die | 19:50 |
| rbasak | 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:50 |
| seb128 | bdmurray, that was me :p | 19:51 |
| rbasak | 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 |
| seb128 | I got convinced people rbasak said we would renegociate the times after election if needed | 19:51 |
| seb128 | but I've a feeling that often people are missing on IRC or busy with other things and not responsive | 19:51 |
| rbasak | For now, I just want to know what to put in my call for nominations to run this immediate election | 19:51 |
| bdmurray | seb128: I knew that | 19:51 |
| rbasak | ...that everyone will be happy with. | 19:51 |
| seb128 | so I do think using more the mailing list might be a positive thing | 19:51 |
| rbasak | IMHO, right now we still need good attendence at the IRC meetings, as we haven't agreed alternative arrangements. | 19:52 |
| seb128 | 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 |
| rbasak | 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 |
| kanashiro | I agree with using more the mailing list but for applications review I'd still prefer the IRC meetings | 19:53 |
| bdmurray | I think you could be more explicit about the times being changeable. | 19:53 |
| seb128 | rbasak, as a non native speaker it didn't reflect that to me | 19:53 |
| rbasak | 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 |
| rbasak | Suggestions appreciated. | 19:54 |
| rbasak | But we need consensus for me to change the wording really. Otherwise I'll just be torn in different directions. | 19:54 |
| seb128 | 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 |
| seb128 | just to clarify that it is an option | 19:55 |
| rbasak | Sure, I can do that. | 19:55 |
| ddstreet | 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:55 |
| rbasak | 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 |
| bdmurray | +1 for renegotiation. | 19:56 |
| ddstreet | personally i think each member should decide how they are best effective | 19:57 |
| rbasak | If everybody started to do that, then application interviews would stop taking place. | 19:57 |
| ddstreet | i don't see that as a problem | 19:57 |
| rbasak | Before we accept ML-only participation, I think we need to agree to change the application process. | 19:57 |
| ddstreet | but i also don't see continuing to hold irc interviews as a problem for members who prefer that | 19:57 |
| rbasak | (and FWIW I prefer realtime application interviews and I don't think we should change that) | 19:58 |
| ddstreet | you can have both, of course | 19:58 |
| kanashiro | +1 for real time interviews | 19:58 |
| rbasak | 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:58 |
| rbasak | 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 |
| rbasak | (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 |
| rbasak | Also we're out of time now. | 19:59 |
| rbasak | Thank you for the discussion. I'll proceed as seb128 suggested then. | 19:59 |
| rbasak | Any other comments? | 19:59 |
| teward | -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 |
| seb128 | not from me | 20:00 |
| teward | my own statement because there's more than just an 'email' lets you answer. | 20:00 |
| teward | nothing more from me. | 20:00 |
| kanashiro | no, thanks for driving the election rbasak | 20:00 |
| ddstreet | teward that isn't my opinion at all | 20:00 |
| teward | thanks rbasak for driving | 20:00 |
| rbasak | Thanks all! | 20:00 |
| rbasak | #endmeeting | 20:00 |
| meetingology | Meeting ended at 20:00:40 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-05-16-19.05.moin.txt | 20:00 |
| teward | > i think the DMB relies too heavily on IRC meetings and lets ML threads die | 20:00 |
| teward | you weren't specific enoug then ddstreet :P | 20:00 |
| ddstreet | teward wow you have some serious animosity toward me dont you? | 20:01 |
| ddstreet | bye all o/ | 20:01 |
| teward | no, i have animosity towards unclear definitions | 20:01 |
| teward | and unclear statements | 20:01 |
| * kanashiro waves | 20:02 | |
| * teward also needs a nap, he's been up since 4AM | 20:05 | |
| seb128 | thanks! | 20:06 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!