HaskellSymposium/ExperienceReports

Haskell Symposium Experience Reports

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 is 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, and written as well as you know how -- then if they think 2-3 hours of their own time will get it across the 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 it means they've only skimmed your report and they don't think it's their job to teach you how to write.

It takes between two 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 reported. 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.

Example Rejecting Comments

Here are some example comments made by PC members when accepting or rejecting experience reports submitted to the Haskell Symposium. To preserve anonymity they have been rewritten to indicate only the general message, and do not contain specifics about individual papers or people.

• "The call for papers explicitly states the report should make a contribution from which other Haskellers can benefit. It is not enough simply to describe a program!. However, this report simply describes a program, giving rather a lot of code, and I'm not even sure what the program does."

• "There are only general observations, and the results presented here are neither new or deep."

• "This is not much more than a description of an implementation."

• "The particular role of Haskell and functional programming is very limited."

• "This report is well written and well motivated, but reads like a tutorial. There really aren't any surprises".

Example Accepting Comments

• "The report is well written and shows how to combine a number of existing libraries and tools. The end result seems useful in its own right, and I think this is a good example of how to implement this sort of system."

• "This report will be of great benefit to the Haskell community as it serves as a good case study in the practical use of this tool. The report demonstrates widely applicable techniques that are not widely known."

Other Advice (besides getting feedback)

Note that these advice pages from other conferences may mention other format and length restrictions than those which apply to the Haskell Symposium.

• ICFP 2009 Experience report advice
• PEPM 2012 Tool paper advice