HaskellSymposium/ExperienceReports

Experience Reports for the Haskell Symposium

Experience reports for the Haskell Symposium may seem easy to write, but acceptance rates are typically lower than for full conference papers. This is a pity because often the underlying experience is interesting in itself, and the community misses out on hearing it.

Part of the reason for the low acceptance rate is that there is a cultural mismatch between the people that tend to write the reports and the people that review them. The people that write the reports are often industry practitioners who have vast domain knowledge, but not much practice writing for an academic audience. In contrast, the people that review the reports invariably come from an academic research background and have particular expectations about how a report should be structured.

Getting Feedback

The best thing you can do to improve your chances is to GET FEEDBACK from someone who has experience reviewing papers. Ideally, you should identify one of the people that wrote a library that you are using, or implemented a language feature, and if they have experience reviewing papers then ask them. Anyone who has worked at a university or research organisation will have this experience. Send them a copy of your report and ask for advice. I guarantee that they will be happy to hear about how you've used their work, and give advice on tweaking your report. If you can't identify such a person then ask someone that was on the Haskell Symposium programming committee in a previous year. The list of committee members in on the website.

You need to ask for feedback *early* -- meaning at least 3-4 weeks before the report deadline. Chances are the people that can offer the best advice will be busy writing their own papers, and you need to give them enough slack to schedule time to look at yours. After you receive feedback you'll also need time to make any changes and then possibly go around the cycle again. If you haven't written a paper before then expect at least two cycles.

Managing Reviewers

To be brutal about it, the amount of time a random academic will spend helping you with your report depends on whether they think you can be saved. If you send them something that's only 50% done then they'll only take a brief glance at it. However, if you send them something that is in their own research area, is 100% done from your perspective, properly formatted, nice diagrams, written as well as you know how -- then if they think 2-3 hours of their own time will get it across then line then they will help you.

If you ask someone for feedback and they say it's not properly formatted, or that you need to learn how to use LaTEX, then this means they've only skimmed it and they don't think it's their job to teach you this.

It takes between 2 days and one week to find an hour to read a report and write feedback. If a reviewer takes longer than this then it means they're not interested enough to find proper time to read it.

What makes a good experience report

Surprises.

An experience report does not need to make a novel technical contribution, but it does need to be novel in terms of the experience presented. It is not enough to write about how you used Haskell for a standard problem in a standard way, and achieved the result you were after. The community wants to hear about people that use Haskell in new and interesting ways, or for applications it wasn't previously applied to, or thought too hard.