Moderators - Can we add a “Small Questions” category here? Maybe that (in addition to enabling chat) could help with this issue?
1 Like
I don’t think a “small questions” category makes much sense. In fact personally I don’t really understand this category and tags distinction. And I always find the category selection a bit odd to perform when I start a discussion.
I’d rather say that people should not feel like they are spamming. The notification system allows you to mute discussions if you are annoyed by them.
1 Like
Seems like there’s an emergent law that we can observe both here and elsewhere:
As discussion about the perceived shortcomings of a programming language, its ecosystem, or its community grows longer, the probability of a comparison involving Rust approaches one.
I think, at least in the past, there were various semi-walled gardens for important pieces of the ecosystem (e.g. dune/lsp/github actions). Though, I agree, the compiler discussions are open.
That is 100% fair.
That is also fair and I apologise for assuming these discussions were somewhere online.
Totally agree also.
So possibly, I’ve been going at this discussion entirely wrong. @gasche, it is clear that Kiran’s comments touched a chord, and it seems also clear, from several comments on this thread, that the community does not have a feeling of inclusion. It is entirely possible (and, from my point of view, probable), that you are correct and really the process is already as transparent as can be. So maybe the question is to you: what do you think can be done to improve this sentiment in the community?
I think I have made it clear that I believe some effort to centralise and organise the community would help. But, in fact, I think that the opinions that really matter are yours, and those of the other maintainers, as well as those of maintainers of core components of the ecosystem.
I am willing to pledge some amount of my free time to help, if consensus is obtained.
I think it’s quite a bit more nuanced than that. I personally also believe that we could improve in terms of making development processes more open and transparent, and I think that there is more than a grain of truth in the perception that it is not as welcoming to outsiders than it should be. (I think it’s quite clear in compiler development dynamics that a feeling of being “connected” to existing maintainers helps making people comfortable to contribute; and so people who step up and eventually become co-maintainers are often people we already know. They are great, but more diversity would also be great.)
I’m trying to make things better when I see what to do (and I proposed some actions in the other thread: restart the compiler-development newsletter and experiment with office hours). On the other hand, some of the analysis in the discussion do not match my perception of reality at all, and there are suggestions that I feel skeptical and possibly unpleasant. As someone more familiar with compiler development than most in the forum, I feel it’s also my place to push back when I’m not convinced – but the point is not to say that I think the situation is fine and there is nothing to be done to improve.
4 Likes
Another way to say this: I think it’s great to have this conversation from time to time and do a reality check on what the perception is and ideas for improvements. It’s important to be open-minded about suggestions, and I try my best to assume that my perception of the situation is subjective and partly wrong. But it’s also a draining topic that comes up regularly, and we are all aware that no matter what we try, things are going to evolve slowly – there is not one single thing that fixes everything. We have made many decisions in the distant or close past that I think go in the right direction, and I hope things keep evolving positively.
@giltho your interest in getting involved to help on these issues is noted and welcome. (This is the reason I cc-ed you the office hours suggestion, I hope you would be interested in being around as well.)
4 Likes
Just to step back a bit and remind everyone that the topic of this discussion is specifically ‘synchronous channel for compiler contributors’, in that light I would say broad statements like this don’t push the discussion forward (and many will disagree anyway). Clearly, there are well-established procedures for newcomers on how to contribute. Also, there is periodic evaluation and experimentation on trying new approaches.
Right now, we are talking about the synchronous discussion approach. One big suggestion that emerged was using Zulip, as many people like it from their Rust experience. Now, of course we can’t force the OCaml team members to use Zulip, but anyone in the community can certainly use it and present their findings. If it is successful, I don’t see any reason to reject it ultimately.
1 Like
I do apologise, I was trying to say something more nuanced. It is clear that some members of the community do not have a strong feeling of inclusion.
I also agree that there are well-established procedures, and this sentiment persists despite that.
Absolutely! And I do respect and find your opinion more important, I was not exaggerating or being sarcastic (not that you implied I was, but I’m re-reading my own message and it reads a bit like that).
I’ll be happy to attend office hours 
I’m personally unavailable on Tuesdays but not sure timing should be organised around me 
Is there a calendar of existing OCaml meetings somewhere? Asking because the dune devs meetings are now every wednesday, and we should avoid clashing.
1 Like
I took no offense and am perfectly happy with our interactions in this discussion. (I have kind of avoided discussing your specific suggestion of migrating to a single chat, in part because I am personally uncomfortable with synchronous chats and in part because I want to take more time to think about this whole question.).
3 Likes
I primarily use discord and this website for my ocaml content.
Wow, I am just discovering Buck2.
Thank you sharing that.
1 Like