Re: Testing Discourse for Debian - Moderation concepts
* Neil McGovern: " Re: Testing Discourse for Debian - Moderation concepts" (Mon, 13 Apr 2020 19:56:28 +0100): > I am going to try and split this out into two replies, so those > following along can see the different issues. The irony of the > difficulty on doing this within email may or may not be lost for others. > > On Sun, Apr 12, 2020 at 02:43:31PM -0700, Ihor Antonov wrote: > > > You have to trust the moderators, > > > > So far I am not convinced that I can trust you to moderate. > > > > > and you have to have some mechanism to > > > evaluate that trust and to discuss it and possibly revoke it if something > > > goes horribly awry. > > > > Prevention should always be the first step. Something WILL go wrong but you > > are too blinded by the immediate sugar candy in front of you. > > > > I just want to state, I won't debate any issues around freedom of > speech. I believe that these do not apply in this context I think, freedom of speech *can be* an issue when you hand over moderation to a system and random people that are not explicitely delegated to do those tasks. > - especially with Debian being a private entity. I tried hard to understand this part of hte sentence, but failed. Could you please elaborate? > Now, I do believe you have a comment on moderation, and how this is > done. This requires me to explain two concepts in Discourse - trust > levels and flags. > > Firstly, trust levels. These are the levels of "trust" that the platform > has in any particular user. Instead of explaining it here, please have a > read of the following: > https://blog.discourse.org/2018/06/understanding-discourse-trust-levels/ > The short version is that the more a particular account interacts with > the community in a positive way, the more trust the system has about > them, and the more privileges they are afforded to assist in > moderation. The trust system gives me no trust at all. It is very closely bound to participation over the web interface, monitors the reading frequency and time spent on reading by users. Apart from a quite unpleasant feeling of 'big brother is watching you' I do not see at all a nearly equivalent handling of users who want to interact over the mail interface. Reading the link above clearly states for me that mail users are second class citizens in discourse. I completely fail in understanding someone who states, that discourse has a good email integration. > Secondly, flags. Discourse has the opinion that moderation cannot be > proactive with a small group of users - this doesn't scale. It must not scale and it must not be proactive, moderation must be correct and considerate. > encourages community members to flag posts. If a post receives > sufficient flags, it is then automatically hidden. Users may chose to > "unhide" the post for themseleves if they wish to view it. > > These are then sent to the moderating team to agree, disagree or ignore > the flag. This will unhide the post, or keep it hidden and offer an > opportunity for the moderator to suggest the original author edits their > post in light of the number of flags they got. If an author does so, the > post automatically unhides. > > All these actions are logged, and affects the trust levels above. In > fact, every time an admin performs any action on a user, this is > logged. Where is it logged? Are the logs public? Where can I see who flagged a post, took action on it? > I hope this explains how I believe that moderation is more powerful on > Discourse, but also more practical, transparent and accountable. All of the above makes me in contrary believe (together with the experience I have so far with interaction on discourse, namely discuss.tryton.org), that discourse is indeed *not* practical, transparent and accountable. Mathias -- Mathias Behrle ✧ Debian Developer PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6
Re: Community Team - where we want to go
mendations >are sought by members of the community; > > * Quick response time alerting reporters that action might be taken; > > * Holding regular meetings (and emergency meetings, when relevant), >to discuss incidents reported and actions to be taken; > > * Writing and providing reports to other teams concerning incidents >or habitual behaviors; and > > * Proactively writing emails to those who habitually make the >community a hostile place, informing them that their behavior is >harmful to the community, that action may be taken in the future, >and that the Community team is a resource to provide explanation or >guidance. What does mean "that action may be taken in the future"? Which actions in which context does the team want to perform? Is this a pure informal step about actions of other teams? I think the following negative list is not the way to go, but a clear statement should be made. > Examples of things the team does *not* do > = > > * Remove blogs from community forums like Planet Debian > > * Ban users and contributors from email lists or other communication >channels; > > * Take preventative action on mailing lists when an incident report >does not come in, excluding general reminders to email lists about >the Code of Conduct; > > * Mediate communications or conversations between individuals; or > > * Take punitive measures or actions against members of the Community. > > Members of the Community Team may of course participate in discussions > as individual contributors to the Debian Project, and will not always > be expressing the views of the Community Team. -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6 pgpQ9aV0zZIUS.pgp Description: Digitale Signatur von OpenPGP
Re: Pride Month Discussion has Run its Course
* Stefano Zacchiroli: " Re: Pride Month Discussion has Run its Course" (Sat, 6 Jul 2019 23:10:57 +0200): > I'm sure that was not your intention, but to bystanders that gives the > feeling that you're undermining the DPL's authority, and gets in the way > of the DPL doing his constitutional job in this specific area. So, > personally, I'm torn here: I agree with your open discussion mindset, > but the main issue here was (as I understand it at least) of a different > nature. If you are sure it was not the listmasters intention, why then speculate about supposed feelings of bystanders? I just can nothing more than say, that I never had the slightest impression of the listmaster "undermining the DPL's authority". Quite contrary to that impression I would expect the listmaster to act completely independent from the DPL. -- Mathias Behrle ✧ Debian Developer PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6 pgp_4K2LrN6pv.pgp Description: Digitale Signatur von OpenPGP
Re: Pride Month Discussion has Run its Course
* Alexander Wirt: " Re: Pride Month Discussion has Run its Course" (Sat, 6 Jul 2019 20:00:58 +0200): > On Tue, 02 Jul 2019, Joerg Jaspert wrote: > > > On 15451 March 1977, Alexander Wirt wrote: > > > [...] > > > Thats possible, but imho not a reason to kill the thread. > > > > It is a very good reason to do so, and its sad that our listmasters > > aren't more active in shutting down threads that repeat and repeat and > > repeat all the same things ever again, every other month. > > It would save so much energy that could be used so much more useful. > > > > Same as getting rid of the "all lists are open" thing, something that > > was nice in the past, but has definitely lost its value long ago. > I can not do more than disagree. If you don't like a thread, killfile it. > But using censorship, banning, blocking threads you/someone don't like, just > for the reason *you* don't find them useful is in my eyes just wrong and is > some kind of censorship and should not be done in an open project like > debian. > > But that is my personal mindset I am coming from. If such a mindset is > outdated nowadays and not wanted anymore I offer to resign as a listmaster. Others have already answered, I have the feeling I have to step in at this point, too: I think you are doing exactly your job as listmaster to not influence discussions, but merely control the correct functionality with respect to respect and list guidelines. Thanks, Mathias -- Mathias Behrle ✧ Debian Developer PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6 pgpC8xlQaSiLW.pgp Description: Digitale Signatur von OpenPGP
Re: Question for Planet Admins: What Should I do if another Developer Removes my Blog
* Sam Hartman: " Re: Question for Planet Admins: What Should I do if another Developer Removes my Blog" (Sat, 25 May 2019 18:37:11 -0400): > >>>>> "Mathias" == Mathias Behrle writes: > > Mathias> * Karsten Merker: " Re: Question for Planet Admins: What > Mathias> Should I do if another Developer Removes my Blog" (Sat, 25 > Mathias> May 2019 17:49:13 +0200): > > Mathias> Hi together, > > Mathias> I am supporting wholeheartedly the view of Carsten with > Mathias> some small amendments. > > In this whole discussion I've been speaking as an individual developer. > > I find your position and that of Carsten confusing. Carsten has already answered to most questions. > At one level you're arguing that we're not planet admins and should not > do planet admin things. > > But then you spend the rest of the message saying how planet should be > run...you spend the rest of the message actually trying to assert the > sorts of things that you said ought to be left up to the planet admins. I cannot find any contradiction in saying, that *doing* the task should be left to the planet admins, while I find perfectly reasonable to give a role some *guidelines*. Mathias -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6
Re: Question for Planet Admins: What Should I do if another Developer Removes my Blog
* Karsten Merker: " Re: Question for Planet Admins: What Should I do if another Developer Removes my Blog" (Sat, 25 May 2019 17:49:13 +0200): Hi together, I am supporting wholeheartedly the view of Carsten with some small amendments. > a) As the general rule DDs who are not part of planet admin >should IMHO never forcibly remove somebody else's feed from >planet on their own. The planet admins run the service and >whether a feed gets removed from planet is solely their >decision (of course subject to a possible override by the >means defined in our constitution). > > b) The only case where I would consider a forced removal of >somebody else's feed by somebody who is not part of planet >admin to be justified would be if the further inclusion of the >feed on planet would constitute a criminal offence in the >jurisdiction where the webserver that serves planet.debian.org >is located, and in this case that would have to be clearly >stated by the person performing the removal. It may go without saying (but explicit is better than implicit): Such a procedure should only be justified in emergency cases that require immediate action and if no planet admin is available in due time. And of course it should be confirmed/reverted ASAP by the planet admins. > c) The onus of proof that there are sufficient reasons to remove >somebody else's feed and the onus of going through the >procedure of contacting the planet admins and convincing them >to take action clearly has to be on the person who wants other >people's content removed, and not the other way around. I would wish a documentation of the reasons in the best possible transparent way. I know other people expressed their reservation to not create some impact on the public image of the blocked feedowner by communicating too many details, but there is also the interest of the project and its members to know as exactly as possible about the reasons. Finally we all (can) know and be aware about such implications when we join Debian and that we will be acting (and perhaps be subject of evaluation) in the public. > While the feedowner in question should of course consider other > people's views on the feed's contents, as a consequence of the > previous points, restoring the feed would IMHO be a legitimate > action unless either the issue is covered by point b) or the > planet admins have taken a decision against further inclusion of > the feed on planet and have already communicated this decision to > the feedowner. Cheers, Mathias -- Mathias Behrle ✧ Debian Developer PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6
