Not really a start, but possibly a help!

[ShapeOfMatter]

I've put a little time into a glossary, but it's clearly not ready to publish ATM, it's incomplete in the sense that it's full of TODOs, and it's missing any kind of rendering engine, and it needs a broader perspective and curatorial help!
But I'm hoping its progress.

[lkuper]

@ShapeOfMatter Thanks so much -- this is great.

A few comments, which you can take or leave:

• I don't really see the advantage of the JSON approach. What do you see the advantage as being, vs. just Markdown?
• I don't want the dictionary to be intimidatingly long. I think we should try to agree on 10 or 15 terms that belong. If we include lots of more general distributed systems terms, like "Active replication", "Conflict-free replicated data type", and so on, the dictionary will get pretty long. "Bisimulation" is even more general than that! Conversely, niche terms that only appear in one CP paper probably don't need to be here.

Here's my first stab at a list of terms that I think should be covered in a CP glossary: Choreography, choreographic programming, multitier programming, knowledge of choice, endpoint projection, comm, process, deadlock freedom, selection, merging, location polymorphism, higher-order choreography.

Thoughts?

[ShapeOfMatter]

@lkuper

Re: JSON:
The disadvantage of Just Markdown is that it devolves to HTML as your formatting gets more ambitious. More specifically, I think handling citations in Markdown sounds like an error-prone chore.
The only advantage of JSON is that any templating system we decide to use is likely to be able to ingest it. (I haven't translated the citations themselves out of bibtex.) Most other data formats are in some way better. I haven't actually included an alternative to Just Markdown in this PR; when Fabrizio suggested JSON he was contemplating Mustache (here?), which I don't know anything about.
If the alternative is Jekyll... it can do this kind of rendering, but it's no fun; I'd only suggest it if we were committing to a long glossary with citations.
Client-side JS rendering is also an option, but it's rude.
There are a lot of other options...

Re: Length:
I think you're right that a shorter glossary would look better and be more welcoming. Whether it's what we should do is downstream of our goals, which I don't think are really settled. I listed in glossary.md what I thought they were.

[lkuper]

I guess I'm trying to figure out how we can collaborate effectively on the glossary in particular, and I don't think it's going to be by editing JSON.

[fmontesi]

What about using YAML? :-) It should support cross-references for synonyms, etc.

Could we also maybe try to restrict this to a couple of keywords for now while we figure out the 'format'? I propose 'Process Projection' (the projection of the choreography on a specific process) and 'Realisability' (there exists an implementation of the choreography).

[ShapeOfMatter]

It seems like I've started us in the wrong place, possibly in multiple senses. Before we make anything, and before we decide how we want to make it, we should know what we're making and why.

Consider the null alternative: We simply improve and expand the relevant Wikipedia page. I can only think of two reasons that wouldn't serve our purposes better than having our own website:

1. As discussed in the business meeting, we want a place to list possible reviewers, so journal editors know who to contact when they get a submission.
2. Possibly, Wikipedia's norms around cutting-edge research would be too restrictive for this group. As a concrete example that's actually in this PR (and I apologize because I know you don't want to read the JSON), I think the disambiguation of synonyms for "participants" (glossary.json, line 277) is useful, and if we do want that level of detail then we need our own website.

So in that context, can I get feedback on the "wishlist" (README.md) and "goals" (glossary.md)?

[lkuper]

I think the wishlist and goals look good for now.

[lkuper]

How about starting a page on this repo's wiki where we can collaboratively hash out the content of the glossary, independent of decisions about templating systems and so on?

[lkuper]

I've started wiki pages for frequently asked questions and the glossary.