Key Ubuntu teams should have an open process for new members

Robie Basak robie.basak at ubuntu.com
Wed Jun 14 17:05:23 UTC 2023


On Tue, Jun 13, 2023 at 09:57:51PM +0200, Sebastien Bacher wrote:
> Le 13/06/2023 à 21:46, Robie Basak a écrit :
> >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.
> 
> It does make sense for the team to approach those uploaders indeed. But in
> practice do you feel like it is happening? Are the SRU team members managing
> to find the time and energy to watch for those people and have the
> discussion? Are you confident that they are no contributors that match the
> criteria but haven't been noticed?

There are a few candidates we decided did not meet the criteria or who
are or have become unavailable for various reasons. It would be
inappropriate to discuss their specific cases in public, so that makes
it difficult for me to give specifics on exactly how well I think we're
doing. But in general, I think we're doing OK, if you consider that a
reasonable rate for SRU team onboarding might be one or two a year.

I think it's also important to consider to what extent the SRU team
_needs_ new members. It's easy to presume that we're overloaded and that
the solution is to add team members.

I think we certainly were overloaded at around the time of Canonical
sprints which made many SRU team members unavailable.

However, I don't think that's the real cause of the issue. I find that I
spend 80% or more of my time on "difficult" cases. Sometimes these are
genuinely complicated, but a lot of the time it's because of mismatched
expectations.

I think adding new members is going to make the problem of mismatched
expectations worse, not better.

So while we could do with one or two additional SRU team members, I
think it would make a much more significant difference to ensure that
uploaders are able to more effectively drive their SRUs. This includes
being able to explain what the SRU team need to see, anticipating their
questions, being able to unblock their own SRUs rather than asking the
SRU team for help on process questions, setting the expectation on
uploaders that special cases must be properly requested and documented
instead of assuming that one SRU team member magically knows what to do
because another SRU team member accepted it last time, and so forth.

I think we'd free up significant SRU member time, and therefore review
delays, if we could improve on these friction points.

I'm actively working to improve the state of things on various fronts.
Documented criteria for new members is in the works, as seen in the
draft earlier in the thread. I am also working on revamping SRU process
and policy documentation. For Unapproved queue review, I set up an
automated Kanban board which helps reduce duplicate review effort. There
are other things I haven't got to yet, too.

Anyway, my point is just that while we do need one or two additional
members, I really don't think that lack of new membership is the cause
of the recent SRU team backlog, and I am working on what I believe are
the real causes.

This also feeds back to the team membership question: ideally, all
regular SRU uploaders should meet our criteria. But right now, many seem
to fall well short of that. If we can fix this, then we should
automatically have more good candidates.

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/20230614/ab1b0c47/attachment.sig>


More information about the technical-board mailing list