Improving the git-ubuntu based sponsorship workflow

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:

  1. 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.

  2. 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:

  1. 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.

  2. 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?

I’ve been a user of sponsorship queue and one little bit is slightly uncomfortable. The merge proposals are created in “Needs Review” state by default. This causes the bot to subscribe Ubuntu Sponsors and the MP to appear in the sponsorship queue in a not ready state (e.g. not enough details, ppa still building packages, etc). Would it be possible to change default state of MP to Work in Progress or create a new state “Need Sponsoring” ?

Thank you for the feedback!

When you create an MP through the Web UI, there’s a checkbox that says “Needs review (Is the proposal ready for review now?)”. You can uncheck that if the MP isn’t ready yet, and I believe that will put it in “Work in Progress” when it is created and the ~ubuntu-sponsors will leave it alone until that the state is manually changed to “Needs Review”.

Would this work for you? Or are you using git ubuntu submit? If the latter, I can add an option like --work-in-progress, and a per-user configuration option so a user can opt-in to making that the default. Would that work for you?

When you create an MP through the Web UI, there’s a checkbox that says “Needs review (Is the proposal ready for review now?)”. You can uncheck that if the MP isn’t ready yet

This is the user interface issue that I’ve tried to highlight - by default MPs are created in a ready, rather than draft state.
--work-in-progress would be a good addition to help alleviate this issue.

If the Web UI is changed so that all MPs start in a draft state by default, then I fear that we’d end up with contributors submitting good work that fail to end up in the sponsorship queue and get lost because they didn’t know to uncheck the box. For this reason I think it’s better to keep the default as it is.

On --work-in-progress, so that I understand how to prioritise this new feature, do you yourself use the Web UI, the CLI, or both?

I am the UI user, but if I will have an option to submit in the draft state, then I will switch to CLI.
But having said that I am just one semi-vocal user =) so regarding priorities its probably good to validate with others =)