@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:

In T124504#2019428, @RobLa-WMF wrote:

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?

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

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?

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?

In T129842#2471624, @mmodell wrote:

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?

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

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.

In T129842#2944492, @Qgil wrote:

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

In T129842#2748540, @mmodell wrote:

@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?

@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-Advocacy 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™ :)

Re-threading statements from the two related tasks:

In T129842#2944492, @Qgil wrote:

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

In T149639#2956614, @greg wrote:

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 T129842#2948546, @Qgil wrote:

In any case, I was thinking about starting with something simple: one person from WMF Technology, one from Product, and one volunteer developer. Developer-Advocacy 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.

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?

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

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.

May still need doing, but we have no process outside Techcom for setting up new committees either. :) Should we keep this open or close it out for now and recreate once there's more activity?

In T129842#3887892, @brion wrote:

May still need doing, but we have no process outside Techcom for setting up new committees either. :)

There is a template for how to do such a thing at https://www.mediawiki.org/wiki/Special_Interest_Groups. Currently there is no formal body to recognize SIGs or enforce that they follow the recommended practices. TechCom specifically recused themselves from that role.

Heh... Let's talk at dev summit with Victoria about a resolution to this impasse maybe. :)

(eg, we'll just sort of ... spontaneously generate a SIG and make sure we get some official blessing)

Removing TechCom-RFC tag per @bd808's note above -- we should have enough process from https://www.mediawiki.org/wiki/Special_Interest_Groups to just hash out a stub SIG and if we need any blessing, we can get it in person at dev summit.

For the records, this is kind of happening. See https://www.mediawiki.org/wiki/Code_Health_Group/projects/CodeReview