[KDE Usability] Usability reviews alongside code reviews

[Celeste Lyn Paul]

I think that could work if developers were good about including
screenshots in their reviews. In the past I've had a hard time
reviewing software because they expect you to apply patches to see the
changes. Other than that, I've also see it work very well for small UI
updates for KDE HIG compliance.

On Wed, Jun 13, 2012 at 1:12 PM, David Edmundson
<david at davidedmundson.co.uk> wrote:
> [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
> _______________________________________________
> kde-usability mailing list
> kde-usability at kde.org
> https://mail.kde.org/mailman/listinfo/kde-usability



-- 
Celeste Lyn Paul
KDE Usability Project
KDE e.V. Board of Directors
www.kde.org