Key Ubuntu teams should have an open process for new members

[Robie Basak]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/technical-board/attachments/20230613/faa1391c/attachment.sig>