Connecting Ubuntu, Upstreams and Users.

Since we started focusing on bridging the gap between upstream projects, users, and distribution packagers, we’ve been talking to a lot of people, to help us better understand the size and nature of those gaps.

(Those conversations are continuing, too — if you’d like to be a source, especially if you’re an upstream developer whose software is packaged in Ubuntu or Debian and you’ve seen bug reports, translations, or other data come to your project via Launchpad, then please see Matthew Revell’s invitation.)

Meanwhile, we’ve started to synthesize what we’re hearing so far. Recently I went through the raw data to distill it into key points. I filtered out some stuff that had nothing to do with bridging the gap, or that was only mentioned by one or two people. (Conversely, I kept some stuff that I know we’ve heard mentioned by multiple people, even though I may only be able to offer one or two citations here.)

Filtering notwithstanding, what’s interesting is how consistent a lot of the feedback is. The same points kept showing up over and over:

  • Speed: Launchpad needs to be faster.

    Cited by:

    • Sandy Armstrong
    • Jussi Schultink
    • Ted Gould
    • Marjo Mercado
    • Jorge Castro

    There is universal agreement on this. We’re working on it everywhere, as there isn’t one magic fix that will solve it for all of Launchpad.

  • PPA-of-the-day is highly desirable! The easier it is for users to test, the more testing they will do. Therefore, instant packaging of latest upstream code would be awesomelicious.

    Cited by:

    • Scott Ritchie
    • Sandy Armstrong (more or less)
    • Carl Richell
    • Ted Gould (see “continuous integration” in his page)
    • Jorge Castro

    Yup. We’re working on this right now.

  • Forward bugs more easily, more quickly, and link upstream back to original reporter. (Bryce Harrington, for example, scripts Launchpad very heavily to get what he wants; he points out that the original reporter of a bug should not have to create an account in the upstream tracker to be contacted by upstream — simply having filed in Launchpad should be enough.)

    Cited by:

    • Sandy Armstrong (as an upstream, wants timely forwarding)
    • Bryce Harrington (as a reporter, wants ease-of-forwarding)
    • Jorge Castro

    We’re trying to nail bug heat and bug Q&A first, but we’re keen to do this too.

  • Branch/patch equivalence: Transform one into the other in one click, and push changes easily to upstream in the form upstream prefers.

    Cited by:

    • Jorge Castro
    • Cody Russell (sort of)
    • Sidnei da Silva

    This is a high priority; we’re working on it!

  • Be able to instantly see attributes of comments or commenters in a bug. E.g., tag the comment as “workaround”, have the commenter be displayed differently because of their role, their credibility, or some other quality. Seeing that kind of information in the UI would save a lot of time.

    Cited by:

    • Sandy Armstrong (sort of)
    • Jussi Schultink
    • Ted Gould

    This would be great. It’s not on Canonical’s roadmap right now, but we’d certainly be interested in helping any community developer who wanted to have a go at it.

  • Get more, better information from users in bug reports (e.g., many don’t say the version number of the software). Jussi Schultink mentioned some kind of LP-integrated screen capture would be great; I’m not sure how that would work, but it’s a neat idea.

    Cited by:

    • Sandy Armstrong
    • Jussi Schultink
    • Bryce Harrington

    This is more a set of related ideas than a fleshed-out requirement, but bug Q&A is probably a step in the right direction.

  • Launchpad’s search is ill-placed in the UI and/or ineffective

    Cited by:

    • Jussi Schultink
    • Ted Gould
    • Ryan Paul

    Insofar as placement goes, that should be a relatively easy fix. As for functionality, we should identify exactly what is going wrong (the raw data has more details). On a semi-related note: probably a lot of the searching people do in Launchpad is with the expectation of finding a match somewhere in the vast bugs database, in which case the new inline dupe-finding may help improve that experience, or at least reduce the necessity of having it.

  • Make it easier to find patches that distro should integrate. This could be a tool that would help everyone: not just Ubuntu, but other distros and upstreams too. Part of the trick is to look at other distros’ trackers for patches, not just at upstream.

    Cited by:

    • Jorge Castro
    • (Others say this too, just happens not to be in the notes I trawled this time… but I know it’s out there.)

    This is ultimately the “patch report” functionality that was discussed at UDS. While the full story is quite extensive and probably will not be in Launchpad 4.0, some of the sub-stories will be, in particular the parts that make it much easier to quickly see patches attached to Launchpad bugs, and to generate reports about patches.

  • Better bug dup searching, better UI for handling bug dup scenarios

    Cited by:

    • Ted Gould
    • Marjo Mercado (esp bugs in other trackers)
  • Access to older PPAs would be great. (Then users could figure out when a bug was introduced, for example.)

    Cited by:

    • Scott Ritchie
    • Ted Gould
  • Cross-distro bug forwarding. E.g., LP copies a bug from Fedora’s tracker and then forwards it to the proper upstream.

    Cited by:

    • Sandy Armstrong
    • Jorge Castro (in private conversation)
  • More ways to view bugs. E.g., omit “fix committed” bugs from list.

    Cited by:

    • Sandy Armstrong
    • Jorge Castro (IIRC, not sure it’s actually in his page)

Interesting that three of those last five related to searching & reporting.

I know much of the above just confirms the direction we’re already going, but I wanted to share it anyway. The emphasis on speed over features was a bit of a surprise to me; good to know.

If you’re really feeling squirrelly, go look over the raw data itself. I left a lot. out above; users have lots of ideas about how to improve Launchpad (as well as much praise for it), and it’s kind of fascinating reading:

The interviewees were:

Bryce Harrington Canonical – stack
Carl Richell System 76. Linux computers, yay!
Cody Russell Canonical – Desktop Experience
Jorge Castro Canonical – Ubuntu Community
Jussi Schultink IRC Council, Kubuntu / Ubuntu Studio
Marjo Mercado Canonical – Ubuntu QA
Ryan Paul Gwibber upstream
Sandy Armstrong Tomboy upstream
Scott Ritchie Packager, mostly for universe, esp WINE
Sidnei da Silva Canonical – Landscape
Ted Gould Canonical – indicators / sys status

The sources include a fair number of Canonical employees. That’s just because we had easy access to them right away, while we were still tracking down upstream developers to interview. We will continue to talk to both, but our emphasis is now on upstream developers and on the people who bridge the gap between upstreams and distribution.

5 Responses to “Connecting Ubuntu, Upstreams and Users.”

  1. Sense Hofstede Says:

    As a member of Bug Control I’d welcome any improvements for the bug tracker, and I have to say that Launchpad is already doing some great stuff.
    However, there is of course still room for improvement.
    Currently Launchpad throws the whole conversation around a bug on one pile and the participants have to figure out what’s relevant to them and what’s not. Especially bug reporters without a lot of technical knowledge find this hard to do and are often unable to grasp the different processes we use in Ubuntu.
    Separating the many different conversation tracks and disabling status changes for people merely reporting bugs would help a lot. I’d suggest to split the conversation up in the following tracks:
    * Ubuntu technical discussion
    * Upstream technical discussion (this should be accesible, but integrating it almost seamlessly in the conversations on Launchpad, which is being done right now, just works confusing)
    * User communication 1
    * User communication 2
    * User communication n-1
    * User communication n

    Why so many user communication tracks? This is because I believe that although different reports from users may have the same cause, they still need support (and consolation!) as well. This is different for all users because of their level of technical knowledge and because of the different ways a bug can show up.
    By taking the communication with other users and the technical discussion away from the user she/he will feel more important and be less confused. Bug Control can explain the actions being undertaken in those tracks and provide support to the users without disturbing the technical discussion. However, in order to prevent duplicating efforts and prevent miscommunication, Bug Control should be able to let comments appear in multiple tracks at the same time.

    Another small issue is that not all bug numbers are included in changelogs and are therefore not closed, leaving them open. Users are unaware that their problem has already been solved and bug triagers have to do extra work to make sure the bug really has been fixed.

    I really like the suggestion to mark certain users in the bug conversations as more thrustworthy or authorative than the rest. People like being helped by someone officially from the project they´re reporting a bug against. Maybe this could be done by allowing projects to create different types of marking, i.e. different colours for different teams and levels of authority.

    Searching for duplicates can always be done better, since a lot of the bugs are actually duplicates, but not handled properly. This has the consequence that people are left out of the conversation, open bugs linger around and Bug Control has to do a lot of extra work to search for duplicates. So, yes, please imrpove the duplicate search! Additionaly it would be nice if teams like Bug Control would have a list of potential duplicates next to a bug they´re reading, so they can mark the bug as a duplicate. A lot of reporters don´t properly look for duplicates first, so making it easier to find potential duplicates after a bug has been reported has use as well.
    It would be even better if this search/list would be automatically adapted to the number of duplicates the bug itself and its potential duplicates have, i.e. if a bug is most likely a master bug, the thing could default to mark other bugs as duplicates of it, and if the potential duplicate is most likely the master bug, vice-versa.

    I would suggest to not forward automatically unless Launchpad is very good at finding duplicates at that upstream bug tracker. Furthermore — like said before by other people — not all upstreams may be very happy with bug reports that were automatically generated by Launchpad.
    Something that would be nice is that if a bug watch is marked as a duplicate upstream, Launchpad does the same, and if there is already a bug on Launchpad linking to that upstream bug, Launchpad marks the bug as a duplicate of that bug on Launchpad.

    I hope this is any useful and readable!

  2. Sense Hofstede Says:

    Something I would also love to see is a report of bugs I’m triaging. It would make it easier to not forget bugs and watch the general health of the bugs I’m working on.

    Maybe this could be implemente by adding a ‘Triager’ filed like Blueprints have as well. The first member of the team assigned as the bug triagers — possibly integrated with the system marking contributions to bug reports as special/authorative — that changes the bug report could automatically assigned as the bug report’s Triager, with a checkbox for opting-out.

  3. grof Says:

    “Launchpad’s search is ill-placed in the UI and/or ineffective” – few days ago I have posted idea how search should be implemented for Launchpad Translation to brainstorm:

  4. Launchpad Blog Says:

    […] tracking in Launchpad which will be one of three stories within the larger story of connecting Ubuntu, upstreams, and users that the bugs team will focus on in the next few months of development […]

  5. Launchpad Blog Says:

    […] been asking users what they want and trying really hard to listen to them. And, of course, since we’re Free Software now, all […]

Leave a Reply