bac's blog

Reducing the confusion

Occasionally people find some things about Launchpad a little confusing.  We know, we know and we strive to correct the problems…but it is hard some times.

I had a professor in college who tried to get us to look at problems and ferret out the inherent complexity in a system from the unnecessary complexities that inevitably crept in.  There is no arguing that the many tasks we’ve endeavored to solve in Launchpad have a goodly amount of inherent complexity that no amount of UI tweaking, hand wringing, and refactoring will diminish.

It is equally true, however, that we’ve introduced some layers of extra cruft that can make the experience of using the system more confusing, more frustrating, and more error-prone than we, or you, would like.  In the words of one Launchpad engineer the current situation is often “suboptimal”.

One area where we’ve failed is in introducing new, novel concepts without fully explaining to our users the meaning and uses.  I recently landed a branch on edge that attempts to clarify the descriptions of some of these concepts.

If you are interested, please read on and see the textual changes I’ve made with the help of Matthew Revell.  If you have suggestions for better wording please let me know.

The first simple change involves the project driver.  This role is not a term most software developers recognize, and for good reason — we just made it up.  And since we just made it up we really owe a good explanation of what the role is supposed to be.  The best way to accomplish the explanation is via a pop-up help on the project index page.  The pop-up can be seen in this screenshot.

A project also has a role called the security contact, which is a little more comprehensible at face value.  Have a look at the before description and the after to see if I’m made an improvement.

It really isn’t too obvious from the name bug supervisor what is expected from the person or team assigned to the role.  I hope the new description provides better information than the old one.

The bug supervisor and security contact descriptions are shown together at the top of the new bug tracker configuration page.  It is the same text as shown before but on a different page.  The bottom of that same page now has a better label for the project’s bug reporting guidelines.

Again, feedback on these changes is welcome.  The changes have been on edge for a while, visible to our great group of beta testers, and will roll into production with the 10.06 update.  If you have suggestions for improvements find me on #launchpad, file a bug or drop me an email to bac (at) canonical.com.

(Photo courtesy of Mr T in DC.)

Ignorance enabling malice

Voted today in the primary.  At the table where I identified myself to get the ballot I noticed the official laptop with the voting registration had the password written on a note taped to the keyboard.  The woman assured me it would be ok since they didn’t let just anyone use the laptop.

At the final station before voting I handed the man my ballot and a printout with my voter information on it.  He scanned a bar code on each.  I found that step troublesome.  Is the barcode on the ballot individual or does it just identify which party’s ballot you got (in the primary Democrats and Republicans have separate ballots but use the same facilities)?  If it is the latter then the use of the barcode and scanner is complete overkill.  If it is the former, each ballot has an individual identifier, then they have closed the loop and can identify votes.  The identification of the voter and the ballot should never be linked or have the appearance of such a link.

I like the fact we use optical scan ballots, the best technology in my opinion.  But the procedure they are using could be used to identify how each person votes, which I don’t like.

I think I’ll contact the State Board of Elections in a few weeks and make some queries.

Helping Ubuntu packages find their home

Curtis wrote a good[1] post Tuesday about the different ways people see Launchpad’s purpose.  To some it is a place to host their project’s code and do bug tracking.  To others it is where the heavy lifting happens to get Ubuntu built.  Both are right depending upon your perspective and tasks.

It is an aspect of the latter role I’d like to address today.  Ubuntu is made of lots of parts and those chunks are called source packages.  Everything in the distribution has a corresponding source package which get built into binary packages which get installed on your computer.  The code for those packages lives somewhere whether it is in Launchpad or elsewhere like SourceForge, Google code, or another host.  Those thousands of projects that are not hosted on Launchpad have lots of information we’d like to know about such as where their bugs are tracked, who is the development team, and who is responsible for taking care of bug management.

In order to track all of that information we create projects in Launchpad that are really just place holders for the real project.  They look like a project hosted in LP but just reference the real project.  If you see “Does not use Launchpad for development” on a project page you’ll know it is a place holder.

Having a project in LP is a good start but isn’t enough.  We need to link the source package for the distribution series (e.g. Ubuntu Lucid) to that package.

Since there are many packages in Ubuntu that are not linked to the upstream project we make it easy to find the ones that need linking so that motivated people can contribute by making those connections.

Looking at the index page for Lucid there is a section called “Upstream packaging” which first shows off the recently linked packages and the fine folks who did the work (Thanks!).  Under that section is a link titled “Needs upstream links”, which you can see below:

Clicking on “Needs upstream links” takes us to the page listing all orphaned packages.  If you want to help, here is a good place to spend some time.

I don’t want to discuss creating projects in this article but instead will focus on linking to projects that already exist.  Out of the list above I know that the ‘claws-mail’ project already exists in Launchpad.  Clicking on the link above takes us to the source package page for claws-mail.  Under the “Upstream connections’ section you’ll see that the package isn’t linked but there is a helpful suggestion for a likely candidate, “Claws Mail”.

Clicking on the “Claws Mail” link takes us to the project page shown here.  A quick examination of that project shows that it looks like the correct project for the source package.  Returning back to the source package page we can make the connection and link the two up.

After making the link we get the heart warming confirmation page showing the connection has been made.  Ubuntu packages are now one step closer to being complete.

Coming soon - Ubuntu 10.04 LTS

I’ve been running the Beta of Lucid Lynx for a few weeks now and it is great.  As a long-term support (LTS) release it will be supported for three years and is getting the extra attention that designation deserves.  So far I’ve been very pleased.

Small, tiny, wee resources

from thegardenroomguide on flickr

so i’m contemplating building a free standing office in the woods behind the house.  it’s silly, really.  i already have a lovely office in our house looking out into the trees.  but that space is cluttered, shared with the television, and, to be honest, too readily available. i want a space that is close, single purpose, and detached.  i want to feel like i’m going to work and, equally important, leaving work.  so i’m thinking of joining the growing number of “shed workers”.

here are some resources i’ve found:

NYTimes on small houses

shedworking

Pittsboro-based Abundance Foundation’s Office of the Future, an off-the-grid 10’x12’ office.

Tiny House Blog

the garden room guide - a UK-based blog with links to lots of pre-built installations

modern cabana - san francisco-based prefab maker with very cool designs

modular dwellings - featuring readymade magazine’s MD-100 and MD-120.