On 09/06/2013 10:42 AM, Dominique Leuenberger a.k.a. Dimstar wrote:

Quoting Sascha Peilicke :

...

Usually, you are mostly interested in incoming requests. That means requests to projects where you hold any (maintainer, bugowner, reviewer) rights but are not the submitter. Similarly, "outgoing" would only display "your" requests to wherever.

If both tables would include request state, I guess it's ok to have the old "declined requests" as part of outgoing. If that's not obvious enough for people, it could also be a separate table (and not showing up in outgoing).

Frankly speaking, I did like the "home" view we had until two days ago...

The split into three tables * Review * New * Declined

Made perfect sense to me, with the various roles I do:

* review was everything to be handled 'at any moment' * NEW usually is my 'long' list of packages ready for checkin GNOME:Factory has, just like openSUSE:Factory, a review/checkin process). The packages could lie there 'for a while' without disturbing anybody.. and it was always simple enouh to have an immediate overview of the balance. * Declined view: really handy to have. Of course hermes sent an email as well...

I'd opt to just revert to the last state :)

But maybe using the tab-ified interface to save some scrolling? Either way, I like playing with the e-mail metaphor of inbox/outbox so that the the request direction is extra clear. People need to be aware that they're supposed to do sth. incoming reviews (10) | incoming requests (5) | outgoing declines (2) | outgoing $therest (7) | ... I'm not sure if in this scheme,it makes sense to differentiate between state "declined" and all other states. Maybe just a default filter on "declined" state is enough so we would have: incoming reviews (10) | incoming requests (5) | outgoing (2) | ... Where the number "2" counts requests in states new, review and declined. However, there should also be a way to display all the other (accepted, revoked, superseded) requests from the past. Previously, it had been the "show all requests" view from the past, but in my proposal, it would move into the other tab. Obviously, the tab-ified interface is only performant if tabs are loaded via ajax only when they become visible the first time. Well, maybe except the default tab, which could be rendered as part of the normal response. -- Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)