For once I know exactly what to look foward to for my birthday: I will spend the evening at a concert of Grossstadtgeflüster. They are a German language band from Berlin, and I really started to love their lyrics. You can download a very fine remix of Ich muss gar nix — the song they are best known for. Today was the day: I received the CD I ordered (just listened to them before through a copy of a friend) together with some stickers, an autograph card and a small button, and also today I bought ten tickets for the concert! *bounces*
"10?!" you might ask. Well, for a start they weren't too expensive, and I also want to have some of my closer friends around me and at least thank them for being there for me all the time. I also want to make sure that they don't miss the chance of buying tickets — it happened to me too often, so this is also a bit of a precaution. I take this as a chance to finally write more about the propably most important part of my life: the music. I have totally neglected this love over the years, but I want to change that and at least reinitiate this part of my blog. Let's see how it's coming along.

From today my blog is available on IPv6. I've set it up so that http://debiana.org/ is only serving an AAAA record (for this server) and no IPv4 records (+/- DNS timeouts, of course...). Tomorrow I will work on getting a nameserver or two running on IPv6, to extend the IPv6 infrastructure another level. This is all me fiddling now that we have an IPv6 allocation at Catalyst, and are developing our IPv6 infrastructure in order to be able to deploy a couple of the .nz nameservers on IPv6 in due course. I'm not sure if I can point a .org domain at IPv6 nameservers so I might have to pick one of my .nz domains and use that to have a top to bottom IPv6 infrastructure. For IPv6 to start to work, I think people just have to start using it, so I'm going to change the systems that I can change. So I've also put a fixed IPv6 address onto my laptop, which is nice, and I will be converting all of my home systems to IPv6 addresses as well as time permits. Of course I can't get rid of IPv4 yet, but I think I will probably be trying to run that through a proxy somewhere non-local if I possibly can. If you can access this server via IPv6 I would be really interested to see a traceroute from you :-)

I always liked pretending that nowadays, there are no driver issues with Linux (well, except for ATI and NVidia not releasing specifications, so for some of their product there are no good drivers available). Well, thats not entirely true. Just these days, I've been running into some driver issues with my Intel hardware; and Intel recently has been the favourite of Linux developers for actually publishing driver source code under a free license. Some details on the driver issues I had: IPW3945 wireless with WPA on dual core. Apparently, there is some kind of race condition in the dual core setup under load, when two interrupts end up being handled by different CPUs. The WPA path probably is a bit slower, I read that theoretically it should also happen with WEP. The effect is as this: when transferring data quickly, e.g. from a local machine on a WPA encrypted network (such as my parents wireless; basic WPA via the common AVM Fritz!Box), it will drop the connection every minute or so, and take another minute to reconnect. Obviously, that makes the wireless rather useless... This is what the errors looked like:

TKIP: ICV error detected: STA=...
N/A: Michael MIC verification failed for MSDU from ... keyidx=0
wifi0: MSDU decryption/MIC verification failed (SA=... keyidx=0)
TKIP: received packet without ExtIV flag from ...

Upgrading to Kernel 2.6.20 turned these errors into something like Firmware bug detected; reconnect already was a bit faster. Upgrading the firmware past the Debian-packaged (in non-free) version to a newer one change them again (I think the ICV error remained) and made the reconnects even faster; still large transfers don't work reliably with WPA. Another reason I upgraded to 2.6.20 was that the microphone didn't work on my Dell 640m. The upgrade helped here, I now can record from my microphone. Every now and then, my system kind of freezes on resume; it seems that some interrupts (especially the keyboard interrupt) remain disabled... I also tried the newer i810-modesetting driver, that should be able to handle the 1440x900 resolution without the aid of i915resolution (which basically overwrites part of the video BIOS to add the resolution to the supported resolutions list). The screen remained black (with both unstable and experimental versions of the driver). Another reason why I was trying this driver is that the current driver has like a default gamma 1.5 for XV, apparently - all XV using apps playback videos way too bright. Even if they don't have an XV gamma control. Well, on the other hand, thats what Windows users might be exposed to every day. 99% of the time, everything works fine for me, too. It just remains open whether 2.6.18 is actually the right kernel to use for the upcoming release... 2.6.20 improved on some of my issues. On the other hand, yaird failed to make a proper initrd for my computer, because CBC (cipher block chaining, a common choice if you encrypt your harddisk) became a module and wasn't added. There are just so many details to iron out when upgrading the kernel... that would pretty much mean an unfreeze, I guess. :-( If we would release more often, that wouldn't be as essential, but for a release interval of two years, we really should have a kernel with few driver issues. And even if we're going to ship newer kernels with "dot releases" of etch, we'll have to avoid issues such as the CBC-module being unknown to yaird.

Thanks to Mako, my weblog (at least part of it) is now syndicated on Planet Debian! I thus ought to introduce myself: I’m Julien, 28 years old, living in the North East of France. I already (co-)maintain a bunch of packages in the official archive, and try to actively report bugs. I also used to acting as a translator for the French l10n team, which I will resume once time allows it. I may plan to enter the New Maintainer process in the next couple of months. I take this as an occasion to thank all my sponsors and co-maintainers (Christoph, Free, Cl ment, Micah and Lo c) for their interest in working with me and for their patience. I hope being on Planet Debian will allow me to better integrate into the Debian community.

Aur lien, I definitely can do better. All my recent blog entries (except one or two political ones) are focused on this activity, which lasts for 1.5 month now. As usual, when I began it, I ommitted to record the status of l10n to just have a proof that it gave great results, so you will just have to believe me. It is giving great results..:-) Making a lot of noise is sometimes a good way to make one's point. That is specifically my goal here. I think that at least one goal is achieved: I now expect many package maintainers to think twice before changing the debconf templates in their packages and, more generally, any internationalised material. Not that I don't want them to be fixed (indeed, that will be my next jihad: take packages one by one, ranked by popcon score, proofread the English templates, change them if needed and accompany maintainers in the interaction with translators), but I want them to be fixed cleanly.

Highly recommended for anybody who might be even remotely interested in LinuxBIOS: There's a video recording (OGG, 234 MB) of the LinuxBIOS talk at FOSDEM 2007 by LinuxBIOS-founder Ron Minnich. The talk is about LinuxBIOS, its history, how it works, what the main challenges are, where it's used today and what the future will likely hold. Watch it, you won't regret it. And if you want to know more, or maybe even consider contributing, head over to linuxbios.org or contact the mailing list.

I recently came across two old and unrelated writings about law, both of which are worth reading, especially for people with strong opinions but no formal training. The first is this piece, entitled Seven Ways in Which Code Equals Law (And One in Which It Does Not), by recently-appointed New York Law School professor James Grimmelmann and EFF Legal Director Cindy Cohn. Several observations are particularly appropriate for the slashdot crowd (and, to a lesser extent, certain members of the Debian community and others who grew up on a diet of BASIC, Pascal, and then C and later perl). I especially like this bit about “hacking the law”:

Some people, seeing this connection, and remembering the values of good code, try to improve the legal system by treating it as a computer. People come to me with ideas for hacking the law. The government says that cryptography is a weapon, they say, but the Bill of Rights says we have the right to bear arms. So that means we have a Constitutional right to use cryptography. But the legal system isn t a computer. If you can t convince a judge that what you re proposing is consistent with the values underlying a law, your argument will go nowhere. People go to jail every year because they think they ve found a way to hack the Sixteenth Amendment. The income tax is illegal, they say, or, The income tax is voluntary, see, it says so right here, and then they get convicted of tax evasion and sent to jail. We did convince several judges about the Constitutional dimension of cryptography, but the claim started from the values of the First Amendment, not a mechanical reading of its words. It s a category mistake to treat the legal system as just another architecture with its own specialized language. Code and law are different ways of regulating; they have different textures. All of those people who are required to make the legal system work leave their mark on its outcomes: they make a certain amount of drift and discretion almost inevitable. Code doesn t have such a limit: it can make perfectly hard-nosed bright-line rules and hold everyone in the world to them. Code is capable of a kind of regulatory clarity and intensity that law can only state, never really achieve.

I don’t entirely agree with the other article, entitled What I Ate For Breakfast and Other Mysteries of Judicial Decision Making by outspoken Ninth Circuit Judge Alex Kozinski (unofficial site maintained by Aaron Swartz, wikipedia entry). For example, I think critical legal studies has resulted in some interesting insights, some of which actually have practical applciation. Still, Judge Kozinski makes an important point about the numerous factors that act as a check on discretion in judicial decisionmaking:

It is popular in some circles to suppose that judicial decision making can be explained largely by frivolous factors, perhaps for example the relationship between what judges eat and what they decide. Answering questions about such relationships is quite simple - it is like being asked to write a scholarly essay on the snakes of Ireland: There are none. But as far back as I can remember in law school, the notion was advanced with some vigor that judicial decision making is a farce. Under this theory, what judges do is glance at a case and decide who should win - and they do this on the basis of their digestion (or how they slept the night before or some other variety of personal factors). If the judge has a good breakfast and a good night’s sleep, he might feel lenient and jolly, and sympathize with the downtrodden. If he had indigestion or a bad night’s sleep, he might be a grouch and take it out on the litigants. Of course, even judges can’t make both sides lose; I know, I’ve tried. So a grouchy mood, the theory went, is likely to cause the judge to take it out on the litigant he least identifies with, usually the guy who got run over by the railroad or is being foreclosed on by the bank. This theory immodestly called itself Legal Realism. Just to prove that even the silliest idea can be pursued to its illogical conclusion, Legal Realism spawned Critical Legal Studies. As I understand this so-called theory, the notion is that because legal rules don’t mean much anyway, and judges can reach any result they wish by invoking the right incantation, they should engraft their own political philosophy onto the decision-making process and use their power to change the way our society works. So, if you accept that what a judge has for breakfast affects his decisions that day, judges should be encouraged to have a consistent diet so their decisions will consistently favor one set of litigants over the other. I am here to tell you that this is all horse manure. And, like all horse manure, it contains little seeds of truth from which tiny birds can take intellectual nourishment. The little truths are these: Under our law judges do in fact have considerable discretion in certain of their decisions: making findings of fact, interpreting language in the Constitution, statutes and regulations; determining whether officials of the executive branch have abused their discretion; and, fashioning remedies for violations of the law, including fairly sweeping powers to grant injunctive relief. The larger reality, however, is that judges exercise their powers subject to very significant constraints. They simply can’t do anything they well please.

Finally, I will link, but not embed, this video of the Anna Nicole Smith court order, for an entirely different perspective on the legal process. You almost don’t really want to have to see this stuff.

I've been investigating ways of testing out applications like Stuff to Do on Windows, and boy has it been frustrating. It's not a fun task in the first place, as I'd rather be coding than trying to deal with crappy incompatibilities between browsers and operating systems. I first looked into VMWare products, which look pretty good. The Workstation version has a free 30 day trial download, and the basic player is free of charge. Unfortunately the Ubuntu player packages appear to be seriously broken. Qemu also looks like a good possibility. I don't care if it's not blazing fast, just as long as reloading a page in IE doesn't take 5 minutes. I think I could make either one of those options work. However, the hairy, gorilla size problem is the microsoft operating system itself. I don't want to deal with Vista, because it's a hog, and emulating a hog is bound to be slow. So I'd like to get XP, and since I'd prefer people to respect the licenses of software I write, I think it's only fair to get a legitimate copy, even if my friends here in Italy will probably think I'm batty. Overlooking the fact that the basic retail price is $200, which is somewhere north of double what I think is reasonable, it seems as if you can't even download the damn thing and pay with a credit card. How antiquated is that? I want to be up and running now, not fiddle around with a CD that might arrive a week from now. The end result: massive amounts of frustrating and nothing to show for it. That I would have avoided if I just found a cracked version. I think for now I'll just put up some extra 'get firefox' banners on my sites:-/

I'd noticed back when Dates was started the libecal was failing to notify Dates when events in Evolution changed, and vice versa. This was magically fixed when Dates moved over to ESource, so I didn't continue investigating it. However, Tasks doesn't use ESource yet and people had noticed that if you add items to Tasks, they don't appear in Evolution or the panel. This is a major problem, so I build EDS and debugged the problem. Turns out that the system tasks store is at ~/.evolution/tasks/local/system/ but when using ESource it is at ~/.evolution/tasks/local/system (note the lack of a slash) and as backends are looked up using literal string comparisons, these don't get the same backend so you don't get change notifications, and even worse modifying the task list with one application will overwrite the other's changes. Luckily the fix was trivial, and I hope that it gets reviewed soon.

I must say I disagree with John a lot about git rebase. git-rebase is the most nice feature I've ever seen float around in a SCM, and is part of the things I love in git. I mean, I do not disagree with the fact that it cannot be used in every single case. It is indeed meant to be used in private topic branches. git-rebase is meant to be used in a workflow where you have a topic branch (meaning some non releaseable nor push-able work) and that you still want to keep up with others work. With other SCM's, you have to update your working repository, wich in many cases generates nasty conflicts, hard to deal with. Especially in svn e.g.. With git, you commit your work, pull the remote branch, and then rebase ontop of it. It makes a lot of sense, and when your topic branch is indeed ready, you can push it upstreams, and the next rebase will merge the bits that have been accepted automatically. I just can't think of a simpler way. Btw, we use svn at work, and I do use git-svn instead of svn to be able to develop my own patches without fearing conflicts in the same way I did before. I know I will benefit from the powerfull git merging capabilities and help at any stage, even if I did not pulled the svn for a long time. That makes the developpement much more sane, as I only try to push coherent changes, hence on a less regular basis. You could not do that without git-rebase. In that sense, git-rebase is anything but evil.

Primary school is a long time ago. Still, every time I buy me some new toy, I somewhere in the back of my head wonder how this will have an influence on my social standing. I have this Nikon D50 since a few months now, and have brought it to FOSDEM. Mostly to take pictures, but, well, I did think it'd make me look good—at least slightly so. Turns out everyone and their dog has one. Guess I'll need to take my flute next time. Or, well, convince nattie to sing Aria 14, and then follow that up with Aria 15.

Ever wanted to insert a character in your terminal but don’t have a keybinding for that character? zsh provides a nifty feature called insert-unicode-char:

autoload insert-unicode-char
zle -N insert-unicode-char
bindkey '^Xi' insert-unicode-char

Figure out the character’s code (take a look at unicode.org/charts/ for example) and press ‘ctrl-x i’, followed by the character’s code and press ‘ctrl-x i’ once more. Usage example: ‘ctrl-x i 00A7 ctrl-x i’ will give you an ‘ ’.

A few days from now is the first BarCamp we've had in a while: DemoCampMontreal1. DemoCamp is a BarCamp variation with a much shorter time frame (a couple of hours, rather than all day) and strict rules about presenting. Demo-ers cannot use Powerpoint slides (or even OpenOffice Impress slides!); they have to demo working code. I'm going to be doing the first demo of the first DemoCamp, which should be pretty fun. What will I be demoing? The OpenID extension for MediaWiki, of course. I'd like to show folks who have MW installs how to get OpenID enabled on their sites, and I'd like to show other developers how to (easily) integrate OpenID into their existing software. I don't think it's necessarily that hard. DemoCampMontreal1 is on Tuesday, Feb 27 2007 at 6:30PM at the SAT. Everybody's invited, and as an extra bonus, t-shirts from BarCampMontreal1 will be there, for attendees. Cool! tags: democampmontreal1 democamp montreal barcamp democampmontreal barcampmontreal openid mediawiki wiki sat

MLUG now has OpenID Lurking in #mlug (Montreal Linux Users Group) on Freenode, I caught a cross-discussion about OpenID being enabled on http://mlug.ca/ . Which is great news -- I'm excited to be able to use OpenID on some of my favorite sites. tags: mlug openid lug

Creative Commons 3.0 I'm excited to see the announcement that the Creative Commons 3.0 licenses have been released. The 3.0 licenses were in part the product of the Debian-Creative Commons Workgroup, which tried to smoothe the rough edges of the CC licenses that made them incompatible with the Debian Free Software Guidelines. See the Debian Creative Commons Workgroup report for more info. We didn't get everything we wanted from the negotiations, but we did get the essential problems out of the way. I think that the 3.0 licenses are compatible with the DFSG, and that works licensed solely under CC 3.0 should be allowed into Debian main. But we probably have some discussion on debian-legal ahead of us on the subject. tags: cc cc3.0 debian

Dead tablet walking So, I think I mentioned that I borrowed a Nokia N800 tablet last week at the LWOSS. I took it to bed two nights ago -- it's a really good computer for reading in bed -- and the battery died on the nightstand overnight. When I plugged it in in the morning, it went into some kind of zombie fugue. It booted up, spun in place for a little bit, then shut itself down and rebooted again automatically. I couldn't get it to stop with the normal power button, so I eventually pulled the battery to make it stop. But if I put the battery back in, it went into its Roomba-bumping-into-a-wall loop again. Frustrated, I ended up re-flashing the entire system. That solved the problem, but I have to admit some regret at losing all my settings. It won't take that much work, but I'm going to backup to a mini-SD once it's done. tags: nokia n800 reboot loop

Nearly no change today. Le Grand Soir est pour demain (fingers crossed) Today's uploads: mserv, shaper, tftp-hpa. Some work on geneweb as the 5.0 release will happen soon (too late for etch). I'm also doing some work on i18n.debian.net, re-writing some scripts I stupidely lost on the server....

Phil Wainewright: “So here is a selection of news stories culled from the past few months that allow us to objectively evaluate what happens when users ‘have total control over things like privacy and security’… […] Would any of those laptop thefts made the headlines had the data been stored in Google Apps? No, of course not, because the data would have remained inaccessible on Google’s servers.” Great points. A little closer to home, how many times have you taken a call from an anguished family member who has just lost their data but who hasn’t heeded your advice to back up said data periodically? While we’re at it, how many times have you not heeded your own advice on the same subject? Could the SaaS providers possibly do any worse than we’ve been doing here? Granted, there needs to be a culture change, one that needs to happen on both sides of the transaction, to make this work. But it will eventually happen, because it Just Makes Sense.

I've been in a good mood toward the end of this week as the stuff I've gotten done has reached that critical mass that makes me feel I'm accomplishing something. First, I got a nice new domain for ikiwiki, with an irc channel for good measure, and there's also work on a Google Summer of code application for ikiwiki afoot. Then there was rather a lot of useful feedback and patches on ikiwiki, and a few nights ago a very tricky race condition was discovered. Batting around possible fixes for it on irc for several hours was pretty useful, it's a lot easier to think about locking, deadlock, races, etc, when there are some other minds to share the thinking. I eventually came up with a fix that seems ok, around 5 am that morning. Yes, my sleep schedule has been suffering.. On Thursday I took a digression into RL to fix some cladding that was pulled away from the eves of my house by a badly attached cable. I ended up wandering around Lowe's for over an hour -- when did that become such a fun thing to do? Oh yeah, when I bought a house.. Some kids were playing hide and seek; maybe a bit dangerous there but it has to be the funnest possible place to do it. Anyway, amoung other things I bought a collapsable ladder and had an interesting time on it 2 stories up while avoiding the nearby electric wire. Also fixed a broken latch on my wardrobe. Concurrent with all this, in $DAY_JOB, I've been working on the armel port of Debian, including getting d-i to work with it. Since this is an unofficial port, that is not gpg signed currently, this also gave me a chance to make d-i capable of dealing with an unsigned repository. Earlier this evening, I almost completed my first armel install on an nslu2, and I expect to release images by Monday. Finally, AJ reminded me about an item that'd been on my TODO list for far too long; some way for James to deal with gpg keyrings that doesn't treat them as binary blobs. I'd been meaning to work on that for oh, 2 years? 3? And I must have been thinking about it in the background a bit, because I fairly quickly came up with this gpg changesets idea, which is basically a dedicated revision control system, and a data format that's not too horrible (though it could be much nicer with support in gpg). Quickly followed by a whole working sample implementation that I hope James, or someone, will find useful.

We went to Scotland on a family holiday this week (brave or stupid, answers on a postcard). You would not believe the number of puns you can get from the simple town of Ayr. For example, R: “You should have turned right there!” Me: “Oh well. To Ayr is human.” I shall spare you the rest: if your mind isn’t already overflowing with similar appalling jokes, you’re no friend of mine. Whilst in Ayr, I came across a marvellous whisky shop, Robbie’s Drams, and bought a bottle of Laphroaig quarter-cask and another of Smokehead. This article, or what remains of it, is to describe the Laphroaig quarter-cask whisky. Should you wish to avoid the Flash-animated website, here’s a precis. Tales are told of a time when the business of Laphroaig was carried on less than legally and it was useful to carry away smaller casks when the Excise men were coming than the more conventional full-size casks. Over the past few years, they have tried their best to recreate the whisky that would have been drunk as Laphroaig a couple of centuries ago: quarter-sized casks, slightly higher strength and an older filtration model. The effect of the smaller barrels is to increase the surface area to volume ratio substantially, so more flavour will enter the whisky from the barrel. Thus, they bottle it much younger than their standard ten-year-old offering. To smell it, a sweet smell hits the nose — perhaps toffee apple. On the taste, there is an initial earthy sensation followed quickly by a brief flash of kedgeree, leaving the smoky aftertaste of turmeric at the back of the throat. This is a much more subtle whisky than Laphroaig’s ten-year-old: thinner and less oily, and with a much more delicate, though still substantial, peaty hit. Because it’s not chill-filtered, the whisky becomes delightfully cloudy when water is added. I recommend that you try it both with and without additional water: many of the flavours become more muted with water, but a creamy taste comes to the fore. In summary: if you can get your hands on a bottle or two of this, it’s well worth doing so. An excellent whisky. I should also say that even if you’ve disliked other Laphroaigs in the past, give this a shot. It may just be your way into the other delights from the Laphroaig distillery.

Today I was musing about different version control systems and merge algorithms. I've been thinking specifically about how I maintain Debian packages in Darcs. I tend to import upstream tarballs into one branch, and maintain the Debian packages in another, simply merging when a new upstream is released.

Now, there seem to be two prevailing philosophies on how to handle merges in this case. I'm thinking here about merges back to upstream. Say I want to contribute my Debian patches to them.

1. Commit "clean" patches upstream. Don't have a bunch of history -- the fixing typos commits, the fixing bugs commits, or the merging to track new upstream releases. Just something like a series of diffs against the current head.
2. Bring across the full history, warts and all, and keep it around permanently.

git encourages option #1, with its rebase option. Darcs encourages option #2 (though some use its amend-record option to work more like #1).

As I got to thinking about it, it occured to me that git-rebase would be very nice if you are going to use philosophy #1. In short, rebase will remove your local patches from a repo, update it to the latest upstream, then re-apply your local changesets -- aborting to have you fix any conflicts. This is as opposed to a more traditional merge, where you add the upstream changesets to your local branch and then commit new changesets to resolve conflicts. (So a rebase would be totally useless in situation #2)

I got to thinking about this, and started wondering what would happen to people that I'm working with that in turn work off my branches. And sure enough, the git-rebase manpage says, "When you rebase a branch, you are changing its history in a way that will cause problems for anyone who already has a copy of the branch in their repository and tries to pull updates from you."

I maintain, therefore, that git-rebase is evil and should be avoided. It only works for a situation where someone maintains a private branch of a project, never shared in any way except to submit patches to an upstream. Forget it if you have a team maintaining that branch, or want to post that branch online for others to help with (as I do with my Debian darcs package). Even if you keep it private now, do you really want to adopt a work process that forces you to keep it private forever, or else completely change how you work?

And this brings me back to the original question of patch philosophy. Personally, I dislike philosophy #1. I'd much rather have the full history of a change, warts and all. Look at the Linux kernel example: changesets that introduced bugs that made it into the official tree have their fixes documented, but changesets that introduced bugs that were fixed before being merged into the official tree could be lost to the public due to rebasing by submitters. Is that really what we want? I don't think so.

With Darcs, tagging is very cheap and it is quite trivial to write an "apply a changeset bundle" script that makes a before tag, applies a series of patches, and makes an after tag. One could then run a darcs diff between the two tags to see the net effect on the repository, or could still look at the individual patches. (Or, you can avoid tagging and manually specify the "from" and "to" patches.) I find that a much better model: you can have it both ways. I'd think that most modern VCSs ought to support some variant on that, too.

And I think that git-rebase should be removed on the grounds that it encourages poor version tracking practices.

After a couple of months' hard work, I've posted the schedule for XTech 2007. And, though I say so myself, it looks good. You can read more about the schedule itself over on the XTech web site, but I thought it would be interesting to explain how we got there. The people bit  After the call for participation, we wound up with 200 proposals in the system. From there, the target was to get down to 5 tutorials and 68 presentations. Each proposal contains an abstract of at most 500 words. I enlisted a small army of reviewers (69 in all) to help, and assigned four or five reviewers to each abstract. 829 reviews were assigned in all. The reviewers work blind, so they don't get to see who the proposer is.
After the review, I read every score and proposal, and created a shortlist of the best scoring proposals plus those that had spuriously low scores given their quality. From this shortlist the hard graft of preparing a draft schedule started. We had already decided in advance on our usual format: four parallel tracks of browsers, core tech, applications and open data. I then filled in the schedule, aiming to create themes for days, or at least for the 2-session blocks. The draft schedule and details of those shortlisted but who missed the cut were circulated among the committee. After some iteration and feedback the final schedule emerged. Picking tutorials was a little different, as this is done by myself and the committee directly. The constraints on choice are more commercially-oriented. Experience has shown we need mainstream topics that people will be happy to pay for. Even so, each year we try to include one emerging topic. Last year, it was Rails. This year, it's OpenStreetMap.
Choices made, I then notified the speakers, awaited their confirmation, and reached the point where we could publish the schedule. The mechanics of it all A glib reading of the above would make it all sound quite simple. And this year I'm pleased to report that it was a lot simpler than previous years. We have been able to use Expectnation from beginning to end, which has streamlined a lot of the work.  Expectnation's my super startup that's taking up the time that XTech and fatherhood don't! I'm about to tell you why it's wonderful, so please forgive a little pride.
Gathering the proposals was easy once the CFP had been set up inside Expectnation. I set up three calls: one for presentations, one for tutorials, and a secret one that the public doesn't get to see. (We always need a secret one for people who have very good reasons why they didn't make the public deadlines.) The review phase Recruiting reviewers was done by Expectnation's request system. This lets me send a request to a large number of people simultaneously, and collect their responses via the web app. (Previously, this had involved email, spreadsheets and wasted time.) The chart you see to the right shows the breakdown of the response to this request. If a reviewer said 'yes', they added a note to say which types of proposal they would review, and signed up for an account in the system. I then passed through every paper assigning four or five appropriate reviewers. A quick search each time allowed me to look for the right reviewers, and ensure no one reviewer got overloaded with work. Once reviewers were assigned, I headed over to the Mailroom department. Expectnation has a large number of configurable mailing targets, one of which is "reviewers with work to do". I emailed each reviewer with details of how to get on with the reviewing. Every reviewer then logged into Expectnation, saw the proposals they needed to review, and used the interface to efficiently score the proposals. One big lesson here is that it needs to be very efficient if you want to get the best reviewers, who are often the busiest. Another wizzy graph enabled me to keep track of the reviews, and the mailroom let me send out a reminder to those reviewers who hadn't finished their work yet, when the time for the close of reviewing drew near. Picking the papers Expectnation lets me sort and filter proposals pretty flexibly, so I went through the papers for each track in turn, ordered by their review score. Anything scored 3 or higher (4 is best, 1 is worst) was almost certain to be shortlisted. I read all the reviews and the abstract, and moderated any score that was unusually low (for some reason, reviewers rarely overrate proposals!) The next step was to set up the empty grid, shown in the top half of the diagram to the right. Here I added the empty time slots to the rooms we had, and assigned putative tracks to each of the rooms (they can be swapped around later if needed.) After that, the scheduling can start, shown in the second half of the picture to the right. Each empty slot can be assigned a paper from the shortlist for the relevant topic. That way it's easy to "paint on" talks into each room and quickly get a sense for the overall flow of the conference. Once it was time to finalize matters, I mass-marked all the scheduled papers as accepted, which automatically sent a notification to the presenters, using the same request system as for reviewers. When a speaker confirms, their proposal status changes and they appear in the final public grid. From there, I am able to use the mailroom again to inform speakers of the information they need to know. Additionally, speakers can log into the system at any time to see when they've been scheduled to speak.
Gridding out the conference in Expectnation is probably the biggest timesaver of all. Previously this involved a lot of sketching on paper or a spreadsheet, and a lot of manual work notifying people, and then more work creating the timetable to go on the web site. Now, both the grid and a full web of abstracts and speaker details are generated automatically. What next? As you can probably tell, I'm rather excited about both XTech 2007 and also about the work we're doing with Expectnation. What's next for XTech is the process of publicising the conference among attendees, recruiting session moderators, and also the writing of papers by the presenters. As the conference draws nearer, the attendee-level interactive features of Expectnation will kick in, allowing personal scheduling and rating of sessions. What's next for Expectnation is that we're ramping up to our 1.0 launch. We're working with a handful of early adopter customers right now, and are always interested in new use cases. As we get nearer the end of the first tranche of engineering work, we're going to gear up the publicity effort and start explaining to the world why we're special. As usual, I'd love to hear questions, feedback and suggestions.