Raise your standards

I gatecrashed LugRadio Live last Saturday and went to an excellent talk by Matthew Paul Thomas about reporting usability problems. Matthew has reported well over a thousand bugs against Launchpad itself (many of which have been fixed) so he knows something about the subject.

Matthew gave six pointers on how to report usability problems, but for me the single most striking one was this:

Raise your standards

When you are using an application with the aim of improving its usability, you need to shed all of your tolerance and forget those many workarounds you've learned. Drum your fingers impatiently while you wait for something to load. Think of how this would look if you were showing it to a sceptical friend.

The point struck me because so many times as an application developer I've thought to myself "it's good enough" or "it will work for now". Really though, that's not good enough. I should work until the thing I've added is invisible, or at least fun to use. I need to raise my standards.

Having raised one's standards, the trick is then to avoid the traps of perfectionism. Do you have any thoughts on how to walk the road, avoiding the pitfalls, standards held high?

Bug squashing sprints

Every time somebody asks me what I think we should do for a sprint, I try to suggest "fix as many bugs as possible".

Each of the Launchpad teams gets together in a single location for a week long "sprint" fairly regularly. Maybe each team has two sprints a year.

Often these sprints end up being long talking sessions where designs for features are thrashed out. That's great and all, and sprints are a rare opportunity to do that, but often the design work goes unused for months while the team deals with the work already on its collective plate.

Sometimes these sprints have the whole team working (i.e. coding) toward a single milestone, be it a release or a major feature. These sprints are fun, but they've been quite rare for Launchpad. (Bazaar had a great one in Brisbane earlier this year).

What I'd love to see is a sprint where people fixed as many bugs as possible. Perhaps as a product strategist, I ought to be advocating higher-level visions and responding to the market and so forth, rather than saying "fix lots of bugs". But I don't think so, at least, not yet.

Fixing as many bugs as we can in a fixed time frame will make many users happy, since behind each bug is a user in pain. It will make us happy as a team, since a vastly dropped bug count will make us feel less overwhelmed and will feel like a concrete achievement. It's an easy sprint to measure the success of, and my hunch is that it would be a fun sprint too. It's also substantially different to what we normally do, which adds to the fun.

What do you think? I'd love to hear from people in community-driven open source projects, as well as people within Canonical who aren't in Launchpad. Maybe we're missing something that others know about.

Command line apps

Back in the day, I used to want to use twisted.python.usage for all of my command-line apps. It's a fairly nice API & a good way of writing code.

Since I started writing Bazaar plugins though, I've fallen in love with Bazaar's command interface. Jamu has too, so he wrote Commandant. I don't really understand it though, which is mostly for lack of trying.

Michael turned our internal EC2-using testing tool into a bzr-a-like app using the Bazaar APIs. There's a bit of duplication, but it works pretty well.

The Bazaar developers are aware that their command-line interface code rocks and that it's too closely bound to Bazaar. I'm not sure whether anyone has filed bugs about it or not, but here's what I actually want:

• The subcommand interface, e.g. "bzr foo"
• Option parsing
• Help
• Command aliasing
• Error handling
• Progress display

There's also a bunch of cool stuff in Bazaar that's useful for a lot of applications, command-line or not.

• Registries
• Transports
• Hooks
• Oh yeah, plugins. (How could I have forgotten this?)

Sometimes I wish projects like Bazaar and Twisted split this sort of stuff out into separate packages. That would probably change the way the packages are maintained, and I don't know whether it would be for better or for worse.

Sadly, no moral or action for this post. Just stuff that's been on my mind that I wanted to write down and publish. I'd very much welcome input.

Launchpad extensions

Launchpad has a pretty awesome public API, implemented using lazr.restful. I've written a few small scripts for it, and the Launchpad team has a few scripts that they use internally for doing admin tasks.

The Ubuntu Platform team does a heap of stuff with the Launchpad API. James Westby has been using it to make sure that there's a branch on Launchpad for every single package in Ubuntu.

There's all this great work, but there's been nothing to tie the room together. I've seen hardly any discussion about how to write Launchpad API applications, or how to test them, or how to get launchpadlib working in GTK+. I haven't even seen much code sharing.

So, borrowing a trick from Twisted's tx super-project, I've created an 'lpx' project group on Launchpad. Bring it your scripts, your applications, your huddled masses. If you want to know more about the API, look at the API help page.

Thanks to Mark for reminding me that this is important.

Launchpad status now on identi.ca

Sometimes, sadly, Launchpad doesn't behave as well as we'd like.

Although we try extremely hard to always be available, and take each instance of downtime (planned or unplanned) as a personal insult, sometimes we're forced to disappoint both our users and ourselves. It's no excuse, of course, but at least we're in good company.

To make these inevitable interruptions easier to swallow, we've set up identi.ca and Twitter accounts that report the Launchpad server statuses, and only the server statuses. We've got people all around the world who are able to update it when things go bump in the night. There's also a link to the identi.ca page in our footer, so you don't have to keep consulting a blog.

Thanks very much to Matt Revell for getting this done.

Meta-meeting stuff

Last week the Launchpad team leads gathered in London and had an absolutely huge meeting. Fifteen or sixteen smart, opinionated & passionate people in a room talking about the next six months of Launchpad development. It was a lot of fun.

When planning the agenda, Martin Albisetti and I were a little worried about things wandering off track, so we thrashed out a lists of dos & don'ts. I'll blurt them out here, with the really terrible ideas filtered out so I look more clever, and then offer some thoughts on how they worked.

Do

• be happy with the results of this meeting.
• ask questions, especially "why"
• be punctual
• stay on point

Don't

• design features
• check your email, i.e. laptops closed
  
• leave the meeting without being clear
• leave the meeting without being happy

The "laptops closed" one didn't work so well. It was great for the first couple of days, but by Thursday afternoon there were always people in a corner with those open LCD screens sucking chi out of the room like little dragons of despair.

The "Don't design features" rule was awesome. The rationale is that feature design leads to long discussions, and that it does a disservice to the many excellent engineers we have who aren't at the meeting and will be actually implementing a feature. At best, it's waste and at worst it's us telling people how to do something that they know how to do better. The clearest sign that it was a good idea came when other people started using it to shut me up.

Talking Time

I've been working on the Launchpad team for a while, with most of that time being in Australia. Others in the team are in the US (red states & blue states), the UK, Germany, Brazil, Canada, New Zealand, Serbia, Lithuania and Thailand.

Here are some tips I've picked up for smoother online conversations, particularly around scheduling.

• Don't say "summer" or "fall". Say the month, or the range of months.
• Say "my morning" rather than "the morning".
• Use 24-hour time.
• In real-time conversations, say "in 2 hours time" rather than "at 10".
• Always include the timezone. Avoid using local abbreviations (e.g. PST), instead use offset from UTC.
• Better still, just give the time in UTC.
• Know your UTC offset.
• Use a timezone-aware meeting planner. You'll get the arithmetic wrong otherwise.
• Say "Oct 7" rather than 10/7 or 7/10. Everyone speaks English, but not everyone uses your dialect.
• The time that you end a meeting is more important than when you start it. Thoughtfully consider the timezones of other attendees when you are planning for & participating in meetings.

Violating these rules isn't a big deal, since people can generally figure out what you mean. Following them, however, can speed things along and sometimes even avoid tedious conversations.