I started an internal-to-Canonical initiative a while ago that is going well and seems appropriate to bring more generally to Ubuntu SRU process.
It doesn't involve any change to existing SRU workflows or change any
existing SRU related expectations.
# The problem we're solving
Uploaders from specific teams and the SRU team were seeing a pattern of
uploads where expectations were mismatched, causing friction, extra
review iterations, and general unhappiness.
This was difficult to tackle in the normal way. Feedback and discussions
can happen in an SRU bug for a single SRU, but this isn't seen by other
members of the uploading team. Mismatched expectations can start by
looking like a criticism of somebody's work, and it's inappropriate to
do this in public, so there wasn't a forum where those involved felt
free to discuss these matters more widely. So then the same issue would
come up in a subsequent upload by a colleague of the previous uploader
who didn't know about that discussion. And again by a member of a
different uploading team. For `n` instances of expectation mismatch type
and `m` uploaders, it was taking `n × m` discussions to resolve
recurrence.
# The Canonical-internal solution
In October, I started a cross-functional team of "SRU Representatives"
("SRU Reps" for short) within Canonical. Representatives are drawn only
from specific uploading teams where this pattern of friction was
perceived to exist. There is a forum for representatives and the
Canonical-employed SRU team members to raise and discuss feedback. For
these purposes, feedback specifically means review issues that: 1)
appear to be part of a pattern; and 2) seem like they should have been
anticipated and resolved before upload.
The outcome of the discussions could be that: 1) documentation, process
or policy need changing to accommodate specific needs; or 2) that
uploaders need to be aware of specific already-documented expectations
and ensure they are met before upload. In the former case, once a
specific change is identified then we can make that change in the usual
(public) way that we make decisions in Ubuntu. In the latter case, the
representative can take that feedback back to the uploader. More
generally, the representative takes responsibility for the quality of
all SRUs uploaded by the team they represent.
Conversations are deliberately kept private so that we can freely
discuss what could be seen (or conclude) as criticism of the performance
of an individual. In my opinion, this has enabled constructive
discussion that would otherwise not have happened.
I think this is working very well so far. It's perhaps too early to try
to measure objectively, I get the distinct impression that we have
managed to resolve some of this unhappiness.
# Widening the solution into SRU process
So far, this has been Canonical employees organising themselves better
within existing Ubuntu development processes. It so happened that at the
time all SRU team members were Canonical employees. Now that this no
longer the case, I think it'd be useful to include non-Canonical SRU
team members in the feedback loop.
To do this properly, it should also mean that any Ubuntu development
team should be able to have an SRU Representative should they want one,
regardless of their employer or other affiliation (but see next
paragraph). There's no formal process for this at the moment. But we
have SRU Reps documented in the SRU docs now[1], and I thought that
explaining the background here would be helpful.
Note though that the representative role is narrow. Specifically, it is
to resolve SRU review feedback that pertains to an issue that is part of
a pattern, such that all SRU uploads coming from the represented teams
consistently meet SRU team expectations and generally do not require
review iterations whether at accept or release time. It isn't intended
to be used for any other purpose; all other SRU related discussion
should happen on the public IRC[2] channels as normal.
If your team's uploads already consistently meet SRU expectations, then
it isn't necessary to have a representative to help achieve that! This
also isn't a replacement for sponsoring, mentoring or patch piloting.
Representatives are expected to be uploaders already. Teams that are
challenged by not having enough uploaders need help from other
initiatives, not this one.
[1]:
https://canonical-sru-docs.readthedocs-hosted.com/en/latest/explanation/roles/
[2]: Probably moving to Matrix soon; see other thread.
signature.asc
Description: PGP signature
-- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
