{"id":1049,"date":"2010-03-01T23:39:50","date_gmt":"2010-03-02T04:39:50","guid":{"rendered":"http:\/\/mikeconley.ca\/blog\/?p=1049"},"modified":"2023-12-20T16:25:17","modified_gmt":"2023-12-20T21:25:17","slug":"author-preparation-in-code-review-what-are-those-authors-saying","status":"publish","type":"post","link":"https:\/\/mikeconley.ca\/blog\/2010\/03\/01\/author-preparation-in-code-review-what-are-those-authors-saying\/","title":{"rendered":"Author Preparation in Code Review: What Are Those Authors Saying?"},"content":{"rendered":"

If you recall, I’m looking at author preparation in code review, and whether or not it impairs the ability of reviewers to perform objective reviews effectively.<\/a><\/p>\n

If this is really going to be my research project, I’ll need to get my feet a bit more wet before I design my experiment.\u00a0 It’s all well and good to say that I’m studying author preparation…but I need to actually get a handle on what authors tend to say when they prepare their review requests.<\/p>\n

So how am I going to find out the kinds of things that authors write during author preparation?\u00a0 The MarkUs Project<\/a> and the Basie Project<\/a> both use ReviewBoard<\/a>, so it’ll be no problem to grab some review requests from there.\u00a0 But that’s a lot of digging if I do it by hand.<\/p>\n

So I won’t do it by hand.\u00a0 I’ll write a script.<\/p>\n

You see, I’ve become pretty good at manipulating the ReviewBoard API<\/a>.\u00a0 So mining the MarkUs and Basie ReviewBoard’s should be a cinch.<\/p>\n

But I’d like to go a little further. I want more data.\u00a0 I want data from some projects outside of UofT.<\/p>\n

Luckily, ReviewBoard has been kind enough to list several open source projects that are also using their software<\/a>.\u00a0 And some of those projects have their ReviewBoard instances open to the public.\u00a0 So I just programmed my little script to visit those ReviewBoard instances, and return all of the review requests where the author of the request was the first person to make a review.\u00a0 Easy.<\/p>\n

Besides MarkUs and Basie, I chose to visit the Asterisk<\/a>,\u00a0 KDE<\/a>, and MusicBrainz<\/a> projects.<\/p>\n

Asterisk was a crapshoot – of all of their review requests, not a single one returned a positive.<\/p>\n

But I got a few blips on the others. Not many, but a few.<\/p>\n

I read all of the author preparation for each blip, and broke down what I read into some generalizations.<\/p>\n

So, now to the meat:\u00a0 here are some generalizations of what the authors tended to say, in no particular order.\u00a0 I’ve also included a few examples so you can check them out for yourselves.<\/p>\n

“Here’s why I did this”<\/h4>\n

The author makes it explicit why a change was made in a particular way.<\/p>\n

Examples:<\/p>\n