One of the questions I’ve been asked a few times is why we’re using our own bug submission form instead of the Launchpad bug tracker.

Our bug submission form asks the following questions:

1. Which language is the manual in? Our manual is has nearly 50 translations at this point. We’re currently only editing the American English version (our base, nontranslated version) at the moment, but this question will serve us in the future when the translated manuals have been released.
2. What revision is the manual? We will be releasing a new revision of the manual each day this week so that we don’t end up with a lot of duplicate reports on bugs we’ve already fixed.
3. Which page number is the error on? This helps us track down the error quickly and assign it to the appropriate editor to fix.
4. What kind of error is it? This is a multiple-choice question and has the following options:
   1. Spelling, grammar, or punctuation error
   2. Factual error (e.g., incorrect information)
   3. Formatting, layout, or artwork error
   4. Missing information / topic
   5. Style / voice problem (e.g., wrong tone, wrong level of detail)
   6. Other (fill in the blank)
5. Please describe the problem in as much detail as is necessary. The reporter can explain the problem using as much or as little detail as they think is required.
6. If you have a suggestion for fixing the problem, please let us know. If the solution to the bug isn’t obvious from its description above, this field allows the reporter to give us their ideas on how we should go about solving the problem.
7. Email address. The email address is optional is used only if we need to contact the reporter for more information.

As you can see, these questions are designed specifically for collecting the information required to fix the types of bugs we expect to find in our manual. We’re not asking irrelevant questions such as the severity or importance of the bug, a summary of the bug versus a description of the bug, or which milestone the bug targets.

One of the primary benefits of using our bug submission form as opposed to Launchpad is that it allows anyone to quickly report a bug without requiring them to have (or create) a Launchpad account, log in, and find the project page. This means that anyone with a few minutes to spare can read through a couple pages of the PDF and immediately report the bugs they find.

Once the bug has been submitted, it’s automatically stored in a Google Spreadsheet. The spreadsheet has been shared with all the Ubuntu Manual editors who triage, assign, and tag bugs. The bugs are assigned to the editor of the chapter in which they appear or, in the case of artwork or layout bugs, the design responsible.

A question that is often asked is, “How do I see if my bug is a duplicate?” Our bug reporters don’t need to worry about checking in advance to see if the bug they wish to report is a duplicate. It takes more time to hunt for a duplicate than it does to simple report the bug. Since our bug reports ask structured questions such as “what page is the bug on?”, we can sort the spreadsheet by page number and quickly see the duplicate bugs. This greatly reduces the overall time that reporters and bug wranglers must spend on finding and marking duplicate bugs.

Many of the bugs in Launchpad start off with the same response: “Thanks for reporting your bug. Unfortunately, you didn’t provide us with the information we need to confirm and fix this bug. Please provide us with the following…” Our bug reporting form avoids this issue by explicitly asking for the specific information we need in the initial bug report.

Another question that has been asked is, “How can you have a discussion about the bug if it’s not in Launchpad?” Most of our bug reports don’t require a discussion. Reports of misspelled words, errors in punctuation, etc. are usually not debatable. However, for those bugs that do need to be discussed, you can still report a bug in Launchpad.

The short answer as to why we’re using our own bug submission form is because it’s easier and saves time for both our users and editors.

The changes from 3.0.0 include:

• Added a nohyper document class option that suppresses loading of the hyperref package.
• Added three commands to modify the positioning of the captions.
• Now automatically recalculates the lengths in case you’ve modified the page size or margins.
• Added a B5 paper size.
• The justification of sidenotes, margin notes, captions, and citations can be set individually now.
• The font and style of sidenotes, margin notes, captions, and citations can now be set individually.
• The \caption command now accepts an optional vertical offset argument.
• Added the \morefloats command that works in the same way the morefloats package does.
• Fixed a number of bugs.

You can find the latest Tufte-LaTEX package at http://code.google.com/p/tufte-latex/. There is a sample handout showing some of the features and the full reference for the Tufte-LaTEX document classes exists in a sample book.

The files have been uploaded to CTAN and should appear there soon.

Thanks to everyone who has contributed patches, suggestions, and bug reports! Keep them coming!

Currently the Tufte-LaTEX project only has a handout document class. When I get a few minutes (read: “when I get bored working on the stuff I should be working on”) I’ll finish up the book style I’ve been working on.

If you discover any bugs with the current document styles or have any suggestions for improvement (or just want to rain praise upon us), join the mailing list.

TagNinja is the result of a class project that Jesse and I worked on. To play TagNinja, just match the proper definition with the highlighted word. By playing, you’ll be teaching computers how to figure out which definition it should use for a word in a particular sentence. Then we’ll be able to bark out orders to our computers just like in Star Trek!

Corpora Storm and Shadow Parser

During HCI 522: “Scientific Methods of Human–Computer Interaction”, we wrote a blog entry each week along with a class presentation. I’ve mirrored my blog entries here in the past.

Now we’ve collected our favorite blog entries from that class and compiled them into a book: Shiny Happy Users. We published the book through lulu.com. There’s a hardcover edition and a paperback edition. And if you’re not convinced to buy a copy of the book, you can even download the PDF for free.

In addition to the book, we’ve created a companion DVD that contains our video presentations and slides.

And if all this weren’t enough, the books and DVD are licensed under a Creative Commons Attribution-NonCommercial-ShareAlike license. That means that you can give copies of our work to your friends and you can make derivatives of our work. Some examples of derivatives would be: translate it into a different language, rework the essays into lecture notes for a class, and transform the work into a different format (say, for e-book readers).

Visit the Shiny Happy Users website for more information and samples of the essays and presentations.

I did all the typesetting for the book, so I’m sure there are plenty of errors and typos. if you find any, please let me know!

http://kevin.godby.org/lt2bib/

Let me know if it works for you or if you run into any problems with it.