Documenting the ubuntu-sru team membership process

[Robie Basak]

Hi!

On Tue, Oct 10, 2023 at 03:27:46PM +0200, Sebastien Bacher wrote:
> I've an action items from the TB to reach out to the concerned teams to ask
> if they could provide a such documentation, which is why I'm writing to you
> now.

I agree that we should have some documented process and policy. I've
been working on improving SRU documentation in general, including on
this aspect, but that's still a work in progress.

For onboarding new members of the SRU team, I have been using some draft
documentation that I've copied below. This has been consulted by SRU
team members to make progress in onboarding for now, but has not yet
been considered final.

I'd be happy to move this draft to somewhere publicly maintained. I
welcome feedback. We could then make sure we have SRU team consensus and
make it final.

I would expect that the SRU team would remain in control of the text and
change it as they feel appropriate in the future - whether that would be
fine refinements or major changes. As one member of the Technical Board,
I would prefer to see all teams manage the details of their own policies
and processes in this way, with the Technical Board only defining what
is expected in terms of outcomes. So, to be clear, using the Backporters
team as an example as they've already been through a similar exercise, I
think that the TB should define a separate text similar to
https://wiki.ubuntu.com/TechnicalBoard#Backporters_Team but for the SRU
team, and the text below would be internal (but public) process
documentation for the SRU team, just as the Backporters team have their
own process and policy documentation that they maintain themselves.

Robie

--- DRAFT FOLLOWS ---

# Process for adding members to the team

 * Existing SRU team members identify when new team members are needed.
   They will privately nominate suitable candidates, with regard to
   their availability (eg. a discussion with their manager may be
   required).

 * One existing team member will study a candidate’s recent SRU
   activity, assess them against our criteria and write a summary.

 * The team will then decide whether the candidate is suitable.

 * One existing team member will onboard a given new trainee,
   “sponsoring” privileged SRU actions such as review accept and
   release.

 * This mentor will consult with other existing team members and the
   trainee will be given equivalent privileges when appropriate.

## Criteria for new SRU team members

### Hard requirements

 * Must be able to upload all SRUs they expect to review; ie. Ubuntu
   Core Developer or SRU Developer.  A member of the SRU team who is an
   SRU Developer is expected to be in the process of applying to be an
   Ubuntu Core Developer: the role involves exercising judgement about
   whether a change in the development series is good, and therefore
   someone in this role should be formally trusted by the project to
   make such decisions for the development series as well.

 * 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?
-------------- 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/ubuntu-release/attachments/20231010/f57592f3/attachment.sig>