== Meeting information == * #ubuntu-meeting: Ubuntu Technical Board meeting, started by amurray, 11 Jul at 19:01 — 19:45 UTC. * Full logs at https://ubottu.com/meetingology/logs/ubuntu-meeting/2023/ubuntu-meeting.2023-07-11-19.01.log.html == Meeting summary == === Apologies === Discussion started by amurray at 19:01. === Action review === Discussion started by amurray at 19:02. * ''ACTION:'' seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage (amurray, 19:04) * ''ACTION:'' rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification (amurray, 19:04) * ''ACTION:'' rbasak to follow up on finding consensus on question of test plans for third party apps (amurray, 19:04) * ''ACTION:'' rbasak to restructure the third-party repo doc to make the status clearer (amurray, 19:05) * ''ACTION:'' rbasak to open wider discussion on third-party repo policy (amurray, 19:05) === Scan the mailing list archive for anything we missed (standing item) === Discussion started by amurray at 19:06. * ''AGREED:'' SRU, AA, Release, Backporters and Security teams to have a documented membership process which is to be linked to from https://wiki.ubuntu.com/TechnicalBoard#Team_Delegations (amurray, 19:39) * ''ACTION:'' seb128 to follow up with SRU, AA, Release, Backporters and Security teams to document their membership process and link to it from https://wiki.ubuntu.com/TechnicalBoard#Team_Delegations (amurray, 19:39) === Scan the mailing list archive for anything we missed (standing item) === Discussion started by amurray at 19:40. * ''LINK:'' https://lists.ubuntu.com/archives/technical-board/2023-July/thread.html (amurray, 19:40) === Check up on community bugs and techboard bugs === Discussion started by amurray at 19:41. * ''LINK:'' https://bugs.launchpad.net/ubuntu-community/+bugs?field.assignee=techboard (amurray, 19:41) * ''LINK:'' https://bugs.launchpad.net/techboard (amurray, 19:41) === Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members) === Discussion started by amurray at 19:41. * ''AGREED:'' next meeting chair: rbasak, backup: vorlon (amurray, 19:43) === AOB === Discussion started by amurray at 19:43. == Action items, by person == * amurray * seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage * rbasak * rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification * rbasak to follow up on finding consensus on question of test plans for third party apps * rbasak to restructure the third-party repo doc to make the status clearer * rbasak to open wider discussion on third-party repo policy * seb128 * seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage * seb128 to follow up with SRU, AA, Release, Backporters and Security teams to document their membership process and link to it from https://wiki.ubuntu.com/TechnicalBoard#Team_Delegations == People present (lines said) == * seb128 (60) * amurray (56) * rbasak (49) * meetingology (19) == Full log == 19:01 #startmeeting Ubuntu Technical Board 19:01 Meeting started at 19:01:22 UTC. The chair is amurray. Information about MeetBot at https://wiki.ubuntu.com/meetingology 19:01 Available commands: action, commands, idea, info, link, nick 19:01 #topic Apologies 19:02 sil2100 and vorlon are both noted as absent 19:02 #topic Action review 19:02 * amurray rbasak to get agreed backporter charter https://lists.ubuntu.com/archives/technical-board/2023-June/002740.html documented under https://wiki.ubuntu.com/TechnicalBoard/ 19:03 Done 19:03 yep - thanks for emailing the backporters team too rbasak 19:03 My other items need carrying over please - no progress so far 19:03 ok - will do 19:03 * amurray seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage 19:03 sadly I have not made any progress here 19:04 #action seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage 19:04 * meetingology seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage 19:04 carrying over rbasak's items 19:04 #action rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification 19:04 * meetingology rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification 19:04 #action rbasak to follow up on finding consensus on question of test plans for third party apps 19:04 * meetingology rbasak to follow up on finding consensus on question of test plans for third party apps 19:05 #action rbasak to restructure the third-party repo doc to make the status clearer 19:05 * meetingology rbasak to restructure the third-party repo doc to make the status clearer 19:05 #action rbasak to open wider discussion on third-party repo policy 19:05 * meetingology rbasak to open wider discussion on third-party repo policy 19:05 as noted earlier sil2100 is absent so will carry over his item too 19:05 #action sil2100 to follow up on the Key Ubuntu teams discussion 19:05 * meetingology sil2100 to follow up on the Key Ubuntu teams discussion 19:05 he did 19:06 not that the reply was adressing my concerns 19:06 oh indeed - yes I do recall I saw that earlier 19:06 #undo 19:06 Removing item from minutes: ACTION 19:06 but most members seem to just want to ignore that specific concern so I guess that's how it is 19:06 #topic Scan the mailing list archive for anything we missed (standing item) 19:06 still frustrating 19:07 seb128: to be clear, what exactly do you think has not been addressed? 19:08 sorry seb128 I seem to be steam rolling along with the meeting - apologies - is it helpful to try discuss this further now? 19:09 rbasak, I still feel like that despite what teams might think or their staffing it is demotivating for contributors to not be able to ask the question and get the answer 19:09 I mentioned my experience for SRU and release 19:10 I still don't know today if my intend to join was clear to the team, if I've been considered and what was the issue 19:10 it sucks as a project member experience 19:10 I wish others wouldn't have to end up in the same cases 19:10 my intend to join was clear to the team> which team? SRU team? 19:11 anyone should be able to make their intend clear and to get an reply 19:11 rbasak, SRU and release, did you read my most recent email? 19:11 to quote the email 19:11 > I had a similar experience with the SRU team a few years ago. At a time where I felt like the team was struggling with reviews and that we making them busy with desktop review I asked if it would help if I was joining to review non desktop upload (and free some time from other reviews to help getting our desktop items reviewed). I remember discussing it in person at a Canonical event with Lukasz in Frankfurt in 2020 who said that it 19:11 sounded like worth considering, I was never able to get an answer about that one either. 19:11 For the SRU team, an answer was supposed to have been relayed to you. 19:12 it was not 19:12 which is part of my point, if there is no (open) process then we have no record and we end up in such situations 19:12 I'd be happy to go into that with you, but perhaps doing that in public isn't appropriate? 19:12 my point isn't about my application 19:13 My position is that this kind of discussion must be private as to judge people in public is usually not appropriate. 19:13 is about the ability for someone to be able to ask a question and to follow the status 19:13 well, a private record would wfm 19:13 but afaik there is no private records in those teams 19:14 like is there a place you could go to check about the status of my request? 19:14 Your request to join the SRU team was a while ago. 19:14 I listed a bunch of similar cases for archive admin and release 19:14 But more recently, I've been trying to assess candidates in (private) documents, so they exist now. 19:14 again I don't think my case is what we want to discuss 19:14 Although who should have access is unclear. 19:14 it's just an example I've visibility on 19:15 k, that's good to hear 19:15 maybe you should reply that on the list 19:15 I think an issue here is that we simply don't agree on what is appropriate. I've said in the TB thread that I don't think a team necessarily must have a process for candidates to apply. 19:15 and we should encourage other core teams to do the same 19:15 IMHO, it's OK for the SRU and release teams to be teams that do not have a process to apply. 19:16 So it's not that I've not addressed your concern - we just disagree (which is fine). 19:16 I'm ok with not having a process, even if I think those teams should 19:16 but I do think that if someone wants to step up there should be a process that own them a reply 19:17 it just hurts being ignored and we just risk loosing those contributors 19:17 -just 19:18 In my view, the reply for some of these teams could be "the team's process to add new members is ". That's not really a reply of course, but the natural consequence of my view as above. 19:18 I personally considered leaving the project because I think that's just not how a welcome community should behave 19:19 ok, so let's agree to disagree 19:19 how do we come to a conclusion 19:19 is that something we can vote on? 19:19 risk losing contributors> IMHO, that's really not a problem for my view of the tasks that the SRU, release team and AAs perform. They are IMHO decision making teams. These are contributions, but a rather special kind. 19:19 If the teams cannot perform their duties, then it may be that they need more members. 19:19 sure you can feel because I'm not worth joining those team I'm worthless to Ubuntu 19:20 But if that's not the case, it's not necessarily appropriate to grow the teams, and therefore there's no loss of potential contributors if people cannot join them. 19:20 it's not only about those teams staffing though 19:20 it's also about making contributors feel valued and treated with respect 19:20 trying to step up to help and being ignored isn't a great feeling 19:20 We do need to make sure that everyone feels valued and treated with respect, as much as is reasonable. 19:21 But at the same time, I think it's perfectly fine for a team to not have any positions open. That doesn't diminish the value provided by contributors not on those teams. 19:22 I'm not arguing against being accept or not 19:22 fwiw I don't think it is unreasonable that for each of the teams there should be some documented process about how new members get added - at least something to lay out expectations to others - and that they have a duty to follow up on enquiries from outsiders 19:22 just that people should be able to hear back on whether someone is on the receiving end and about what they can expect 19:22 > and that they have a duty to follow up on enquiries from outsiders 19:23 ^ that's the point I'm trying to make 19:23 that's not the case today 19:23 I agree with teams having a documented process. But if the process is "we will invite and assess new member candidates using process ", then the only reasonable response to a member asking to apply is to be pointed to that documentation. 19:23 That would just be a stock answer. 19:24 well at least that would provide something a bit more formal than what there is today 19:24 Sure. I have no objection to doing that. 19:24 I posted the SRU team's draft process in the ML thread already. 19:24 well if the candidate follows process , what's next 19:25 seb128: if the team's process doesn't involve candidates applying, then there's no process for them to follow. There would be nothing next. 19:26 seb128: you seem to want all teams to have an application process. I think that's a point upon which we disagree. 19:26 alright 19:26 so how do we come to a conclusion 19:26 do we call a vote from the TB members? 19:26 I think we're all agreed that these teams should document a process. 19:26 yep 19:26 So maybe would make some progress by focusing on that? 19:27 that would be a first step 19:27 As the TB, we could ask the teams to produce that documentation. 19:27 We need a list of teams for a start. 19:27 I think SRU, release, AA, backporters to start with? For DMB, it's already an election run by the TB (although usually delegated). 19:27 do we have a list of teams that got delegation powers from the TB? 19:28 Are there any other relevant teams here? 19:28 For upload access the DMB already has process. 19:28 And there are various other teams that just have open membership that probably don't need to be within the scope of this, eg. ~ubuntu-server. 19:29 the main ones imho are release/archive-admin/SRU 19:29 I can't think of any other decision-making teams in Ubuntu right now, except for the various uploading teams whose membership is managed by the DMB. 19:30 Oh, ~ubuntu-security 19:30 CC? but that has a documented election process 19:31 Yes, but that's out of the scope of the TB 19:31 (along with all other community teams directly managed by the CC) 19:31 heh yep ~ubuntu-security - which is essentially ~canonical-security, ie. you have to be a canonical employee of the ubuntu security team 19:32 amurray: that is generally the case but it is not a requirement. The CoC requires that anybody can join that team. 19:32 indeed, I was just stating the current status quo for the team 19:33 OK. But that means that it's within scope for this discussion I think - it's reasonable for ~ubuntu-security to also have a documented process. 19:33 (and that process cannot be Canonical-only, even if it is in practice) 19:33 fair poitn 19:33 +1 19:33 point 19:34 OK, so how about we start there? I started the section at https://wiki.ubuntu.com/TechnicalBoard#Team_Delegations earlier. 19:35 seb128: how about we look to link to a documented membership process for each of the teams mentioned above into there? 19:35 If the TB today agrees to do that, could seb128 drive that perhaps, asking each team to provide that documentation? 19:35 sounds like a good first step 19:36 I can do that yes 19:36 +1 19:36 For the SRU team, I can proposed what I already have drafted to the SRU team as an initial answer. It can of course be developed over time. 19:36 Perhaps that will help the other teams as well. 19:36 ack 19:36 thanks rbasak I think that would be quite helpful 19:37 #agreed SRU, AA, Release and Security teams to have a documented membership process which is to be linked to from https://wiki.ubuntu.com/TechnicalBoard#Team_Delegations 19:37 AGREED: SRU, AA, Release and Security teams to have a documented membership process which is to be linked to from https://wiki.ubuntu.com/TechnicalBoard#Team_Delegations 19:38 #action seb128 to follow up with SRU, AA, Release and Security teams to document their membership process and link to it from https://wiki.ubuntu.com/TechnicalBoard#Team_Delegations 19:38 * meetingology seb128 to follow up with SRU, AA, Release and Security teams to document their membership process and link to it from https://wiki.ubuntu.com/TechnicalBoard#Team_Delegations 19:38 Also Backporters I think please? Not to single them out, but they're part of the complete list I think. 19:38 argh right 19:38 Because they are in charge of -backports just as security is of -security and SRU is of -updates. 19:38 #undo 19:38 Removing item from minutes: ACTION 19:39 #undo 19:39 Removing item from minutes: AGREED 19:39 #agreed SRU, AA, Release, Backporters and Security teams to have a documented membership process which is to be linked to from https://wiki.ubuntu.com/TechnicalBoard#Team_Delegations 19:39 AGREED: SRU, AA, Release, Backporters and Security teams to have a documented membership process which is to be linked to from https://wiki.ubuntu.com/TechnicalBoard#Team_Delegations 19:39 #action seb128 to follow up with SRU, AA, Release, Backporters and Security teams to document their membership process and link to it from https://wiki.ubuntu.com/TechnicalBoard#Team_Delegations 19:39 * meetingology seb128 to follow up with SRU, AA, Release, Backporters and Security teams to document their membership process and link to it from https://wiki.ubuntu.com/TechnicalBoard#Team_Delegations 19:40 #topic Scan the mailing list archive for anything we missed (standing item) 19:40 #link https://lists.ubuntu.com/archives/technical-board/2023-July/thread.html 19:40 nothing new 19:41 #topic Check up on community bugs and techboard bugs 19:41 #link https://bugs.launchpad.net/ubuntu-community/+bugs?field.assignee=techboard 19:41 #link https://bugs.launchpad.net/techboard 19:41 nothing new here either from what I can see 19:41 #topic Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members) 19:42 #agreed next meeting chair: rbasak, backup: seb128 19:42 AGREED: next meeting chair: rbasak, backup: seb128 19:42 #topic AOB 19:42 ack,thanks 19:42 I will not be there of the next meeting (holidays) 19:42 for 19:43 unsure if we should update the backup already to reflect that? 19:43 ah ok - should I put down vorlon then as backup? 19:43 +1 19:43 #undo 19:43 Removing item from minutes: TOPIC 19:43 #undo 19:43 Removing item from minutes: AGREED 19:43 #agreed next meeting chair: rbasak, backup: vorlon 19:43 AGREED: next meeting chair: rbasak, backup: vorlon 19:43 #topic AOB 19:43 thanks 19:44 no AOB from me 19:44 nothing from me either 19:45 ok I think that is about it then 19:45 #endmeeting Generated by MeetBot 0.4.0 (https://wiki.ubuntu.com/meetingology)