Representation: a new programming language (or an extension of an old one) that represents protocols more expressively, with greater clarity, or more concisely. Such work may propose novel language features that are either aimed at domain-specific issues or that overcome barriers. Contemporary examples: Orleans, Dryad/Linq, Overlog.
Reasoning: the research facilitates reasoning about protocols using formal methods, for example to assist in the creation of correctness proofs, or to permit a security analysis. Examples: TLA+, IO automata.
Automation: the work aims at the automation of hard tasks, for example, by allowing the user to specify a protocol in a high-level form against a simplified abstract machine, and then transforming it into an executable capable of running in a far more complex, realistic environment. Examples: Macedon (model checking), BAST (type checking).
Other: programming language-related work in distributed systems that does not fit well into above categories
Our hope is to organize the workshop into sessions that would be structured around the categories best matched to the submissions received. Each session would start with several presentations, and then be followed by discussion of cross-cutting themes, similarities and differences, tradeoffs, etc.
Of course, this will work only if we get the categories right, and if we correctly categorize the work you would want to talk about. It would thus be very helpful for your submission to position your work appropriately.
In fact we would like to go a step or two further, with your help. If your project fits squarely into one of these categories, could you possibly take the next step and list a few example applications (meaningful to a general audience) that illustrate the power of your approach? For example, suppose that you have a new language construct that falls into the Representation category. Rather than just telling us so, it would be very helpful if you could also explain that your construct makes it easy to express and prove properties for, say, atomic commit, consensus, and leader election. In particular, we would like to use the two-phase commit protocol as a common "challenge problem", and we also plan to use for discussion at the workshop the most common additional problems addressed in the selected position papers.
In short: tell us where your work fits, but also try to connect it to something you would use as an example in a paper or presentation aimed at a general audience.
We’re hoping to end up with a few submissions in each category, and with luck, that these might even overlap on some example application (although perhaps not the ones we listed above: pick examples that match what you do). Notice that we are not asking you to work out these applications in the position paper: just make unsubstantiated claims! We’re hoping to stumble on some overlap, which could then be developed as cross-cutting themes in the corresponding presentations.
When writing your position paper, keep in mind that we’ll have a very varied audience. Every participant will be an expert in some aspect of the overall area, but it would be best to assume that very few people are experts in your specific area. So please try to make your paper an enlightening experience for the non-expert!
Please also make it clear, in your position paper, whether or not you wish to present your ideas at the workshop. It may not be possible for everyone to present, but we will do our best to honor your request. If you do present, the above exhortation about accessibility will apply to your presentation too: plan to give a talk that will make sense even for someone lacking expertise in your area.