Launch the Wikimedia "Code Review Special Interest Group"
Open, NormalPublic

Description

This task item was mentioned as one potential idea in the Developer Summit session T114419 and hence is a subtask of T101686.

From T114419:

Should we have a CR committee? Does a CR committee have sufficient ROI?

This idea is connected to the discussion that the Architecture Committee is having on groups / (sub)teams working on special areas.
A potential Code Review committee / working group could exist for a limited time. (It would be different from a Collaboration working group, see T119030.)
This group would cover social, technical, and organizational aspects of Code Review and work on improving Wikimedia's Code Review process in T78768.

Potential candidates could be @demon, @mmodell, @Qgil, @Aklapper, <insert name here> and any further people with knowledge and authority to move forward.

There was a session about the topic of code review (T149639: Better code review processes for reviewers) at the 2017 Wikimedia Developer Summit.
During that session, consensus was reached to form a code review working group. See action items on the summary page for that session.

Related Objects

We already have a code review working group within Release-Engineering-Team, consisting of @demon, @hashar, @greg and myself.

I'm sure we would welcome anyone else who is interested in contributing / participating.

Qgil moved this task from Backlog to Team radar on the Developer-Relations board.Mar 15 2016, 2:24 PM

Great!
Is that working group in sync with the Architecture Committee? (Or maybe it does not necessarily need to?)
Does that working group agree with the "Blocked By" tasks listed in T101686 and would help identify the "most urgent tasks" and help drive those tasks forward to a resolution within some reasonable time frame?

jayvdb added a subscriber: jayvdb.Mar 15 2016, 8:02 PM
RobLa-WMF added a subscriber: RobLa-WMF.

@Aklapper, I'm adding TechCom-RfC as a tag to get this into TechCom's workflow.

T123606 proposes how we'd like to create working groups, but momentum has stalled because the engineering community hasn't arrived at consensus as to what working group should be the first. I'll quote here what I wrote in a subtask, since I think it applies here:

Working groups should be formed with a scope emphasizing the problem the group is tasked with solving. We should avoid forming working groups where the answer to the problem is baked into the charter/scope of the working group is solving. As I said in T123606, my fear is that what people really want from ArchCom is a place where we can officially bless their solution looking for problem, rather than forming working groups tasked with taking an open-minded approach to solving a problem. Every working group should be formed with a defining statement of what problem they are trying to solve.

For example, CoC requires a permanent committee (hence T126605). That said, we need to define the problem that that group is trying to solve clearly, and be open to the possibility that a written set of rules is the wrong tool for the job.

I've admired the times when an ArchCom member interrupts a long overly complicated discussion with "what problem are we trying to solve anyway?" We should all get into the practice of regularly asking ourselves that, and in particular, endeavor to take the 5 Whys approach (recursively challenging each problem statement until we hopefully get to the root cause). At each level of recursion, the scope likely increases, and we're likely to realize we need broader and deeper expertise to solve the problem well.

For ArchCom to have authority, it needs to have the trust of the Wikimedia developer community that it delegates that authority wisely. Overly narrow delegation would be disempowering, and give subteams the excuse to avoid exploring root causes (they could claim "out of scope"). ArchCom also needs to have capable subgroups to delegate review of bold new ideas to, which becomes impossible if the scope of all of the subteams is too narrow. Overly broad delegation will make it difficult for the subteam to focus, and create a situation where individuals won't be able to trust the subteam without participating in it (thus making it so that everyone needs to be part of every subteam).

I would love for y'all to be pioneers in forming an ArchCom subteam. You up for it?

RobLa-WMF moved this task from Inbox to ArchCom-RfC on the TechCom board.Mar 17 2016, 9:41 PM
hashar removed a subscriber: hashar.Apr 8 2016, 12:07 PM
Aklapper added a comment.EditedApr 15 2016, 6:19 AM

FYI, RobLa was kind enough to update https://www.mediawiki.org/wiki/Code_review_management which was also about a group dealing with code review. That page could be used (or not).

Qgil added a subscriber: Qgil.Apr 15 2016, 1:46 PM

What steps do you think that need to happen to decide whether we want this group to be created or not? For starters, who wants to take ownership of this task?

mmodell claimed this task.Apr 15 2016, 2:26 PM
mmodell added a subscriber: Bawolff.

@Qgil: I'm not sure what the steps are but I will take ownership of the task and try to move towards figuring that out.

I feel that @Aklapper and @demon would be valuable contributors to such a group if it is created. @Bawolff also had a lot of thoughts on the topic. I wish @greg was around but he's not going to have a chance to chime in here for a while.

mmodell triaged this task as High priority.Apr 15 2016, 3:11 PM
Qgil awarded a token.Apr 15 2016, 3:33 PM
RobLa-WMF mentioned this in Unknown Object (Event).May 4 2016, 7:33 PM

I haven't had much time to work on this and I haven't heard much feedback from anyone about this subject.

I still feel that code review is important. The code review meetings have been somewhat successful but not overwhelmingly so.

Have TechCom had any further thoughts about this, especially regarding how a code review committee would be organized and how it relates to TechCom?

mmodell lowered the priority of this task from High to Normal.Jul 18 2016, 5:11 PM

I haven't had much time to work on this and I haven't heard much feedback from anyone about this subject.

I still feel that code review is important. The code review meetings have been somewhat successful but not overwhelmingly so.

Have TechCom had any further thoughts about this, especially regarding how a code review committee would be organized and how it relates to TechCom?

I don't. I'd recommend sending an email to wikitech-l asking that question. I'm guessing this was discussed in the 2016-03-23 ArchCom planning meeting based on @Krinkle's workboard move (I believe I was out that week). @Krinkle, do you recall why you made that move?

RobLa-WMF moved this task from Inbox to Under discussion on the TechCom-RfC board.
RobLa-WMF moved this task from Backlog to RobLa-WMF on the TechCom-Has-shepherd board.
Qgil added a comment.Oct 27 2016, 1:32 PM

Would this task be a good topic for the Wikimedia-Developer-Summit (2017) ? If so, the deadline to submit new proposals is next Monday, October 31: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/Call_for_participation

mmodell removed mmodell as the assignee of this task.Oct 27 2016, 3:30 PM

@Qgil: yes, it might be a good topic for Wikimedia-Developer-Summit (2017), however, I won't be attending the summit in January. It was decided that some of Release-Engineering-Team will skip the summit in order to save some of our team travel budget for a team off-site in the spring.

If anyone else is interested in submitting a proposal I will be glad to hand this over to a new champion.

The code review committee needs more than one member participating. While a committee of one might come to decisions very efficiently, it's not likely to be very balanced. I must also admit that I may not be the most qualified to lead a committee as I've never done anything like it before and I've never had much respect for committees either.

So with all that said, I'm putting this task up for grabs. The code review office hours were a short-lived success but I am unsure how to turn that into something more formal.

I intend to do a bit more promoting to raise awareness of #wikimedia-codereview / E179: Code Review Office Hours but I think that's all I can hope to contribute to this effort in the coming months.

daniel added a project: TechCom-RfC.
Qgil added a comment.Jan 17 2017, 9:04 AM

After the Summit, is the creation of this committee a done deal?

It seems like there was consensus to do it but who is stepping up to be involved? I certainly will contribute.

The situation around arcanist and differential is improving, upstream is moving closer to implementing T5000 - Using Differential with plain Git, without requiring Arc. That one task is probably the most important feature request for many Wikimedians. Besides eliminating much of the friction associated with switching to phabricator for code review, it should bring phabricator much closer to feature parity with both Gerrit & Github.

After the Summit, is the creation of this committee a done deal?

As an aside, after talking to people at the summit it appears some people thought the comittee action item was sarcastic

@Qgil: yes, it might be a good topic for Wikimedia-Developer-Summit (2017), however, I won't be attending the summit in January. It was decided that some of Release-Engineering-Team will skip the summit in order to save some of our team travel budget for a team off-site in the spring.

Did you end up attending?

Qgil added a comment.Jan 18 2017, 7:17 AM

@Bawolff in that case it would be great if "some people" could join this discussion here. :)

Another idea: present this proposal at Developer-Wishlist (2017) and see how much support it gets. Note that the proposal would be "decide whether", not to directly create the committee.

In any case, I was thinking about starting with something simple: one person from WMF Technology, one from Product, and one volunteer developer. Developer-Relations and Team-Practices could eventually support this committee if they need help.

@MZMcBride: No, I wasn't at the dev summit but I did read through the session notes Because I Care™ :)

mmodell updated the task description. (Show Details)Jan 21 2017, 6:25 AM
ksmith added a subscriber: ksmith.Jan 23 2017, 5:40 PM
greg added a comment.Jan 23 2017, 11:51 PM

Re-threading statements from the two related tasks:

After the Summit, is the creation of this committee a done deal?

Summary wiki page with follow-up actions: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/Better_code_review_processes_for_reviewers

Notably:

  • Set up a working group (which might form a committee)
    • purpose: problem definition / scoping.
    • timeframe: 2-3 months? present finding and recommendations for next steps (probably something like "form a committee to work on the problem")

      What I don't have is... who. :)

In any case, I was thinking about starting with something simple: one person from WMF Technology, one from Product, and one volunteer developer. Developer-Relations and Team-Practices could eventually support this committee if they need help.

Something new from me: I think the current proposal of the working-group (see above) is small enough in scope that it can happen without much consternation (famous last words); if people want to devote time to it we should let them (and come back with those findings/recommendations for next step review).

Thus, I volunteer either myself or someone from my team (ohai @mmodel ;) ) to join this initial working group per @Qgil's proposal.

I am willing to facilitate meetings, and perform some light coordination work. I am not able to lead this charge, but can participate in a support role. I also reserve the right to share my own opinions about code review at times. :)

I'm not sure where to post this, and I don't want to lose it. This article describes some research around code reviews published by the IEEE: https://www.linkedin.com/pulse/code-reviews-software-quality-empirical-research-results-avteniev

One finding:

It appears that peer code reviews are better suited for knowledge sharing and code improvements than for eliminating defects.

As an aside, after talking to people at the summit it appears some people thought the comittee action item was sarcastic

Many also seemed to think it's just a group with a whip to force people to do code review. I don't think that kind of group would do any good.

I would be interested (participating) in a group that looks ways to improve code review by

  1. catching up with existing research
  2. surveying what kind of practices teams/people are currently using and whether they work or not
  3. experiment with a different kind of practices/tools with interested teams/people to see what would work best for us.
Qgil added a subscriber: bd808.EditedJan 31 2017, 5:56 AM

On the name and purpose of the group, this unrelated comment could be recycled here:

! In T156301#2984747, @bd808 wrote:
This is probably something that can be split into a separate conversation, but I have some thoughts on terms that we could use. The Kubernetes community has two types of groups:

  • Special interest groups which are long standing groups of volunteers interesting in working on a particular aspect of the project (e.g. API, CLI, Auth, Docs). There are well defined expectations for how a SIG operates and a directory of SIGs that make getting involved relatively simple.
  • Working groups which are similar to SIGs, but formed to address a particular time bounded issue rather than a broad area of interest in the community. In a Wikimedia context a WG could be used to do something like organize a hackathon or implement a single technical RfC.

    I like this distinction between long standing and task focused sub-communities. I also like that the term "special interest group" is fairly self-explanatory and shares terminology other organizations such as the Association for Computing Machinery, Kubernetes, CentOS, etc (https://www.google.com/search?q=special+interest+group).

Would "Code Review special interest group" help explaining what this team is about?

On authority and power, if the group has a good representation, is responsive, publishes sensible recommendations, and organizes successful activities... I expect this group to have little formal power, but to be followed by the powers that be.

Initial membership to obtain critical mass is a required first step. Greg and Kevin (and Nikkerabbit?) have stepped in. Thank you! Who else?

Aklapper added a comment.EditedFeb 6 2017, 4:40 PM

I'd be very happy to bring a 'Community Engagement' perspective to such a working group and help wherever possible.

I'm definitely interested. I agree with @bd808's suggested naming conventions, so +1 for Code Review SIG

mmodell renamed this task from Decide whether to have a "Code Review" committee / working group to Launch the Wikimedia "Code Review Special Interest Group".Feb 6 2017, 9:09 PM
demon removed a subscriber: demon.Feb 6 2017, 11:33 PM
Pine added a subscriber: Pine.EditedFeb 11 2017, 4:57 AM

I am glad to see any interest in and progress on code review process improvements! (Photo courtesy of @Lydia_Pintscher, CC-0)

Tgr added a subscriber: Tgr.May 5 2017, 7:28 PM
Qgil added a comment.Jun 8 2017, 7:33 AM

It would be useful to check https://www.mediawiki.org/wiki/Architecture_committee/Charter and clarify whether this Code Review Special Interest Group and code review in general would be withon scope of the new Technical Committee.

The Technical Committee (Architecture Committee) seemed to feel that managing a SIG like this would not fall within its scope. It would happily work with a group that had overlapping interests, such as code review or technical documentation.