I’d love to find a container community-centric place that is not irc (for a lot of reasons I don’t think need to be repeated) to commiserate with other users of the box builder project and drive development.
Discussing with @thaJeztah about doing this with the Docker Community slack, we came to the conclusion that maybe a Moby-centric slack with less barrier to entry would be good.
I think the biggest advantage here is that a community slack run by the community itself w/ basic charter + guidelines to shape who and how people run it, really goes a long way to express the project’s autonomy and allows the community to grow as the project does.
It would make sense to have a slack just for the Moby project (and other tools like this forum). It would also remove a bit the confusion happening on the docker community slack where people tend to ask question about docker on the #moby-project channel.
Having a separate slack for the Moby project makes sense to me as well; it allows us to create channels for projects / components that are part of the Moby project, or built on top of Moby, without confusing it as being related to Docker’s products. For example, @erikh’s Box IMO would be a better fit in a Moby slack, than in the “Docker community” slack
In addition, the Docker community slack is a “free” version, which has a 10.000 message limit; having a separate slack for Moby allows it to have a bit more history
Also makes sense to me to have a separate Slack for Moby. We’ve just moved over some projects like moby/datakit onto #datakit in Docker Community Slack, so it’s not too much more effort to just shift everyone over quickly to another Slack channel before it gets too embedded
This isn’t going to be solved by having another Slack. You’ll hit the limit much quicker than you think, so this point very quickly becomes moot. Right now the #moby-project channel is archived via a bot, so someone would have to set up an equivalent (or copy archives regularly), if we want to keep history.
Edit: I’m actually a fan of the idea of archives being copied somewhere daily (automated, ofc).
I think this really underestimates the amount of work involved. It’s non-trivial to set up things like charters, etc and should not be taken lightly.
Community infrastructure as described still has to be run by someone and we have to be very specific about the details if we want it to succeed and be maintained (i.e. imho ‘run by the community’ is far too vague, I could argue things are already ‘run by the community’ since we’re figuring out the mechanics ourselves as we go).
.
