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.

On my surname

I’ve been married for nearly five months. I still use the surname on my birth certificate rather than my husband’s surname. I haven’t talked to anyone about why, and no one has asked either, so this isn’t That Entry.

This is, however, Another Entry, which is about why people who call my house think that my name is Mrs B. This isn’t even so much about being actually married. It’s been going on for years. If I answer the phone, and it’s a telemarketer, or back when Andrew was looking for work, a recruiter, they will automatically assume that any woman who answers the phone where he lives must be both married to him and using his surname.

And this is positively weird to me. It’s true that married couples using different surnames are getting less common as time goes on after peaking about 10 to 15 years ago. However, living arrangements other than husband and wife are getting more common. De factos are common, and they almost inevitably have different surnames. We could also be platonic housemates. In any of those cases I could have any name in the world. When they want something from me, a donation or a sale, addressing me by the wrong name is a mistake. I know that English doesn’t really have a polite telephone script when you don’t have someone’s name, but that’s really too bad: it isn’t somehow better to have just guessed that I might have picked up a name from the man who lives in the house. Surnames are only communicable in a limited number of circumstances.

It’s doubly weird from telemarketers. We happen to be listed in the phone book under his first initial and surname alone thanks to old share house division of labour when it came to accounts (likewise, the electricity has been in my name since 2002, three houses ago). So the person calling has no prior knowledge that there’s even a Mr B at all. I could be the person listed in the phonebook. And yet inevitably it’s Mrs B for me. I have a surname don’t I? Stands to reason it’s because I’m married to someone.

I’ve only had the pleasure of the reverse a few times yet: where people assume from the different last names that we’re not married. Of course most people don’t give a rats nowadays, so whatever assumptions they make don’t really make it out of their heads. The only exception is the travel agent who recently booked our flights to Thailand put me down as Miss G (my understanding is that married women really don’t use the title ‘Miss’ even if we keep our surnames), that’s about it. It wouldn’t rate a mention as a bit peculiar except that we both sat in front of her wearing gold rings on our left ring fingers for half an hour.

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.

How to accept an invitation

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

Traditional etiquette is pretty spot-on about accepting social engagements in the first place. A quick rundown for those who aren’t familiar:

You get an invitation. For geeks, it probably comes in email, unless everyone has moved to Google Calendar without me looking. For big ticket events like weddings, you might still get a written invite. You reply by the same method you received the invite, unless another method is specified in the invitation itself.

You should reply to all personal invitations that come from people you know, either accepting or declining. A personal invitation is one-to-one (or one-to-a-few, in the case where households or partners are invited together). For public events like LUG meetings, you typically don’t reply unless there’s specific instructions to, and usually those will ask for acceptances only. For those, general invitations are issued to the public, rather than specific invites to individuals. In case of doubt though, it doesn’t hurt to reply.

Responses should be timely and brief. Let’s look at those.

If the invitation has an RSVP date, this is the drop-dead date for responding. The date is typically influenced by things like the date on which your friend must tell their caterers the final numbers, or on which she wants to do that giant shopping run to buy all the pizza ingredients. Replying before the RSVP date is the best thing to do and you should aim to do this almost all of the time. If you can accept or decline right away, do that, so you don’t forget.

If you’ve missed the RSVP date by a few days you should typically send profuse apologies and, if you want to accept, non-pushy inquiries about whether a late acceptance is all right. If you’ve missed it by much more, you need to decline the invitation with profuse apologies for being so late. Accepting is no longer in the question, unless your friend tells you that you can do so. Don’t ask; if this offer is going to be made, they will make it.

If the invitation has no RSVP date, you reply as soon as you can make a decision. You can work out a rough drop-dead date, usually: when do they need to start spending money? For an average sized informal party, it’s probably a couple of days before. For a trip overseas, it’s probably several months before. You need to reply before you think they started spending money on guests.

Now, to your brief replies. If you’re accepting an invitation, you say something like “I’ll be there, and I’m really looking forward to it.” There’s special wording for replying to formal invites, basically mirroring the invitation back at them. (If they said “Ms Nerd requests the pleasure of Mr Geek’s company on the 9th June”, Mr Geek replies “Mr Geek accepts with pleasure Ms Nerd’s invitation for the 9th June”.) You likely only need this for weddings and there are lots of websites with full examples of how to word replies to formal invites. Otherwise, all you need to do is accept and express that you’re looking forward to it. Don’t go into any and all sacrifices you’re making to come. (“It’s really a pain to get flights that weekend, and my usual travel agent is
away, and I’m going to miss my new puppy, but I’m coming because I just love you that much.”)

Once you’ve accepted the invitation, you regard this as a fixed engagement and you must either turn up as you said you would, or break your word, a subject we’re going into soon. You never just fail to show up and don’t either warn them beforehand or apologise afterwards.

If you’re declining, the excuse you use in all circumstances is either “I’m so sorry, I have a prior engagement, I would have loved to be there” or “I’m so sorry, I won’t be in town, I would have loved to be there”. Not being in town gets its own excuse because ‘prior engagement’ refers to plans for a particular day. It just sounds weird to call your six month holiday overseas a ‘prior engagement’.

‘Prior engagement’ is what’s called a ‘polite fiction’: it covers everything from a real prior commitment to your need to wash your hair that night. That is, in the event that you can’t be bothered or just don’t want to, the phrase for this is still “I’m so sorry, I have a prior engagement.” (Alternative phrases include “I already have plans”.) Almost all explanation beyond that comes across more as “your event sounds dumb” than “I really wanted to come but can’t”.

One geekly explanation for this, if you like, is cognitive load. You care deeply about not liking smoky venues, or not liking events that Boring Dude is at. That’s fine, that’s why you’re allowed to decline invitations and organise your own events which are in fresh air and to which Boring Dude is not invited. There’s no reason to bring it up for a particular event, because that event is already being organised and there’s nothing that can be done about it without the organiser making radical changes, so you’re just adding to her load of things to fret about. If smoky venues and Boring Dude are about to cost the organiser your friendship, you should bring this up separately when a particular event isn’t under discussion.

The only exception to offering generic excuses is when invited to something by intimates who know what you’re doing most days: partners and very best friends. With them, you should be more open. Etiquette by and large is a guide to social relationships, not intimate ones.

Creative Commons License
How to accept an invitation by Mary Gardiner is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

The linux.conf.au review process

I’ve written already about the type of proposal that is likely to be accepted to linux.conf.au, this is a discussion of how the process worked.

Our process aims to find a good set of talks. Past conferences have asked for written papers too, but we do not believe they are widely read and some authors have simply not sent them in, which is possibly unfair to people who believed the given requirements and wrote their paper. This year we didn’t ask. By not asking for papers, conferences like linux.conf.au are missing one opportunity to actually check that our speakers have had more than a paragraph worth of thoughts concerning their talk. Hence the emphasis on known good technical quality and known speaking ability in the criteria.

I’d like to make a quick comparison here with academic computing conferences. Firstly to clear up a common misconception about academic conferences: people don’t just read their papers out loud; or at least not in computing. I’m told they do in philosophy. It’s meant to be an engaging narrative about a problem and its solution, much like a technical conference talk. (Both types of conferences have speakers that fail at this.) The selection is very different though: for an academic conference you submit an abstract or a full academic paper, usually in the 8–15 pages range, and selection is usually based entirely on the quality of the research as demonstrated in the paper, rather than on your history as an engaging or hugely popular public speaker. And the papers are actually important, in computing they will contain (or ideally contain) enough details to allow people to replicate the research (in traditional experimental science, that stuff goes in journals, in computing journals tend to contain only very serious and really stellar work). People wanting to do serious critiques of the work or to extend it will refer extensively to the paper; the paper matters in the way that code does in Free Software. Reviewers will study the paper in detail: ten conference papers would be a very very high reviewing load for a single conference.

This year all program committee members were asked to review all proposals. We voted on them, literally, on a scale of 1–5, which I personally interpreted as please no through to I will die if we reject this, although other reviewers may have calibrated differently. We did not provide feedback that was intended for the authors. We did not, therefore, do what would be called peer review, which is about extensive constructive criticism of the work suggesting ways to improve it, even if it is being rejected. That’s expensive for reviewers and would require drawing reviewers from a broader range of backgrounds: the kind of expertise required to say this talk is not terribly exciting is not the same as the expertise required to write a letter to the author suggesting technical improvements to their work. I called the linux.conf.au process Am I hack or not? initially, although since our acceptance rate is about 25% this turned out to be unfair to people who were rejected. Many were actually hack.

That acceptance rate does have certain effects when it comes to our criteria. We are not able to take many chances on people without a track record. We do not have the reviewing manpower to make any useful suggestions to people about their work or their talk proposal, although this would be possible with some other processes we could have used. The abstracts length for this conference makes proper peer review impossible (we could offer suggestions about making a better abstract, but not about doing better work as such even if we had the manpower). We can aim to possibly only select good or excellent talks.

I’ll be interested to compare the PyCon process, particularly since they’re pattern nuts and have found a series of patterns around which you can organise your committee meetings. I have to say an occupation hazard of doing these things is that you really want to go to the conference afterwards. I’d kill to go to PyCon now, if it wasn’t that that wouldn’t help me get a ticket to Texas one bit.

In other news, the linux.conf.au programme is available. Here’s talks I’m particularly looking forward to:

  • The Kernel Report (Jonathan Corbet)
  • Fixing suspend for fun and profit (Matthew Garrett)
  • Digital Preservation – The National Archives of Australia, Open Standards and Open Source (Michael Carden) [although unfortunately this is up against Val Henson, who I’d also like to see]
  • The OzDMCA: what it means for FOSS (Kimberlee Weatherall)
  • Tutorial:GIMP Uncovered: Understanding Images and Image Editing (Akkana Peck) [I’ll have to catch either Kimberlee Weatherall or Akkana Peck on video though, another clash]
  • Starting an Open Source business (Paul Fenwick)
  • How to Herd Cats and Influence People (Jono Bacon)
  • Concurrency and Erlang (André Pang)
  • Making Sausage: How the OLPC Machine Was Designed (Jim Gettys)

Andrew has already put his hand up for the cricket match and he doesn’t even have permission to take the leave yet.

Creative Commons License
The linux.conf.au review process by Mary Gardiner is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Women and men, across the ocean, and the vessel runs aground

I’m occasionally asked what it’s like being a "woman in Linux". It’s not such an easy question for me to answer: what’s it like being a man doing the shopping? what’s it like being an elderly person drinking Scotch? You can say lots of things about the shopping and the Scotch, but not a lot about the maleness or agedness of the experience.

I suspect most of my "woman in Linux" (in the user sense, I’m not a developer) experiences are pretty subtle: some of my unease in combative situations is undoubtedly socialised, and some of that socialisation is probably related to being a woman. But which bits? How much? Who knows. Questions about being a woman in Linux always leave me floundering.

Raven, a "woman in security", has an answer though. For her, the "woman in X" question is all about being hit on. Relentlessly.

I don’t get hit on relentlessly. I get hit on about as much as most men seem to: hardly ever. If I was going to draw parallels with Raven’s experience, I would draw them not with experiences of fending off the horny masses, but of fending off the hordes of people who’ve never met a woman as tall as I am.

At 190cm, I’m willing to believe I’m one of, if not the, tallest woman most people have seen, or at least spoken to. (I have, in the course of my life, seen about four women who are taller than I am, and I keep an eye out, trust me.) And I hear about it a lot. I’ve heard all the jokes. I’ve heard all the compliments. And I’d like to think I’ve heard all the insults, but I have my doubts.

I’ve even well and truly had enough of the empathetic tongue-in-cheek responses ("I bet people say that all the time, hey?") but I try to take them in the spirit they were meant: more empathy is more better, as a general principle. I don’t want to discourage people from walking a mile in someone’s shoes, especially if they’re someone who stocks shoe stores and can order in size 11s for once.

But there are a number of parallels with being hit on, and one of them is that not everyone is a well-meaning bumbling fool with a propensity to innocently hit on women or call tall women "lanky bitches" if they run into them around a corner. (I have never heard the word lanky unattached to bitch. What quirk of humanity spawned that meme?) A number of people dealing out this stuff are out to hurt people. In fact, a solid majority of people commenting on my height are complete strangers commenting with the intention of hurting or embarrassing me.

One of the most common responses to "I get hit on all the time&quot rants, after "wow cool what the hell is wrong with you, whinger?" anyway, is "I can see how that’s a little annoying, but you know, they mean well. It’s a compliment. Whinger."

That’s crap. Sure, some of them mean well, in so far as wanting to have sex with someone is meaning well (I think it’s neither a virtue nor a vice in and of itself, but some of the people who want to gift Raven with the spawn of their geek genes prove that Stephen Pinker’s gentle "good for your genes isn’t the same thing as morally good" warnings could be hammered into his books with a chisel and they wouldn’t be clear enough). But the reason people who get hit on a lot find it creepy isn’t because they’re weirdly hostile to the compliment of someone’s flattering and harmless attraction, but because being hit on can be genuinely creepy. And is. A lot of the time, it is.

A lot of the sexual attention I get is decidedly negative: it’s more or less suggestions of sexual violence from passing strangers (usually driving past, but occasionally they’re brave enough to mutter threats as they pass me on foot). I didn’t count that in the "I don’t get hit on" count: if I counted people who yell "suck my cock, lanky bitch" out of cars, I get hit on any time I’m out walking after dark.

I won’t pretend to speak for all women here: some women do consider the vast majority (or possibly all) come-ons as a compliment. I try to take them as they come. But I’m sick of the ‘compliment’ defence in general, it’s as bad as the joke defence. Sexual attention is neutral: when you get it a lot like Raven does, it’s as annoying as being asked about your height all the time, and it also is sometimes used as a way to hurt people, making them scared, or embarrassed, or leaving them feeling like shit the rest of the day. Some other times, it’s a compliment, or mutual, or otherwise wonderful.

And you know, most people can tell the difference. The people on the receiving end know the difference, and the people dealing it out damn well know the difference too.

The height analogy glosses over the fact that being constantly reminded of your gender (not always by being hit on) destroys the "we’re all geeks/friends/partners/collegues here" feeling. I’m lucky to escape that, and if I was offered the trade of being constantly reminded that I’m female — and therefore different — in a group of men against being reminded that I’m really tall — to some people, unattractive — I’ll keep taking the latter.

But in either case I can’t stand the stupidity of the "it’s a compliment!" defense. Nothing’s automatically a compliment.

Some things are meant to be a compliment, or friendly, or whatever, and are taken badly because the recipient has had a bad day, doesn’t like the same things about themself that you like, or has heard your complimentary little joke fifteen times that morning, and fifty times yesterday, thanks. Some people are cranky (OK, I confess).

But some things are never meant to be a compliment in the first place. Come-ons regularly fall into one of those categories. If you want to compliment someone, see if you can figure out what makes them happy, rather than deciding on their behalf what should make them happy, doing it, and then giving them a lecture when they complain.

Comments

I, too, get hit on virtually never, and I wonder about the difference between Raven’s and my experiences on that issue. Is it a matter of the network security field being a whole lot worse than the embedded software development field I’m in? Mine is probably equally male-dominated, but I have the impression there’s a much lower percentage in my field of the jerks Raven describes. Or perhaps it’s that I’m not as immersed in my field as Raven is in hers. I feel like I’m still a fledgling in my field; my employer doesn’t pay for me to go to conferences (as I don’t have anything about which to speak there), for instance.

Posted by katie on March 19, 2004 01:13 AM

At LUV (linux users victoria), I’ve not seen anything adverse to the one or two women we have. Nothing on the mailing list either – or at least, the posts I have read.

But I did hear about that big SLUG stupidity. I think SLUG is a lot bigger than LUV, but no idea really.

I would certainly like to think that this wouldn’t happen in Linux – most people seem mature enough. Perhaps the security thing might have been from script-kiddies?

Astronomy is way too petty and political, so its hardly surprising that women would be treated bad, and consequently lose interest after honours (we’ve got 4 out of 30 – despite there being lots of female summer students coming through).

Nice article, BTW.

Posted by TimC on March 19, 2004 01:33 AM

Librarianship is a fairly non-grunchy profession, as these things go… of course, the way this works is that the entire bloody profession has been grunched—our pay reeks and our image is worse. Nonetheless. Librarianship is blessedly grunch-…

Trackback from Caveat Lector on March 19, 2004 01:10 PM.

Getting a talk into linux.conf.au

We had a programming committee meeting for linux.conf.au 2007 on Saturday. Decisions were made. They may be revised based on budget. But the general consensus was that it’s the papers that linux.conf.au rejects that makes linux.conf.au the best. And here’s the more cuddly than Rusty guide to being among the best.

First a note. We had in the order of 250 proposals for 60 talk slots. (The ratio is a bit better for tutorials, about 2 proposals for every slot available.) We reject most of what we get, and we reject a fair number of things we suspect or know would be perfectly fine talks. It’s a competitive conference.

  1. Software talked about or that is core to your talk must be available under an Open Source licence. This is not negotiable, with a tiny bit of wiggle room for people who are waiting for their employer to sign off on an Open Source release. Only a little wiggle room, mind you.
  2. It is getting towards being a requirement that you are a core member of a project, or of the part of it you’re talking about. You need to have written a fair chunk of the code, initiated the documentation project, done the benchmarks, whatever. Sweated the sweat. Tutorials are a little different: for a tutorial, evidence of ability to convey enough knowledge well is generally important, and depending on your intended audience might trump not being a major developer of the tool in question.
  3. Project maturity is not essential, but is desirable. If it hasn’t been merged yet, or you are the only user, it will have to be great to be accepted.
  4. Enormous maturity can be a disadvantage, or at least it is if it leads to the the style of proposal that goes here’s the update on my LCA 2005 talk about [some project]. It’s easier to get accepted if you submit a talk focusing on a particular new feature or development.
  5. Being known as a good enough speaker is a big advantage. Standards here are high, but I feel not crazy. You can be accepted without being an amazing speaker. It is, however, essential to convince the review committee somehow that you have had and can convey 45 minutes worth of thoughts about your subject and that people will want to hear it. Being known as a good speaker from other conferences or events is excellent, and a high quality abstract can be convincing in some cases too.
  6. Insane coolness is another huge advantage. In particular, people who’ve built things they can hold in their hands, put their arms around or have a sword fight with, tend to get their papers accepted. Most proposals do not fall into this category, those that do have a high acceptance rate.
  7. Not submitting a kernel talk helps your chances of acceptance. This one is interesting. The problem is that we get a huge number of very good kernel proposals. linux.conf.au accepts a fair number of kernel talks, but is not a kernel conference and doesn’t intend to become one. So to get a proposal accepted into this stream, you must not only be good, but be very very good.
  8. Not submitting a general commentary on your experiences in the Open Source world also helps your chances of acceptance. Again, we accept some of these, but almost everyone has opinions on how to run an Open Source project, and they submit a variety of them. We need some special reason to believe you have something to say that the audience can’t easily think up for themselves or read about.
  9. Having some relevance to a primarily Australian audience is useful. This is really only meaningful for the above mentioned commentaries, for things like kernels it doesn’t matter, and if it’s hella cool, it also doesn’t matter.

For comprehensive information about submission statistics and a list of all the program committee’s blog entries, see John Ferlito’s entry.

Creative Commons License
Getting a talk into linux.conf.au by Mary Gardiner is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

A degree in computing?

This is a re-publication of an essay I originally posted on a now defunct website in September 2004.

I’m obsessed with understanding the minor failures in my own university education, probably unreasonably so considering that I have two undergraduate degrees, good mental health and a debt to the Australian government that will buy them only one new low range car.

Nevertheless, there are a few striking things about a degree in computer science that I’ve learnt through experience, and thankfully sometimes through the experience of others, that I think are worth noting for the record. This essay is a guide for people considering starting a undergraduate (bachelor-level) computer science degree or computer science major. I’m going to lead with the negatives: I think people should think more carefully before starting computing degrees, and degrees in general for that matter. But as I don’t actually regret the degree, I will conclude with some positives.

Why you may not want to do a computer science or computing degree

You aren’t suited to university

By this, I basically mean that you don’t want a degree. Degrees are what universities think their purpose is. Degrees are annoying things to get. In most universities there’s a complex set of rules governing which subjects you have to take in which combinations, which subjects you can’t take, how many subjects you can take, what marks you have to get, and what level of courses you need to do. They almost invariably involve at least one time-serving course which is totally uninteresting to you, and one boring but difficult course which you need to put a lot of work into.

Once you jump all those hurdles they let you wear a silly hat.

Further, universities are geared towards students getting degrees. If you show signs of not being such, like repeatedly failing courses, or simply doing too many low level courses and not enough final year courses, they have a distressing tendency to try and throw you out.

Further, at least in Australia, you can get by without degrees in computing fields. Their official function is to act as a stepping stone into academia, or as a heuristic for employers to demonstrate that you are capable of completing a long, and more than somewhat arbitrary, list of tasks in order to achieve a goal (employers are in the long and arbitrary tasks business too). They also indicate a certain skill set. But they aren’t the only way to show that you have that skill set.

Larger organisations get a bit hung up on them. It can be difficult, for example, to get work visas to certain countries without a four year degree in a relevant field. As businesses get bigger, it tends to get more likely that “degree in relevant discipline” appears in the ‘mandatory requirements’ section of job ads too.

While failing to get a degree you wanted can be miserable, hanging around at university without much intention of getting a degree can be fun, especially in countries that have low tuition fees. My experience of people who do this is that they eventually get sucked into the degree mania and have some regrets, especially once their friends start graduating, but if you really want university without the degree I don’t have much more advice to give.

There’s good things about university too (later!) but if this description is making you grit your teeth and long to flee into a job, or possibly to the Himalayas for a good long hike, follow your dreams there instead.

You don’t like programming

To people who know about the content of most university computing courses, it will seem extremely strange that you want to do computer science at all. The reason is that university computing courses focus on one of two things: in the vast majority of cases, that is programming theory and practise with dashes of software engineering and a smidgen of computing theory (discrete mathematics, in other words); in a small minority of cases they concentrate on computing theory.

In short, if you are certain that you do not like computer programming, you should not do a computer science degree, with a few rare exceptions for people who like the mathematics rather than the programming and want to do a theoretical computing degree. Even in that case, check the program you’re entering thoroughly because almost all of them will have you programming much of the time. You might well be better off in a mathematics major.

If your bent is systems administration or other techie non-programming skills, you will also want to avoid most undergraduate courses, because they teach programming to the exclusion of what you’re interested in. There are a few exceptions to this, and you might find some interesting Masters courses, but be sceptical and enter programs only when you’re sure that you aren’t doing “programming with a dash of systems” when you want systems. It’s likely you could find relevant courses outside the undergraduate system, and it is worth considering skipping the whole thing and learning on the job.

In the, alas, most common case, where you have some idea that you might like to “work with computers” (or often, you would like to manage people who do), have no particular existing skill set above using your computer for email or gaming, but are certain that coding is not your thing, you don’t want to touch a computing degree. In the best case you’ll struggle through a semester or two, realise that it’s all programming and you hate it, and spend another semester or two establishing prerequisites in a different field. In the worst case you’ll push through three or four years wondering when you’re going to learn ‘industry skills’ (meaning management). You aren’t. You’re in a programming course. Definitely skip the whole thing. Do a little research and find a faculty or major that teaches the skills you want or the things you’re interested in.

There are a number of non-programming computing majors, normally called ‘IT’ or something similar (although not always, some ‘IT’ courses are also programming courses). These generally have varying amounts of ‘basic computing’ (using office products), system design, project management, database design, and business skills. Computer science students tend to look down on these courses, but the few people I know who’ve done them say that the management skills they teach can be worth it. The only thing I’d warn about if you’re thinking of one of these courses is checking whether you like programmers themselves. If you find them insufferable or laughable, you’re going to have a hard time managing them and it might not be worth training to do it.

You have no idea if you like programming, because you’ve never done it

I know several people who started university in this category, two of whom graduated from computer science with highest honours. Unlike loathing programming, it’s not a death-knell for your enjoyment of the course. In addition, at least in Australia, all computing degrees assume that you cannot program when you begin them (the University of Sydney claims that, except for a few very experienced students who earn excellent marks easily, the difference between the experienced and inexperienced in terms of marks is negligible after three months).

Nevertheless, before committing three or four years and a fair bit of money to a programming degree, you may want to get a basic idea of what it is you’re going to be doing with your time. There’s a few options: there are a lot of online programming tutorials these days and many free toolkits — a lot of your programming is going to be self-taught anyway, so you could start out that way. You could also take a summer course at a technical or community college. Which one you want to do may depend on your personality: as a beginner I spent a lot of time trying and failing to think of interesting practise projects, so I guess I was a course-type person.

Programming is difficult and frustrating initially, but allowing for that, having a little programming experience will help you decide whether you like it enough to spend years listening to people talk about nothing else.

You love programming and are very experienced

By this I don’t mean that you got high marks in high school computing courses (or at least, not that alone). People who can program to the extent that they get high marks in your average high school, but not a great deal more, will probably find computing degrees really useful: you will meet people more skilled than you; you will find many of the assignments at least somewhat challenging; and while you will probably begin to find the lecture courses dull, they won’t cause you to attempt to pound your lecturer’s head through the wall.

Even in this case, you will find the early stages, which are aimed at the non-programmers allowed into the course, quite frustrating. But it’s quite likely that you will learn a great deal in the later years of the course, from courses and especially from classmates. You might well emerge ready to program professionally. In case you can’t tell, this is the category I entered university in.

But if you’re experienced to the extent that you’ve written working 10 000 line (or much more) projects for fun, have programmed professionally, or have done extensive work with others, you are likely to find at least the first two years so insufferably tedious that you may well be tempted to turn violent. Anyone who is a major code contributor to a medium sized Open Source project almost certainly falls into this category.

In addition, you may not do very well. There’s a couple of reasons for this. First, it’s unlikely that you’re going to be doing programming exclusively. In most computing degrees, your first year will include mathematics courses, and depending on the institution, it will probably also include at least one business, engineering, or science course. Your programming experience will probably not help you pass these other courses — which is not to say that other abilities, such as good mathematics skills, writing skills, or a good memory won’t get you through them — and the mind-numbing simplicity of introductory programming risks convincing you that you can pass them as easily as you will programming.

Or will you? Mostly, yes, with blindingly good marks. But alas, programming courses will often involve just enough theory to trip you up if you aren’t interested in some of the theory, or neglect to flick through the textbook: you’ll code up a storm but be unable to remember precisely how pushdown automata work when it comes to the exam (unless you ever coded one of course!) This is sometimes more the case as the degree goes on.

Some people who are experienced programmers might prefer to do a related degree with new skills (like mechanical or electrical engineering); a theoretical degree with a lot of maths, since they’re less likely to have taught it to themselves already; or a completely new field, if they want an extended break from their programming. Others might skip the degree. Otherwise reconcile yourself to the tedium a bit and try and seek challenge in your fellow students and your teachers, not your courses themselves.

You have no academic interests aside from programming

As above, most university degrees require some semblance of balance in your courses for a few years until they finally let you geek out on an all computing extravaganza. Annoyingly, some of these courses will also stand in your way — in particular, failing maths may stop you proceeding in computing.

If you really cannot stand any of the other subjects that are likely to comprise your program (make sure you investigate what these are) or aren’t going to be able to pass them, you’re going to have a hell of a time getting to the interesting bits of computer science inside the university system.

I did a science degree with maths and computing, and an arts degree with linguistics and philosophy: the first is a fairly typical computing degree. Other common ones are engineering based courses, which will have a lot of maths and physics with the programming; and business based courses, which will have accounting and management, and sometimes a touch of maths, with the programming. Some universities are very flexible and will let you do, say, metaphysics and computing, others stick to traditional patterns. But at least in Australia, computing degrees without non-computing course components are rare.

Why you may, after all this, want to dance to the university tune

I think I was actually a fairly good candidate for undergraduate computer science. I have reasonable mathematical ability, I’m a better writer than the majority of my fellow students (this became relevant during the last year of my degree when I did a research project), and at the time I entered I had some programming ability but very little experience of projects that took more than three hours to complete.

I ended up getting a lot out of my computing degree, and in this section I’ll discuss some of the things you could get out of it.

You will meet other students

I actually think this is the single major reason you should consider undergraduate studies at all. University is an easy way to make friends. You will be exposed to a wide group of people who like you are confined to the campus much of the time. Making friends after university is harder because the range of people you meet daily falls and it’s hard to see a lot of them, especially in cities where you may live two hours drive from your colleagues and friends.

I have a typical geeky high school sob story, although it’s on the mild side because it didn’t involve being assaulted or attempting suicide, it just involved loneliness. I arrived at university more or less convinced that I was terminally unattractive to my peers.

After considerable time (I spent five years at university) I left with quite a large group of friends and acquaintances, an immeasurably improved set of social skills, and a much better self-image.

In computing, in particular, your peers will have a lot to teach you, assuming you find a good group of people. Computing students tend towards the obsessive and will spend a lot of time teaching themselves and each other all about their findings. It’s probably more the rule than the exception that you will learn more programming skills from your peers than from your teachers. (This doesn’t seem to be true in other science disciplines, and is only true in the humanities when your peers are exceptional.)

‘Networking’ deliberately is a bit yucky, but the natural process of meeting people with common interests and hanging out with them will introduce you to people who have a lot to teach you. If you end up getting a job through these people eventually, you’re in good company.

The course discipline can be useful

Computing courses will tend to set relatively fixed assignments that force you to practise programming skills, although some teachers are far better at this than others. At the university I went to, these assignments were also very open-ended, in that you spent about three days getting 80% of the marks and then for every mark after that the time you spent would increase. While this was both good and bad (some students deliberately chose part time studies in order to improve their marks at the cost of an extra year’s study) it did force me to practice.

If you don’t, early on, get sucked into an intense group of hardworking programmers (and talented programmers can be among the world’s best procrastinators) the discipline of the coursework will improve your programming skills. In my case, and I only really did hobbyist programming in the final two years, the early improvement was huge.

You have the chance to study other things

A lot of people hate the elective requirements of some degrees, particularly if essay writing and mathematics don’t come easily to them (you’ll likely need one or the other), but undergraduate studies are one of the very few opportunities you’ll have to learn about a lot of subjects from experts in the field, some of whom will be marvellous teachers. In some cases — mathematics and science particularly — it’s very hard to learn about the field later without course discipline to push you along, in other cases it might just expose you to something you can follow up at leisure.

I gained two major interests from non-computing study at university: language and modern history. One is likely to be part of my career path, the other is filling my bookshelves. I wouldn’t be without them.

You’ll get the piece of paper

In most ways it’s an arbitrary measure of ability to finish a regimented program, but for some career paths you need it, and it might well make you happy to have it. I quite like having mine, I even gamed the system for a fifth major. In hindsight I wouldn’t do a five-year pre-honours program again (and I wouldn’t do high level maths after second year because I wasn’t committed enough to it) but I’m pretty happy about it overall.

Creative Commons License
A degree in computing? by Mary Gardiner is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Broken windows

There’s been some fun and games in LinuxChix lately with a particularly violent sounding poster calling himself MikeeUSA posting variations on the phrase “Death to women’s rights” interspersed with some obscenity laden mails.

He’s been posting to Debian Women for a while longer and a bit more extensively. From what I gather from them and from Google his purported beef with women’s rights is that either:

  • increasing rights for women reduces the pool of submissive women suitable to be his mate; or
  • horrible controlling women not suitable to be his mate are invading every aspect of his life including his Free Software hobby and are actively attempting to steal all the credit for them, eg by claiming that women built Debian or something.

Some random places to look include the bug he filed against Daniel Stone for being a “a woman disrespectful of men” (Daniel claims to be neither a woman nor the Debian xorg maintainer, but has not yet to my knowledge stated in public that he respects men, so I consider this case open) and the by now rather well linked post to debian-women. With some small ingenuity with Google you can find him getting banned from games forums and Wikipedia for similar activities. It all gets a bit nastier later on with him posting fantasies about the violent deaths of the women reading, and harassing people’s teenage daughters off-list and stuff. Suffice to say that I disagree with his purported premises really quite a lot (if nothing else, he doesn’t strike me as being that attractive pre-feminism either: just because women earned less doesn’t mean that they didn’t know stark raving madness when they saw it) and with his methods so strongly that I can’t think of a good way to express it.

What I have been considering is the correct response to this.

Conventional wisdom about trolls says “don’t feed them.” Ignore them and deny them the precious coin of attention, and take especial care to avoid actually engaging with their arguments even as an antagonist. This has some merits, although it’s actually quite difficult to accomplish: the work of 499 people in ignoring the troll is more or less undone by the one person who responds. It’s pretty rare that I’ve seen all 500 people respond with silence.

The initial Debian Women post got a response that I (and Anarchogeek) considered quite bizarre: someone attempted to engage with whatever sanity lurks beneath the madness and honoured MikeeUSA’s need for recognition as a software developer. The only reasoning for this I’ve seen was in the Anarchogeek thread, in which commenter Jeevan argued that it was an appropriate decision because “Don’t you think the reason one person on the mailing list thanked him for the software is because it’s a Debian mailing list and not a human rights (or something equivalent) mailing list.” I appreciate that some members of the Debian community have different social norms to me, but I don’t quite understand how the mere mention of doing FOSS development entitles you to a free ride on such matters as making death threats against a group of Debian community members. However, Jeevan seems to think so, and therefore the option of “giving them the respect that they so manifestly deny you” is placed before me. Let’s move on from that one without further comment.

I may be missing a thread, but as the mails from this nut job continued I believe the next response from Debian Women was a month later, and here it is. It’s much closer to what I did on LinuxChix.

My decision on LinuxChix was to do the following: wherever this guy appeared, I would respond with a post directed at the list saying that this blatant violation of the “be polite, be helpful” list rules was being responded to by banning. After a few more episodes I posted a warning to people about avoiding direct interaction with him where possible. (Given the reported incident of harassing someone’s family together with the hysterically violent emails, I think it’s possible that he may pose a danger to people, if only by upsetting their family. I’m shocked not to have gotten a direct contact from him yet.)

My reasoning for doing so was as follows:

  1. it’s not acceptable behaviour on our lists, and we generally call people on considerably less outrageous nonsense than this;
  2. LinuxChix is a community which is always partly composed of people new to online forums and new to the related forms of bad behaviour; and
  3. some of these newcomers, in addition to possibly finding the nastiness frightening, would interpret silence as implying that that behaviour was either unremarkable or acceptable (as might readers of the archives).

Hence I wanted to show clearly that that behaviour was not acceptable.

I later thought of a further point, which is the Broken Windows theory.

In its standard formulation, this theory goes that minor signs of urban decay such as broken windows that are not quickly repaired lead very quickly to other decay and then to a failing of any kind of civic feeling.

My particular variant of this for this case is that by not clearly having someone with some notional authority about to state clearly that violent harassment is unacceptable has two negative consequences:

  1. it encourages a feeling that violent harassment may in fact be acceptable; and
  2. it encourages a feeling that whatever we might say is unacceptable doesn’t matter, because we’re not around to stomp on unacceptable crap when it happens.

In other words, nastiness that’s not publicly identified by someone with authority (in this case, I chose to use the authority conferred by my list admin status) who asserts community norms, is like a broken window in a community.

In many ways I imagine this matters more on LinuxChix, where blatant trolls are now rare, than on Debian Women which is still waging the odd flamefest with some Debian developers who have only slightly more moderate opinions than MikeeUSA’s, and which probably has a different position on trolls. (LinuxChix is not as ban happy as this post might imply, but people who the list admins consider purely disruptive will be booted: this happens once a year or so). I think following the standard prescription on trolls, while useful when individually targeted or when you realise that you’ve got into a discussion with one, is a potential broken windows disaster from a community’s point of view. The troll doesn’t care, but the rest of the community is likely to be pleased and reassured to see agreed standards fairly enforced.

Planet Free Software

Article originally posted at the IT Kitchen, a now defunct project founded by Shelley Powers.

Free Software developers, who had strong mailing list and IRC based online communities before the advent of weblogging, have nevertheless found their way into it. This post is a summary of how the Free Software world is using blogs for collaboration; largely preferring aggregation of community members’ blogs over setting up single access group blogs, and using them as a community building tool rather than a software development collaboration tool.

One of the big developments was Advogato, which started in late 1999. The creator of Advogato, Raph Levien, appears to have been trying to start up a kind of a semi-formal guild system for Free Software developers, allowing them to rank each other as Master, Journeyer or Apprentice. As a small feature, he added the ability for users to make “diary entries”, the most recent of which were listed at the side of the front page.

While the other features of advogato proved only an intermittant success — the quality of the articles on the front page is widely lamented, and the certification system has been subject to a lot of debate and has not resulted in the development of formal mentoring — the diary feature was a smash hit. Waves of Free Software developers hit advogato in 2000 and 2001 as they started reading their co-developers’ diaries. The buzz even generated a Salon article in mid 2000.

The initial buzz surrounding Advogato occasionally caused users to publicly renounce their former bad opinions of “online journals”: rather than being ‘useless’ things full of stories about children and cats, they were a new space to talk about your code and find out more about your fellow developers. Advogato was known as a friendly place, in contrast sometimes with the development mailing lists themselves.

Eventually the worlds of Advogato and of blogs began to meet. In mid-2002 Levien was discovering the wider blogosphere and started exploring using his Advogato diary as a primary means of communication with other interesting people. By that time RSS feeds of individual entries and of the entire recent diary entries page were probably the single most requested feature: people no longer wanted to drop in on the site to skim through the new entries, they wanted to poll them like they were beginning to do with other websites. (RSS feeds of individuals’ diaries were added in April 2003.)

At around about this time also, some people started to express serious dissatisfaction with the Advogato community as political debates became more common and the community attracted a few diary trolls. Levien added a diary rating feature as requests to be able to keep some users off the recent entries page grew. Others used the Advogato article feature to deplore the decline in the community.

As various blogging tools became more popular around this time, it became increasingly common to see diary entries from an Advogato regular announcing that their diary was moving elsewhere.

As RSS feeds became fairly ubiquitous, the Free Software community started to revert to a more typical blogging community model: you read blogs of people whose names you knew, and you found other people you knew or knew of through sidebars and comments.

However, in mid-2003 Jeff Waugh of the GNOME desktop project decided to create his own version of the Advogato front page, a HTML page with recent blog entries from GNOME developers all over the web (including several on Advogato). He used the Spycroll aggregator software to pull in RSS feeds, and he made them all available on a single webpage, with the cute addition of disembodied "hackergotchi heads" personalising each name.

He was stunned with the popularity of the page he linked from his own sidebar as Planet GNOME and started to field all kinds of questions about it: the three most popular were “why isn’t this at planet.gnome.org?”, “why aren’t I on it?” and (to his surprise) “why isn’t there an RSS feed?”

The Planet idea took off rapidly over the next six months. Scott James Remnant was the next off the mark, creating Planet Debian. Remnant and Waugh forked spycroll soon after that to create the Planet aggregator script. In fairly short order, a lot of large Free Software projects needed to have their own planet: the Planet homepage now lists nearly 40 separate planets.

The planets have evolved a loose set of customs based on the ones in place at Planets GNOME and Debian. They do not require that syndicated blogs talk about Free Software or software development all the time: they encourage getting to know your fellow developers as people as well as techs. (John Fleck, a GNOME documentor who is not only a frequent poster, but is a frequent non-tech blogger, has been a kind of an acid test for this editorial policy: see the John Malkovich post and a later complaint.) The larger planets are starting to have to deal with line-ball calls about who should and should not be on the planet pages: Waugh apparently finds requiring that contributors use a real photo of themself somewhat helpful on Planet GNOME.

The planets have proved to be amazingly good at spreading blogging among Free Software communities. The two planets I host, LinuxChix Live and Planet Twisted are close to being my most popular hosted sites. They also fill an important gap in the usual Free Software communication tools: they don’t need to be as on-topic as mailing list posts, and they are more expressive than IRC. They’ve also had some influence on corporate group blogging: Richard Giles reported that the creation of Planet Sun was part of the explorations that led Sun employees to promote blogging internally, eventually leading to the creation of blogs.sun.com.

See also

Creative Commons License
Planet Free Software by Mary Gardiner is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.