launchpadblog

Being on support for Launchpad has a huge sense of responsibility. For a whole week, you are the first point of contact for users experiencing issues related to Launchpad or the services attached to it. For the person on support, even roadmap work takes a backseat. 

All Launchpad engineers, except managers, take turns being on support. Managers provide Level 2 and 3 support, and in some sense, are always on support. There is no explicit expectation for a technical author (TA) to take on this responsibility, but why should engineers have all the fun?

What was the motivation to go on support?

For a TA being embedded in your team’s duties and processes is key to driving documentation efforts and positively influencing what the team does beyond documentation. As Launchpad’s first full-time TA, I had my work cut out.

When I started, my main role was driving existing objectives to completion. In later months, I had to play a key role in choosing the objectives. With so many pending issues, prioritization was the main challenge. Although I was able to figure things out, with lots of help from the Launchpad and documentation teams, I knew there were still some gaps left to cover.

I decided to learn as much as possible about the product, team, and users, to help identify which aspects of documentation were most important to address. Guruprasad and I discussed shadowing engineers on support, but Clinton suggested I try the real thing too.

Shadowing engineers on support

The expectation that I would be going on support raised the stakes, and I had to make the most of my time shadowing engineers. Interacting with users requires a higher level of care, and I was also keen to repay the faith the team had placed in me.

I shadowed İlker, Artem, and Inês in the three weeks before my turn. We used different techniques depending on our calendars and what issues they were addressing. In some cases, we would have a live meeting and I would follow along as they handled different tasks. In other cases, the approach was asynchronous, with the person on support linking me to user requests they were working on, discussions in the Launchpad channel, or documentation they had used to address specific issues. 

In the support chair

On the morning of my first day on support, I couldn’t change the header of Launchpad’s public channel on Matrix. This was a simple yet frustrating problem and it took me a while to figure out this was a Matrix issue, not a skill issue. Despite the frustration, this was a good reality check. Support week is unpredictable and nothing can be underestimated. 

The rest of the week brought plenty of highs, lows, and unpredictable scenarios. My main takeaways were:

• Documentation – Being on support relies heavily on the availability and quality of documentation. In addition to improving my product and team knowledge, I was able to identify where and how existing documentation succeeded and failed. Whoever is on support is always expected to identify gaps and add to the documentation, but as a TA, I was also able to identify additional issues that hamper information extraction in our docs. 
• Many requests are easy to handle – The Launchpad team has done a great job of documenting the processes needed to handle many types of requests and issues.
• The role challenges you to learn and do more – Trying to address user issues required interacting with parts of Launchpad I didn’t have to before. 
• It’s a great team-building experience – For Launchpad engineers, being on support is such a core part of the job that it has its own culture and language. A lot of what it means to be part of the Launchpad team became clearer during this experience.
• It’s not a one person job – It was mentioned to me many times before, but it was great to see it in practice – the person on support isn’t always expected to solve the issue. Sometimes I just needed to tag someone else in, redirect the issue to the right team, or let a user know we would look into an issue

Best moment

A user reported a bug where they couldn’t delete a comment. On inspection, the comment seemed to just be an attached text file. I started by going through the logs and confirmed that they had indeed deleted something, but it appeared to have been a different comment.

I suspected this had something to do with the attachment so I decided to recreate the issue, i.e., uploading an attachment as a comment and trying to delete it. I confirmed that trying to delete such comments did not work. Bug confirmed… right?

In Launchpad, we are a bit suspicious when things go exactly as planned the first time round. In this case, this issue appeared far too easy to encounter. I did some digging and found an older bug report where the unusual process for deleting such comments was also mentioned. So, I was able to tell the user how to solve their problem and avoided adding to our long list of bugs by marking this as a duplicate.

Final words

Supporting users is a team’s responsibility, not an individual’s. Technical authors maintain documentation used in support but may not get to test the experience of using it, and this can result in blind spots. This experience not only highlighted some of these blind spots for me, I also got to learn a lot about Launchpad, the community that uses it, and how we can improve the documentation to better serve users.

Laura: What do you do on the Launchpad team?
John: I’m the team lead for the Blue squad. Right now our squad is on Maintenance, so I generally do the coordination work of our team with other teams and the system administrators.

Laura: Can we see something that you’ve worked on?
John: Before we switched to maintenance, our team was focusing on doing Bazaar work. Within the more recent time, we’ve done stuff like fixing up the Ubuntu Distributed Development package importer, and getting translations for Quantal started for Launchpad.

Laura:Where do you work?
John: I work from home in the Netherlands.

Laura: What can you see from your office window?
John: We have a forest near our house, and some of the other neighbors houses.

Laura: What did you do before working on the Launchpad team?
John: As mentioned, we were focused on development of Bazaar, though arguably that was still part of the Launchpad group (not officially, but in spirit).

Laura: What did you do before working at Canonical?
John: I worked for a company developing medical imaging algorithms, mostly for detection and visualization of disease.

Laura: How did you get into free software?
John: Our team wanted to use something better than CVS for development. At the time SVN was pretty hard to set up, and there was just the beginnings of a couple of tools for distributed version control. I got into tla at the beginning, and was happy when Canonical started Bazaar, and I was able to hack on it.

Laura: What’s more important? Principle or pragmatism?
John: I’m a fairly pragmatic engineer. I think it is good to use principle as a guideline, but in the end if the work isn’t in the hands of people using it, it is providing no benefit and is arguably wasted effort.

Laura: Do you/have you contribute(d) to any free software projects?
John: Well, Launchpad and Bazaar are both pretty clear things (and tla a little bit before that). I also developed some other tools while here at Canonical. Such as Meliae for profiling python memory.

Laura: Tell us something really cool about Launchpad that not enough people know about.
John: The UDD package importer turns the changes from debian packages into real VCS branches that you can do lots of nice stuff on. (annotate the history, log the history, see the graph over time, etc.)

I think we are at about 90% coverage, and you can do “bzr log ubuntu:package” to find out the recent history for a package in ubuntu.

Laura: Is there anything in particular that you want to change in Launchpad?
John: My own personal project with launchpad is improving the connection handling when accessing Bazaar branches. Right now it is approximately 3s just to do the ssh handshake and start talking to codehosting. I have some improvements that should decrease that significantly, but we encounter some strange hanging bugs that are only reproducible in production. And LP’s commitment to having minimal user-visible downtime is particularly problematic for SSH connections. A single HTTP request is less than 5s, but an SSH connection can legitimately be active for an hour if accessing a large project.

Setting up a commercial project in Launchpad has gotten easier. You can now quickly register a proprietary project and enable private bugs. You can create private teams and private personal package archives, AKA private PPA or P3A without the assistance of a Launchpad admin.

When you select the Other/Proprietary license while registering a project, or changing the project’s details,

it is given a complimentary 30-day commercial subscription.

The delay between the moment when a commercial project was registered and when the commercial subscription was purchased and then applied to the project caused a lot of confusion. During this delay, proprietary data could be disclosed. We chose to award the project with a short term commercial subscription which enabled the project to be properly configured while the 12-month commercial subscription was being purchased and applied to the project.

Any project with a commercial subscription can enable

Default private bugs

Once enabled by configuring the project’s bug tracker, all new reported bugs are private. You can choose to make the report public.

Default private branches

You can request a Launchpad admin to configure private branches for your teams. (You will be able to do this yourself in the near future when projects gain proprietary branches.)

As the maintainer of a project with a commercial subscription, you can register

Private teams

When you register a team, you can choose to set the team visibility to private. The team’s members and data is hidden from non-members.

Private mailing lists

When you create a mailing list for a private team, the archive is also private. Only team members may see the messages in the archive.

Private PPAs

When you create a PPA for your public team, you may choose to make it private; private teams can only have private PPAs. You can subscribe users to your archive so that they may install packages without revealing all your team’s members and data to the subscriber.

A secondary benefit of this change is that you can now try Launchpad’s commercial features before purchasing a 12-month commercial subscription. The features will be disabled at the end of 30-days. Your test data will remain private to ensure your data is not disclosed.

Any open source project may also have a commercial subscription to enable commercial features. You can purchase a commercial subscription at the Canonical store. Commercial subscriptions cost US$250/year/project + applicable V.A.T.

 

(Photo by Fred Dawson on flickr, creative commons license)