Mailinglist Archive: opensuse-buildservice (148 mails)

< Previous Next >
Re: [opensuse-buildservice] About the recently deployed "home" view
On 09/06/2013 10:42 AM, Dominique Leuenberger a.k.a. Dimstar wrote:

Quoting Sascha Peilicke <speilicke@xxxxxxxx>:

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
and it was always simple enouh to have an immediate overview of the
* Declined view: really handy to have. Of course hermes sent an email as

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
Sascha Peilicke
SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend├Ârffer HRB 16746 (AG N├╝rnberg)

< Previous Next >