19:01 <amurray> #startmeeting Ubuntu Technical Board
19:01 <meetingology> Meeting started at 19:01:22 UTC.  The chair is amurray.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
19:01 <meetingology> Available commands: action, commands, idea, info, link, nick
19:01 <amurray> #topic Apologies
19:02 <amurray> sil2100 and vorlon are both noted as absent
19:02 <amurray> #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 <rbasak> Done
19:03 <amurray> yep - thanks for emailing the backporters team too rbasak
19:03 <rbasak> My other items need carrying over please - no progress so far
19:03 <amurray> ok - will do
19:03 * amurray seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage
19:03 <amurray> sadly I have not made any progress here
19:04 <amurray> #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 <amurray> carrying over rbasak's items
19:04 <amurray> #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 <amurray> #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 <amurray> #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 <amurray> #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 <amurray> as noted earlier sil2100 is absent so will carry over his item too
19:05 <amurray> #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 <seb128> he did
19:06 <seb128> not that the reply was adressing my concerns
19:06 <amurray> oh indeed - yes I do recall I saw that earlier
19:06 <amurray> #undo
19:06 <meetingology> Removing item from minutes: ACTION
19:06 <seb128> but most members seem to just want to ignore that specific concern so I guess that's how it is
19:06 <amurray> #topic Scan the mailing list archive for anything we missed (standing item)
19:06 <seb128> still frustrating
19:07 <rbasak> seb128: to be clear, what exactly do you think has not been addressed?
19:08 <amurray> sorry seb128 I seem to be steam rolling along with the meeting - apologies - is it helpful to try discuss this further now?
19:09 <seb128> 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 <seb128> I mentioned my experience for SRU and release
19:10 <seb128> 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 <seb128> it sucks as a project member experience
19:10 <seb128> I wish others wouldn't have to end up in the same cases
19:10 <rbasak> my intend to join was clear to the team> which team? SRU team?
19:11 <seb128> anyone should be able to make their intend clear and to get an reply
19:11 <seb128> rbasak, SRU and release, did you read my most recent email?
19:11 <seb128> to quote the email
19:11 <seb128> > 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 <seb128> sounded like worth considering, I was never able to get an answer about that one either.
19:11 <rbasak> For the SRU team, an answer was supposed to have been relayed to you.
19:12 <seb128> it was not
19:12 <seb128> 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 <rbasak> I'd be happy to go into that with you, but perhaps doing that in public isn't appropriate?
19:12 <seb128> my point isn't about my application
19:13 <rbasak> My position is that this kind of discussion must be private as to judge people in public is usually not appropriate.
19:13 <seb128> is about the ability for someone to be able to ask a question and to follow the status
19:13 <seb128> well, a private record would wfm
19:13 <seb128> but afaik there is no private records in those teams
19:14 <seb128> like is there a place you could go to check about the status of my request?
19:14 <rbasak> Your request to join the SRU team was a while ago.
19:14 <seb128> I listed a bunch of similar cases for archive admin and release
19:14 <rbasak> But more recently, I've been trying to assess candidates in (private) documents, so they exist now.
19:14 <seb128> again I don't think my case is what we want to discuss
19:14 <rbasak> Although who should have access is unclear.
19:14 <seb128> it's just an example I've visibility on
19:15 <seb128> k, that's good to hear
19:15 <seb128> maybe you should reply that on the list
19:15 <rbasak> 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 <seb128> and we should encourage other core teams to do the same
19:15 <rbasak> IMHO, it's OK for the SRU and release teams to be teams that do not have a process to apply.
19:16 <rbasak> So it's not that I've not addressed your concern - we just disagree (which is fine).
19:16 <seb128> I'm ok with not having a process, even if I think those teams should
19:16 <seb128> but I do think that if someone wants to step up there should be a process that own them a reply
19:17 <seb128> it just hurts being ignored and we just risk loosing those contributors
19:17 <seb128> -just
19:18 <rbasak> In my view, the reply for some of these teams could be "the team's process to add new members is <whatever>". That's not really a reply of course, but the natural consequence of my view as above.
19:18 <seb128> I personally considered leaving the project because I think that's just not how a welcome community should behave
19:19 <seb128> ok, so let's agree to disagree
19:19 <seb128> how do we come to a conclusion
19:19 <seb128> is that something we can vote on?
19:19 <rbasak> 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 <rbasak> If the teams cannot perform their duties, then it may be that they need more members.
19:19 <seb128> sure you can feel because I'm not worth joining those team I'm worthless to Ubuntu
19:20 <rbasak> 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 <seb128> it's not only about those teams staffing though
19:20 <seb128> it's also about making contributors feel valued and treated with respect
19:20 <seb128> trying to step up to help and being ignored isn't a great feeling
19:20 <rbasak> We do need to make sure that everyone feels valued and treated with respect, as much as is reasonable.
19:21 <rbasak> 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 <seb128> I'm not arguing against being accept or not
19:22 <amurray> 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 <seb128> 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 <seb128> > and that they have a duty to follow up on enquiries from outsiders
19:23 <seb128> ^ that's the point I'm trying to make
19:23 <seb128> that's not the case today
19:23 <rbasak> I agree with teams having a documented process. But if the process is "we will invite and assess new member candidates using process <whatever>", then the only reasonable response to a member asking to apply is to be pointed to that documentation.
19:23 <rbasak> That would just be a stock answer.
19:24 <amurray> well at least that would provide something a bit more formal than what there is today
19:24 <rbasak> Sure. I have no objection to doing that.
19:24 <rbasak> I posted the SRU team's draft process in the ML thread already.
19:24 <seb128> well if the candidate follows process <whatever>, what's next
19:25 <rbasak> 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 <rbasak> seb128: you seem to want all teams to have an application process. I think that's a point upon which we disagree.
19:26 <seb128> alright
19:26 <seb128> so how do we come to a conclusion
19:26 <seb128> do we call a vote from the TB members?
19:26 <rbasak> I think we're all agreed that these teams should document a process.
19:26 <amurray> yep
19:26 <rbasak> So maybe would make some progress by focusing on that?
19:27 <seb128> that would be a first step
19:27 <rbasak> As the TB, we could ask the teams to produce that documentation.
19:27 <rbasak> We need a list of teams for a start.
19:27 <rbasak> 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 <seb128> do we have a list of teams that got delegation powers from the TB?
19:28 <rbasak> Are there any other relevant teams here?
19:28 <rbasak> For upload access the DMB already has process.
19:28 <rbasak> 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 <seb128> the main ones imho are release/archive-admin/SRU
19:29 <rbasak> 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 <rbasak> Oh, ~ubuntu-security
19:30 <amurray> CC? but that has a documented election process
19:31 <rbasak> Yes, but that's out of the scope of the TB
19:31 <rbasak> (along with all other community teams directly managed by the CC)
19:31 <amurray> heh yep ~ubuntu-security - which is essentially ~canonical-security, ie. you have to be a canonical employee of the ubuntu security team
19:32 <rbasak> amurray: that is generally the case but it is not a requirement. The CoC requires that anybody can join that team.
19:32 <amurray> indeed, I was just stating the current status quo for the team
19:33 <rbasak> 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 <rbasak> (and that process cannot be Canonical-only, even if it is in practice)
19:33 <amurray> fair poitn
19:33 <seb128> +1
19:33 <amurray> point
19:34 <rbasak> OK, so how about we start there? I started the section at https://wiki.ubuntu.com/TechnicalBoard#Team_Delegations earlier.
19:35 <rbasak> seb128: how about we look to link to a documented membership process for each of the teams mentioned above into there?
19:35 <rbasak> If the TB today agrees to do that, could seb128 drive that perhaps, asking each team to provide that documentation?
19:35 <seb128> sounds like a good first step
19:36 <seb128> I can do that yes
19:36 <amurray> +1
19:36 <rbasak> 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 <rbasak> Perhaps that will help the other teams as well.
19:36 <seb128> ack
19:36 <amurray> thanks rbasak I think that would be quite helpful
19:37 <amurray> #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 <meetingology> 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 <amurray> #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 <rbasak> Also Backporters I think please? Not to single them out, but they're part of the complete list I think.
19:38 <amurray> argh right
19:38 <rbasak> Because they are in charge of -backports just as security is of -security and SRU is of -updates.
19:38 <amurray> #undo
19:38 <meetingology> Removing item from minutes: ACTION
19:39 <amurray> #undo
19:39 <meetingology> Removing item from minutes: AGREED
19:39 <amurray> #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 <meetingology> 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 <amurray> #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 <amurray> #topic Scan the mailing list archive for anything we missed (standing item)
19:40 <amurray> #link https://lists.ubuntu.com/archives/technical-board/2023-July/thread.html
19:40 <amurray> nothing new
19:41 <amurray> #topic Check up on community bugs and techboard bugs
19:41 <amurray> #link https://bugs.launchpad.net/ubuntu-community/+bugs?field.assignee=techboard
19:41 <amurray> #link https://bugs.launchpad.net/techboard
19:41 <amurray> nothing new here either from what I can see
19:41 <amurray> #topic Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members)
19:42 <amurray> #agreed next meeting chair: rbasak, backup: seb128
19:42 <meetingology> AGREED: next meeting chair: rbasak, backup: seb128
19:42 <amurray> #topic AOB
19:42 <rbasak> ack,thanks
19:42 <seb128> I will not be there of the next meeting (holidays)
19:42 <seb128> for
19:43 <seb128> unsure if we should update the backup already to reflect that?
19:43 <amurray> ah ok - should I put down vorlon then as backup?
19:43 <rbasak> +1
19:43 <amurray> #undo
19:43 <meetingology> Removing item from minutes: TOPIC
19:43 <amurray> #undo
19:43 <meetingology> Removing item from minutes: AGREED
19:43 <amurray> #agreed next meeting chair: rbasak, backup: vorlon
19:43 <meetingology> AGREED: next meeting chair: rbasak, backup: vorlon
19:43 <amurray> #topic AOB
19:43 <seb128> thanks
19:44 <seb128> no AOB from me
19:44 <amurray> nothing from me either
19:45 <amurray> ok I think that is about it then
19:45 <amurray> #endmeeting