Talk:Gerrit/Code review

"Reversions themselves are always "ok"."
What if person A makes rX, which fixes bug P, and then person B reverts rX in rY because he thought it added bug Q, which was actually caused by something else. Since rY re-introduces bug P, can't it be marked fixme? Aaron 23:43, 15 November 2010 (UTC)


 * We mark reversions "ok" because it's OK to be cautious. The reviewer may have reintroduced the bug, but at least the situation is no worse than it was in the previous release. The onus is on the developer to convince the reviewer that their changes are worth having. The change that introduced the bug in the first place can be set from "resolved" back to "fixme", and the relevant bug reopened, while the developer is working on a solution that will make everyone happy. If it proves that the revert was a mistake, then the developer (or someone else) can reapply the change, once consensus is established that that's the right thing to do. -- Tim Starling 05:16, 3 February 2011 (UTC)

Inspected and tested
Hallo. What is exactly the meaning of "inspected" and "tested" in code review?

If i have to guess, "inspected" = "i read the code" and "tested" = "i tried to run the code". And in both cases it also means "i think that it's fine, but not sure enough to mark as OK".

Did i understand correctly? --Amir E. Aharoni 00:26, 18 October 2011 (UTC)
 * Yes! Sumana Harihareswara, Wikimedia Foundation Volunteer Development Coordinator (talk) 18:37, 17 February 2012 (UTC)

To add re Gerrit
-2 does not veto a change or prevent a merge going through. It's a strong disapproval. But another project owner can still come along, add a +2, and merge. The only way to actually cancel a commit and take it out of the merge queue is to click Abandon Change. Sumana Harihareswara, Wikimedia Foundation Volunteer Development Coordinator (talk) 23:36, 27 February 2012 (UTC)

"the code will still make sense in five years"
This page says:

''Remember that when you mark a commit with +2, you're saying: ...''
 * the code will still make sense in five years.

Aren't we exagerating a bit here? --JGonera (WMF) (talk) 18:21, 27 December 2012 (UTC)

Moving +2 specific info to +2
This page would benefit from better neighborhood with +2. The content that applies only to developers with +2 permissions could be moved there, making this page lighter and easier for new developers willing to learn how to exercise their +1/-1 powers.--Qgil (talk) 22:09, 28 February 2013 (UTC)

Why for MediaWiki code review only?
This is the only document we have here for people willing to contribute their time reviewing changes in Gerrit. However it is focused in MediaWiki when the changeset queue is full with changes of many other projects and we welcome feedback on all. The basic advice for any reviewer could be placed in a first, simple section. Then MediaWiki or any other project could have whatever specific advice in their own sections.--Qgil (talk) 22:15, 28 February 2013 (UTC)

Adding a "privacy" section
We at the Wikimedia Foundation are in the process of revising our privacy policy, which now refers to our code review practice. We'd like to implement a change to this document that reflects that. I don't have time right now to make this work in a less WMF-centric way, and it may not be possible, but I'd like to create a new section which covers these two points:
 * Does the feature generally conform to the Wikimedia Foundation privacy policy?
 * If this creates a new operational requirement in order to conform, is there a realistic plan to ensure that the responsible parties know and are ready to comply with the new requirement?

Thoughts? -- RobLa-WMF (talk) 23:04, 29 January 2014 (UTC)
 * A few other points that Rob and I had discussed (though so long ago that he may have forgotten :). These are less about privacy per se and more about data retention; not sure which frame works best. I tried to frame these in the style of the current document, particularly the security review section:
 * * The reviewer should have read and understood the data retention guidelines and should be aware of the retention issues discussed there.
 * * Check what data is retained by the code being reviewed.
 * * Check that, if required by the data retention policy, that the stored data is deleted in no more than the time permitted by the policy.
 * This could perhaps be strengthened by adding separate points for PII (as opposed to data generally), but I'm not sure how best to phrase that. —LVilla (WMF) (talk) 18:26, 30 January 2014 (UTC)
 * The only issue I see is that sometimes the retention is tied to the operating environment (like relying on a cron-job to run deletion scripts). But it seems like a lot for a developer (especially our volunteers with +2) to have to ensure Ops is setup correctly before they merge a change. Should we also require some sort of document in the repo that tracks any operational considerations for data retention? CSteipp (talk) 23:55, 30 January 2014 (UTC)
 * I'm tempted to say "if you can't guarantee it is deleted, you probably shouldn't be recording it". (Certainly, there are lots of examples of data retention problems that boiled down to "I kept it because I forgot to delete it, and I could have deleted it immediately.") But I definitely see the point about burdening non-WMF reviewers and committers. More generally, I really don't know enough about how platform/ops communicate with each other to say how best to implement this in practice. —LVilla (WMF) (talk) 23:32, 11 February 2014 (UTC)