larch: migrating mail between IMAP accounts

I recently had to move several gigabytes of email (not my own, work-related) into Google Apps (Gmail). As best I can tell, the way most people do this is that they grit their teeth and they open up a graphical email client and drag folders one-by-one. It’s a one-off job for most people.

There were a couple of reasons I didn’t want to do that. One is that I was on my parents’ DSL connection at the time and pushing gigabytes of data through someone’s DSL is a violation of good guest principles, at least in Australia. The other is that we have over 500 folders in the account I’m talking about: that’s a lot of mouse pain.

Anyway, here’s your answer, if you are in the same position as me. After substantial searching, at least for this kind of tool, I came across larch, which is a Ruby command-line tool for IMAP-to-IMAP moves, most tested on Gmail and essentially designed for the “move my mail archives into Gmail” use-case. It’s much more mature than most of the one-off scripts people have thrown up on the ‘net. It certainly seemed robust over this volume of mail, although I did have to run it a couple of times to get past a few errors (it does not re-copy already copied mail, so re-runs are fast). It deserves more search juice.

If you wanted to keep two accounts permanently in sync, offlineimap would be the tool of choice, although the manual still seems to regard IMAP-to-IMAP syncing as not as robustly tested as its core mode of operation, which is IMAP-to-Maildir.

Creative Commons License
larch: migrating mail between IMAP accounts by Mary Gardiner is licensed under a Creative Commons Attribution 4.0 International License.

Viewing attachments when using mutt remotely

Yes, that’s right, I’m still in the dark ages and do not yet use Gmail for my email. Even though it has IMAP and everything. I still use Mutt.

I almost always use Mutt locally, using offlineimap to sync IMAP folders to local maildirs. This means I don’t usually have the problem of being unable to view non-text attachments. However, for the next little while I’ll be using Mutt on a remote connection.

Don Marti has one solution to this, which assumes that you are accessing the server with Mutt on it via SSH (probably true) and are easily able to create a tunnel to your local machine, which is trivial if you are using a commandline ssh client, but while you can do it with PuTTY I figured it was just annoying enough that I might not bother. (And I doubt you can do it at all with those web-based SSH clients.)

My alternative assumes instead that you have a webserver on the remote machine that has mutt on it. It then just copies the attachment to a web-accessible directory, and tells you the URL where you’ll be able to find the attachment. It’s thus a very trivial script (and I doubt very much it’s the only one out there), but perhaps using mine might save you fifteen minutes over coming up with your own, so here it is:

copy-to-dir.sh (in a bzr git repo)

Sample output is along these lines when you try to view an attachment in Mutt:

View attachment SOMEPDF.pdf at http://example.com/~user/SOMEPDF.pdf Press any key to continue, and delete viewable attachment

In order to use it, you need to:

  1. copy the script to the remote machine where you use mutt;
  2. make it executable;
  3. edit it to set the OUTPUTDIR and VIEWINGDIR variables to something that works for your setup;
  4. set up a custom mailcap file much like the one Don Marti gives, that is, put something like this in your ~/.mutt-mailcap:
     text/*; PATH-TO-SCRIPT/copy-to-dir.sh %s application/*; PATH-TO-SCRIPT/copy-to-dir.sh %s image/*; PATH-TO-SCRIPT/copy-to-dir.sh %s audio/*; PATH-TO-SCRIPT/copy-to-dir.sh %s
  5. set mailcap_path = ~/.mutt-mailcap in your ~/.muttrc file.

Something like this probably could work for Pine and other text-based email clients used remotely too, but I’m not sure how because I don’t use them. And if someone wants to document this in a way that assumes less pre-existing knowledge, go ahead.

Also, making your attachments web-accessible means that they are, well, web-accessible. I’ve set up a HTTP Auth-protected directory using https for this, you should think about your own setup too.

Creative Commons License
Viewing attachments when using mutt remotely by Mary Gardiner is licensed under a Creative Commons Attribution 4.0 International License.

Ethics of Free Software community research

Most of this entry is exactly a year old today and it’s just sat around in draft form all that time. Since I posted something similar on Geek Feminism about research into women in tech and similar topics, I thought I’d get it out there.

In January 2009 a researcher named Anne Chin of Monash University Law emailed the chat list for the linux.conf.au 2009 conference asking for research subjects to be interviewed about licencing and Open Source software. There were several responses criticising her use of HTML email and Microsoft Word attachments. I’ll leave the specifics of this alone except that people should be (and probably are) aware that this is almost always an unknowing violation of community norms.

I did, though, think about making some notes on research ethics and Free Software research. A bit about my background: I am not a specialist in ethics. I’m somewhat familiar with ethics applications to work with human subjects, but not from the perspective of evaluating them. I’ve made them, and I’ve been a subject in a study that had made them.

For people who haven’t seen this process, the ethical questions arising from using human subjects in your research in general covers the question of whether the good likely to arise from the outcomes of the study outweighs the harm done to the subjects, together with issues of consent to that harm. (There are many philosophical assumptions underlying this ethical framework, I don’t intend to treat them here.) Researchers in universities, hospitals, schools and research institutes usually have to present their experimental designs to an ethics committee who will determine this question for them and approve their experiment. Researchers who work across several of these (eg, a PhD student who wants to interview schoolchildren) will need to do several ethics applications, a notable chore when the forms and guidelines aren’t standardised and occasionally directly conflict. Researchers working for private commercial entities may or may not have a similar requirement. Researchers who use animals also have to have ethical reviews, these are done by animal ethics committees, which are usually separate.

At my university, essentially any part of your research that involves measuring or recording another person’s response to a research question and using it to help answer that question needs a human ethics application.

The good/harm balance may include very serious dilemmas: is there a health risk to subjects? how will the researcher manage the conflict between maintaining subject confidentiality and research integrity and the good of her subjects or the requirements of the law if she uncovers, say, episodes of abuse or violence? But it also involves less immediately obvious and serious ethical questions. Is this study a giant waste of subjects’ time? is considered a question of ethics by ethics committees, and is in fact the most serious problem for linguistics research, since there’s very seldom an outcome of particular interest to the subjects themselves.

The study in which I took part a few years back was towards the serious end actually: it was a study into the psychological profiles of people who have an immediate family member who had cancer as a child and involved both questionnaires and a phone interview with a psychologist. Both because the study explored memories of the illness and because the profiling included evaluating depressive episodes, suicidal ideation and so on, it came with a detailed consent form and with information about a counselling service that had been informed of the study and was prepared to work with its subjects.

In the case of the Free Software community the ethical questions are often more towards the waste of time? end of the spectrum than the more immediately serious end. It’s important to understand that this isn’t necessarily the case though. Here are some more cutting ethical problems:

  • getting findings that expose your subjects and/or their employers to intellectual property claims; or
  • revealing that your subjects are breaching employment contracts in some way (generally also related to IP) and thus exposing them to job loss and possible civil action.

Getting ethics approval to carry out workplace studies can be fairly hard precisely due to problems like these. But in the rest of this post I will treat the waste of time problem.

Firstly the basics: are your subjects going to be identifiable in your final reports or to the general public? If not, who will know who they are? Can a subject opt to have their responses removed from the study? When and how? All this should be explained at the start. (Usually if an ethics committee has been involved, there’s a consent form.) If doing a survey look into survey design, in order to construct non-leading questions and such.

Now, for specifics. Most of them arise from this principle: there are a lot of researchers working, in various ways, on the Free Software community, possibly making it a slightly over-studied group if anything. This places the onus on the individual researcher to demonstrate to the community that their project is worthwhile and that they’re going to do what they say. Thus:

  1. demonstrate some familiarity with the background. Depending on your research level this could mean anything from demonstrating a knowledge of existing anthropological work on Free Software (say, if the research project is for your anthropology PhD) down to at least understanding the essential concepts and core history (say, a project at high school level). This can be demonstrated by research design, eg asking sensible well-informed questions, but actually mostly requires a bigger time investment: making appearances in the community, either virtually or physically, ideally for a little time before asking the community to help you get your PhD/A-grade/pass.
  2. don’t get the community to design your experiment for you. Have a specific goal, more specific than get people to write me lengthy essays about Free Software, and get ideas from that and write about them. In the general case, the ask people incredibly vague stuff and hope they say something interesting technique fails the waste-of-time test.
  3. give your results back to the community. The most common problem with the various surveys, interviews and questionnaires sent to the Free Software community is that responding to them is like shouting into a black hole. It is not unheard of, of course, to see the thesis or essay or roundup that comes out of these, but it is unusual, relative to the number of requests. Most of the time the researcher promptly disappears. Researchers should come to the Free Software community with an explanation of when and where they will make the results of the study available. They should explain the aims in advance unless this would compromise the results. (On that note: Anne Chin is giving a linux.conf.au talk this year.)

Creative Commons License
Ethics of Free Software community research by Mary Gardiner is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Possible structures for a technical talk

Edited version of a private email I sent about linux.conf.au 2010 preparation, but not conference-specific. The email discussion led to me enumerating the kind of talks that I think you can give about technical subjects at a linux-conf.au-style (non-academic developer-oriented) conference.

Recitation of facts; or the architecture diagram talk

In this kind of talk, the speaker walks the audience through, say, the architecture of a project. The talk contents are dictated by the architecture. Five minutes on the input module, five minutes on preprocessing, five minutes on transforming into a new set of matrix bases, five minutes on postprocessing, five minutes on sanity checking, five minutes on rendering.

This is the most obvious structure for a technical talk. It’s also the driest structure. It is useful mostly for audience members who want to work on or with the project code, which is for most talks a small fraction of the audience. It best suits very major projects with years of cruft in their architecture and a wide potential userbase.

Insane hack adventure; or “hacking the Tivo”, Andrew Tridgell, linux.conf.au 2001

In this kind of talk, the speaker usually talks about a project he or she personally undertook and structures it as a battle against the odds. So of course Y is the most obvious solution, although not trivial. So I tried Y for a couple of months. And then it turns out that the X protocol absolutely makes Y impossible for these reasons [dramatic pause] and at this point any normal human being would have given up, but I retired to a monastery for six months and returned refreshed and a lotus blossom I saw on my return inspired me to try Q…

This is probably the most effective structure for a technical talk and it’s surprisingly widely applicable (you can frame a lot of things in terms of here’s the current problem, here’s what you think the obvious solution is, here’s what happened when I tried it). The biggest limitation is that it’s very hard to do it about work you didn’t do yourself so it’s not available to all speakers. And you can misjudge it: so of course I tried Y says the speaker uh, Y is obviously dumb, why didn’t you go straight to Q? asks the audience (at some conferences, they might well ask it out loud, repeatedly). It doesn’t work for speakers who don’t have expertise (at least narrowly on this one topic) over that the audience has.

Demonstration of surprising ease

In this talk, the speaker proposes a task which sounds too formidable to complete in the talk slot. (Pretty much any task, for some talk slots.) They then proceed to show how it can be done despite the odds using their tool. Edward Hervey edited a video PiTiVi at linux.conf.au 2008. At OSDC 2008 Thomas Lee added a ‘unless’ keyword to the Python language.

This structure can be fun but it has a lot of pitfalls. Edward was continually battling to type while dealing with a handheld microphone. Speakers should recruit an assistant for these talks. The Python keyword talk was kind of fun, but it was also hard to follow: and now I am going over to this totally other tree and adding several lines to this other file at line 1099 and 1346 and is obviously required: he did not succeed in making me think I could easily edit the Python language. In all cases, it needs a decent amount of rehearsal: even more so than other talks.

Dropping of wisdoms

These talks are generally (at linux.conf.au anyway) talks about the social/community/artful aspects of coding. For example, Jonathan Corbet’s talk about how kernel hacking actually works in terms of the trees and maintainers etc at 2009. (One of Linus Torvalds’s bigger 2009 contributions was being in the audience for that talk and adding occasional commentary on his various prejudices.) Andrew Bennetts has had some good luck with a series of talks that began at OSDC 2008, in which he essentially lists every tool he can think of to help you make your Python programs faster. I didn’t see it but I would guess Paul Fenwick’s talk about awesome things you’ve never heard of in Perl was the linux.conf.au equivalent in 2009.

These are useful talks, the main pitfall is that they require considerable expertise over the bulk of the audience. Otherwise someone is just listing a bunch of stuff you do every day back to you. They also need to be about tasks or tools that a lot of people actually use or want to use. No one wants the hidden tricks to using libnousersexceptme.

Creative Commons License
Possible structures for a technical talk by Mary Gardiner is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Writing helpful reviews

I outlined the style of good academic reviews to Jonathan in light of our impending OSDC review responsibilities, and it’s worth noting here too.

For information’s sake, my authority, such as it is, on reviewing comes from being the editorial assistant of Computational Linguistics, which is a journal with a hardworking editor and conscientious reviewers. Not all academic reviews are of the quality I discuss below. They should be.

Begin with stating the title of the paper you are reviewing. Then spend one to three paragraphs summarising its content, particularly what you perceive as its major findings and conclusions.

This has a couple of purposes. The first is that if the reviews have got mixed up in the system the author finds out as soon as possible and doesn’t have to slog through a review that (perhaps) is a partial match for their paper and (especially in academic circles) a privacy problem to boot. The second is so that they know in what light to read the rest of the review. If they see that you have understood its fundamentals they will be inclined to take the entire review seriously. If they see you have misunderstood it, they can do one of two things. One is to realise that their paper is confusing, and to make its focus clearer. The other is to discount your review. The decision here may be affected by the following section.

The main body of the review is a discussion of how to improve the paper. Both the tone and discussion will vary considerably depending on certain factors:

  1. is the paper already accepted?
  2. is this the only reviewing round or will you or another reviewer be checking the changes?

For OSDC, both factors hold. For almost all conferences, there is only (at most) one reviewing round for full papers. This makes reviews more limited in scope than journal reviews, where substantial changes are often recommended even (or perhaps especially) to articles the reviewer fundamentally likes. Journal reviewers can have a role which is not far from being anonymous co-authors. (If a colleague did as much re-reading and suggestions of additional work and additional reading as Computational Linguistics reviewers do, many people would consider adding them to the authors list.)

In the event that the article has been accepted, or that this is the single reviewing round, you should limit the scope of your suggestions to much more cosmetic things. Someone who has had an article accepted is just going to be annoyed that you want it to have a whole new body of work incorporated, and they will ignore you. (And if it’s rejected after a single reviewing round, they are probably ill-placed to revise much!) In the OSDC scenario, reviewers are going to be mostly limited to suggestions as to how to structure the argument and the paper better, and not really able to productively suggest changes to the argument or the work described in the paper.

As you write your review and this section in particular, keep in mind the key factor of providing useful critiques: how could this work be better on its own terms? That is, don’t provide a review that is, fundamentally, about how the paper would have been better if you’d written it… about your pet topic. This is a subtle, tempting and common mistake, and if you have never caught yourself in it, you are likely to be the worst affected. Remember: What is the paper trying to do? How can it do it better? Avoid the temptation to suggest that it would be a better paper if it was doing something different from its current aim. (There is a little more leeway for this in journal reviews, but even in that case, generally what happens if a reviewer thinks this is that they review the article on its current form and recommend a fate suited to its current aims, and additionally comment that they would be interested in seeing further work in the additional direction should the authors choose.)

As a recipient of reviews, I do have a couple of things to add. One is to respect page limits. If you are reviewing for a work with a page limit, especially a conference, and you do really want to see a longer discussion of foo, please suggest which bar could be shortened or cut. Otherwise it is close to impossible for an author to consider your suggestion. Also, if you are making suggestions for future work that you think the authors should consider but which you do not actually want to see in the article, make this clear in the text of your review. I would probably recommend a whole separate section for this if you’re going to do it.

A review may conclude with a list of typos, spelling mistakes, suggested rephrasings, etc. Mistakes that affect the reading of the paper (eg mislabeled figures and sections) go right at the start of this list. A sufficiently ill-proofread paper may go back with a suggestion that the authors find the mistakes themselves.

Creative Commons License
Writing helpful reviews by Mary Gardiner is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Clean up IMAP folders

Per Matt Palmer’s blog entry OfflineIMAP and Deleting Folders users of any mail sorting recipe that creates new mail folders a lot tend to find that over time they accumulate a lot of mail folders for, eg, email lists they are no longer subscribed to. And most IMAP clients will waste time checking those folders for new mail all the time.

Matt wrote:

Now, of course, someone’s going to point me to a small script that finds all of your local empty folders and deletes them locally then issues an IMAP “delete folder” command on the server. But I had fun working all this out, so it’s not a complete waste.

I haven’t quite done this, I’ve just written a script that detects and deletes empty remote folders. (For me, offlineimap does not have the behaviour of creating new remote folders, so I haven’t bothered cleaning up local folders.)

It’s good: it’s speeding up my mail syncs a whole lot, deleting these old folders I haven’t received mail in for about five years. I’ve got full details and the script available for download (as you’d expect, it’s short): Python script to delete empty IMAP folders.

Creative Commons License
Clean up IMAP folders by Mary Gardiner is licensed under a Creative Commons Attribution 4.0 International License.

Headless / commandline Bittorrent

I made noises yesterday that I might learn about BitTorrent. So I tried. (It’s an interesting protocol from the point of view of needing clients to enforce penalties against refusing to upload.) Here’s the paradigm I wanted it to fit into: at, the command scheduler. 95% of my readership will know (intimately) how residential broadband works in Australia, but for those who don’t it is typical to not have unlimited downloads. On a good, just above entry level, plan you might have a limit of about 4GB to 10GB a month. (The entry level plans tend to have a limit of about 512MB or 1GB for only about $10 to $15 less. This is like selling small amounts of an addictive substance. Someone will eventually tell you about Google Earth.) However, it is also very typical to have an off-peak period with a higher, perhaps even unstated, bandwidth cap. (Mine is 48GB in a month, in the midnight to noon period only.)

Since I run a headless server anyway (for mail and music), I vastly prefer to schedule my downloads for when I’m sleeping and bandwidth is cheaper. When I’m going to download something available on the web, I run at midnight and then give the command wget --limit-rate=something -q -c [url] (-c because I’ve usually tested about the first 100K of the download already). In the morning, assuming I’m not downloading an album from a very well known band, my file is there. I therefore wanted to do the same with Bittorrent.

I’ll cut to the chase here: the solution is Transmission‘s command-line tools, particularly transmission-daemon and transmission-remote. The daemon controls all the torrents, and, usefully for my limited download window, they can be stopped and started from the remote command and therefore from cron. The only catch is that these tools seem to have only very recently matured, as in, they don’t exist in Ubuntu 7.10/Gutsy. (It has a transmission-cli package, but the daemon isn’t in it.) The transmission-cli package from Hardy will not install on Gutsy either, but you can backport it without any hassles, assuming you know how to get hold of and build Ubuntu (Debian-style) source packages, which, granted, probably doesn’t apply to 95% of my readership (although it might apply to a majority once we count Planet Linux Australia).

I thought this was worth sharing though, after I spent hours mucking around with BitTorrent (the Python client, not the rebranded µTorrent) and BitTornado, neither of which, even in the headless versions, has much support for such selfish notions as not wanting to run it until such time as it’s good and done (you can send SIGTERM and they do resume cleanly on the next invocation, not exactly champion of the world on design though), and neither of which puts up with this old-fashioned nonsense of wanting to run a process without a controlling tty. BitTorrent doesn’t even have an inkling that you might want to limit download speeds to anything less than maximum (perhaps Bram Cohen has never lived in a house with anyone else who wanted to use his net connection). I ended up looking at Transmission because the GUI version (also apparently very nice) is now Ubuntu’s default BitTorrent client. (Clutch is allegedly a nice web interface for Transmission too, but I haven’t looked at it at all.)

Edit: this post is not a bleg. The last paragraph describes a problem, yes, but this post is about how I’ve solved that problem by discovering Transmission. Please, there’s no need to email me on getting BitTorrent, BitTornado or rTorrent to work in screen or similar. I’ve discovered Transmission, which doesn’t need screen and which is very cron-friendly. This post is intended as a positive review of Transmission, not a request for help. End edit.

Creative Commons License
Headless / commandline Bittorrent by Mary Gardiner is licensed under a Creative Commons Attribution 4.0 International License.

WordPress locked down with HTTP Basic Auth

I run several WordPress sites for other people (this isn’t one of them). A couple of them are private: no password for the site, can’t read the site. For years I’ve had an unwieldly situation in which the lockdown was implemented with HTTP Basic Auth configured in Apache, and the users separately log into the site in order to post.

I used HTTP Basic Auth for locking it down even after I discovered Authenticated WordPress (requires a login as a WordPress user before you can see anything) partly because it’s accessible to RSS readers. Many RSS readers (and assorted web fetching tools) can speak HTTP Basic Auth. Few can log themselves into WordPress, although I wouldn’t be surprised to find an exception or three. Eventually though different search terms led me to the HTTP Authentication plugin, and it turns out they play nicely together. If you install them both the site requires HTTP authentication in order to access any part of it, and any person who has successfully authenticated is logged into WordPress too.

A couple of niggles:

  1. (The HTTP Authentication plugin requires that you have two matching lists of user names (well, actually one can be a proper subset of the other if you like, but users who aren’t in both can’t authenticate): the WordPress DB needs to have a registered user, and the external authentication source needs to have an entry for the same user.) Actually, I tell a lie. There is an option to automatically create a WordPress account for a user who shows up as successfully authenticated with an unknown user name.
  2. The HTTP Authentication documentation is slightly wrong: you don’t need the nickname to match the external user, you need the username to match the external user (which is the sensible way anyway).

Creative Commons License
WordPress locked down with HTTP Basic Auth by Mary Gardiner is licensed under a Creative Commons Attribution 4.0 International License.

Attaching messages to outgoing mail in mutt

When I want to forward an email to someone as an attachment (usually because I want them to reply to it without having to snip gunky forward ‘headers’ in the body and preserving Message-ID and such) I can’t always forward-as-attachment, sometimes because I’m replying rather than starting a new mail, sometimes because I’m forwarding messages from multiple folders.

Up until today, I’ve resorted to all kinds of tricks to add other messages as attachments to mutt messages. One old favourite was copying them (shift+c) to a new maildir, attaching the individual files and manually setting their MIME type to message/rfc822. This does actually work but there is an easier way, the attach-message function, bound to shift+a by default.

On the screen where you normally add attachments, press shift+a. Navigate to the folder containing the messages you wish to attach (if they’re in different folders, just do this once per folder). Tag all the messages you want to attach (the default keybinding for tagging a message is ‘t’). Quit from the folder browser (‘q’). All tagged messages will be attached to the outgoing mail.

Creative Commons License
Attaching messages to outgoing mail in mutt by Mary Gardiner is licensed under a Creative Commons Attribution 4.0 International License.

The art of the blow-off

This article originally appeared on the now defunct Geek Etiquette website.

The primary rule is to consider how much your absence will inconvenience your friend, and how much damage it might do to the relationship. The more of these factors that hold, the firmer you should see the commitment as being:

  1. you have blown off this friend for any reason in the recent past
  2. he has not blown you off for any reason in the recent past
  3. he has invested emotional energy in you in the recent past (eg letting you talk about a breakup or work woes)
  4. the plans involve a small number of people, possibly just the two of you
  5. the plans involve him going out of his way, eg travelling a long distance, making a lot of phone calls, reminding you of the event fifteen times
  6. the plans involve the organiser paying for things, especially in advance (consider this carefully… he may regard telling you that he paid a deposit, or that the tickets aren’t refundable, as crass, so use some common sense)
  7. a number of other people have blown off this event already
  8. it’s close to the event, such that the organiser is likely to have chosen to say no to other things that might have been fun and/or profitable because he had committed to his plans with you
  9. you have expressed extreme enthusiasm about the plans (even if you actually express extreme enthusiasm about everything)

If you consider these, and either very few of them hold or your reason for the blowing off is stellar, you should:

If you consider these, and either very few of them hold or your reason for the blowing off is stellar, you should:

  1. make every effort to cancel as early as possible
  2. apologise sincerely and be accepting of and don’t call the organiser on any irritation that creeps into her voice
  3. if money was spent, make several firm offers to repay the organiser for the money she spent on you (about three firm offers is the right number). If you can possibly afford to, don’t ask her to buy back your ticket from you if there was one: give it to her for someone else’s use.
  4. when apologising, don’t explain the excuse in great detail. You probably should mention the general idea (“this big project has sprung a leak”, “John is in town”), but don’t lean on it, even if it’s really important to you, and especially if your motives are money (eg overtime rates).

The only time that you should dwell on your excuse is when your excuse is traditional: that is, you were sick or another friend or family member died or was sick and needed you. Attempts to downplay that come across really strangely (eg “I had this seizure type thingie, oh well, I’m so so so sorry, I’m such a bad person”). Your friend will want to help or sympathise, most likely.

Otherwise, the problem with explaining your excuse in great detail is that it comes across as tantamount to explaining to the nearest cent exactly what the relationship is worth to you (“ok, so I’m less important than the boyfriend’s last minute availability”, “ok, so overtime rates trump my friendship”). More details actually make this impression worse, not better, because they show just how cold-bloodedly you calculate the worth of your friends. This may seem like nonsense—we’re all upfront hyper-rational geeks here who should be happy to have our friendship valued at market rates—but remember, it’s best for her when you over-commit to a friendship. So showing signs that you’re only rationally committed is hurtful, and not only at the conscious level either.

In some cases, eg hard to get tickets or the like, it can be nice to make gentle offers of a replacement for yourself. “Please go ahead and find someone else to take with my ticket. If you don’t find anyone, I know my friend Karen would be happy to go with you, and you’d love her, so give me a call.”

The best way to make amends is to firstly be careful to honour social engagements with this person very highly the next couple of times and depending on the level of trouble you put them to, try and assume the organiser role next time. Take the trouble on yourself, and furthermore organise to do something that your friend likes, at a time and location especially convenient for her, rather than yourself.

Oh, and if the reason you are blowing your friend off is because you suspect that he or she is romantically and/or sexually interested in you, and you are trying to gently signal your own lack of interest, this is a bad way to do it. The good way to do it is to bite the bullet and deliver that awkward “um, so, I’m not sure if I’m right, but just in case… I, um, I’m not interested in dating/shagging you” line and then give him or her a week or two without unnecessary contact so that he or she (a) believes you and (b) can choose to put on a social mask and pretend that this interlude never happened.

On the other hand, if you are blowing off a friend BUT you are romantically or sexually interested in him or her, just your luck, they probably will read blowing them off as a irrevocable sign of your lack of interest. If for some reason the time is not ripe to make a completely unambiguous move, you need to really work hard and express your regret at missing this thing, and furthermore, organise a replacement event almost immediately, ideally one that’s slightly more intimate and slightly harder to organise than the one they organised for you.

Creative Commons License
The art of the blow-off by Mary Gardiner is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.