Greetings! I created this site in response to to a thread on the Caml-list requesting that the beginners group be moved on from Yahoo.
As such, there are a few sub-communities in OCaml that have expressed interest in using a modern, asynchronous, discussion mechanism. So now that this is setup, we need to figure out what categories to setup, and who will administrate them. Please free to comment on this, and I will edit this post as the discussion evolves.
We should use just a few categories to start with, and split up busy topics at a later date. Having said that, some structure is useful, and these initial categories are being set up. Bear in mind that we can rearrange all of this while the site is in beta.
Libraries: does it make sense to let library authors create sub-categories for people to discuss the use of their code? For example, I would quite like one for the Cohttp ecosystem, and a JavaScript one (include jsoo and Bucklescript) would be useful.
OPAM: as opam2 is round the corner, this could be a good place to post higher level updates on the OPAM repository and bigger package updates.
Multicore: @kayceesrk would like an area to discuss multicore OCaml developments.
Not being done at the moment
Infrastructure: to replace the existing (and underused) infrastructure list. This one is too vague at the moment so we will come back to it when the rest of the forum settles.
âbuildâ â all about build system
"compiler" â OCaml compiler development
"ReasonML" â for ReasonML community
"web" â all about using OCaml in web programming
It turns out that categories can also be nested, so designing some top-level ones with sub-categories might be the way to go.
For each of the categories, it would be good to have a primary contact to help move their respective communities over to this forum, and to generally keep an eye on the discussion. @objmagic: any suggestions for contacts for yours?
Having a build category seems great, with maybe jbuilder as a sub-category? Jeremie Dimino seems like the natural contact for the jbuilder one, if the sub-categories are deemed worthwhile.
And of course any other build system maintainers who would like a discussion forum for theirs.
I wonder where Windows support goes in all this. Rather than a Windows category, it might be better to discuss Windows support for build in the categories above.
Hm, I would love a Mirage category; I wonder if this would make sense as a sub-category of âlibrariesâ? (can we come up with a better name for that other than âlibrariesâ? For example (assuming that Ocsigen is interested):
libraries/mirage
libraries/ocsigen
libraries/core
libraries/reasonml
ReasonML doesnât quite fit under this scheme, and Mirage also has front-end tooling and so isnât a library. Perhaps itâs best to leave these as top-level categories since they are major efforts in and of themselves.
@Yaron_Minsky it should be possible to move your new topic into a fresh category when itâs created, so this just lets us experiment with that functionality.
Whatâs the interplay between categories and tags? I guess categories are hierarchical, and every topic is in at most one category? And tags are, well, tag-like? i.e., simple identifiers, any number attached to any topic? (or is that per message.)
I like the libs idea. I donât think reasonml fits there. Maybe Reason just needs its own toplevel category?
Donât create too many initial categories, as you can overwhelm your audience. You can always add more categories, and easily bulk recategorize topics later. Itâs better to figure out the organization as you go rather than assuming youâll get it all right from the beginning (hint: you wonât).
Rather than design the structure upfront what about having very broad categories and create subcategories on the fly once people get tired because a topic comes too often and it feels noise to them ?
Iâm saying this because we created quite a few focused mailing lists on lists.ocaml.org which are essentially dead.
I definitely agree about not just doing a frenzy of category minting, and I like the idea of peeling things off as you go.
But that doesnât mean we should start with no structure. A good starting point might be existing things that we want to migrate here. The Beginners mailing list is a clear example, as @avsm noted. Also, it seems like migrating the Core mailing list here would make sense.