Usability reviews alongside code reviews

David Edmundson david at davidedmundson.co.uk
Wed Jun 13 17:12:31 UTC 2012


[emailing both the KDE Usability and KDE Quality mailing list]

This is an idea I had with Björn Balazs during the KDE Workspace sprint.

Most (good) KDE projects use a service called Review Board for
reviewing new code. Other developers then look for bad code and
anything that could crash, doesn't follow standards, etc.
When there's been a large visual change this is normally accompanied
by one or more screenshots, normally in the form of "before" and
"after".

In reviewboard the developer tags which group (or groups) should
perform the review, normally just the team controlling the code.
What I'm proposing is that we have a special group on ReviewBoard
called "Usability" this is an open group that any usability experts
can join. When a developer submits a change that has a large visual
impact they should upload screenshots and mark that it should be
looked at by the usability team in addition to the normal review
process.

Everyone on this team will receive these reviews, and get a chance to
comment on the screenshots.

This a really simple solution to set up, and the only technical change
we need is a new group in Reviewboard.

It will be useful if we can do usability and interface reviews BEFORE
code is merged, rather than our traditional approach of doing it after
a release, which is far too late. Also it's not invasive on
developers, they have to tag their review as wanting feedback from
usability as well as their traditional reviews. This is not a policy
change, anyone can already comment on any review, this just makes it
more accessible to involve the right teams.

Though we need to make sure we:
1) Only add useful comments and/or approval, but not click the button
"Ship it" which tells the submitter they can commit their code. (the
maintainer alone should do it)
2) Only comment on what's changed, not on anything in the relevant app/dialog
3) Avoid internal arguing over design decisions.
4) Are constructive and say _why_ the developer should edit something.

Do you think this is a good idea?
If there was such a group would you be happy to join?

David Edmundson


More information about the Kde-testing mailing list