Page MenuHomePhabricator

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

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

StatusSubtypeAssignedTask
ResolvedQgil
ResolvedDicortazar
InvalidNone
InvalidNone
DuplicateQgil
ResolvedQgil
ResolvedQgil
ResolvedQgil
Resolved Aklapper
DeclinedNone
DeclinedNone
OpenNone
ResolvedQgil
Resolved Aklapper
Resolved Aklapper
Resolved Aklapper
ResolvedDicortazar
ResolvedDicortazar
ResolvedAcs
ResolvedDicortazar
ResolvedDicortazar
ResolvedDicortazar
ResolvedDicortazar
ResolvedDicortazar
ResolvedDicortazar
InvalidDicortazar
ResolvedDicortazar
ResolvedDicortazar
Resolved Aklapper
ResolvedDicortazar
ResolvedDicortazar
DuplicateNone
ResolvedDicortazar
ResolvedBawolff
Resolved mmodell
ResolvedNone
Resolved mmodell
ResolvedLegoktm
Resolvedtstarling
Resolvedgreg
Resolved Aklapper
Resolved Aklapper
Resolved Aklapper
Resolved Aklapper
ResolvedNone
DeclinedNone

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Aklapper raised the priority of this task from Low to Medium.Oct 5 2015, 11:33 AM

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

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

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.

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

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

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

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.

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

Is this data available in another tool (bitergia perhaps)? The one linked in the task description (http://korma.wmflabs.org/browser/gerrit_review_queue.html) is no longer available. I'm particularly interested to see this data for specific repositories, if possible.

@kostajh: It depends on which exact data you're looking for. :) https://www.mediawiki.org/wiki/Community_metrics#Time_to_first_review_for_Gerrit_patches_per_repository and the following section might provide some insights.
The "Organizations" widget lets you filter for author_org_name:"Independent"; the "Repositories" widget allows filtering for repository:"mediawiki/extensions/Examples".

@kostajh: It depends on which exact data you're looking for. :) https://www.mediawiki.org/wiki/Community_metrics#Time_to_first_review_for_Gerrit_patches_per_repository and the following section might provide some insights.
The "Organizations" widget lets you filter for author_org_name:"Independent"; the "Repositories" widget allows filtering for repository:"mediawiki/extensions/Examples".

That's useful, thanks!

Aklapper lowered the priority of this task from Medium to Low.Feb 7 2022, 11:47 AM