Support the Ada Initiative

That time of year (a tradition has not yet been established) has come around again: the Ada Initiative is fundraising!

The what? The Ada Initiative is the charity that Valerie Aurora and I started in early 2011, supporting women in open technology and culture. Val and I have been working independently and together on supporting women in open source since circa 1999 (starting, in my case, when someone said something derogatory about my computing skills, in a university context*) and we were both at a transition point in our careers last year and decided to try and go pro. Everyone in open source is growing up and getting paid, the activists too!

Since then we’ve done a bunch of things:

  1. run two AdaCamps: cross-project summits for and about women in open tech and culture (to give an idea, at AdaCamp DC we had women who do GNOME programming, women who help run fandom organisations, and women from Wikipedia among many others)
  2. continued to work with conferences and communities to develop and promote the conference anti-harassment policies we developed in late 2010. Most recently a version was adopted by Google and linked from the Google IO 2012 homepage.
  3. developed our allies training workshop: we’re planning to develop a curriculum to train other people to run it
  4. worked with several companies and conferences to respond to sexist incidents or patterns in their community

I also appeared at Wikimania this year, to give a keynote on diversity ideals and strategies.

As for reasons to donate: let me share with you the argument that got me involved. They still motivate my work for the Ada Initiative. (I’ve been paid a salary for over a year now, but I donated my time through to July 2011.)

The basic reason is this: open technology and culture is changing the world. But all world-changing movements have problems with replicating the same old problems inside their communities: that the more boxes you check of Western, white, educated, male etc, the more you will find the community suited to putting you in leadership positions and the more you will benefit from it and change it to benefit you. Some areas of open technology and culture — famously, open source software development, but also, for example, Wikipedia editing — are notorious for low participation by women. For me the argument amounted to “I want to play too” but there are knock-on effects too: see Valerie’s Why We Need More Women In Open Source: The Founder Gap when it comes to employment.

At present this is do or die time: we have project experience and fundraising experience now. Our donation drive has 7 more days to run: if there’s not enough support out there for us to keep doing what we’re doing, we’ll need to re-think the idea that this is activism that it is possible to pay for.

I’d very much appreciate it if people who have benefited from open source, open knowledge, Creative Commons work and so on, especially people who have built a career from it or from having access to the community consider donating: it’s not a level playing field and it damn well should be!

* I don’t think it was the time that my tutor announced “oh hey, here’s our token woman” on the first day of semester, actually, but for the record: don’t do that.

Donation progress bar: donate now
Support the Ada Initiative‘s work for women in open technology and culture!

Creative Commons License
Support the Ada Initiative by Mary Gardiner is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Ada Lovelace Day: Marita Cheng, Robogals founder

Today, October 16, is Ada Lovelace Day: write or record a story about a woman in science, technology, mathematics or engineering (STEM) whose achievements you admire.
This is a slightly updated version of a profile that has appeared on Geek Feminism and Hoyden About Town.
Marita Cheng was named as the Young Australian of the Year winner at the beginning of the year. She’s been involved in volunteering since she was a high school student, and in 2008, early in her undergraduate studies (mechatronic engineering and computer science at the University of Melbourne) she founded Robogals, which is an engineering and computing outreach group, in which women university students run robotics workshops for high school age girls.

Marita, while still in the final year of her undergraduate degree, is also an entrepreneur and has been previously awarded for her work as founder of Robogals, including winning the Anita Borg Change Agent award in 2011. In 2012 she travelled to several countries with the aid of the Nancy Fairfax Churchill Fellowship to study “strategies used to most effectively engage female schoolgirls in science, engineering and technology.”

While I have heard of Robogals, I hadn’t heard of Marita specifically before she became Young Australian of the Year. One of the fascinating things about starting the Ada Initiative is slowly discovering all the other amazing women who work in technology career outreach and related endeavours. But it’s a little embarrassing, judging from her bio, to have not heard Marita Cheng’s name before the beginning of the year!

Further reading:

  • Marita Cheng’s website
  • Life is turbocharged for Robogals founder (a profile this past weekend)
  • Creative Commons License
    Ada Lovelace Day: Marita Cheng, Robogals founder by Mary Gardiner is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

    Ada Lovelace Day: Else Shepherd, leading Australian electrical engineer

    Today, October 16, is Ada Lovelace Day: write or record a story about a woman in science, technology, mathematics or engineering (STEM) whose achievements you admire.

    Else Shepherd is an Australian electrical engineer specialising in communications equipment. She has co-founded multiple Australian engineering companies, including Mosaic Information Technology, a custom modems company, and Microwave & Materials Designs, developing microwave filters for mobile phones. She was appointed as the chairman of Powerlink, the state government-owned corporation maintaining Queensland’s high voltage electricity grid, in 1994, and has been a board member of the National Electricity Market Management Company (now known as the Australian Energy Market Operator).

    Shepherd won Engineers Australia’s Peter Nicol Russell Memorial Medal in 2007, their most prestigious award, recognising an engineer with over 20 years of substantial contributions to professional engineering in Australia. As best I can tell, she is the only woman Peter Nicol Russell medallist. She is also a Member of the Order of Australia since 2003, and was the University of Queensland Alumnus of the Year in 2009. She is also a pianist and choral director.

    Shepherd has talked about her experience as a woman in electrical engineering with University of Queensland publications. She and one other woman graduated in 1965, the university’s first women graduates in electrical engineering. She was unable to attend Institution of Engineers meetings in the 1960s, because they were held at the local Men’s Club. She continues to promote workplace flexibility, having used part-time work during parts of her career to care for her two children.

    Further reading:

    Creative Commons License
    Ada Lovelace Day: Else Shepherd, leading Australian electrical engineer by Mary Gardiner is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

    Harassment report at your conference: what do you do???

    This article was written by me and originally published on the Ada Initiative’s website. It is republished here according to the terms of its Creative Commons licence.

    The Ada Initiative’s anti-harassment work and other anti-harassment initiatives have resulted in many conferences adopting anti-harassment policies.

    The Ada Initiative are not enforcers of individual conferences’ policies: this is the responsibility of conference staff, and conferences do not usually inform us of reports, nor do we expect them to. Harassment within a community is that community’s responsibility. However, in some cases when Ada Initiative staff have attended a conference, we have been asked to advise conference staff on responses. We’ve learned several useful techniques for making sure that the conference follows through quickly on its commitment to anti-harassment. We’ve drawn our experiences together into a wiki page: Responding to harassment reports.

    Our first tip is, of course, to have a policy. Harassment incidents at geek conferences — including open technology and culture conferences — are widespread. If harassment is reported at your conference and you do not have a policy, it is difficult to reach consensus among conference staff that harassment is not welcome, let alone that you should respond to it, or about how you should respond. The result is that people who are worried about harassment, or who have experienced it at your event or other events, will not feel or be safe at your event. Your policy should be in place before your conference. The Ada Initiative and Geek Feminism volunteers have prepared substantial resources on how to put a policy in place.

    You should also pre-prepare some emergency contacts, for incidents that you can’t handle. Conference volunteers and staff are rarely able to solely respond to and properly help with physical safety threats, illness or people in crisis. We suggest preparing a handout with contacts for emergency services, venue security, local medical and mental health facilities and crisis hotlines for mental illness, sexual assault, and physical violence. Make this info available in your conference materials so that attendees do not have to come to you, but have copies to hand in case they do.

    Having a staff member whose key responsibility is to assist attendees in difficulty (rather than routine conference chores) can assist in a fast response, see the Duty officer wiki page.

    Unfortunately, having a policy does not mean harassment won’t occur at your event. Once an incident is reported, you need to respond rapidly to reports. As the wiki page discusses in more detail you should:

    1. get a written report where possible, or have the staff member who received it write down what they were told
    2. have a staff member collate these reports in case of multiple incidents of harassment by one person, so that you can respond to the pattern rather than one instance
    3. have a staff member discuss the incident with the alleged harasser
    4. convene a meeting as soon as reasonably practical to decide on a response
    5. decide on a response and communicate it to the complainant and the harasser as soon as possible
    6. provide the harasser with an avenue of appeal if one is available but insist that they abide by any sanctions in the meantime
    7. communicate the incident and response briefly to the community, either attending the conference or reading your blog etc, to allow them to see that the policy is enforced
    8. remind the attendees and community where the policy is found and invite them to review it

    We welcome additional improvements to our detailed guide on how to respond to harassment reports. If you would like to discuss the suggestions, please do so on the wiki’s talk page.

    Creative Commons License
    Harassment report at your conference: what do you do???
    by the Ada Initiative is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
    Based on a work at https://adainitiative.org/2012/10/04/harassment-report-at-your-conference-what-do-you-do/.

    Viewing attachments when using mutt remotely

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

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

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

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

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

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

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

    In order to use it, you need to:

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

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

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

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

    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.

    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.

    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.

    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.

    1. Where is your conference?

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

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

    4. Would a user of Free Software benefit from your conference?

    5. Would a developer of Free Software benefit from your conference?

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

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

    2. Any visa tricks or traps in your part of the world?

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

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

    5. What kind of social events are you holding during the conference?

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

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

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

    2. How much will your conference cost for attendees?

    3. Can I get any kind of discount for being a student, unemployed, young, old etc?

    4. Can I volunteer to help out in return for cheap or free admission?

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

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

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

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

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

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

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

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

    Further reading

    This article formed one part the basis of the OSDC FAQ, which has other questions that conference websites might want to answer.

    Credits

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

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