I think we’ve got a few issues with how this works at the moment. This is a long explanation of what the current situation is, and why, which I think is needed to be able to find a solution.
Data model
It’s important to remember that Launchpad hosts much more than just repositories for Ubuntu packages. MPs can be filed in various places in Launchpad, both against Bazaar and against Git. They have a specific target repository and target branch. The target repository can be associated with a distribution, and if it is, then also a source package in that distribution. The target repository also has an owner, which in the cases of git-ubuntu is ~git-ubuntu-import (soon to be renamed to ~git-ubuntu). However, not all packages are primarily developed using git-ubuntu repositories. Non-git-ubuntu git repositories for Ubuntu packages also exist.
An MP has a list of review slots, but a voting decision itself might not have been performed on a slot yet in which the slot’s vote is “Pending”. After a decision, the vote becomes “Approved”, “Needs Fixing”, etc. Each slot has a nominated reviewer which may be a person or a team, but note that the reviewer can change!
A person can “claim” a review slot if its reviewer is a team and the person is a member of that team. If they do this (eg. by clicking on the “Claim review” button), then the reviewer is changed from the team to that person. This is commonly used to prevent duplication of effort within a reviewing team.
When a person votes on an MP, Launchpad finds a review slot for which the person is the reviewer, and sets it to the person’s chosen outcome. If there isn’t a slot for which the person is the reviewer, Launchpad will claim a slot on behalf of the person if any are claimable, choosing one if multiple are available. If no slots can be claimed, then Launchpad will create an additional slot with the person as the reviewer and use that one.
This can lead to surprising behaviour if a person voting on an MP belongs to more than one team for which there is a review slot. One will get claimed, and the others will remain open. The team whose slot that got claimed will no longer be represented in the MP.
Desired behaviour
Not missing contributions
If a contributor believes they are waiting on sponsorship, we don’t want to miss it!
Efficient piloting
We’d like for pilots to be able to focus on actionable MPs that require sponsorship only.
If another pilot has been and requested changes, then an MP is temporarily unactionable until the contributor is ready again. For example, it’s undesirable for there to be 20 items in the sponsorship queue, and for a pilot to go through them one by one only to eventually find that 19 of them are waiting on the contributor. Ideally, they’ll have just been able ignore the ones that are waiting, and have spent all their time on just the one that needed their attention.
This might be achieved in one of two ways:
-
The sponsorship report has entries that make it clear if it’s waiting on a pilot or not, and/or allows the pilot to sort or filter, so that the pilot can just focus on the ones that need attention, but we still have a good overview of how things are going, and can quickly find things if contributors make enquiries.
-
Don’t display entries needing not needing pilot attention in the sponsorship queue at all.
Current Method
The sponsorship queue displays only MPs where there is a review slot whose reviewer is ~ubuntu-sponsors. This can arranged manually by the person submitting the MP - either when they create the MP, or later by using the “Request another review” button.
But we don’t want to ignore submissions from contributors who “should have known” to do that. That would seem like an unreasonable expectation. To resolve this, there’s a bot (currently operated by @rbasak) that automatically adds a review slot for ~ubuntu-sponsors under certain conditions.
We start by considering two types of MPs only:
-
Some default reviewer team that doesn’t actually have any process to review these MPs, so we consider if these should have a ~ubuntu-sponsors slot added.
-
Some reviewer team that we instruct submitters to request to bootstrap some specific workflow for which the reviewer team has specifically opted in to request automatic appearance in the sponsorship queue for, so we consider these too.
We then disqualify some MPs from this list:
-
They must be git-based MPs that target git-ubuntu repositories. We might be able to do non-git-ubuntu repositories in the future, but would need to decide how exactly this should work.
-
If the MP is submitted by someone who can upload the package themselves, then they don’t need sponsorship.
-
For sponsorship queue purposes, we don’t want to interfere with any team’s existing workflow, such as a bunch of patch pilots suddenly interfering with already established alternative workflows. So if an MP is filed with some specific reviewer that isn’t otherwise handled here, we don’t touch it.
Issues with the current method
If a pilots votes on an MP (eg. “Needs Fixing”), then their account will probably automatically claim the ~ubuntu-sponsors review slot, causing the entry to disappear from the sponsorship queue. This might be what we want, depending on our position in “Desired behaviour” above.
But what happens when the contributor responds to the feedback? Only the original pilot will receive the email. The contribution won’t reappear in the sponsorship queue because the bot now won’t touch it since it cannot differentiate between the sponsorship workflow and someone having some other workflow who just wanted that person to review it with no intention of wanting sponsorship.
Feedback wanted
Where do we go from here?