RFC Consolidating synchronous communication to one venue

Tl;DR: scikit-learn development discussions now take place in [the #development channel on discord](https://discord.com/channels/731163543038197871/1046822941586898974). Please don't use the [gitter channel](https://gitter.im/scikit-learn/dev) anymore.

Discord invite link: https://discord.gg/ZDZzqwESay

---

The goal of this issue is to "shop around" an idea from the monthly meeting (28 Nov 2022). To gather feedback and impressions on the proposal.

There are several real-time/synchronous communication platforms in use for the scikit-learn project. There are several gitter channels and a discord instance with several channels. Combined with a (perceived) lack of a clear answer to "Where should I go for my synchronous communication?" this leads to lots of channels that appear "empty" at first glance (think "curse of high dimensions"). To make matters worse, if a venue appears empty people will try new/other venues to reach the people they are trying to reach. Which further increases the possible venues, further reducing the probability of observing activity in any one of the venues.

This topic was discussed at the monthly meeting (28 November 2022) and the feeling was that the status quo is worth improving. There was consensus that reducing (to one) the number of venues would be useful. There was no clear preference for which of the many platforms to select. There are pros and cons to each of them, especially considering the various use cases (sync communication to coordinate repository activity, voice/video channels for sprints, administrative chat).

However, there is a concrete proposal that didn't result in big opposition in the call. It tries to serve all of the use-cases, but of course tradeoffs had to be made. The proposal is to consolidate to "discord with a revamped channel list".

Concretely this means to point people towards the existing discord instance, away from other chat platforms, and to restructure the channels to make it easier to know which one to use when. A proposed list of channels:
* a "read me first" channel: this channel gives people an introduction to where they are, overview of channels, rules, expectations
	* for example making clear that the "users" channel isn't a "hotline to the developers". There are better places for support style discussions (we should link them).
* a "welcome/introduce yourself" channel: useful for people to say "Hi 👋!". Especially during online sprints
* a "development" channel: a place for people to synchronously discuss things that are going on in the repository right now. People who are (very) active on the repository could use it to discuss where they need help, how to resolve a problem, get help with a review, announce what they are focusing on or that they will have reduced availability for a while. Basically the kind of topics you'd talk about when in an office with others you work with.
* a "users" channel: this is the place for people using scikit-learn to talk to each other. 
* a "admin" channel: a (private) place for administrative tasks related to the discord instance
* a selection of voice channels (with explicit accompanying text rooms): these are for ad-hoc voice chats, to create "tables" during sprints and other occasions where you need several ad-hoc video+voice communication channels.


The goal of this issue is to "shop around" the idea from the monthly meeting. This means, gathering feedback and impressions on the proposal. Depending on what happens the next steps will hopefully become clearer. Keep in mind that there was support for making a change/the current situation is not great. This means that we should try and use this issue to iterate towards something that we can do, even if it is not perfect or might need tweaking in the future. A change that is too ambitious or needs too many resources to implement is a change that might never happen. Similarly, not making a decision is a form of passive decision making for the status quo. It is probably better to actively decide either way than let it linger.


---

I wasn't sure if I should open this issue here or on github.com/scikit-learn/administrative. If that would have been a better place, please someone move this issue there.

COMMENT:
That is a good point. During the meeting people mentioned that Numpy(?) considers the fact that their Slack instance "forgets" messages as a feature. Someone asked if discord/gitter could be configured similarly. This can help reinforce the fact that chats are for fleeting conversations where it is Ok if tomorrow everyone has forgotten that they ever happened. Long lasting conversations and those that should be recorded for historical purposes need to go somewhere else. Many projects use issues or a forum for those, I guess sccikit-learn does too. Maybe a topic for a new issue/RFC: what are the options for communication and what should go where.

Labels: RFC