Some uploads missing from +packages

I believe that listing only shows the latest package uploaded to each release, to avoid the list blowing out of proportion. Is that a problem in practice? What sort of utility would knowing data for previous uploads help you? Note that you can navigate to previous versions by visiting the package pages..

Well, we use the +packages pages when reviewing people, say for Ubuntu Membership or MOTUship. For the packagers it's pretty vital.

I see. So ideally you'd like an option to display /all/ packages the person ever uploaded -- with bug and ticket stats, too?

Well, it would be very helpful to be able to see as much as possible about the contributions a user has made. Bug work can be reasonable seen from bug karma and recent bug work. Uploads are difficult because it can be difficult to keep track of who is uploading what, there is no karma, and reviewers often want to see specifically what people uploaded, etc. . The +packages page is a great view of work but it really does need to be a complete record.

There is very little point in having +packages if it leaves out uploads whenever it feels like it. It is the only record (other than searching through <distrorelease>-changes) of a person's uploads. If it isn't meant to show all of them, that should at least be noted on the page.

I agree that it should be a batched view of all uploads, with sensible defaults. We will also be adding karma for package uploads (hmm... some for PPA's, more for real distro packages :-)) which will restore some balance to the Force.

See also bug #43020.

William, please tell me what you think of this plan.

This is next to impossible to do without introducing batching, which requires some thought since +packages has got three sections of results on it.

So, the initial page will just change so that there is at most 60/(the number of types of package the person has out of {maintained, uploaded, PPA}) rows of data. This nicely covers the case where there are not many results to show.

Each section will have a "show all" that will reach a page containing a set of batched results that also show the previous versions, for the section of interest.

The actions menu will be expanded to include navigation links to each section, and back to the overview page.

It would be really nice to have bug #155956 implemented alongside this. +packages would then show a complete categorization of uploads and include all package activity. I think batching would be a good way to go. If there are 5 categories (maintained, uploaded, sponsored, mentored, PPA) and say show at most 10/section then you should get a reasonable sized page (max 50 entries) while still giving the proper information.

Having navigation available to complete information on uploaded packages would return the page to usefulness. Showing a trimmed default would be acceptable, but the page should indicate this with language such as "Last N uploaded packages", and should include *every* upload in that set (I'm not sure why you choose "60/$(num_types)" for the definition of N, but it doesn't really matter: I'm not likely to be interested in that data).

60 was plucked out of thin air to limit the result set. We can certainly increase that based on the 150 we have right now, but I'll be sure that we let you guys play with this on the dogfood server before we release it so we get some feedback.

Thanks for your input!

Just out of curiosity: what workflows are intended to be supported by this page?

In the case of a package maintainer wanting to review the bug status of maintained packages, I'd think that package subscriptions (and /+packagebugs) is more interesting. This is all the more true given that the primary distribution using Launchpad (Ubuntu) doesn't tend to have specific package maintainers.

In the case of someone wanting to review PPA contributions, I suspect that they would be better served by guidance on which PPAs contain their uploads, and inspection of those PPAs. For their own PPA, /+archive is much more useful. For team PPAs, a listing would be nice, but one expects most packages to be reviewed within the context of the PPA, rather than on a per-uploader basis. Further, open bugs in PPA packages is mostly meaningless, as one can't file bugs against a PPA, or report a fix with a PPA. Just linking to PPAs to which the user has contributed would likely solve most of these workflows.

In the case of someone wanting to review uploads to Ubuntu (e.g., in the context of reviewing technical work towards an application to MOTU or core-dev) the reviewer wants to see every version of every package uploaded (or sync'd), and it would be nice to be able to check diffs from these uploads to see the specific work done (currently this is a manual process, and now sometimes uses -changes scraping rather than +packages). In this case, bug counts are also interesting, although bug counts at the time of the upload are more interesting than current bug counts, as it helps indicate if someone routinely closes bugs when uploading packages.

Given that some people have thousands of uploads, batching of this information is a sensible performance enhancement, as long as the user remains able to page through it to see more (and the majority of candidates receiving technical review will have less than 100 uploads scrutinised, although both the absolute number and presence of specific packages (e.g. those in a specific component, native packages, packages related to a specific flavour team, etc.) are interesting, so these are not always the most recent uploads.

In summary, at least for the use cases I understand, I don't think the page as it exists now is worth preserving: I'd much prefer to see a page that provided navigation to /+packagebugs, to /+archive for each of those PPAs to which the user has contributed, and to a tool providing history of every upload/sync to each tracked distribution in which the user participates (perhaps batched) when viewing people records.

For team records, the page should be a redirect to /+packagebugs, as those teams maintaining a manageable number of packages ought be subscribed to those packages, and those teams maintaining an unmanageable number of packages (e.g. MOTU) are unlikely to examine the page. Also, teams cannot upload, so teams never contribute to a PPA or a distribution (although the members of a team may do so).

Ok so what we're going to do is an incremental approach to solving this because I think there are a number of different issues here. Emmet, I've taken your comments on board and what I think we can do is create a new navigation sub-menu under the Related Software tab, so it looks roughly like:

            | Profile | *Related Software* | Karma | Personal Package Archive |

 | Overview | Maintained Packages | Uploaded Packages | PPA Packages | Related Projects |

The "Overview" can be the existing page for now, which could be possibly tweaked to include your suggestions about packagebugs and listing archives rather than PPA packages. The other tabs will include batched listings of the existing sections in the old page. If someone wants to see more information then we can simply add a new tab without affecting the other pages.

Let me know how this sounds to you, I'll try and get it finished for the next release on the 20th if it's any good.

I think that would work for my use cases. I'm less sure about other's use cases. For clarity, the only reasons I look at that page are 1) to review someone's work as part of determining if I think they should be a member of ~ubuntu-dev, 2) As part of an overview of someone's general activity as part of determining if I think they should be a member of ~ubuntumembers, and 3) when I'm bored and wondering if any of the packages I've previously worked with might need deep bug triage.

I agree with having specialized pages for different aspects of a person's contributions to software in Launchpad, while the general "Related Software" page acts both as a general guide to someone's contributions (please report specific bugs about how it isn't), and as good-enough information for someone who has only one type of contribution without having to navigate to a specialized page (ditto).

I hope this can be presented without using a second navigation menu, though. Firstly because nested navigation menus are awkward, for the same reason as nested tabs are. And secondly because using a navigation menu would require either using "Overview" to mean two separate things on the same page (ugh), or reaching for the thesaurus.

One possible way of doing this is to use a hub-and-spoke navigation system like the secondary pages for a bug page: the specialized pages link back to their parent, but not to their siblings.

Another, slightly crazier, way is to style second-level navigation menus so that they don't look like navigation menus.

The other option was to include links at the bottom of each section in the "overview" page that say something like "See all uploaded packages", which takes you to the batch-listing page.

However, I think this hides these links somewhat. If someone is quickly looking to navigate to the uploaded packages page they'd need to scroll down the page and find the link. Presenting them in the sub-menu keeps them more visible for quicker navigation.

I agree that overly nested navigation menus are awkward, but we're only talking about 2 levels in total here, it's not that bad is it? And there is precedent on the other person-related pages!

Also, maybe "Summary" instead of "Overview", but still I fail to see the reticence for that. The +related-software would still only ever go to one page. What are the "two separate things on the same page" that you refer to?

I agree with having links at the end of each section. If we had a smarter Related Software page, these links would be easier to find without scrolling. For example, the "Failures", "Bugs", "Blueprints", and "Questions" columns don't seem particularly useful (at least, not for a summary page); if they were removed, the page could use a two-column layout if the window was wide enough (something like {float: left; min-width: 20em; width: 49%;} for each of the sections).

Launchpad developers understandably become desensitized to the complexity of Launchpad's navigation. Almost every Launchpad page has two levels of navigation already: the hierarchy and the applications. A navigation menu is a third level, and a second navigation menu is a fourth level. Thanks for reminding me to report bug 255802 about abolishing the second-level navigation menu on person pages. :-)

The two "Overview"s on the same page would be (1) *Overview* / Code / Bugs / Blueprints / Translations / Answers, and (2) *Overview* / Maintained Packages / Uploaded Packages / PPA Packages / Related Projects.

Interesting ideas, thanks Matthew.

I've no idea if people use "Bugs" and "Questions" and they certainly have no relevance in the PPA section. The "Failures" also seems a bit useless to me - are build failures really relevant to anyone here? Emmet?

For the sake of getting this page functional again, for now I am going to do the navigation tabs because it's the least amount of work. They are trivial to add and remove so I can change them in favour of in-line links later if needs be, when the summary page is redesigned. For now, I think it's more important to get the other sections batched so the information that people need is available.

I would welcome more comments from people on all the layout proposals so far. When I have a working mockup, I'll put it on the dogfood server for people to play with.

Build failures are interesting to me. If I upload 20 packages at once to e.g. clear NBS, I like having an overview of which builds might need attention or retries. Otherwise I need to dig this up on each and every package page, which is annoying. Mind you, I'm generally only interested in this in a transient manner, and so my interest in build failures in history is limited.

That said, if I'm reviewing someone's work, and many of the packages they uploaded have unresolved build failures, that is interesting to me as it may indicate that the person isn't taking care to ensure the work they do is reaching users, or not providing sufficient follow-up.

So yes, I'd like to keep information about build state.

Folks, please check out my mock-up on dogfood. Two good pages to view are:
https://dogfood.launchpad.net/~pitti/+related-software
and
https://dogfood.launchpad.net/~doko/+related-software

The dogfood database server is very slow so you may get time-outs on the initial page load.

This is looking much better, although still some minor textual and filter changes would improve it. Thank you for restoring the page to use. Also, looking at the proposed UI, I'm inclined to agree more with mpt about the number of levels of navigation, but I still think the page needs a complete overhaul to address common use cases, etc. (but that should be handled by another bug).

Landed in RF 6863

Please file separate, specific bugs for suggestions on how you'd like this improve. Thanks for the input so far!

Ok not quite fixed. Batching was implemented which has fixed bug 43020, but this page should also be showing non-published packages to give a complete history for the person.

RF 6899