On Tue, Jun 13, 2023 at 07:11:15PM +0200, Sebastien Bacher wrote: > (for context that's an email I sent the techboard before I joined the board, > the discussion picked up recently and TB members agreed that we should have > it on the mailing list)
(and this was my reply, with some minor copyediting) IMHO this is an important topic, since the CoC says "We invite anybody, from any company, to participate in any aspect of the project. Our community is open, and any responsibility can be carried by any contributor who demonstrates the required capacity and competence." and I think it would defeat the point of a community project to not have this. However, I think an appropriate method depends on a team-by-team basis, and it would be reasonable for a team to decide that they don't currently need any new members, or that some specific person isn't currently suitably qualified to be on that team. If the team is wrong, then the TB would be the appropriate point to escalate; my point is just that if the team is right then I think that's a perfectly acceptable situation from a governance perspective. Therefore, I think that if there's a problem with a team's position on 1) not delivering appropriately because of a perceived shortage of team members; or 2) choosing new team members in an inappropriate way, then that should normally be raised with the team first and escalated to the TB if required. It would be nice if teams documented their position on team membership (open or closed, how they decide if new members are required, the process for selecting new team members, etc). I'm open to the idea that the TB might require teams to document this; I think that would fit into my general push for documenting specifics of what the TB has delegated to teams. However, I don't think that necessarily means that all teams must have processes for candidates to _apply_ for membership, for the reasons above. It would depend on the team. On the SRU team, I tried to define some objective requirements for prospective new members, and other SRU team members have tweaked it. I hope this goes in the sort of direction you're seeking. I intend to document this publicly, but haven't yet. Here's the current text: Hard requirements * Recent track record of good quality SRUs * Recent uploads (whether sponsored or not) either met our expectations or successfully anticipated concerns that could reasonably have been predicted by existing SRU team members. * Few recent poor quality SRUs (nice to have: none). This includes uploads for issues that are unsuitable for SRU, as well as missing SRU information, missing bug references, poorly completed SRU information, etc. Exception: if an omission or concern is called out by the uploader and the upload was for the purpose of asking the SRU team about it. * Can they say no? Nice to haves * Demonstrated familiarity across existing SRU policies and procedures (rather than just having correctly submitted good SRUs that might be limited in parts of SRU policy and procedure that they exercise) * What about SRUs they've sponsored: do they successfully raise the quality of SRU submissions to our expected level before they sponsor them? If so, then this might be a good indicator that they'll be able to do similar at SRU review time. * Do they have a track record of spotting issues before they occur? How broadly do they look when determining "Where problems could occur"? Do they then make sure the Test Plan covers identified risks? * Do they seek to change general policy when appropriate, rather than ignoring it? Can they identify the difference between individual exceptions and the general case? IMHO, for the SRU team, it makes sense to actively approach uploaders who the existing SRU team considers to meet the criteria, rather than have an open application process. I wonder if the archive admin and release teams would think the same, or want a different approach. Robie
signature.asc
Description: PGP signature
-- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
