One worry I have with synchronous-encouraging mediums is that:
They tend to encourage producing content in an unstructured form that is natural to consume content in the moment, in context, but has lower lasting value (it is more painful to re-read and reuse after the fact than a forum post).
Typically they are not indexed by search engines or at least less well-indexed than typical forums.
I ask my search engine for Rust questions from time to time, it often redirects me to Discuss forums of the Rust community (‘internals’ or ‘users’), and it never sends me to read content on the Zulip. Does that happen to you sometime? Could you maybe do the experiment of picking a specific Zulip thread from the past that you found interesting, and trying to find it again through a search engine?
Being hard to search “externally” may look like low-priority for people in the moment, because they know about the discussion space and can use the search feature there (which sometimes work). But technologies change and in 5-10 years they are going to be used a different discussion space, and typically not think of going to the previous place to search for answers.
(In contrast, I regularly encounter caml-list posts from more than ten years ago that make interesting points, and/or pre-github issue discussions that were saved by importing them into github on migration.)
Interestingly, Discourse chat be linked to topics, which may address the synchronous overload by allowing conversations to be packed into forum posts once they “mature”. Message #2 by avsm – #General is a test!
I do want to emphasize again that the main problem I’m trying to point out is not synchronous vs asynchronous, it’s more centralising the discussion, and redirecting flow of interest to a unique place.
Discourse chat might do the trick though, I’ve never used it
I think starting in a new location (zulip), despite the tool being excellent, is going to spread resources even thinner.[…]the discord server already has a large following (5000 members, with 500 online as of this moment), and amplifying the same location provides a feedback effect and allows more people to get involved in compiler development.
I tend to agree with this; one of the issues I’ve noticed in the OCaml community is a strong urge to use unpopular tools on the basis of marginal technical benefits. Yes, Zulip is on some levels technically superior, but it’s also the case that vastly more people have Discord already installed. Yes, Zulip is successfully used by the Rust folks because they started using it at a point where Discord wasn’t particularly popular, and they have a lot of inertia. Now? I think it would be a bad idea to split up community discussion more. It already happens in too many places.
Indeed no, Zulip chats are not referenced by Google. That being said, they are still linkable, which is a net improvement over Discord.
That being said, discussions end up being referenced in relevant RFCs (example 1, example 2), so context is can be accessed. In addition, Zulip has a pretty good search and I do use it frequently when searching for specific details of the Rust semantics (and often find the answer there more easily than on Google, though that’s not quite an argument if Google doesn’t reference the place where the discussion happens).
Again, it’s not specifically Zulip that I’m arguing for here. I’m arguing for centralised communication channel where core team and community discussion happens, in a way that is referençable and inspectable. Zulip fits the criteria, Discord does not. The closest we have is this discourse, in my opinion, but it is not where design discussions happen, and the OCaml repo and other repos of the ecosystem have no link to here.
is compounded by timezones. You log in in the morning and there are 100+ hastily-written unstructured messages, only some of them about the specific conversation you are interested in.
The concept of a centralized model is not feasible - you can’t force anyone to switch, and these things are determined by popularity and going “viral”. Rust isn’t centralized on Zulip either and has a very active discord presence. Even if we assume some people move to Zulip (which I do think is somewhat technically superior while lacking some features), we already have multiple OCaml organizations with different Zulip homes created for themselves - there’s not going to be one umbrella location that includes everything, so we need to let go of that fantasy.
Each of the current avenues has advantages and disadvantages.
discord isn’t crawler-friendly and is closed source, but also has strong presence and is extremely popular among the programmer demographic and young people in general. It’s a great avenue for attracting people to OCaml, since many projects live on discord and it’s very easy to just “add one more server”. The conversation is less focused, but that’s not entirely a negative - human informal communication tends to be unfocused and wanders from topic to topic. Also technically, we can have more focused discussions there, much like Zulip - we can just open a forum on discord (a feature copied from Zuip), and then have the best of both worlds - subject-based discussion and realtime communication. Check out the #forum channel to see it in action.
discourse is open source, websearch friendly and a great bridge with the more traditional elements of the community who prefer email communication. It’s also just a great and simple forum experience.
Zulip has some advantages over both competitors, but are those advantages enough to force-migrate the entire community? Probably not. People get comfortable where they are. Much like the way dune swept through the community by winning over programmers, Zulip needs to compete and show sufficient advantage to dominate. Right now, it’s been adopted by various niche OCaml technical communities. Those communities will not necessarily want to break up their small ecosystem just to “centralize”.
None of this will change the fact that OCaml core developers don’t communicate via online forums. Most communication at that level happens personally in various other forums. We would happily open a specific channel for them on the discord, possibly a forum-style channel if they wanted it, or they could choose a Zulip server, or even make full use of their github forum, but they’re just not currently interested - you’d need a major culture shift for it to change, and that can only happen if they’re interested in it, which they don’t seem to be.
Bottom line: the status quo matters, and people like the things that they’ve gotten used to. Something new has to be so much better, that it blows away what existed previously. Before discord and discourse, we had much less (IRC and email), and the delta was large. The delta with zulip is ostentibly there, but it’s not massive. Discord can already emulate (imperfectly) much of what Zulip has with its forum system, and discourse itself has also had to compete with its new realtime competitors. The community will not magically unify under one roof - that’s just not how communities work, and the OCaml community in particular never worked like that.
Again, this is the nature of human conversation, and a community needs to have informal as well as more formal outlets. Read it or ignore it. Sometimes I read it, sometimes I don’t care and just skip. For more structured discussions, this forum exists (or the #forum in discord, if more people were to use it).
I remember finding a small misbehavior in the compiler when I started contributing. I wanted to fix it (and I did) but I needed to know in which part of the compiler to look for. The problem was I didn’t knew where to ask my question (ie : “In which file is written the function that does XXX ?”) and this was a bit frustrating. Now I know that I’ll either ask some people directly or maybe ask on the slack server but for the first one I know those people and for the second it’s closed access. In the end I asked my question on discord and the first answer where from random people that never contributed to the compiler (which was nice from them but completely useless) until @octachron gave me the answer.
My feeling is that the discord is much more a community place for people learning OCaml and that compiler related discussions are out of place there. Discuss is nice but new people might be a bit scared to ask question they deem to trivial/small for a whole thread here. Slack is much more compiler oriented but with restricted access.
In the end my belief is that it would be more beneficial to move the people from Slack to Zulip (ie : open to new people) rather than moving the people from Discord to Zulip.
I feel like I’ve repeatedly failed to make my point given your answer, so I’ll try one last time. While I do think Zulip is particularly adapted for that goal (and I have intertwined this opinion too much with the rest of my arguments) I don’t care about the specific technology.
Please see this message for what I mean with centralized. Yes Rust has a Discord, but the community and core development is organised around a single polyvalent medium.
Again, the history of this threads stems from Kiran stating this:
To which I only said that I believed the success of the Lean (and Rust) model comes from having a centralised open channel of communication where discussion happens and is referenceable. The “discussions in public” happen on Zulip, and the agenda of the “office hour regarding compiler development” is discussed in advance on… Zulip.
It is. Every link in the official Rust repository contributing guidelines and various contribution guide point to Zulip, every discussion about planning for meetings of any of the official Rust teams (language, compiler, cargo, standard library…) officially happens on Zulip in the open, and most RFCs end up referencing a link for history and justification. Yes, there is a discord and probably a billion other small channels and sub-community (e.g. Rust London). But these are not the center of the Rust ecosystem, Zulip is.
Also, the Rust discord is shutting down (though, again, I am not advocating for this on the OCaml side at all, this is happening because of scalability issues which we won’t suffer from – but it does confirm that the community is centred around Zulip):
Currently, the OCaml communication model is more unclear. I usually ask my questions here, but constantly feel like I’m spamming, because a forum is not quite adapted to this kind of discussion.
Though, I opened the OCaml Labs Slack today, I had uninstalled Slack, and it seems inactive. That being said, at least two of the channels I am a part of about core components of the ecosystem (VSCode plugin and Github Action) are private channels within an already-private slack… So it’s fair to say that, although progress has been made recently, the OCaml ecosystem doesn’t have a strong history of openness).
Again, I don’t care specifically about Zulip (I even don’t really like Zulip that much, I’m a bit mad at their desktop app), but it happens to have the features that make this model work.
Finally, and for the last time also, I would like to emphasize that in no way am I trying to criticize the OCaml core team(s). OCaml is a fantastic language, and I am repeatedly in awe of this too small pool of people doing such an amazing work for every one of us. It is beyond unreasonable to have such a good language and tools given the amount of people actually doing things. I am deeply thankful. I am simply trying to convince of something I believe would improve the ecosystem.
I think it’s fine for this type of discussion. The discussion might also start off in a discord channel and move here once it matures.
I think this is the key point on which we agree. OCaml’s central hub (i.e. mainly the compiler) is not very public. That hasn’t really changed that much in the 13 or so years I’ve followed this community. It’s not the same culture that exists in other, more modern languages, and it doesn’t have that much to do with the tooling - all the tools are there already. We have multiple walled or semi-walled gardens, and none of them feels much of a need to interact with the rest of the community except for the occasional announcement message or discussions on specific PRs, but even there, much of the discussion happens behind the scenes. This is a cultural issue. OCaml has advanced despite this culture, but its chances of great success are reduced due to its presence.
Much of this insularity is driven by the desire to reduce noise. When every decision is opened up to the community, various people may chime in who waste everyone’s time since they lack the needed knowledge to contribute to expert-oriented topics. But that also prevents people from getting involved and learning in the first place. Other languages have realized this and have radically opened up their processes, but OCaml has not done so.
Members of the wider ecosystem are mostly more open in their approach, and can be found on discord and other avenues. I’m sure the most eager of them will also be happy to experiment with Zulip. But there’s a distinct cultural difference there. Anyway, now that I understand your point, I don’t disagree with you.
Absolutely! And that is why I pointed to various contribution guidelines for Rust. I believe that they have manage to “enforce” a culture of openness by redirecting all flow to Zulip from all documentation. Same for Lean.
Even the governance model of Rust has explicitly one Zulip channel associated with each team. These Zulip channels are open to anyone. Of course, they are mostly used by the team in question, but I have created several topics to the operational semantics team channel to ask questions and always found a quick answer. Because the t-opsem team monitors that channel.
Similarly, OCaml could attach a Zulip channel (or again, anything else, as long as it’s open and externally referenceable without account) for e.g. dune-devs, compiler-devs, editor-devs, stdlib-devs, and working groups such as wg-modular-implicits, where discussion would be redirected. Importantly, these groups would be referenced by the contribution guidelines of each of these projects.
In contrast, I was looking at modular implicits and found a discussion from last year with this message:
I could not find where said discussion happened It does indicate that, sometimes, synchronous discussion is needed. Ideally, this message would contain a link to that discussion, and I would feel like I could take part. Reading this, I think this interaction could have been slightly frustrating for Eduardo.
IMHO community follows from license and ownership, and that explains the primary difference between OCaml and Rust + Lean culture. Rust and Lean are both Apache licensed and (I think) don’t require CLAs; OCaml has its own flavor of a GNU license and a CLA for meaningful contributions. Rust and Lean are legally owned by communities (Rust Foundation and Lean Focused Research Organization) that include industry competitors; OCaml is owned by INRIA.
I know the thread is about Lean and Rust, but I think the more relevant comparison is to sqlite3. The sqlite3 owner does not accept many outside contributions, and for the most part people are comfortable with that because of the quality of the project. And the OCaml compiler and language are super high quality. However, I don’t think quality that extends to the standard library and the build system. My personal wish is that the non-compiler parts of OCaml had a broader ownership base … it is sad to see obvious improvements like Buck2 (ICFP 2023; Meta) languish for no discernable reason, and I think having a broader set of owners would get these contributions through the door.
I see no technical difference in practice between Zulip and Discord; the practical difference is that vastly, vastly more people already have Discord installed and use it every day, and there’s already an OCaml Discord, so there’s much less friction there. Decisions should never be recorded on chat channels anyway, they should be turned into Architecture Decision Records and put into a git repository with proper editing. The purpose of a chat channel is real time communication among developers, not to produce a permanent record.
As I’ve said before: the OCaml community has a serious tropism towards using unpopular tools on the basis of marginal technical benefits. Fundamentally, coding is a social activity — social benefits of tools should be considered in most cases before technical benefits. Rust didn’t succeed because they use Zulip (they use Zulip because when Rust started Discord wasn’t yet really a thing), Rust succeeded because they persistently worked to lower barriers to participation.
I think you’re missing the forest for the trees. You see what Rust did but you’re not noticing that the important part here is that Rust is a welcoming and open organization that tries to reduce barriers to contribution; the specific processes they use are uninteresting.
I have often failed to get things added to OCaml and have repeatedly succeeded much more easily in Rust, and I’ve never logged in to their Zulip at all. Why was it easier in the Rust community? Because of their culture of inclusion. It has nothing to do with the tools or the processes.
Indeed, but where do the discussions that lead to these decisions go? How do I get to take part of it? How do I access it later?
That is simply false. They started on Discord and gradually moved to Zulip. Discord has been a thing for way longer than Zulip, the latter was optimised to fit this use case.
We agree on that one. I am proposing a process that, it has been show, works for reducing barrier to entry. In fact, a link to the relevant Zulip channel is the first thing that is proposed by the CONTRIBUTING.md file of Rust (which the forum warns me, I’ve linked several times).
100% agree.
Entirely disagree. How do you cultivate inclusion? If not by following, encouraging and enforcing process that ensure said inclusion is possible?
Again, not specifically advocating for Zulip. I’d be fine with the answer “all discussions happen on discuss.ocaml.org in the open”. I don’t think it’d scale that well, but it at least has the relevant features. I don’t think discord has the features to do that.
Also, I recently moved my work team to Discord, I use it everyday, I don’t care that it’s closed source, it does what I need it to do extremely well. I don’t think it does what a community like OCaml needs.
One thing to keep in mind: not all teams are the same–not all teams work in the same way. The Rust team has a lot of people being paid to work on it full-time. Referencing the ‘move semantics’ thread you shared, I would bet that it was literally many of those participants’ job to make progress on move semantics. The could afford the dedicated effort it took to focus on it synchronously with others across time zones and over the course of many days, weeks, months.
I would be wary of trying to shoehorn the much smaller OCaml team, who spend a fraction of their time on the project, into the same model. My fear is that trying to force the same synchronous model on them would be a recipe for burnout. We should be wary of making broad generalizations based on the success of the Rust communication systems.
But maybe it’s looking at the problem backwards? Maybe by opening up the process and making it more transparent, other people will be given a chance to become interested enough to step up and join the core team, thus reducing the load on the current devs?
This is a weird description to me. The development of the compiler happens on github. The vast majority of discussions happen on github and are entirely public (and searchable, etc.). Anyone is welcome to participate. The discussions on the github/ocaml/ocaml codebase happen on github/ocaml/ocaml, I don’t see how this is a “walled garden”.
We also have:
Synchronous meetings for compiler maintainers to get a sense of what people are interested in working on, meeting face to face in a while, and take decisions on issues that have gotten stuck or proved too controversial to be resolved remotely. (These meetings are organized on a low-traffic mailing list that is occasionally used to discuss maintenance topics, and is private for historical reasons.)
Two separate channels to discuss large changes with a more structured process: the RFCs repository (public, open, etc.), and more recently a Language Committee to try to make some decisions on questions that are not making progress (publicly visible but membership-restricted, following the GHC model suggested by Richard Eisenberg).
I have no idea what you have in mind when you write that “much of the discussion happens behind the scene”. My best guess as to what is going on is that people don’t realize that most of the changes in the compiler are led by two people working together on their spare time, and imagine that there must be a higher volume of discussions than what is really going on – and thus that the discussions are hidden from the public.
… and it also happens that people talk in person!
Right, these are questions I asked these people (and trefis) in-person, on a few occasions over the course of months/years, as I found @EduardoRFS’s criticism relevant and interesting. Nowadays I meet diremy and samsa1 about once a week, and lpw25 maybe once or twice a year when we happen to attend the same conference. Small-group in-person conversations are not recorded, but I do my best to post summaries when relevant – here I thought that it was important to acknowledge @EduardoRFS’ contribution to the design of modular explicits.
My best guess is that Rust caretakers talk to each other in-person from time to time, and that those discussions are typically not recorded. (For large meetings organized in advance, it is reasonable to keep minutes and share them; but in-person meetings also need unstructured get-together time to be productive, and those don’t get transcripted except via individual efforts such as the above.)
Note: I don’t think that trying to eliminate face-to-face conversations would be a very good idea. In my experience online discussions tend to get heated more quickly or get misinterpreted, and there is always a risk that people get angry at each other and it’s draining. I have seen heated discussions in-person, but much more rarely. Having social times between people working together is important in my experience, even if it is only once every few months. I suspect that an online-only project would lead to demotivation and burnout (as indeed happened in larger amount than usual during COVID lockdown).
