Page MenuHomePhabricator

Agree on and implement actions to prioritize code review of patches submitted by volunteers
Open, NormalPublic

Description

Our speed reviewing patches is not impressive, and this is a problem difficult to solve.

In this task we discuss how to solve the problem for patches contributed by volunteers. A subset that is worth paying special attention to are developers submitting their first contribution. This is a critical area, for many reasons:

  • There is only one chance to cause a good first impression. Quick reviews contribute to engagement and retention of new contributors. Unsurprisingly, being ignored during days or weeks does the contrary.
  • Patches are gifts. Good teams don't ignore gifts and their donors. Note that from the point of view of the volunteer, this is a gift made to Wikimedia / MediaWiki, and your efficiency handling the gift will impact on the perception that volunteer will have about the whole project, not just your component.
  • Frequently these patches are related to low priority tasks that maintainers don't have to work on. By making happy a volunteers developer, we may make happy other volunteers that reported a problem or are following its progress.
  • Chances that more patches arrive after a successful first contribution are high. More work, more gifts, provided by a volunteers becoming slowly regular contributors.

What do we need?

  • We need to agree on the importance of this goal as a community, having repo maintainers and WMF tech management fully on board.
  • While newcomers are easy to spot by number of commits, finding volunteers among all contributors is less simple. In theory anybody without "wikimedia" in their email domain would be a volunteer, by many Wikimedia Foundation employees use non-Wikimedia email addresses in their patches.
  • Ideally, patches from volunteers and new contributors would be easy to identify as they arrive and in lists.
  • A team of patch triagers could watch this page or an equivalent to follow patches from new contributors, and help pinging reviewers whenever is needed.

Tools:

Related Objects

StatusAssignedTask
ResolvedQgil
ResolvedDicortazar
InvalidNone
InvalidNone
DuplicateQgil
ResolvedQgil
ResolvedQgil
ResolvedQgil
ResolvedAklapper
OpenNone
DeclinedNone
OpenNone
ResolvedQgil
ResolvedAklapper
ResolvedAklapper
ResolvedAklapper
ResolvedDicortazar
ResolvedDicortazar
ResolvedAcs
ResolvedDicortazar
ResolvedDicortazar
ResolvedDicortazar
ResolvedDicortazar
ResolvedDicortazar
ResolvedDicortazar
InvalidDicortazar
ResolvedDicortazar
ResolvedDicortazar
ResolvedAklapper
ResolvedDicortazar
ResolvedDicortazar
DuplicateNone
ResolvedDicortazar
ResolvedBawolff
Resolvedmmodell
ResolvedNone
Resolvedmmodell
ResolvedLegoktm
Resolvedtstarling
Resolvedgreg
ResolvedAklapper
ResolvedAklapper
ResolvedAklapper
ResolvedAklapper
ResolvedNone
DeclinedNone

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Qgil renamed this task from How to prioritize code review of patches submitted by volunteers to Goal: Plan to prioritize code review of patches submitted by volunteers.Sep 10 2015, 1:41 PM
Qgil added a comment.Sep 10 2015, 1:56 PM

@Aklapper and me have been discussing about setting an Developer-Advocacy quarterly goal as a continuation of T88531: Goal: Organize a Gerrit Cleanup Day on September 23, 2015. We can polish this task and convert it in such goal.

The measurement of success would be a proposal for WMF Engineering to address the code review queue of changesets submitted by volunteers and committing to a service level agreement. This proposal should be created with the participation of the parties involved in order to assure its approval and implementation in the following steps.

Details of scope will need to be discussed, for example I guess we are talking more about "non-WMF contributions" than "volunteers", and I guess this SLA would be applied to a subset of repos (deployed in Wikimedia servers, "maintained by the WMF"...?)

I'm updating T109829: Developer Relations quarterly goals for October-December 2015 accordingly.

Dropping some bullet points here so I don't forget:

  • When it comes to timing, the Release-Engineering-Team also has plans to put efforts into moving from Gerrit to Differential, so these efforts should be aligned.
  • I should try to find some research how other large FOSS projects handle this (papers, potentially reach out to folks via emails or blog).
  • Outcome should be a documented and process agreed among WMF that teams will implement (and metrics to verify)
Jay8g added a subscriber: Jay8g.Sep 24 2015, 3:34 AM
Aklapper raised the priority of this task from Low to Normal.Oct 5 2015, 11:33 AM
Tgr added a comment.Oct 13 2015, 10:59 PM

There is a proposed WikiDev16 session about improving code review, especially for volunteers: T114419: Event on "Make code review not suck". You are welcome to comment there if interested.

Aklapper renamed this task from Goal: Plan to prioritize code review of patches submitted by volunteers to Goal: Agree on and implement actions to prioritize code review of patches submitted by volunteers.Dec 3 2015, 4:28 PM
Aklapper removed a project: DevRel-December-2015.

I've changed the task summary by prefixing "Agree on and implement actions to..." and removed DevRel-December-2015 here as this task is blocked by T101686: Goal: Define potential actions to reduce code review queues and waiting times (to be finished in December) and hence will not get fixed in December 2015.

Aklapper renamed this task from Goal: Agree on and implement actions to prioritize code review of patches submitted by volunteers to Goal: Agree on and how to implement actions to prioritize code review of patches submitted by volunteers.Dec 29 2015, 7:43 PM
Dzahn removed a subscriber: Dzahn.Jan 15 2016, 8:16 PM
Izno added a subscriber: Izno.Feb 29 2016, 2:16 PM
Qgil added a comment.Apr 6 2016, 1:33 PM

This task was one of the T119387: Community Liaison and Developer Relation quarterly goals for January - March 2016. We have missed it as it was formulated. @Aklapper could you formulate the current status and the progress during the past quarter, please?

Meh. Not sure why I renamed this task on Dec 29. Reverting back to old title.

Potential actions (a blocker for this task) were successfully identified in T101686 - I added them as blockers to this task, regarding their implementation.

Aklapper added a comment.EditedApr 7 2016, 12:02 PM

Defining and proposing potential actions

Agreeing on actions

Regarding the "agree on" part of this very task, this was done by the following steps:

Implement actions

The "implement" part was clearly not done in Jan-Mar 2016, though some work has been started in specific tasks with defined owners. Some tasks still miss owners and miss a clear way forward, e.g. T115852.

Obviously we have identified actions to improve the code review situation in general, so everybody should benefit from future improvements regardless of their affiliation, not only volunteers contributing patches (though they are still our main focus).

Regarding involvement of Developer-Advocacy specifically, T129068: Improve code contribution guidelines for patch authors and T129067: Document a structured, standardized approach for reviewing code contributions are @Aklapper's personal goals for the April - June 2016 quarter.
Until T129842 is resolved it's not entirely clear how much the Developer-Advocacy team will be involved in actually driving all (emphasis by me) these action items.

[Task is blocked by numerous tasks hence not convinced whether punting this to yet another quarter helps anybody. And this is marked as Tracking-Neverending. Hence setting generic team project instead of milestone.]

Danny_B removed a subscriber: Team-Practices.
ksmith added a subscriber: ksmith.

Removing Team Practices because we're not sure how we could help with this in the near term. If you have a specific request for us, please see: https://www.mediawiki.org/wiki/Team_Practices_Group/How_To_Engage_With_TPG

Aklapper removed Aklapper as the assignee of this task.Sep 23 2016, 7:46 PM
Aklapper moved this task from To triage to Team radar on the Developer-Advocacy board.

As written in T129067#2582754, Technology & Product need to lead efforts to have teams follow guidelines, establish a routine of going through unreviewed patches, and other iterative improvements.
Hence I am removing myself as assignee of this task.

As Qgil wrote in T129067#2639298, discussion with @greg / Release-Engineering-Team / Technology & Product has to happen to define what are the next steps that they should lead because our time as leaders here has come to an end.

This might require creating a new task that will block this very task T78768.

Krinkle removed a subscriber: Krinkle.
Zppix renamed this task from Goal: Agree on and implement actions to prioritize code review of patches submitted by volunteers to Agree on and implement actions to prioritize code review of patches submitted by volunteers.May 12 2017, 9:41 PM
Tgr added a comment.Jan 31 2018, 7:45 PM

From T156120: Update gerrit to 2.14.6:

You can now set an assignee for changes.

From one of the sub tasks I have published a blog explaining the Gerrit review by blame plugin as well as other manual way to find reviewers: J139: Blog Post: Gerrit now automatically adds reviewers. That would help to at least get some reviewers on changes since they are now added automatically by Gerrit.