Tag: creative commons licence

Posted on

Remembering Malcolm Tredinnick

I flew home from the US yesterday and when I arrived in Sydney I got a message from my husband saying that Malcolm Tredinnick had died. According to this piece by Simon Dulhunty, he was found on Monday to died at home in Sydney, possibly after a seizure, while I was at PyCon 2013.

Malcolm Tredinnick speaking to an audience
Malcolm Tredinnick speaking at DjangoCon 2008 (by Sebastian Hilling CC BY-NC)

I’ve known Malcolm slightly since my first linux.conf.au in Sydney 2001. In late 2004 I interviewed for a job at CommSecure (since closed) where he was then working, having been a lead developer of and continuing to maintain and develop a real-time data delivery system for the Hong Kong stock exchange. (The eventual end of that contract was the reason CommSecure later closed.) He was also my boss for about half of 2005 until I left to begin my PhD in early 2006.

I still caught up with him at technical events, the last long conversation I remember with him was at PyCon AU 2011 where my husband Andrew and I had a very Malcolm conversation with Malcolm, which roved over the paperwork hassles of having no fixed address (Malcolm travelled a lot and went through periods where he housesat or lived in serviced apartments for a while), the Australasian chess community, and some gentle mutual trolling between him and Andrew over narrative testing.

What I will remember most about Malcolm is that he was a teacher at heart. I never personally had this relationship with him, but I knew several people at CommSecure and elsewhere who Malcolm had tutored or mentored in programming, often over a very long period of time. Elsewhere I know he had taught mathematics (long before I knew him, he very nearly completed a PhD in mathematics when his area suddenly became fashionable and about 50 years of work was done in 6 months by incoming mathematicians) and chess. I will also remember his dry and sadonic approach to nearly everything (for a very recent example, Malcolm gives useful parenting advice), combined with “really, how hard could it be?” used both straightforwardly and distinctly otherwise. Goodbye Malcolm.

Update, funeral plans: Ray Loyzaga who was Malcolm’s close friend, and long-time founder-CEO of CommSecure, has announced that Malcolm’s funeral will be at 2:30pm Thursday April 4, at Camellia Chapel, Macquarie Park Cemetary, North Ryde, Sydney.

Other memorials:

Malcolm online:

Creative Commons License
Remembering Malcolm Tredinnick by Mary Gardiner is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

Posted on

Why my phone is silent during LCA talks

I don’t especially like Tasker’s interface, but setitng one’s phone to silent is nice enough to bust it out, so I thought I’d explain how I do this during linux.conf.au.

A bit of background: Tasker is an Android application (not free in either sense of the word) that does things to your phone when certain conditions (called contexts) are true. For example it could change the wallpaper (task) when you have unread text messages (context). I have, for example, Tasker tasks that turn my phone to silent between 10:30pm and 7:30am local time; and to run rsync backup (which copies the contents of my phone to my home server, ie backs it up) every time it is both on power and connected to my home wireless network.

Tasker somewhat trades between UI simplicity and power in favour of power (although even then I think there are better possible UIs for it). You can generally find specific apps that do individual Tasker-like things (for example, I would not be surprised if there was a ‘Silent at Night’ app), but Tasker lets you specify a wide variety of contexts and tasks.

First: the LCA calendar iCal is in my Google calendar, so it’s available to Tasker through its Calendar contexts. So that’s prior to setting this up.

The basic setup would be this:

  1. Go into Tasker.
  2. Add a Context (called eg ‘LCA activities’), select ‘State’, ‘App’, ‘Calendar Entry’.
  3. In Calendar Entry, go down to Calendar, press the search icon, select your LCA calendar.
  4. Press the tick.
  5. Now it will prompt you for the task, which is silencing your phone. Select ‘New Task’. Name the task (‘Silence’): it might be useful for other contexts!
  6. Press + to add an action. Select ‘Audio Settings’ and then ‘Silent Mode’. Turn ‘Mode’ to ‘On’. Leave ‘If’ alone. Press tick to approve the action and then tick to approve the task.

After this teeny (ahem) amount of work you now have a Tasker task that silences your phone during any event on the LCA calendar.

Fine print

My setup is a bit more complicated than this because I thought ‘wait, I want my phone to ring during meals’. This is a pain in the neck to do.

I added a second Context (long hold on the existing context), another Calendar Entry, also on the LCA calendar, but I also searched for location, selected ‘MCC Foyer’ (which is where the morning and afternoon teas are) and selected the Not tickbox, to make it a negative context. The total effect is that when there’s an event in the LCA calendar AND when there’s not an event in the LCA calendar that is in MCC Foyer, the task triggers. But that’s quite a bit nastier.

It can end up being easier to have a calendar that amounts to a ‘Do Not Disturb’ calendar, which isn’t ideal. Some people do something like “silence during anything in my work[/personal] calendar that’s marked busy”, etc etc, which would be longer lived than my LCA recipe. BUT at least my LCA recipe buys us silence for this conference!

Creative Commons License
Why my phone is silent during LCA talks by Mary Gardiner is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Posted on

How to do more writing, by someone who has never made any such resolution

Jonathan Lange asked on Google+ for ideas about keeping a “write more” resolution. I took over his comment section, and in the spirit of taking some of my own advice, here’s a synthesis of what I said there. Since not writing as much as I feel I ought is never a problem I’ve had, this advice is in the delightful genre of someone who has never needed the advice simply making some up and giving it to you anyway! Enjoy my half-baked ideas.

Re-use your writing. A lot of people I know spend an enormous amount of time on crafting lengthy, tightly argued emails. These count, and you can make them feel like they count by editing them for a sufficiently general audience and publishing them on your blog. This is one I actually do do: several of my Geek Feminism pieces originated in annoyed private emails I sent to close friends, or in IRC rants.

Accountability and incentives. This is like all of the “how to exercise more” advice: make it public, make it social. Make a public commitment, make a shared commitment with a fellow writer. Have a competition, one-sided or not (“I will write more blog entries than N will this year”?). Deadlines and someone who will be personally disappointed in you can be an excellent motivator (as long as it doesn’t tip you over into an avoidance cycle), and for writing there’s a whole profession which involves, in part, holding people to deadlines and being disappointed if they fail to meet them: so, find an editor.

Unfortunately, in order to get an editor one generally needs to pitch (leaving aside the whole question of finding an agent, especially when it comes to fiction), which means writing, so you will have to be motivated to do some writing before you can partially outsource your motivation to editors and deadlines.

Becoming a freelancer seems like a big effort in order to fulfil a personal goal to “write more”, but part of the attraction is that you can pitch to places that have a ready-made audience, which means that you have outsourced any implicit “write more in places people will read it and find it useful” goal; you don’t need to put an equal or greater amount of work into building an audience for your writing.

Specific goals. This assists with accountability. What does writing more mean? A certain wordcount? A certain number of blog entries? A certain number of pitches sent out? A certain number of pitches converted to published articles? All of these are more artificial but easier to keep accounts of than “write more”.

Spend money. Enrol in a course or similar. This adds deadlines too, typically.

Creative Commons License
How to do more writing, by someone who has never made any such resolution by Mary Gardiner is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Posted on

Mourning the Squeezebox

Logitech has discontinued their Squeezebox line of wireless music players.

Background: the Squeezebox was a device originally by Slim Devices, later acquired by Logitech. The Squeezebox (SB) originally supported playing music which was streamed over your home over a custom protocol, it involved running a server process written in Perl on the machine which contained the music. For several years, there has also been a My Squeezebox service which streams music over the Internet. The server/My Squeezebox can in turn stream podcasts, radio stations and so on.

We bought our first Squeezebox in, I think, 2008, which drives some Yamaha reference monitors I’ve had since 2001 (and then spent 7 years searching for a half decent networked music playing solution in order to use them more than occasionally) and added a Squeezebox Boom, which is about the size of a classic micro hi-fi system and has built-in speakers, a year later. We’ve been using them ever since. Both were already discontinued models in favour of the SB Touch and SB Radio, but were receiving firmware updates and support. All support for the entire ecosystem is now being ended by Logitech, in favour of the Ultimate Ears (UE) brand, which so far contains one wireless music player, the UE Smart Radio.

Possible replacements:

The Logitech UE system. Pros: I believe it’s similar hardware, and the SBs have worked well for us. Cons: the UE line only contains one wireless player right now, the UE Smart Radio, and it does not support use of your own speakers. UE devices do not understand the SB protocol, so unless we junked our SB devices we’d need to run two server processes and would lose things like syncing all our players to play the same thing at the same time. Linux is no longer officially supported for running the server software. In addition, I haven’t got confirmation of this, but it seems it is impossible to use the UE Smart Radio without signing up for an online service, which raises the spectre of not being able to play my music when the ‘net is down, or possibly at some point in the future having the UE suddenly stop working forever, when that service is in turn discontinued.

The Sonos. Pros: I don’t follow the wireless music market closely, but I understand this is the brand that’s associated with quality music engineering. Technically, it can stream music from a SAMBA share as well as from the Internet. Cons: it too has made its deals with the we’re-watching-you devils: It will only play RadioTime’s approved podcasts, obviously there’s a workaround involving downloading to the SAMBA share we would use, but that’s still annoying. We again lose the house-wide syncing if we keep our (not cheap, and still functional) SB devices in the house. The podcast thing suggests that the Sonos may also be vulnerable to “do the players still work if Sonos goes away?” concern, but again, I don’t know.

The Roku Soundbridge. Pros: I believe it understands the SB protocol, which means it would be the best fit for our existing music network. Cons: there only seems to be one model in its lineup too, a speakerless one. I’m not intending to buy separate speakers for every room we want music in. Otherwise this is probably the most seamless replacement for an SB.

Bluetooth speakers. Or I guess a receiver, in the case of my reference monitor. Pros: a bigger market to buy from, way less vendor-dependent (even if documented) custom streaming protocols to deal with. Cons: Bluetooth support, or alleged support, in car stereos has not endeared this solution to me, to me Bluetooth means “does not work-tooth”. I have no idea how to achieve the multiple rooms with the same music effect either. And it then leaves the problem of queueing up the music on the headless server. I spent several years seeing how bad all MPD clients could be, I’m not keen to go back to that. In addition, we have enough trouble getting 802.11 signals to span our house, never mind Bluetooth.

I think at this stage, given that luckily the SBs are not going to stop working unless the hardware fails or the software stops running on later versions of Linux (both are possible, of course), that what we’ll probably do is try and snag a SB Radio or two before they get too hard to get hold of, stick with them and our existing devices until the bitter end, and then hope that Bluetooth or some later protocol and its Linux support are up to what we want to do. Since we aren’t likely to subscribe to streaming services in the very near future, this is viable.

If Logitech eventually puts out firmware support for the UE protocol onto older SB hardware, as Gadget Guy suggests they will (but there’s no sign of it on the Logitech forums), it will be more tempting to move to UE than otherwise, at least if the server is known to work on Linux. Otherwise, an additional strike against Logitech products is that they’ve substantially damaged my faith in their longevity. Quoth Matthew Moskovciak on CNET It may be wise to see how Logitech handles its Squeezebox customers before committing to the new UE ecosystem. There’s probably 12 to 24 months of endgame in that.

Update: Sue Chastain has more info, including an apparent confirmation that the UE Smart Radio will indeed not work in the absence of an Internet connection, even when playing locally stored music.

Update January 2016: we moved to Chromecast Audio. No more hardware ecosystem lock-in for us!

Creative Commons License
Mourning the Squeezebox by Mary Gardiner is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Posted on

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.

    Posted on

    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.

    Posted on

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

    Posted on

    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.

    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.