Talk:Wikimedia Developer Summit/2017/How to grow our technical community

Is this the best category for any sessions about improving our code review processes?

@KSmith (WMF): Do you have something in mind already? I'd also be interested in this area and I can see many problems, such as:

• As a code contributor, it is unpredictable when my proposed change will receive feedback and not be CR=0 in Gerrit anymore
• As a code contributor, it is unpredictable when my positively reviewed change (CR+1 in Gerrit) will receive a CR+2 and get merged
• As a maintainer, negatively reviewed changes (CR-1 in Gerrit) might be very close to being acceptable but noone might pick them up and rework them
• As a code reviewer, there are repositories and areas of repositories that have unclear maintainership and noone feels responsible/capable for reviewing
• As a code contributor, it is not easy to find out whether a repository is active or maintained and whether it's worth to propose a change
• As a code contributor, it is not easy to find out who are the maintainers of a repository in order to contact them and discuss changes (e.g. architectural ones) beforehand

(Plus adding the notorious link to User:AKlapper (WMF)/Code Review here.)

I'd be happy to team up if we could define what to discuss and share expectations on outcome. :)

I don't really have anything in mind. My own personal interests are more in the code reviewing itself, and less in the tooling and process. But I suspect that given the state of things, more of a focus on tools and process might be a better starting point.

Perhaps the most important question to answer first is: Who would be the audience? Patch submitters? Reviewers? Would-be reviewers?

"New patch submitters" is interesting but I'm afraid we'd end up with stuff we'll all agree on ("improve docs, make learning curve less steep") and some unactionable bikeshed on Gerrit/Differential. Reviewers feels like a way better target and touches aspects like having team routines to regularly review patches (some Teampractices Group wisdom might be helpful here) or assigning reviewers to patches that no one feels responsible for. Would you agree?

Yes, I think a focus on reviewers (or potential reviewers) makes sense. It could be more on an individual level, or more on a team level. I suspect the former would be more in line with the DevSummit concept, but the latter might be easier to achieve tangible improvements .

Which of these problems do you think might be worth trying to address here?

• Lack of skill about how to perform effective CR
• Lack of confidence of ability to correctly evaluate patches
• Lack of time (or CR not being prioritized by managers)
• Lack of interest in doing CR (because it can be less exciting than writing code)
• Lack of agreement that CR is valuable
• ...other?

If we discussed skill and confidence in a session, what could be the potential outcome? Mentoring for reviews (what should happen anyway if more than one person took a look at the patch and its review comments)? If everybody agreed there's not much to discuss. :) I don't think that discussing lack of interest in doing CR or whether CR is valuable would be a good use of time.

Which leaves us with "Lack of time (or CR not being prioritized by managers)" though that might be a very WMF (or WMDE) specific problem. I'd love to see that discussed though - code review as part of a developer team's regular routines, exchanging best practices (socially and technically), and how to foster that. Would require to have people from different teams to be present in the session though.

Thoughts? :)

@KSmith (WMF): Deadline for session proposals is today - do you plan to draft a task about CR? (Doesn't have to be perfect and I'd be happy to help!)

@AKlapper (WMF): Unfortunately, I don't have the energy to move ahead with this now. If someone else wants to propose a CR related session, I would be happy to help.

No worries - I've created a placeholder task in https://phabricator.wikimedia.org/T149639 and your edits are welcome. :)

Yes!