ocamlbuild
ocamlbuild copied to clipboard
ocaml
What is a good communication channel?
There are sometimes discussions that are not focused or task-based enough to be a really good fit for issues or pull requests. Would it make sense to also have an ocamlbuild-specific mailing list, for example?
In principle I think that having a mailing-list would be good (it is more portable data, with archives for easy browsing, etc.), but in practice I observe that projects with both github issues and a mailing-list tend to use issues more to communicate.
I'm particularly interested in the opinion of occasional contributors ( for example @Armael , @agarwal , @rgrinberg ?). Would you subscribe to a mailing-list? Are you already subscribed to all github issues/PR, or do you just watch some of them?
I would subscribe to an ocamlbuild mailing-list. I'd rather not receive all github issues, as I prefer to only get github notifications for things that concern me personally.
To make it easy for people to know in which case they should use github issues or the mailing list, it might be helpful to define some kind of policy. Maybe something like "issues for bugs only, ML for design/improvement concerns/discussions".
I'm OK with using mailing lists but it's clear to me that a large portion of the OCaml community (newcomers and young users I'd bet) aren't interested in mailing lists. Thus, to serve as many users as possible, I think it would be a good idea to let people use github issues as they see fit while pointing out that a mailing list also exists.
I can set up an ocamlbuild mailing list on lists.ocaml.org easily enough. You may also be interested in Discourse -- @amirmc has setup a unikernel forum, and Rust is using it at https://internals.rust-lang.org/.
I don't see what is the difference between mailing-list and watching a repository ("all github issues") except that you have the advantage with issues to be able to unsubscribe yourself from the one that doesn't concern you specifically.
Would you subscribe to a mailing-list?
Yes, but ...
Are you already subscribed to all github issues/PR, or do you just watch some of them?
Yes, so for me there's no particular benefit to creating a mailing list.
No strong opinion, but my view is that adding a mailing list is useful only for more active projects where the volume of traffic on GitHub issues is getting overwhelming. Then there is some benefit in separating the use cases into: mailing list for broad discussions, and issues for specific close-able tasks. But there are still ambiguous categories; e.g. where should questions be posted? GitHub issues with appropriate use of labels satisfies the full spectrum.
@dbuenzli do you feel that the platform mailing-list is not appropriate for this? Do you have in mind discussions that make sense across build systems (eg. on sharing work or evolutions of the rest of the ecosystem that affect or are affected by build systems), but would be too technical for the more general "platform" audience?
Yeah maybe it's better to keep that to the platform mailing list, let's not multiply lists for no reasons.
Just a quick comment on Discourse (and related solutions) — I think such options may be a little heavyweight for ocamlbuild. It might make sense to have such a thing for a large project, or an ecosystem of smaller ones, but I suspect there wouldn't be enough discussion to be worth setting it up for just ocamlbuild. For example, I'm setting up discourse for unikernel projects (which includes MirageOS and others) and I know that Wordpress uses Slack — these both cover a wide range of topics.
Other options might be chat-like boards, for example, CoHTTP uses Gitter, which others here can comment on (I suspect this is not really what you're after but I thought I'd mention it).
In any case, my reading of this thread is that there's rough consensus around keeping things primarily on GitHub issues but having a mailing-list as an option when needed. If this is indeed what you settle on, then you can ask for the list to be created by sending an email to the infrastructure list.
