Web Extension for Debiasing Code Reviews in Splinter Experiment

NEW
Unassigned

Status

()

Bugzilla
Bugzilla-General
3 months ago
a month ago

People

(Reporter: emceeaich, Unassigned)

Tracking

(Depends on: 1 bug)

Details

Design, build, test, and deploy a web extension for bugzilla.mozilla.com, which when used, will redact the author of a change log/patch.

It is understood that this will not work in all situations (pull requests linked from GitHub, diffs pasted from email.)

The extension should also append an additional field (which we will check if can be done) indicating that the extension was active when the review was done.
:dylan, can we send an additional value back up with a review that corresponds to a custom field or flag?
Flags: needinfo?(dylan)
To redact attachment creators in splinter, the nodes associated with #attachmentCreator would need to be changed.

To redact comment-creators, the nodes associated with .attach-author would have to be changed. 

To redact comments, look for nodes with the class .change-author. You will need to search within the comment itself, which is in a PRE tag, and use that to scrub comment authors.

Comment 3

3 months ago
A reviewer may want to go through the code "blind" and then _after_ commenting, re-show the personal info in order to add a polite welcome for a new contributor.

We should be able to log if the review has had some comments done before turning personal info back on -- so not just blind/name-attached but also part blind.
Summary: Web Extension for Debiasing Code Reviews Experiment → Web Extension for Debiasing Code Reviews in Splinter Experiment
How do you intend on hiding the information on the show bug page?
Flags: needinfo?(dylan) → needinfo?(ehumphries)
The web extension will use a content script to hook into class names used to display attachment authors and pattern matching in comment text on show bug, and on the attachment detail page.

See comment #2 above.
Flags: needinfo?(ehumphries)

Comment 6

3 months ago
I fully support this effort to tease out some biases. However, there are risks that *complete* blinding could be counter-productive. As a reviewer, I often take prior interactions and experience into account when reviewing. For example, if I know they've done hundreds of patches, I can usually be more concise and blunt. Conversely, I need to be more gentle and hand holding to newcomers. On a personal level, if I know the author is from a Commonwealth country, I may use "proper" English spellings so as to not cause offence with my American/Low English. Or I may work in a meme or cultural reference I know they can relate to. This personalizing of review feedback helps soften what can be a conflict-oriented interaction, leading to a more positive outcome.

So my request would be to conditionally blind authors. Perhaps we could only blind people if they have less than N attachments or something. That would achieve the stated goal of debiasing for new contributors while allowing learned context to improve future interactions.
Depends on: 1373051
Depends on: 1375229

Updated

2 months ago
Assignee: nobody → general
Component: Community Ops → Bugzilla-General
Product: Participation Infrastructure → Bugzilla
QA Contact: default-qa
Version: other → unspecified

Comment 7

2 months ago
Right now Bugzilla-General is a better product for this bug than Community Ops, just moved it.
Depends on: 1381505
You need to log in before you can comment on or make changes to this bug.