launchpadblog

It’s my pleasure to announce that as of today, Matthew Revell is the new
Launchpad Product Manager replacing Jonathan Lange.

We were seduced by his bold vision for Launchpad along with his data-centric approach that he intends to bring to the role. He also has an already extensive experience interacting with Launchpad developers and users. If you read this blog, you probably read something written by him! Or you might have interacted with him in one of the many user-research sessions he ran. The introduction of user-research helped us release better designed feature. Building on this experience, we hope that his leadership will bring Launchpad to the next level.

Matt will communicate more about his plans for Launchpad shortly. In the
mean time, let’s give him our warmest congratulations!

Users can use the affects form on the bug page to change which project or distribution the bug affects. You can also select the affected package. Lp API users can assign a project, distribution, or package to the BugTask target property to change the affected bug target. The behaviour is similar to the way questions can be retargeted between projects and distributions. Affected series cannot be changed, though the affected series package can be.

Retargeting a bug to a distribution, package, or project

Previously, users had to mark a bug affecting a project or distribution as invalid, then add a new affected project or distribution. This cluttered the UI, caused excessive emails, and made pages slower.

Not long back, Sumana Harihareswara, who is Volunteer Development Coordinator at the Wikimedia Foundation, contacted some members of the Launchpad community to ask how we handle code review.

She’s written a summary of her research for the Wikimedia community.

It makes interesting reading for someone, such as me, who’s close to the process. If you’re interested in contributing to Launchpad, Sumana’s report is a really useful overview of how we review and deploy code.

I can’t believe it’s been two weeks already! From June 25th to July 1st, the whole Launchpad team was gathered in Dublin for our semi-annual all-hands event. Like usual, we also invited the Bazaar team and  one of our friendly sysadmin­.

The theme this time around was “UI, UI, UI”. Since the January squad reorganisation, it became evident that a big stumbling block for squads working on features was UI work. Our team is still inexperienced with JavaScript and the YUI3 framework. So each squad has encountered similar problems and sometime found different solutions. We wanted to take advantage of the face-time to come to a common understanding of the best patterns to use.

In the end, it was a week of intense hacking on UI infrastructure, with part of the mornings dedicated on presentation where people shared what they learnt in the past 6 months.

Projects that were worked on during the week:

• An asynchronous notification system (extracted from Landscape) which will allow us to update pages as soon as tasks complete on the backend.
• We ditched our buggy Windmill-based Javascript integration tests, in favour of a yuitest-based suite. We already use yuitest for JS unit tests, but now we’ll be able to use it  for integration tests where  we need to make XHR requests to a live server. We’ll even be able to set server-side fixtures from within the test!
• Investigate the use of selenium2 for acceptance testing. These are tests ensuring a complete workflow works and that ideally will be able to run against both the staging server as well as within tree for regression testing.
• Integrating loggerhead-backed branch data on some Launchpad pages. You should soon be able to get the diff of a particular revision directly on the merge proposal page.
• Infrastructure to refresh all the client-side representation of objects related to a page in one request.
• Many UI bugs were fixed.

This was also the week we said farewell to old friend: Jonathan our Product Strategist  and Ursula Junque who is now working as QA analyst for the Ubuntu Server team. In the end, Jono didn’t get pied as we still had a huge number of Critical bugs left open. We did rejoice in achieving our performance improvements target. Given the trend, I estimated that we have still 6 months before emptying the Critical bugs list. The new target is to reduce to a 100 for October. Let’s see if I was more realistic this time around.

And we also took the traditional team picture.

Great fun it was, and I can’t wait for the next one in January.

Photo by Miss_Colleen. Licence: CC BY-NC-SA 2.0.

Visit this URL:

https://launchpad.net/~

Cool, eh?

Same works for https://bugs.launchpad.net/~, as well as code, translations, answers and blueprint.

Actually, it’ll work anywhere that you’d normally put /people/+me or your own Launchpad id — so long as you’re logged in.

For example: visit https://launchpad.net/~/+participation to see a list of all your team memberships.

Thanks to Martin Pool.

Photo based on an original by Michael Francis McCarthy. Licence: CC BY 2.0

So, you’re about to select someone in Launchpad — maybe you’re assigning a bug — and you’re not exactly sure you’ve got the right person. One way to confirm would be for Launchpad to tell you what relation that person has to the project you’re currently dealing with.

Sound like something that might help you?

If you’ve got 25 minutes today or tomorrow, you can help us choose the best way to show those affiliations. Sign up to let us know if you’re interested. There may even be an Amazon voucher in it for you 🙂

Launchpad has quite a few background tasks that update things outside of your browser request, and the only way you know that they finished is to reload a page to see if it changes.

Updating the preview diff on a merge proposal is one example.

At our Launchpad sprint in Dublin a couple of weeks ago, we added a so-called “long poll” where the browser opens a long-running connection using XHR (a background Javascript connection) to a new piece of infrastructure called the “long poll server”

This server is something that the Landscape team originally wrote and we’ve now open-sourced it so we can use it in Launchpad. The server connects to a RabbitMQ instance and relays information back to the browser when the background task completes so that the user doesn’t need to keep reloading the page – the page will automatically update thanks to the magic of Javascript.

The proof-of-concept is done but we now need to make it work in our production environment, which means making it more reliable, configuring the deployment and add some stats collection so we can see how it behaves. We’ll start off by only letting a small subset of people use it and grow it over time until we consider it stable enough for all users.

Photo by Jay Gooby. Licence: CC BY 2.0

On Launchpad we have a lot of links that take your focus away from the current task. Usually, these exist to let you get more information on Launchpad or take you off Launchpad to do something like look at upstream information.

These links are usually represented one of two ways–a blue link with a globe for something that takes you to a new website, or a blue or green link for an internal link that opens a new window.

There’s a problem with this though. Green links mean an action will not take you away from your current view. Using a green link to take you to another window is a contradiction in our UI. Blue links alone aren’t ideal either, because blue links are scary. Everyone’s been bitten by clicking a link while in the process of filling out a form and losing the data they’ve spend five minutes filling out.

Right now, on our enhanced person-pickers, we have a green “Details…” link to let you see more information about a person. This link opens in a new tab, and we need to come up with a better way to indicate that action. We’ve put together a survey showing some rough ideas of how we might indicate a link that opens in a new window. It’s a very short survey, and we would love to get your input.

Please, take the “link opens a new window” survey.

We’re having a Launchpad meet-up in Dublin next Wednesday (29th June) from 8pm at the Porterhouse on Nassau Street.

Come and meet some of the Canonical Launchpad team, a few other Canonical types and members of the Ubuntu Irish LoCo.

We are testing changes to the person picker used on many pages in Launchpad. Our general goal is to ensure that you can trust you know who the user you are seeing is.

Beta testers will see two subtle changes to pages: The login status area in the upper right of the page will show both your display name and launchpad id.

We call this presentation unique-name. This is the same presentation that users will see when you post a comment.

When you read comments, you should know exactly who wrote it. There should be no confusion when there are many users with the same Launchpad display name. Launchpad users commonly have a single word display name, such as Tom, and it is not clear who wrote the what when there are comments from several users named Tom on a page.

Beta testers will will see substantial changes to the person picker. We want you to find the user you are searching listed in the first page of results. It is easy to confuse users of similar name and IRC nickname, and users often hide their email address. The listing must show enough information for you to confidently make a choice.

There will always be a link to choose yourself for any action where you are a legitimate choice. You should never need to search for yourself.

The search results are ordered by best match. Exact matches on Launchpad Id, email address, and IRC nicknames are shown first. Users who are active in Launchpad are shown next. Non active users are shown last.

The listing of users shows the unique-name. IRC nicknames were added, since it was common for users to search on them. Those who are active in the project you are working with are shown with the project’s badge to the right of their name. While users may have similar names and IRC nicknames, Their Launchpad Id is unique and their activity in Launchpad or your project is a strong indication who the user is. There will be cases where you want to see more details about the user before choosing, so the listing includes a link to see the user’s profile.

We are tracking person picker defects with the person-picker tag. If you find issues not already reported, add the person-picker tag to your new bug get them triaged quickly: https://bugs.launchpad.net/launchpad/+bugs?field.tag=person-picker