> > I understood that the change was not going to be popular, but I was expecting civil discourse and a level-headed response.

Not to give credit to the antisocial mob, but it would be a lot easier to take the maintainers' side here if the discourse was started before the change was merged into production.

It's incredibly ironic that the LWN article praises Jeremy Soller for having reasonable objections against the change but fails to mention that systemd maintainers locked the issue* when he tried to raise his objections (and implicitly called them spam). I really fail to see how anyone could expect civil discourse given these circumstances.

* In an incredibly pathetic way too - the systemd maintainer responded to his comment, then immediately locked the issue without even waiting to see what Soller would write in return.

▲

JuniperMesos 17 hours ago | parent | next [-]

This is classic bad online-forum-moderator behavior, that you see in all sorts of online chat and message board spaces where there's a moderator who has the power to lock threads at all. Obviously, the systemd maintainers have no obligation to adhere to any particular moderation policy on their org's github issues, but they definitely deserve mockery for this.

▲

SpicyLemonZest 15 hours ago | parent [-]

Have you ever been on the moderator side of this? There's ultimately no perfectly polite and collegial way to say "we've heard your concerns, but this is our decision and it's not subject to your review". Being more direct about it would only have inflamed the situation further.

▲

JuniperMesos 9 hours ago | parent [-]

My actual opinion here is that Github issue threads shouldn't exist at all; and pretty much all online communication should be redesigned in such a way as to prevent anyone taking the role of a moderator to lock down a coherent comment thread from everyone else who wants to participate. (I agree this is a hard chat UX problem).

In my ideal world, instead of having Github accounts everyone in the thread would be posting under their own personal ID (in a way similar to ATProto, Nostr, etc.), using a discussion UX that would allow Soller to seamlessly continue the thread along with any other willing participants even after the systemd maintainers blocked it from their own end (which is their right to do). Perhaps if systemd entirely forked over this, this issue comment thread could seamlessly transition into a new issue on the fork, to serve as documentation for why the fork works the way it does.

In general, sometimes the best response to a moderator banning some kind of discussion is for everyone who is subject to that ban to fork the discussion thread itself; and online communication software should more readily facilitate this.

	▲	SpicyLemonZest 4 hours ago \| parent [-]
		I think that's affirmatively a bad idea, even given a solution to the UX problem. Maintaining a healthy discussion forum requires the ability to terminate bad discussions that are causing problems, and making decisions effectively requires that there be a seam-ful distinction between the thread where a decision is discussed and meta-threads where someone else in some other context wants to talk about the same issues. I see where the intuition for your idea comes from (I can't just declare that my friends have to stop talking about a road trip because I'd prefer to ride the train, I can pull someone out of the circle for a side conversation freely), but it only works in closed groups where all participants are invested in their reputation and there's no clear decisions to be made.

▲

15 hours ago | parent | prev [-]

[deleted]