-----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 [email protected] > 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----- _______________________________________________ Kde-testing mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-testing
