Usability reviews alongside code reviews

[Janek Bevendorff]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I think this is a splendid idea to ensure consistency and usability
for larger changes to the UI.
As a webdesigner and new member of the KDE quality team I would also
like to join this group if this should become reality.

Best regards
Janek


On 06/13/2012 07:12 PM, David Edmundson 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-testing mailing list Kde-testing at kde.org 
> https://mail.kde.org/mailman/listinfo/kde-testing
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJP2MuJAAoJEN/wwJ2g68YYH3IH/1vd9ds4WfMcf8TIxH6KuDOr
JMI2P0UrgpohB+gu38e728e5yDMqMmYSz5CYCMmNBKNNoA5V0HjWKWLq0f2lHACK
gyBXlwpPOhNcwVEBAL254RGtVQp8yVIhDrygEicYHsRchATrB2n7ZBUBOa9+4PJJ
CgLZ3YPA1LKzU0j+ARPOuzssHKpl3swBmFfPpjhNPO3Tm5Raa6zKS65bwj0ekBKR
ZSZFWP6S/JGyRPDRi5letLuz3kdZv1+zFBlHbsm3m1iYZR2O3XGSXwRyqIWh17X0
VHqAkN7B0LU8s+PhpayAouedH1vmMFZ2oXZLSZ4y4EwokEEw/BLzG0WKvVd29eA=
=AI+I
-----END PGP SIGNATURE-----