If you're the new UI-Review Coordinator, doing a UI-Review or just want to know what happen in a UI-Review then you've found the right page for explaining that. This article discusses what steps are taken to coordinate a UI-Review with the UI-Reviewers and the GNOME community.
A top level bug is a "meta-bug" that depends on other bugs in the bugzilla system. Each module with a ui-review is a bug report which may actually have other bug reports that it depends on. This "meta-bug" is done so that the UI-Review top level bug can be closed once the individual module ui-review's are complete.http://lists.gnome.org/mailman/listinfo/post-only
To create the Top Level Meta-Bug, go to open a new bug in the GNOME bugzilla. In the new bug select the general category. If you don't have a bugzilla account already you'll need to sign up for one and then get someone (probably the person who put you as the UI-Coordinator) to upgrade your bugzilla privileges so you can at least modify bugs. Next put your bugzilla registered email address in the "Assigned To:" field, in the "Keywords:" field put ui-review so this bug will show up in the ui-review queries. Select the proper GNOME Version from the radio choices, use a summary and description similar to the example below.
See bug #129568 for an example on how to create a top level bug.
Run a query on the existing ui-review bugs by searching all modules for the ui-review keyword and look at them to get a feel for that the ui-review bugs look like.
Close what bugs you can from the search query, now you'll need to start getting some help from the UI-Review volunteers to move any further on the ui-review bugs.
The How to Write a UI-Review page is probably old by now and will need some fixing, look for errors with all the links and clean up any irrelevant material. The more clear and precise you can make these pages look the easier it will be for anyone to help out with ui-reviews. Also, while you're at it, fix this page too; there are likely to be lots of mistakes in it and you want to look as good as possible in this job.
Here's how to get the sources for these pages:
cvs -z3 co web-devel-2/content/projects/gup/ui-review
Take a look at the older start pages for how to create this page. Here are the links to the 2.3 and 2.5 ui-review pages. Check one of those pages out from CVS to create the new page. For the 2.5 review the CVS checkout will like like so:
cvs -z3 co gnomeweb-wml/www.gnome.org/start/2.5/ui-review
UI-Reviews are a team effort, now that you've put some work into organizing some things it's time to let other people know they can start getting their hands dirty in some user interface work. You'll need to be subscribed to the lists you'll announce to or you may subscribe to the post-only list which allows you to post to all lists, but not receive all the messages from those lists. Announce your message to the following lists: gnome-list@gnome.org, gnome-love@gnome.org, gnome-bugsquad@gnome.org, desktop-devel-list@gnome.org, gtk-devel-list@gnome.org, usability@gnome.org. You can take a look at this example announcement from the usability archives for a reference.
You've announced that the UI-Review stage has begun this will give people a little time to check out the docs you've created and respond. Now you need to create a strategy for reviewing as many modules as you can while staying in the strict time frame of the review. This strategy also gives the maintainers a heads up to be ready for a ui-review as well as letting others who are interested in helping know when the module they are most familiar with is going to be reviewed.
You might start some discussion asking what applications should get priority in the review. Most times maintainers will know if their app is in dire need of some love. Sending a message to the usability list will be a good way to get feedback on this.
Use the discussion to aide your strategy, but a generic plan of attack should look something like this:
Now that you have a strategy in place announce to the lists that you'll be hosting a IRC session of UI-Review. Pick a day, a time and let everyone know what's going on. Here are some example emails [1,2] you can use as guidelines.
After each UI-Review session you should send a message to the usability list and the desktop-devel list with status updates on the progress of the ui-review. Your status updates should include the following:
And something witty to make everyone laugh (don't work too hard on this one ;-) )
Don't forget to update the start page to reflect the changes that have happened
Before your job is really over you'll need to send a final status update to the list detailing (in the same way) what happened during the UI-Review.
Congratulations and good work! You can continue to close bugs, work with the developers and update the start page as things change.