ImproveSponsorshipQueue

Summary

Release Note

To ensure a great experience for new development contributors, we are going to try out something similar to the Bazaar team's patch pilot programme. We will have dedicated on-call reviewers in #ubuntu-devel that will help to ensure that sponsoring requests are tended to in a timely manner.

Rationale

Right now we don't ensure that sponsoring requests are dealt with at all. So sponsoring items only find their way into Ubuntu if there's an active maintainer, enough pressure or if a good relationship between sponsor and contributor already exists.

As a patch pilot your duty will be to make sure contributors get a timely response and you do your best to help them get their fix in order. (More specifics about the role below.)

User stories

James is part of Canonical's Ubuntu Platform team, he gets up in the morning, checks his calendar and finds he's on duty for today. He updates the topic in #ubuntu-devel to indicate he's patch pilot. Checks the sponsoring queue for new items and reviews them. In some cases the package does not belong to his area of expertise, so he reviews and tests as good as he can, and gets the contributor in touch with somebody who can make a better decision on it.

Rick wants to see how well the sponsorship queue is being tended to. He checks the statistics and sees the number of incoming and existing items and how quickly the development team responded.

Jorge has problems getting his patch into Ubuntu. He joins #ubuntu-devel, reads the topic and knows who's patch pilot. He starts a quick discussion and gets the help he needs.

Assumptions

Design

We will set up the patch pilot programme for Ubuntu and seed the pilot schedule with Canonical Ubuntu Platform members that can do uploads.

We will publish the initial schedule, ask others to either add themselves to the schedule or just show up and help out in an ad-hoc fashion. Also will we make sure the topic in #ubuntu-devel gets updated with the current pilot regularly.

We will also track these statistics to verify if we're making progress:

  1. Patches in the queue
  2. Time from "patch submitted" to "patch landed/resolved"
  3. New contributors
  4. Repeat contributors
  5. Time to first response

Implementation

First we will update our documentation for contributors and for sponsors to set expectations for what a patch pilot does.

Then we will set up an initial schedule and seed it with members of the Canonical Ubuntu Platform team. It will be explained to members of this team that it's their duty to work as a patch pilot for at least 4 hours per month.

We will reach out to the whole Ubuntu developer community to help out with the project and announce the new plan widely.

We will update the topic in #ubuntu-devel with a bot to indicate who's currently patch-pilot. Updating it by hand will be the fallback.

We will also track these statistics to verify if we're making progress:

  1. Patches in the queue
  2. Time from "patch submitted" to "patch landed/resolved"
  3. New contributors
  4. Repeat contributors
  5. Time to first response

To ensure we're on track and the programme is a success, we will revisit it at the Canonical Ubuntu Platform rally (around Feature Freeze time) and at UDS-O. The outcome of these sessions will be published as well.

Test/Demo Plan

We will review the results of this at the Canonical Ubuntu Platform rally (around Feature Freeze time) and at UDS-O.

BoF agenda and discussion

Experience:
 - stuff mostly waiting in core
 - demotivating to wait for months/cycles for a fix to land

Random suggestions:
 - let "junior contributors" review as well

Related problems:
 - no culture of reviewing
  + no idea what the actual problems of infrastructure/processes are
  + we don't share knowledge as well as we could


Suggested solutions:
 - Dogfood experiment to figure out process and tool/infrastructure issues
  + Reviews mandatory for all uploads
  + This works well in the SRU world or in freeze times
  + Try on a per-team basis for a week or two
  + Send feedback to Launchpad/Bazaar team, improve tools and infrastructure
 - Make more resources available
  + schedule mandatory on-call reviewers
  + update https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews
 - More "social" mentor-like experience
  + make it easier for people to find who could review/upload your stuff
  + get people together

Additionally:
 - more statistics, track:
  + size of the queue
  + length, how long items are in the queue
  + number of first-time committers


the gang of 6's proposed plan:

Goals of Sponsorship Queue
 0. Provide new contributors a great early experience contributing to Ubuntu, make them feel good about participation
 1. Provide feedback and mentoring to community members asap on their patches
 2. Provide a welcoming experience to folks contributing patches, and connect folks with members of the community who share interests
 3. Get patches to upstreams or into Ubuntu in a timely manner
 4. Grow the community

Sponsorship in Natty
 0. Current expectation is that all Ubuntu Engineering engineers do 1 hour of sponsoring a week
 1. Don't change current working teams, processes: (#ubuntu-desktop, @ubuntu-x)
 2. Every engineer in Ubuntu Engineering will have one 4 hour block per month as dedicated "Patch Pilot"
 3. Patch Pilot will spend the time working on patches in the sponsorship queue, in order that they come in (this may entail there being multiple Patch Pilot on some days) Focus on minimizing response time.
 4. Patch Pilot will work with each patch, regardless of the target package. The engineer may contact an expert for the package for a sanity check before uploading the patch.
 5. Patch Pilot may introduce the patch author to specific people in the community who have a shared interest in the package.
 6. Put the current Patch Pilot into the topic of #ubuntu-devel
 - what to do with #ubuntu-reviews? should stick with this as it's working for that team


Metrics
 1. Patches in the queue
 2. Time from "patch submitted" to "patch landed/resolved"
 3. New contributors
 4. Repeat contributors
 5. Time to first response



What is a "Patch Pilot"?
  * someone who pilots the patch into the safe harbour of where it belongs
  * not necessarily an uploader, but perhaps someone who connects contributors
    to the uploader, and feels responsible for helping the contributor
  * cf http://wiki.bazaar.canonical.com/PatchPilot

Celebrate the results:
  * eg https://lists.ubuntu.com/archives/bazaar/2010q4/070628.html
  * https://lists.ubuntu.com/archives/bazaar/2010q3/070173.html

Actions:
[dholbach] set up schedule and give to Rick for review
[dholbach] talk to jml about getting sponsoring bug data
[dholbach] get feedback from Rick about sponsoring stats
[dholbach] schedule session for next UDS to revisit patch-pilot schedule
[dholbach] improve UbuntuDevelopment/CodeReviews to explain patch-pilot
[dholbach] improve SponsorshipProcess to explain patch-pilot
[kate.stewart] review documentation
[dholbach] blog about review process changes, mail ubuntu-devel-announce
[jonobacon] to ask IRC council for an IRC bot for making patch pilot visible on ubuntu-devel
[jonobacon] schedule discussion at the Platform Rally to review results
[rick-rickspencer3] flesh out communication plan for letting the Platform team know

CategorySpec

Specs/ImproveSponsorshipQueue (last edited 2010-11-02 15:29:36 by i59F70EB9)