The projects around the OCaml.org domain name are becoming more established and it’s time to think about how they’re organised. 2014 saw a lot of activity, which built on the successes from 2013. Some of the main things that stand out to me are:
There is other work besides those I’ve mentioned and I think by any measure, all the projects have been quite successful. As the community continues to develop, it’s important to clarify how things currently work to improve the level of transparency and make it easier for newcomers to get involved.
For the last couple of months, I’ve been looking over how larger projects manage themselves and the governance documents that are available. My aim has been to put such a document together for the OCaml.org domain without introducing burdensome processes. There are number of things that stood out to me during this process, which have guided the approach I’m taking.
My considerations for an OCaml.org governance document:
A governance document is not necessary for success but it’s valuable to demonstrate a commitment to a stable decision-making process. There are many projects that progress perfectly well without any documented processes and indeed the work around OCaml.org so far is a good example of this (as well as OCaml itself). However, for projects to achieve a scale greater than the initial teams, it’s a significant benefit to encode in writing how things work (NB: please note that I didn’t define the type of decision-making process - merely that it’s a stable one).
It must clarify its scope so that there is no confusion about what the document covers. In the case of OCaml.org, it needs to be clear that the governance covers the domain itself, rather than referring to the website.
It should document the reality, rather than represent an aspirational goal or what people believe a governance structure should look like. It’s very tempting to think of an idealised structure without recognising that behaviours and norms have already been established. Sometimes this will be vague and poorly defined but that might simply indicate areas that the community hasn’t encountered yet (e.g it’s uncommon for any new project to seriously think about dispute resolution processes until they have to). In this sense, the initial version of a governance document should simply be a written description of how things currently stand, rather than a means to adjust that behaviour.
It should be simple and self-contained, so that anyone can understand the intent quickly without recourse to other documents. It may be tempting to consider every edge-case or try to resolve every likely ambiguity but this just leads to large, legal documents. This approach may well be necessary once projects have reached a certain scale but to implement it sooner would be a case of premature optimisation — not to mention that very few people would read and remember such a document.
It’s a living document. If the community decides that it would prefer a new arrangement, then the document conveniently provides a stable starting point from which to iterate. Indeed, it should adapt along with the project that it governs.
With the above points in mind, I’ve been putting together a draft governance framework to cover how the OCaml.org domain name is managed. It’s been a quiet work-in-progress for some time and I’ll be getting in touch with maintainers of specific projects soon. Once I’ve had a round of reviews, I’ll be sharing it more widely and posting it here!