Category: Politics and society

Posted on

Identifying as a geek

This article originally appeared on Geek Feminism.

I mentioned in my introduction post that I haven’t had to struggle internally to identify as a feminist. But the title of this site leads to another question: is it as easy for me to identify as a geek?

And the answer is no. A lot of this is pretty trivially heretical stuff. I mildly tend to being a morning person; left to my own devices, I do not tend to observe a 28 hour day, it’s sometimes as short as 23.5 hours. I am quite staggeringly indifferent to cats. I loathe being bathed in fluorescent light all day and jokes about the alien environment of the big blue room puzzle me. The thought of a world where human communication is as simple as TCP/IP’s SYN and ACK packets makes my skin crawl (I’m a computational linguistics student specialising in lexical semantics, mustn’t wish myself out of a job). I don’t eschew caffeine, but have never been tempted to consume it more than once a week or so. Given these examples and others, there are a lot of (computer) geek insider-status affirmation jokes and rituals that are as foreign to me as mating rituals at nightclubs are.

Some of this is me, and some of it is culture, and some of it is gender I think. I’ve never felt like I had to pass a test to count as a woman, or as a feminist. I feel like I trip over geekdom all the time. I don’t have pithy anecdotes of key experiences, but I strongly identified with Dorothea Salo’s discussion of “honorary guys” in Sexism and group formation:

A woman can be an honorary guy, sure, with all the perquisites and privileges pertaining to that status””as long as she never lets anything disturb the guy façade.

That is, I feel like I’m admitted to geekdom under sufferance, and womanhood and feminism don’t feel like that. But I know this experience is not universal, for many women reading geekdom is your skin and female gender like a coat that doesn’t fit all the time, and for others neither is problematic or they both are. How did you come to feminism, and geekdom, and womanhood (if you’re a woman)? Does one of them fit better than the others at the moment, and does that feed into your questioning anything?

Posted on

Why we document

This article originally appeared on Geek Feminism.

A comment over on the Geek Feminism wiki asked whether we aren’t damaging the community by documenting sexism. I don’t want to get too 101 on our fine blog, but I do want to talk about why I consider our pretty long list of sexist incidents in geekdom a success.

My first geek feminist forum, and still the one I participated longest in and therefore in many ways most influential on me, was LinuxChix. Things I learned over there included the reasons why having men dominate conversations can be anti-feminist, via the discussion around the document now available as behaviour in technical forums, which was originally a response by Valerie Aurora to a problem where the LinuxChix techtalk list was seeing fewer and fewer posts by women and was generally perceived as scary and hardcore.

We also had a long-standing problem articulating what it was that led to the extreme gender imbalance in Free Software development and many of its user communities. I can’t speak for the community, but what I remember feeling about those discussions was a major unease. There was sexism in computing and in Free Software… probably? Some women had stories, some women didn’t. There was social, peer and societal pressure on young women considering science and technical careers or even on developing those skills… probably? Again, some women had stories, some didn’t.

Had you asked me in 2003 for troublesome incidents in Free Software””are we doing anything wrong, or is this a problem we’ve inherited from other people who did things wrong, or is this just a thing about women, that they don’t like to be too nerdy in their spare time?””I don’t know that I would have been able to give you examples of anyone doing anything much wrong. A few unfortunate comments about cooking and babies at LUGs, perhaps. Things started to change my awareness slowly. Valerie’s 2002 HOWTO Encourage Women in Linux dug up some incidents at LUGs. In 2005 LinuxChix itself got some attention from (trigger warning) the troll Skud posted about. I was personally present at a sexualised presentation, the Acme::Playmate presentation at the Open Source Developers Conference in 2006. And in 2007, very soon after I had seen Kathy Sierra keynote linux.conf.au 2007, she was scared out of her work writing about technology by (trigger warning) online harrassment and for the first time, I personally saw the Internet explode over the issue of active, virulent sexism against women in technology.

I do not in fact find writing the wiki documentation of incidents in geekdom very satisfying. The comment linked at the beginning of the post compared the descriptions to a rope tying geekdom to the past. Sometimes being known as a wiki editor and pursued around IRC with endless links to yet another anonymous commenter or well-known developer advising women to shut up and take it and write some damned code anyway is like a rope tying me to the bottom of the ocean.

But what makes it worth it for me is that when people are scratching their heads over why women would avoid such a revolutionarily free environment like Free Software development, did maybe something bad actually happen, that women have answers. It’s not the only answer, there’s still all that social, peer and societal pressure, the shorter leisure hours, and so on, after all. And there’s no level of harrassment or cruelty that won’t find someone, plenty of someones, prepared to immediately argue that it’s really no big deal, what are you doing here, giving up? Letting them win? But now if when I’m asked about whether geek women have problems and why there aren’t more of us, I’m not left fumbling to explain it even to myself.

I don’t know what the Mary of 1999 (my watershed geek year wasn’t 1998, in fact) would have done if she’d come across that page in more or less the condition the wiki comment described, “the girl entering the community without any predispositions”, the woman vulnerable to being misled into thinking that geekdom is full of scoundrels (or, we might argue, not entirely misled). Maybe she would have run, I can’t say for sure that she wouldn’t have. But what woman is without baggage? In 1999 as a teenage girl with hair flowing down to my waist (I tell you what, short hair has cut my street harrassment down nearly as much as it cut my grooming routine down) I walked down the street to the steady beat of rape threats from passing vehicles. At least I would have found that geek women were talking about it and had got together and got each other’s back.

Posted on

Girly geekdom for girls… only?

This article originally appeared on Geek Feminism.

Several of the front page posters here are participating in discussions on the Python diversity email list, a list created by Python community member Aahz to discuss diversity problems in the Python programming language community. The initial aim of the list is creating a diversity statement like that of the Dreamwidth community.

Some of the more problematic discussions on the list come down to “this stuff is hard, and hard to talk about, and people get angry and defensive when things are hard.” I don’t want to discuss the tenor or direction of the discussions there in general in this post though, I want to talk about a specific incident. A poster to the list made reference to being “beaten up by a girl” (in a metaphorical sense, what had actually happened was off-list criticism from a woman, not physical violence). A 101 discussion followed, and while it was pretty clear to most people posting that the framing played right into the idea that being beaten by women, physically or in argument, is emasculating, it took a surprisingly long time until it was pointed out, originally by me, eventually also by Aahz in a separate thread, that “girls” is a problematic term. It seems this was a new idea even to some of the more pro-feminist posters.

Now despite the Python diversity list’s innocence, calling women “girls” even in conversations where men are just “men” is not a new problem. As I pointed out to someone on identi.ca, Wikipedia has a prominently placed discussion of how there are few neutral terms for women, especially more informal ones. And the geek feminism groups have run into it ourselves. We have LinuxChix and Girl Geek Dinners. One syllable terms make for snappy names and the “girl geek” alliteration has zing. Reclaiming problematic terminology has a long history, but one of the appeals is that it’s just plain fun, and it’s happened to some extent with the term “geek” as well.

But how much are we playing into the idea that geek feminism is for young women, that once first year CS is gender balanced we’re done here? I’ve seen concerning things. LinuxChix’s name has on occasion drawn young women who explicitly say they only want to interact with other young women. LinuxChix and Girl Geek meetups are often just as inconveniently timed and placed for primary carers as LUGs and gaming groups. When Julie Gibson interviewed me for Ada Lovelace day, she talked about how LinuxChix turned out not to be for her, she’s too far removed in time from having enough geek hours in her life to learn Linux. An older woman””in her late forties, perhaps, well outside the Australian LinuxChix demographic””at our LinuxChix miniconf in 2008 said that she’s careful to avoid becoming a “face” for women in IT: she thinks no teenage girl wants to grow up to be her. It reminded me of Lauredhel’s post at Hoyden About Town, Monica Dux thinks I’m bad for feminism’s image, about the trend to say it’s great to be a proud feminist, as long as you aren’t a marketing problem for the feminism brand. Is it only great to be a woman geek if you’re exactly what the guys on Slashdot are asking for, 18 and single and heterosexual and able to fix your own computers, thus making time for everyone’s two favourite leisure activities, gaming and sex? Of course not. But I’m worried that we’re talking about ourselves as though it is.

This is hard for me. I’m in my twenties. It’s a lot easier for me to think about what my fifteen year old girl geek self would have wanted from geek feminism than what the sixty year old woman I hope to be will want. But we should. What does geek feminism look like, for women who aren’t girls any more and don’t want to be?

Posted on

“Girl stuff” in Free Software

This article originally appeared on Geek Feminism.

This is an edited repost of a blog entry of mine from February 2009.

In January 2009 I gave a talk at the LinuxChix miniconf held as part of linux.conf.au 2009. It was titled ‘Starting Your Free Software Adventure’ and used women developers and community leaders as examples. The idea was to show people what the first steps look like. I conducted (extremely short) email interviews of several women involved in Free Software or Culture or their communities, including Kristen Carlson Accardi, Brenda Wallace and Terri Oda among others.

One thing stood out and kept coming up all week: Terri mentioning that she had resisted at times working on things perceived as ‘girl stuff’. In Free Software this includes but is not limited to documentation, usability research, community management and (somewhat unusually for wider society) sometimes management in general. The audience immediately hit on it, and it swirled around me all week.

This is a perennial problem for professional women: software development is by no means unique in having developed a hierarchy that goes from high status roles disproportionately occupied by and associated with men to somewhat lower status roles disproportionately occupied by and associated with women. (In the case of software, disproportionately occupied by women still means male dominated of course, at least in the English-speaking world.) It’s difficult to disentangle the extent to which women and/or their mentors and teachers self-select for the lower status roles (and I would hardly argue that the self-selection occurs in a vacuum either) versus the extent to which they are more or less barred from high status roles versus the extent to which the association is actually flipped and professions and jobs within them have become low status because women started doing them. Other well-known examples, are, for example, the concentration of women in biological sciences as opposed to, say, physics, the different specialisation choices of male and female medical doctors and surgeons, and so on. Sometimes, as in the war between sciences, the status of a field is somewhere between a joke and real, to the extent that those can be differentiated, but often it isn’t: there’s a correlation between the male to female ratio of a medical specialty and its pay.

In all of these cases, a woman who is conscious of this problem tends to face a choice. Do the ‘girl stuff’, or not? (Of course, ideally one rejects the dichotomy, but no individual woman is responsible for constructing it.) And some, although I don’t know what proportion, of women feel guilty about their choice, especially if they do choose to do girl stuff. Just go ahead and imagine your own scare quotes from now on, by the way.

It also gets messy in various other ways. There’s the extent to which a woman who doesn’t do girl stuff is invested in maintaining the status of her boy stuff role and also the aforementioned vicious cycle where if women are doing something, it will come to be seen as not particularly hard or noteworthy.

Most concretely, I usually see this tension bubble away underneath outreach programmes promoting computing careers (you know what, I have my own status issues and I still resist calling it IT) to women. There’s the people who want to go for yeah we all know coding is populated by weirdos, and male weirdos at that, luckily you don’t have to be a geek and you don’t have to code, phew! I tend to hear about that one only once my outreach friends have gotten involved and staged a coup, admittedly. There’s the there’s so many opportunities in computing, and yes, coding is one of them and its fulfilling and it’s something you can do, but dammit, coders get all the cred and attention and dammit can we talk about something else? Women who admin/write/test/manage rock! And there’s you know, women coders don’t exactly rule the world yet, and furthermore isn’t all this oh-yes-you-could-code-I-guess-and-that’s-a-fine-thing but look! something for folks with people skills! talk basically a soft version of ew coding that’s for boys, also, last I checked, math is hard?

I observe again that there’s no right answer here in the real world right now. Women doing girl stuff have good reasons to feel dissatisfied that their hard-won skills are underpaid and under-respected, women doing boy stuff (scare quotes! please insert!) want other women to know that there’s fun to be had over here, thank you.

One crucial point in my thoughts about this I stumbled on only after the conversation Brianna Laugher recounts, over Indian food on the Friday night (the location of all major conference breakthroughs worldwide). She said”Š”””Šparaphrased”Š”””Šthat she didn’t feel that she should have a problem or be criticised for doing what she is good at, or what’s so desperately needed in her communities, and have to be just another coder in order to be fully respected. And I said that while this was certainly true, women also need to have the opportunity, to give themselves the opportunity, to be selfish: if we want to code, or do something else we are currently either bad at or not notably good at, or for that matter which we are good at but in which we’d have competitors, we should consider doing that, rather than automatically looking for and filling the space that is most obviously empty. However women are justifiably reluctant to enter places where they aren’t obviously welcomed, and what better way to be welcomed than to do work that needs doing and not become just another person doing the coding free-for-all and delaying external validation for potentially quite a long time?

I have no answers. Just the perennial question of distinguishing what other people want, what other people claim they want, the genuine satisfaction of being of service to someone, and the genuine satisfaction of knowing you’ve done a good job of something hard. Where do you like to stand on that?

Posted on

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.

Posted on

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.

Posted on

Links to Women in Free Software groups

I gave a 5 minute lightning talk at OSDC entitled Women in FOSS groups (meaning groups for women involved in Free Software, rather than about women in Free Software groups, I could have done a better title I know). It was mostly an attempt to jam Adam Kennedy’s lightning talk about Acme::Playmate, which featured lingerie shots of women (and maybe topless shots, I didn’t want to watch it, being quite firmly and viscerally of the belief that there’s a very small amount of sexual desire I like at my open source conferences). So mine featured pictures of women, fully clothed, with labels like Linux user and AI researcher.

For more on Kennedy’s talk, see Richard Jones’ entry about it: Jones was the chair of the session that Kennedy gave his talk in.

I’m not putting my slides up for a few reasons: bits of them only make sense in the context of that particular jam; other bits only make sense if you hear me say the words that went along with them; and finally while I got permission to use them in the talk, I didn’t get permission from all the women whose pictures I used to stick said pictures on the ‘net.

However, the last couple of slides were a list of links to groups for women using and developing Free Software, and Paul asked if I could provide them in a place where people would have a chance to write them down. Fortunately, these were even prepared earlier:

  1. LinuxChix’s list of groups for women in computing generally; and
  2. LinuxChix’s list of groups for women developing Free Software (and Free Culture, in the case of WikiChix).
Posted on

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.

Posted on

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.

Posted on

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.