Tech community – Page 3

October 4, 2008April 10, 2026

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:

is the paper already accepted?
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.

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

November 9, 2006August 31, 2016

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.

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

October 26, 2006April 9, 2026

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.

October 10, 2006August 31, 2016

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.

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.
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.
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.
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.
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.
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.
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.
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.
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.

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

October 27, 2004April 22, 2017

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.

Questions your conference website should answer

This article was originally posted at advogato.org in 2004.

Introduction

This article gives a list of questions that your conference website should answer, if it is to attract speakers and participants who are unfamiliar with the jargon. Most conference websites do a good job of answering some of these questions, but many go unanswered.

This article is inspired by discussion on the LinuxChix mailing lists over the past couple of years about speaking at conferences; specifically, discussion about how to encourage people to make their first ever talk proposal.

One problem with almost all Free Software conference web sites is that they aren’t very helpful to a novice speaker. One participant in the discussion recollected reading that she would need to send in a "paper" if her talk was accepted and asked what would be required of the paper. Was it an article? How long did it have to be? How did it have to relate to her talk? The only response from the organisers pointed her to mbp‘s (excellent) article on getting a conference abstract accepted, which, alas, helped her not one bit in finding out what it meant to send a paper if her abstract was accepted.

Many Free Software conference websites assume a lot of background knowledge of the conference process. This assumption is a strange one: many Free Software developers work outside academia, and if they were ever inside it, never got to the stage where conferences become part of academic life. And the Free Software conference procedures are subtly different from academic conferences in ways that aren’t obvious, mostly because Free Software conferences are generally more informal events than academic conferences. People used to the peer review process may not be sending in abstracts because they’re used to a very high workload of writing and revision for each conference.

In other words, your conference might a first conference for a lot of people — some of whom are qualified to speak. You need to write parts of your website assuming that potential speakers and attendees know very little of the conference process. This is doubly important since conferences vary in lots of respects: do they pay for travel? are they for users or developers?

Simple general questions about your conference.

Almost all conferences websites answer these simple questions already.

Where is your conference?
When is your conference?

Give times as well as dates when answering this question, so that people know to book an extra night’s accommodation if your last event finishes at 8pm.
What is the target audience of your conference?

Are you focused on a particular project, are you a general Free Software conference or a tech conference accepting talks related to Free Software?
Would a user of Free Software benefit from your conference?
Would a developer of Free Software benefit from your conference?
Would a Free Software advocate or someone involved in community projects (like LUGs) benefit from your conference?

Questions everyone wants answered

Many conference websites are doing a good job of answering these questions somewhere, but not all are.

How can I get to your conference?

It’s worth listing the airport, train station, and bus station nearest your venue and giving some idea of the carriers that travel to that station. If you’re not in a city with a major international airport or transit hub, it’s also worth suggesting a hub for people to travel to, and then a route to your location.
Any visa tricks or traps in your part of the world?

Will international attendees need a visa? Will it need to be a tourist or business visa? Will they need a letter from the conference organisers to get their visa (this is not unheard of)? Will they need to have anything to present to border officials?

Something conference organisers in the US in particular are apparently still neglecting is this fact: if you are not a citizen of a country whose citizens the US will admit without a visa, it can take months to get a visa to enter the US and it requires considerable time spent gathering documents and visiting consular officials. Accepting speakers closer to the conference will result in your international speakers being unable to come. If your conference is elsewhere in the Americas, it is important to warn attendees that even transiting through a US airport now requires a visa.

Similarly, visitors to Australia are frequently shocked to find out that the Australian government has no visa waiver program, except for citizens of New Zealand. Nor are the US and Australia the only two countries that trip visitors up with their entry regime.

In most cases, being denied entry to a country will require your attendees to immediately return home at their own expense. If your conference website addresses the basics of getting permission to visit your country and points to the relevant authorities, you can avoid a lot of pain for them.

What sort of accommodation is available nearby and what is the approximate cost?

Some conferences are doing excellent work organising conference accommodation. Even if your conference isn’t doing this, you could provide pointers to a few types of accommodation nearby: budget hostels and mid range hotels will be the most useful for your attendees.
What kind of social events are you holding during the conference?
If I bring partners, family members or friends who won’t be attending the conference, is there anything they can do or see while I’m at the conference?

Free Software conferences tend to be slightly bigger events in the lives of their participants than academics ones. Frequently, attendees combine a big conference with a holiday, and might want to bring their family. Kudos to linux.conf.au 2004 for providing activities for partners and family members who didn’t attend the conference.

A few more questions: Is the conference providing any kind of childcare? (I’ve never heard of that happening.) Is there short term childcare in the area? Can family members too old for daycare attend the conference social events?
What’s there to do in your area?

A not insignificant number of attendees will want to combine your conference with a holiday, or at least with some sight-seeing, or a visit to the pub. Give them some information about your area. Link to tourist web sites and nightlife guides.

Something I’ve very rarely seen done which would be extremely useful is a list of restaurants that are likely to be able to serve large groups of people at short notice late in the evening. Everyone who’s been at a few conferences knows the experience of trying to take fifteen people out to dinner in a strange city.

Questions attendees want answered

There’s going to be even more neophytes amongst your potential attendees than there are among your potential speakers. Try and put yourself in the position of your greenest attendee: has an interest, heard your conference would give him or her an opportunity to meet some hackers working on interesting stuff, but has never ever been to a conference. Aim your attendees section at them: a little extra info won’t hurt anyone else.

What kind of talks can I expect to see? What will their topics be? How long will they be?

It’s a good idea to get your program up as early as possible. If nothing else, attendees have the same or even more difficulties organising transport, accommodation and visas as speakers do, so you should make it possible for them to decide whether or not to attend as early as you can.
How much will your conference cost for attendees?
Can I get any kind of discount for being a student, unemployed, young, old etc?
Can I volunteer to help out in return for cheap or free admission?
Are there any sources of funding for attendees?

Questions potential speakers want answered

Now to the problem of neophyte speakers. For this section, imagine someone who has some experience speaking to groups, but nothing of abstracts, or proceedings or anything like that. There’s no reason this person can’t speak at your conference, so don’t make it hard for them to submit a talk proposal. In particular, don’t make your talk proposals or the talk process sound any more mysterious or difficult than they actually are.

What do all these words mean?

Explaining what is expected from an ‘abstract’, a ‘paper’, a ‘presentation’, a ‘tutorial’, a ‘workshop’ and a ‘BOF’ are is crucial if you use those terms. Not only do some people not know them, but they vary reasonably widely by conference anyway.

Providing links to abstracts and papers from previous years is invaluable if any are available. You might wish to draft a sample abstract or paper if you cannot link to previous papers. If not, you should certainly describe requirements in detail. Place the links prominently with the call for papers.
What kind of talks or presentations can I give? How can I tell which one I should give?

The answer to this question should provide detail. For each type of talk, specify the length, the size of the audience, and the expected depth of the content if you can. Is it going to be a lecture, or interactive discussion, or something in between? Will most speakers be using slides, giving demonstrations, or running a Q&A session? Are speakers going to be showing the code? What kind of knowledge level can the presenter expect from the attendees? Are the attendees going to be peers or are they going to be people new to the topic? Are there any different "tracks" devoted to different topics?
How do I get a talk/paper accepted?

When answering this question, be detailed. Provide approximate word lengths for abstracts (or papers if you require full papers at this stage). Specify what kind of information needs to go in the proposal. And then tell people about the process: when do they submit? how (roughly) is their abstract going to be judged? when will they hear back from you?

Ideally, you would give examples of a few accepted abstracts here, with a short discussion from the selection panel of what made those abstracts appealing to them.
If my talk is accepted, will I still need to pay the admission fee for attendees?

Norms on this vary: conferences where most attendees are also speaking will often not waive the admission fee for anyone. Be very clear about which way you’re going with this.
If my talk is accepted, will you cover travel and/or accommodation expenses? Will you cover international travel?

Be very clear about the limits of what you can cover. It’s very disappointing to have a talk accepted and then find out that the organisers can only pay for local attendees, but not for international flights.
If my talk is accepted, will I receive any payment above expenses?

I’ve never heard of a Free Software conference doing this, but as there are other conferences which may do so, and some of your speakers might come from that kind of world, best to disappoint them early.
What do I need to do once my talk is accepted?

If you’re asking speakers to provide papers, describe whether you need slides, recordings, or written articles from accepted speakers, together with any administrative extras like due dates for the final paper. Describe any editing processes that will take place.

Your answer to this question should be detailed. It should explain what you require from a full paper (if you require one) including length and format. How should the paper relate to the talk? How formal should the paper be? If it doesn’t matter, say so. If its optional, say so. If all that is required is a talk, say so. All this talk of ‘papers’ is scaring people. To many first time speakers, especially ones with a passing acquaintance with the academy, a "paper" sounds like something bristling with citations and withstanding the full force or peer review. If what you’re actually doing is getting people to send you their slides tell your speakers this.

On the other hand, if you are a fairly formal conference hoping to attract Free Software developers outside the academy, you will probably want to link extensively to style guides and citation guides for your potential speakers to use. You will need to assume that they are not familiar with the peer review process also (and it varies enough within academia anyway), so give a detailed guide to it.

Conclusion

If you’ve tried to answer these questions as you went along, you probably answered "well, it depends… small conferences can’t pay travel… Free Software conferences don’t focus on citation so much…"

This is precisely the reason your conference website and publicity needs to answer simple questions like "what do you mean ‘paper’ anyway?" The answer varies. Some potential speakers will submit anyway, and assume they’ll hear from you if they don’t do something. Judging from the discussion that inspired this article, others will not.

Credits

Thanks to Jenn Vesperman, Telsa Gwynne and Terri Oda for input into this article.

Questions your conference website should answer by Mary Gardiner is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Category: Tech community