On 12/13/20 12:25 AM, Adrien Glauser wrote:
There are few clear-cut and objective criteria for on-topic vs. off-topic. Putting people under moderation on the base of unclear, non-objective criteria might not the best of ideas if you want to build trust and healthy social interactions. Arbitrariness and biases will probably be lurking in about every corner.
Fortunately the on / off -topic is not the most relevant distinction you need to keep the MLs clean. If you need a middle-ground between (dangerously arbitrary, free-speech infringing) moderation and nice but sometimes insufficient abstract rules (such as the Code of Conduct), you can do 2 simple things:
Both these lists have reasonably well defined definitions of what is and isn't ontopic. In this instance we are more trying to put in a framework on how to handle people who are repeatedly taking these lists off topic. They will still be able to post, its just there posts will need to be approved to ensure they are not going offtopic. This isn't intending to target someone who posts something offtopic on a one off occasion because they are unaware of the rules, we always want to be open and friendly to new people. The second part is sometimes it is obviously clear that a one of post goes against our guiding principles in such cases by empowering a moderator to take action here the issue can be clearly and cleanly resolved far quicker and easier then if the board needs to be involved, especially if it occurs at a time when the board is sleeping etc.
1) Provide a clear path / resolution site for interpersonal conflicts and issues. For example if two people are going two far, you take them apart and iron things out, taming the fire before it spreads over other channels. 1 able person might suffice for doing that for not just the mailing lists but every oS channel. So that instead of punishing, you might end up creating a positive mindset for all parties.
This has and very much will continue to be the role of the board and very much describes the process we take to deal with such issues although it varies a little from instance. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B