Hello all, On 03/27/2018 09:09 AM, Raphael Hertzog wrote: > Hi, > > On Tue, 27 Mar 2018, Chirath R wrote: >> I have made mockup designs for package overview page as part of GSoC >> project. It would be nice to get feedback on the design and if you could >> mention which fields are most important. > I find the table layout more useful. Concerning the fields, you need > to consider the use-cases. Here are the two main use cases that I can > imagine: Agreed. > > As a team contributor, I want to check what packages need to be worked on. > In this situation you want all relevant informations of the work to be > done: > - the action items should be easily accessible at least in the expanded > view, the number of action items by severity would thus be interesting > - the bugs data > - the lintian data > - the availability of a new upstream release > - the status wrt what's in the VCS > - the grouping by "status/action needed" makes it easy to find a package > with a specific issue to fix and offers a sort of "process pipeline" > where the package progresses from group to group until's ready for > upload Initially, my idea was to implement this team contributor view, similar to PET [1]. Mainly, because PET is not so easy to evolve and with the migration of git repos to salsa it is not working anymore. > As an outsider, I want to check what packages are maintained by the team, > the versions availables and what all those packages are about and why they > are there. > - the grouping should be gone, or should be by team-specific categories > which are meaningful for the end user > - all the version data is interesting > - we want the description too > - etc > > It's not clear that both use cases can be met with a single version of the > page. This is a good point, but probably we should accomplish it with another page. What do you think? [1] https://pet.debian.net/pkg-ruby-extras/pet.cgi Thanks for the feedback :) Cheers. Lucas Kanashiro.
Attachment:
signature.asc
Description: OpenPGP digital signature