//This task item was mentioned as one topic in the Developer Summit session T114419 and hence is a subtask of T101686. See also T207.//
* From https://www.mediawiki.org/wiki/User:AKlapper_%28WMF%29/Code_Review#Unstructured_review_approach :
** Unstructured review approach potentially demotivates first patch contributors, but fast and structured feedback is crucial for keeping them engaged
** Discuss and decide whether to set up and document a multi-phase, structured patch review process for reviewers: [[ http://sarah.thesharps.us/2014/09/01/the-gentle-art-of-patch-review/ | Three steps proposed by Sarah Sharp for maintainers / reviewers ]], quoting:
*** "Is the idea behind the contribution sound? / Do we want this? Yes, no. If the contribution isn’t useful or it’s a bad idea, it isn’t worth reviewing further. Or “Thanks for this contribution! I like the concept of this patch, but I don’t have time to thoroughly review it right now. Ping me if I haven’t reviewed it in a week.” The absolute worst thing you can do during phase one is be completely silent.
*** Is the contribution architected correctly? Squash the nit-picky, perfectionist part of yourself that wants to comment on every single grammar mistake or code style issue. Instead, only include a sentence or two with a pointer to coding style documentation, or any tools they will need to run their contribution through.
*** Is the contribution polished? Get to comment on the meta (non-code) parts of the contribution. Correct any spelling or grammar mistakes, suggest clearer wording for comments, and ask for any updated documentation for the code"
** Help (**TODO**: who? #Team-Practices? #Release Engineering? T129842?) WMF teams to implement this process
* From https://www.mediawiki.org/wiki/User:AKlapper_%28WMF%29/Code_Review#Unhelpful_reviewer_comments :
** Due to unhelpful reviewer comments, contributors spend time on creating many revisions/iterations before successful merge. Make sure documentation for reviewers states:
*** Reviewers' CR comments considered useful by contributors: identifying functional issues; identifying corner cases potentially not covered; suggestions for APIs/designs/code conventions to follow.[5]
*** Reviewers' CR comments considered somewhat useful by contributors: coding guidelines; identifying alternative implementations or refactoring[5]
*** Reviewers' CR comments considered not useful by contributors: Authors consider reviewers praising on code segments, reviewers asking questions to understand the implementation, and reviewers pointing out future issues not related to the specific code (should be filed as tasks) as not useful.[5]
*** Reviewers' CR comments considered somewhat useful by contributors: coding guidelines; identifying alternative implementations or refactoring[5]
*** (Previous bullet points taken from //Amiangshu Bosu, Michaela Greiler, and Christian Bird. 2015. Characteristics of useful code reviews: an empirical study at Microsoft. MSR '15, pages 146-156.//)
*** While still using Gerrit and not yet Differential, potentially agree and document how to use -1.
* Potentially clean up other existing parts of https://www.mediawiki.org/wiki/Gerrit/Code_review