Re: Testing Discourse for Debian - Moderation concepts
On Mon, May 04, 2020 at 05:47:16AM -0400, Dan Purgert wrote: > On May 03, 2020, Florian Weimer wrote: > > [...] > > What I find concerning is that Discourse (the web application) does > > not clearly communicate how it shares the data it collects about me > > with users. For example, it seems to notify other users that I'm not > > active on the site, next to my posts, without showing me that > > information. > > Web forums have had an "Online" indicator in various flavors for near on > 2 decades now. It's a bit pointless to show you that you're online, > since obviously you're online in order to be reading the posts (unless > you're not logged in, then you see the little "Offline" indicator > instead). FWIW, this is for me, as for Florian, a reason to avoid this kind of software as much as I can. For how long this is customary is irrelevant to me. Cheers -- t signature.asc Description: Digital signature
Re: Testing Discourse for Debian - Moderation concepts
On May 03, 2020, Florian Weimer wrote: > [...] > What I find concerning is that Discourse (the web application) does > not clearly communicate how it shares the data it collects about me > with users. For example, it seems to notify other users that I'm not > active on the site, next to my posts, without showing me that > information. Web forums have had an "Online" indicator in various flavors for near on 2 decades now. It's a bit pointless to show you that you're online, since obviously you're online in order to be reading the posts (unless you're not logged in, then you see the little "Offline" indicator instead). -- |_|O|_| Github: https://github.com/dpurgert |_|_|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860 |O|O|O| Former PGP: 05CA 9A50 3F2E 1335 4DC5 4AEE 8E11 DDF3 1279 A281 signature.asc Description: PGP signature
Re: Testing Discourse for Debian - Moderation concepts
* Ansgar: > I'm not concerned about marking messages read after some time and > keeping the view time in ephermal storage for that. But that's not > what Discourse does: as described elsewhere it stores all read times > persistently on the server; that would not be neccessary for marking > posts as read even on a web application. > > I feel it dishonest to compare storing data persistently in a database > and evaluating it for statistical purposes (or other analytics that > people come up with to increase participation and measure community > engagement for community building) with keeping data in ephermal > storage for a short while. > > Evolution also keep track of the mouse cursor, but that is something > different from recording clickstreams and evaluating them to increase > user participation as some people do. Your reply seems to put both on > the same level. It's also not clear whether the presentation requires message-read-state for every addition to a discussion thread. From the user perspective, it might be sufficient to record the last scroll-down position. What I find concerning is that Discourse (the web application) does not clearly communicate how it shares the data it collects about me with users. For example, it seems to notify other users that I'm not active on the site, next to my posts, without showing me that information. Using message-read information could be used for similar notifications. And with the gamification tendency, users might not even be aware that such information is available to users at higher privilege levels (with better scores).
Re: Testing Discourse for Debian - Moderation concepts
Neil McGovern wrote: > On Wed, Apr 15, 2020 at 12:47:06PM +0200, Ansgar wrote: > > I'm not concerned about marking messages read after some time and > > keeping the view time in ephermal storage for that. But that's not > > what Discourse does: as described elsewhere it stores all read times > > persistently on the server; that would not be neccessary for marking > > posts as read even on a web application. > > No, but it is required for things like knowing which posts in a topic > is popular, so should be used for auto-summary. The more I think about this, the more I think "required" is overstating it. The system could just trust users to click "like" or "thanks" or "+1" or whatever on a post, rather than spying on them. > It also is used to reduce abuse, as a normal new user would spend > time reading topics before posting for the first time. Such heuristics have a bad history of blocking (and sometimes grossly insulting) people who use access-assistance software and special apps because they find unmodified major web browsers hard to use. I haven't tested any on discourse yet because it's a lot of work to sift the javascripts. Nonetheless, in case you don't already know, I really appreciate your work in giving us an instance to test and explore these concepts and consider what next. Regards, -- MJR http://mjr.towers.org.uk/ Member of http://www.software.coop/ (but this email is my personal view only)
Re: Testing Discourse for Debian - Moderation concepts
On Wed, Apr 15, 2020 at 03:40:40PM +0200, Ansgar wrote: > On Wed, 2020-04-15 at 08:56 +0100, Neil McGovern wrote: > > The point of the trust levels is to distribute the moderation. Whatever > > metric we come up with, it will involve a certain amount of actually > > using the site, and engaging with the community. > > Looking at some topics on meta.discourse.org, people explicitly use > trust levels as a "reward" tool to increase "user participation" in > some metric. [1] mentions this for example, but it's not the only topic > talking about reward systems or gamification in Discourse. > I think to be accurate, this should be rephrased as "some people, who are not discourse developers explicitly use..." - I know this may seem pedantic, but posting an example of where someone's priorities are doesn't mean that Debian would have the same priorities. > Badges and other systems serve the same purpose. I conceed that it certainly can, but I would ask you to consider that there are also other uses. As the discourse developers themselves have stated, a number of the badges are there to help guide new users on how to use Discourse features, and the badge notifications quickly drop off. Additionally, each badge can be customised and individually enabled/disabled. Note: I am not making a judgement here on the suitability of any particular badge or trying to balance if the badge award system is good or bad. In fact, the *whole thing* can be disabled, or a custom one addeed to encourage people to log in once an hour, or to like every post, should we wish to do so. I simply ask that motivations are not ascribed to what is going on when other possibilities exist. > (I can do those tricks too ;-) SCNR this one time...) > *grins* Neil -- signature.asc Description: PGP signature
Re: Testing Discourse for Debian - Moderation concepts
I reordered the quoted paragraphs to make it more consistent with bottom posting. On Wednesday, April 15, 2020 07:24:03 AM Neil McGovern wrote: > On Wed, Apr 15, 2020 at 12:47:06PM +0200, Ansgar wrote: > No, but it is required for things like knowing which posts in a topic is > popular, so should be used for auto-summary. It also is used to reduce > abuse, as a normal new user would spend time reading topics before > posting for the first time. > > I'm not concerned about marking messages read after some time and > > keeping the view time in ephermal storage for that. But that's not > > what Discourse does: as described elsewhere it stores all read times > > persistently on the server; that would not be neccessary for marking > > posts as read even on a web application. I think I understand what Ansgar wrote here, but I'm not 100% sure. I use kmail with pop3. As far as I know, even if kmail does keep track of my reading time to mark emails as read (which I think I saw as an option once and disabled), I'm pretty sure, and certainly hope that information is stored (or used and discarded "instantly" (for some value of instantly)) only on my local machine. I don't know if the situation is the same if I used imap, but there are several reasons I don't use imap, some relating to privacy issues. To keep that reading time on any kind of central server would be a big invasion of my privacy. I wouldn't mind something like I mentioned in another email, the writer of an email volunteering information about how thoroughly he has read something before replying, but for something to collect my reading time and make inferences about it is not acceptable to me. Oh, and I guess that is the thing that I forgot in that other email -- I might be willing to say that I didn't read an email (TL;DR) before responding, or some variations, that might imply that I tried to read, but don't think I clearly (or fairly?) understood the email I'm replying to, and some others along those lines.
Re: Testing Discourse for Debian - Moderation concepts
On Wednesday, April 15, 2020 03:56:28 AM Neil McGovern wrote: > Could you explain this please? I feel that having a notification (which > only appears for people who regularly interact with the site) that > someone is new to the community to be useful. I am probably going to say more about this in reply to a different post, but, in general, it would be nice to have something to indicate that when someone has responded to a post that they have read (and understood) what they are replying to. Unfortunately, reading time doesn't always do that for various reasons -- I'll cite two: * people read at different speeds * to consider my habits -- I use kmail -- quite often I finish reading one email, move it to a folder (or trash it), or even start reading an email, but then switch desktops and do something else -- I don't know whether kmail keeps track of all the time that particular email was open in kmail and counts that as reading time -- I suspect it does. But I do strongly agree with the sentiment of knowing whether someone has read the entire response or not and reasonably comprehended it and am trying to think of ways to accomplish that. Maybe an approach that somehow required the writer of a reply to add a statement like "I've read the entire email before responding". (Or I guess if they use the "TL;DR" response literally (meaning that they didn't read all or part of the email they are replying to because, from their point of view, it was too long (or too difficult?) to read, then I might choose to either not bother considering their reply, or simply respond with some other acronym -- trying to think of one: * TU;DR (Too Uninformed, Didn't Read)? If anyone thinks this is a good idea, I (and/or they) can try to think of some less incendiary responses, and probably a variety depending on circumstances, e.g.: * TD; DR (Too Disrespectful, by virtue of not having read what they are responding to, Didn't Read) Hmm, I probably should re-read (again) what I've written here, I think I'm forgetting something I meant to say.
Re: Testing Discourse for Debian - Moderation concepts
On Wed, 2020-04-15 at 08:56 +0100, Neil McGovern wrote: > The point of the trust levels is to distribute the moderation. Whatever > metric we come up with, it will involve a certain amount of actually > using the site, and engaging with the community. Looking at some topics on meta.discourse.org, people explicitly use trust levels as a "reward" tool to increase "user participation" in some metric. [1] mentions this for example, but it's not the only topic talking about reward systems or gamification in Discourse. Badges and other systems serve the same purpose. [1] https://meta.discourse.org/t/trust-level-wishlist-items/141349 > > The notifications to welcome new people or that the system hasn't seem > > someone for some time[1] also seem designed to manipulate people into > > spending more time on the system. > > Could you explain this please? I feel that having a notification (which > only appears for people who regularly interact with the site) that > someone is new to the community to be useful. I think "In a nutshell, we use computers to detect the behavior we want to see and then we use people to recognize and reward it" from the post I linked to above explains it well: the system is designed to have people say "welcome back", not because they know them, but because the computer system encourages it to further the goals of the person operating the forum (increase user participation), not because of sincere human interaction. One such system alone is probably not a problem, but taking everything together (trust level as "rewards", badges, scores, like counts, ...), Discourse certainly leaves me with the impression that it is designed to increase participation levels and time spent on the site via psychological tricks and manipulation. I don't use so-called "social" network services like Facebook because I don't like this sort of subtle manipulation, and I probably won't like Discourse much for the same reasons, even though it might be nice to use otherwise as it offers a nice feature set. I have no idea if these reward systems can be turned off for Debian's instance of Discourse. I recognize that other people will like such systems given systems like Facebook, Twitter or daily rewards for mobile games are quite popular, but some other people have mentioned they don't like the gamification aspects either. On the other hand, I like Discourse's feature set so far; the mail integration isn't that great, but at least works for basic interaction. But handling mail is complicated and like other restrictions (offline use) that's probably something I could mostly live with. So to summarize, I think technically Discourse is okay. The "rewards" and related systems would however probably not make me use the system much. Ansgar Likes per Day: 12*π Total Views:∫₋∞ᵀ viewrate(t) dt ≈ 1.3 flocks Average Read Time: 5.321 Imperial minutes, 4.323 metric minutes Total Read Time:6.917 flock Imperial minutes, 5.620 fmm Author's Read Time: Yes #Cats In Author's Room: ~2 Suggested topics: - Debian is testing Discourse [User] https://lists.debian.org/debian-user/2020/04/msg00516.html - What are your thoughts on discourse? [Devel] [Vote] https://lists.debian.org/debian-vote/2020/03/msg00046.html - ITP: python-pydiscourse [Devel] https://lists.debian.org/debian-devel/2020/04/msg00143.html - why dig ? I wanna use nslookup ! [Devel] https://lists.debian.org/debian-devel/2001/04/msg02502.html Want to read more? Browse other recent project topics on https://lists.debian.org/debian-project/2020/04/threads.html or discover all categories on https://lists.debian.org (I can do those tricks too ;-) SCNR this one time...) signature.asc Description: This is a digitally signed message part
Re: Testing Discourse for Debian - Moderation concepts
On 2020-04-15 11:21, Neil McGovern wrote: > Yes. You can subscribe to categories, topics and tags (or combinations > of them). For example, if you only ever care about m68k, you could watch > #m68k and get a notification email for that across all categories. This is pretty nice! Thank you! (Also for your other answers!)
Re: Testing Discourse for Debian - Moderation concepts
On Wed, Apr 15, 2020 at 12:47:06PM +0200, Ansgar wrote: > I'm not concerned about marking messages read after some time and > keeping the view time in ephermal storage for that. But that's not > what Discourse does: as described elsewhere it stores all read times > persistently on the server; that would not be neccessary for marking > posts as read even on a web application. No, but it is required for things like knowing which posts in a topic is popular, so should be used for auto-summary. It also is used to reduce abuse, as a normal new user would spend time reading topics before posting for the first time. > Evolution also keep track of the mouse cursor, but that is something > different from recording clickstreams and evaluating them to increase > user participation as some people do. Your reply seems to put both on > the same level. My point is that it's unhelpful to automatically equate "user tracking" to something undesireable. > > Interestingly, I've generally mixed replying via email with visiting > > the > > site. I would agree that it's not en par with the web UI, but I don't > > think it ever can be, due to email being designed rather differently. > > >From my tries with Discourse, it just silently stripped all quotes out > from the reply. > Perhaps this is: https://meta.discourse.org/t/single-quote-block-dropped-in-email-reply/144802 > Is this documented in some discoverable place or hidden? I've still not > managed to discover any documentation for Discourse targeting the user > (compared to admin or API documentation). > https://discourse.mozilla.org/c/meta/faq/244 Generally, there isn't a central user documentation, because each discourse instacne can be configured quite heavily, depending on each community need. Neil -- signature.asc Description: PGP signature
Re: Testing Discourse for Debian - Moderation concepts
On Wed, 2020-04-15 at 11:21 +0100, Neil McGovern wrote:
> On Wed, Apr 15, 2020 at 11:08:45AM +0200, Martin wrote:
> > On 2020-04-15 08:56, Neil McGovern wrote:
> > > Could I point out that the email program you wrote this message
> > > in is
> > > doing the same?
> >
> > Could you elaborate on that? Ansgar seems to use
> > "User-Agent: Evolution 3.36.1-1"
> > (While I'm using mutt.) How do such UAs track reading behaviour?
>
> Evolution tracks how long you've looked at a message in order to mark it
> read. This is configurable in Preferences -> Mail Preferences -> Mark
> messages read after X seconds. My point is that one cannot simply say
> "user tracking is bad", as it may be required for actual functionality.
> User tracking is also known as "saving state" :)
I'm not concerned about marking messages read after some time and
keeping the view time in ephermal storage for that. But that's not
what Discourse does: as described elsewhere it stores all read times
persistently on the server; that would not be neccessary for marking
posts as read even on a web application.
I feel it dishonest to compare storing data persistently in a database
and evaluating it for statistical purposes (or other analytics that
people come up with to increase participation and measure community
engagement for community building) with keeping data in ephermal
storage for a short while.
Evolution also keep track of the mouse cursor, but that is something
different from recording clickstreams and evaluating them to increase
user participation as some people do. Your reply seems to put both on
the same level.
> > > Quoting does work in most circumstances. Could you explain what
> > > additional funtionality is missing?
> >
> > Speeking for myself, I find the email support in Discourse poor,
> > to the point, that I would not advertise it. It is useful for
> > notifications, but by far not en par with the web UI.
>
> Interestingly, I've generally mixed replying via email with visiting
> the
> site. I would agree that it's not en par with the web UI, but I don't
> think it ever can be, due to email being designed rather differently.
>From my tries with Discourse, it just silently stripped all quotes out
from the reply.
> > After reading more about Discourses many features ("likes"...),
> > this is completely understandable that one cannot mimic one
> > medium via the other. Trying so, will lead only to frustration.
>
> Just on this one, you can a little. Replying with a +1 will turn your
> email into a "like". Currently supported actions are:
> * +1 or like: likes the post
> * watch: watches the topic
> * track: tracks the topic
> * mute: mutes the topic
Is this documented in some discoverable place or hidden? I've still not
managed to discover any documentation for Discourse targeting the user
(compared to admin or API documentation).
Ansgar
Re: Testing Discourse for Debian - Moderation concepts
On Wed, Apr 15, 2020 at 11:08:45AM +0200, Martin wrote:
> On 2020-04-15 08:56, Neil McGovern wrote:
> > Could I point out that the email program you wrote this message in is
> > doing the same?
>
> Could you elaborate on that? Ansgar seems to use
> "User-Agent: Evolution 3.36.1-1"
> (While I'm using mutt.) How do such UAs track reading behaviour?
>
Evolution tracks how long you've looked at a message in order to mark it
read. This is configurable in Preferences -> Mail Preferences -> Mark
messages read after X seconds. My point is that one cannot simply say
"user tracking is bad", as it may be required for actual functionality.
User tracking is also known as "saving state" :)
> > Quoting does work in most circumstances. Could you explain what
> > additional funtionality is missing?
>
> Speeking for myself, I find the email support in Discourse poor,
> to the point, that I would not advertise it. It is useful for
> notifications, but by far not en par with the web UI.
Interestingly, I've generally mixed replying via email with visiting the
site. I would agree that it's not en par with the web UI, but I don't
think it ever can be, due to email being designed rather differently.
> After reading more about Discourses many features ("likes"...),
> this is completely understandable that one cannot mimic one
> medium via the other. Trying so, will lead only to frustration.
Just on this one, you can a little. Replying with a +1 will turn your
email into a "like". Currently supported actions are:
* +1 or like: likes the post
* watch: watches the topic
* track: tracks the topic
* mute: mutes the topic
> Btw. do you know by accident, how I can "lurk" in Discourse via
> email? E.g. Let's say, I'm subscribed to debian-project, but
> only to know what is going on. Can I subscribe to a "category"?
Yes. You can subscribe to categories, topics and tags (or combinations
of them). For example, if you only ever care about m68k, you could watch
#m68k and get a notification email for that across all categories.
Neil
--
signature.asc
Description: PGP signature
Re: Testing Discourse for Debian - Moderation concepts
On 2020-04-15 08:56, Neil McGovern wrote:
> Could I point out that the email program you wrote this message in is
> doing the same?
Could you elaborate on that? Ansgar seems to use
"User-Agent: Evolution 3.36.1-1"
(While I'm using mutt.) How do such UAs track reading behaviour?
> Quoting does work in most circumstances. Could you explain what
> additional funtionality is missing?
Speeking for myself, I find the email support in Discourse poor,
to the point, that I would not advertise it. It is useful for
notifications, but by far not en par with the web UI.
After reading more about Discourses many features ("likes"...),
this is completely understandable that one cannot mimic one
medium via the other. Trying so, will lead only to frustration.
Btw. do you know by accident, how I can "lurk" in Discourse via
email? E.g. Let's say, I'm subscribed to debian-project, but
only to know what is going on. Can I subscribe to a "category"?
Cheers
Re: Testing Discourse for Debian - Moderation concepts
Hi Ansgar, To start with, I want to say that I found your mail to be quite frustrating. I feel it may have been more constructive to phrase concerns as questions, rather than stating them as facts, and ascribing motivations or inferances which simply aren't correct. That said, I'll try and reply to the factual bits. On Tue, Apr 14, 2020 at 02:30:52PM +0200, Ansgar wrote: > The "trust levels" though are one of the features that I don't like: in > particular "Trust Level 3 - Regular" mostly requires to constantly > visit the site every day (or every other day), read x% of all posts and > topics (even though they might not be relevant to your interest or in a > foreign language you don't speak), ... to not get demoted again. This is the default configuration. It can be changed to pretty much any limit we want, including zero. However, I should point out that the additional important abilities gained at this level are that the user can: * Recategorize and rename topics * TL3 spam flags cast on TL0 user posts immediately hide the post * TL3 flags cast on TL0 user posts in sufficient diversity will auto-silence the user and hide all their posts The point of the trust levels is to distribute the moderation. Whatever metric we come up with, it will involve a certain amount of actually using the site, and engaging with the community. > The system also requires tracking active read time and such; I don't > really like a system doing that... Could I point out that the email program you wrote this message in is doing the same? Exactly how this work and the reason for it being required is explained here: https://meta.discourse.org/t/how-does-post-tracking-work-in-discourse/115790 > The notifications to welcome new people or that the system hasn't seem > someone for some time[1] also seem designed to manipulate people into > spending more time on the system. Could you explain this please? I feel that having a notification (which only appears for people who regularly interact with the site) that someone is new to the community to be useful. > The claim of Discourse having an excellent email interface also feels > exagerrated: unless I missed something[2] it seems very basic. One can > send and receive messages, but quoting in replies already doesn't work > as usual and any additional functionality isn't exposed at all as far > as I can tell. Quoting does work in most circumstances. Could you explain what additional funtionality is missing? > > Instead, it 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. > > What decides who is in the moderation team? That seems to be something > different from the trust levels? Yes. At the moment those in the moderation team is... well, me. I would expect to follow something similar to Mozilla: https://discourse.mozilla.org/t/updates-to-moderation-guidelines/2 > I would also expect Discourse to have some way to entirely remove > messages, or at least remove the original content fully and replace it > with a notice that the message was removed; who can do that? Also the > moderation team? Yes, that is correct. Neil -- signature.asc Description: PGP signature
Re: tracking our readers? (Re: Testing Discourse for Debian - Moderation concepts)
Hello Karsten, On Tue 14 Apr 2020 at 06:42PM +02, Karsten Merker wrote: > As a personal note: compared to my email client I find the > discourse web interface very unwieldly and impractical (like most > web forums). This is of course a matter of taste and personal > preferences, but exactly that is an important point. With > mailinglists everybody can use a client that suits one's personal > preferences, while web-based systems inevitably force a > particular user interface onto every user. This one interface > naturally cannot fit everbody's personal preferences and > therefore makes the task of following and taking part in > discussions actually harder for a significant number of people > compared to performing the same tasks on a mailinglist. Just on this point, if there's sufficient API stability, then there is the possibility of developing other clients for Discourse. Making them operable offline would be a lot of work though. -- Sean Whitton signature.asc Description: PGP signature
Re: tracking our readers? (Re: Testing Discourse for Debian - Moderation concepts)
Hello, On Tue 14 Apr 2020 at 08:22AM +00, Holger Levsen wrote: > On Mon, Apr 13, 2020 at 02:31:23PM -0700, Sean Whitton wrote: >> > 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. >> [1] >> https://meta.discourse.org/t/how-does-post-tracking-work-in-discourse/115790 > > thanks for pointing this out, Sean. This makes even using discourse > inaccepable to me, sorry. > > I also wonder where we will store this private data of our users, how > we will protect it and how users can request their data to be deleted. Just a note that the text Holger quoted is from Mathias Behrle's e-mail, not mine -- and he should have credit for having noticed this. I just Googled a bit. -- Sean Whitton signature.asc Description: PGP signature
Re: Testing Discourse for Debian - Moderation concepts
I'd like to echo the comment that requiring people to regularly visit the site does not seem to meet Debian's needs very well for trust. I'd imagine there are a number of people in our community who will tend to read things via email, but who would only visit the site to help moderate--splitting topics, editing things, flagging posts, etc. You can like a post via email. I think it is great to try new things. But I think that biasing the moderation power too much toward people who visit the website would make me uncomfortable trusting the system for important project discussions in ways that a system that allowed all our trusted users to be trusted would not. I absolutely think it is reasonable to require people to become familiar with the site and its capabilities. I think it is reasonable to expect trusted members to understand how this is different from traditional email. But forcing a particular interface on those people seems problematic. From my personal standpoint, the site isn't horrible from an accessibility standpoint, but reading what I can out of email is always going to be more usable for me. I'll go to the site if I need to, but being forced to go to the site to meet some metric is off-pissing. I'm not saying this needs to be addressed prior to experimenting. I'm saying that as an individual I want to see an improvement here prior to depending on this for any important project decisions. --Sam
Re: Testing Discourse for Debian - Moderation concepts
On 2020-04-14 14:30, Ansgar wrote: > That said I'm in principle fine with trying a mostly > web-only system; just like GitLab also really needs to be used over the > web. I'm a salsa.d.o user of course, but how often would I login into the web interface? Once a month? 99 % of the interaction is git push and fetch. I'm happy, that we moved from svn to git, partly because I can do more things offline. While I'm in favour to explore alternatives to email, I don't feel comfortable with anything, that does not support offline usage and that does not work well on the text console. Maybe somebody™ can write a Discourse client? "Discurses"? Something that downloads messages, supports offline reading, answering, editing, "likes" and votes, and uploading results.
Re: Testing Discourse for Debian - Moderation concepts
On Mon, 2020-04-13 at 19:56 +0100, Neil McGovern wrote: > 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. I think some features of Discourse can be useful, for example moving messages to new topic, simple polls (I don't like "like" buttons...), or even editing messages to make the wording clearer instead of sending further follow-up messages. Trying to experiment with Discourse for this seems useful to me. The "trust levels" though are one of the features that I don't like: in particular "Trust Level 3 - Regular" mostly requires to constantly visit the site every day (or every other day), read x% of all posts and topics (even though they might not be relevant to your interest or in a foreign language you don't speak), ... to not get demoted again. It feels more like a customer loyality program to try to bind users to the Discourse service, like rewards for daily visits in mobile games, not anything that implies trust to somehow govern the system. The system also requires tracking active read time and such; I don't really like a system doing that... The notifications to welcome new people or that the system hasn't seem someone for some time[1] also seem designed to manipulate people into spending more time on the system. Such psychological tricks are something I would more expect from Facebook than Debian :-/ [1]: https://discourse.debian.net/t/likes-per-post-ratio/152/2 The claim of Discourse having an excellent email interface also feels exagerrated: unless I missed something[2] it seems very basic. One can send and receive messages, but quoting in replies already doesn't work as usual and any additional functionality isn't exposed at all as far as I can tell. That said I'm in principle fine with trying a mostly web-only system; just like GitLab also really needs to be used over the web. [2]: I couldn't really find much Discourse documentation, even less than for other things in Debian people say are underdocumented. > Instead, it 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. What decides who is in the moderation team? That seems to be something different from the trust levels? I would also expect Discourse to have some way to entirely remove messages, or at least remove the original content fully and replace it with a notice that the message was removed; who can do that? Also the moderation team? Ansgar
Re: Testing Discourse for Debian - Moderation concepts
On Tuesday, April 14, 2020 06:09:48 AM Dan Purgert wrote: > On Apr 14, 2020, to...@tuxteam.de wrote: ... > > This is just the ultra-liberal way to see things. He who owns the > > resources has absolute say on their use. > > "ultra-liberal" -- I don't think that word means what you think it means > > :). As this veers wildly off topic, would you mind explaining this to > > me off-list? I'm interested as well, can it be posted on-list, the subject changed, and be marked OT?
Re: Testing Discourse for Debian - Moderation concepts
On 2020-04-13 23:33, Andy Smith wrote: > Not to speak for Neil, but it's generally argued that private > entities cannot censor, because a nation/state can tell you that you > cannot express an opinion using your own resources. By contrast a > private entity like Debian can only tell you that you cannot express > that opinion using *Debian's* resources: Debian can't prevent you > from publishing it independently, So Debian can't, under this line > of argument, censor you. That's a very strict interpretation that, even though technically possibly correct from a very specific human rights point-of-view, doesn't really match the general, real-world use of the term. For example, the concept of self-censorship clearly exists (eg: film industry), but wouldn't under the above strict interpretation. To emphasize the real-world use of the term, I point to the Wikipedia page for the term [1], which states in its first paragraph that "Censorship can be conducted by governments, private institutions, and corporations." [1] https://en.wikipedia.org/wiki/Censorship
Re: Testing Discourse for Debian - Moderation concepts
On Apr 14, 2020, to...@tuxteam.de wrote: > On Mon, Apr 13, 2020 at 09:33:20PM +, Andy Smith wrote: > > [...] > > > Not to speak for Neil, but it's generally argued that private > > entities cannot censor, because a nation/state can tell you that you > > cannot express an opinion using your own resources. By contrast a > > private entity like Debian can only tell you that you cannot express > > that opinion using *Debian's* resources [...] > > This is just the ultra-liberal way to see things. He who owns the > resources has absolute say on their use. "ultra-liberal" -- I don't think that word means what you think it means :). As this veers wildly off topic, would you mind explaining this to me off-list? -- |_|O|_| |_|_|O| Github: https://github.com/dpurgert |O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5 4AEE 8E11 DDF3 1279 A281 signature.asc Description: PGP signature
Re: tracking our readers? (Re: Testing Discourse for Debian - Moderation concepts)
On Apr 14, 2020, Holger Levsen wrote: > On Mon, Apr 13, 2020 at 02:31:23PM -0700, Sean Whitton wrote: > > > 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. > > [1] > > https://meta.discourse.org/t/how-does-post-tracking-work-in-discourse/115790 > > thanks for pointing this out, Sean. This makes even using discourse > inaccepable to me, sorry. > > I also wonder where we will store this private data of our users, how > we will protect it and how users can request their data to be deleted. The only correct answer is /dev/null. -- |_|O|_| |_|_|O| Github: https://github.com/dpurgert |O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5 4AEE 8E11 DDF3 1279 A281 signature.asc Description: PGP signature
Re: Testing Discourse for Debian - Moderation concepts
On Lu, 13 apr 20, 19:56:28, Neil McGovern wrote: > > 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. How do trust levels work for users interacting mainly (or even exclusively) via mail? Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: tracking our readers? (Re: Testing Discourse for Debian - Moderation concepts)
On Tue, Apr 14, 2020 at 08:22:22AM +, Holger Levsen wrote: > On Mon, Apr 13, 2020 at 02:31:23PM -0700, Sean Whitton wrote: > > > 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. > > [1] > > https://meta.discourse.org/t/how-does-post-tracking-work-in-discourse/115790 > > thanks for pointing this out, Sean. This makes even using discourse > inaccepable to me, sorry. I think the problem isn't tracking itself. I'd trust Debian blindly in that :-) For me, the problem is the kind of anti-pattern promoted by this. > I also wonder where we will store this private data of our users, how > we will protect it and how users can request their data to be deleted. AsI said -- I'd espect Debian to not even collect that data. But even considering use a tool whose makers subscribe to that way of thinking seems iffy to me. Cheers -- tomás signature.asc Description: Digital signature
tracking our readers? (Re: Testing Discourse for Debian - Moderation concepts)
On Mon, Apr 13, 2020 at 02:31:23PM -0700, Sean Whitton wrote: > > 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. > [1] > https://meta.discourse.org/t/how-does-post-tracking-work-in-discourse/115790 thanks for pointing this out, Sean. This makes even using discourse inaccepable to me, sorry. I also wonder where we will store this private data of our users, how we will protect it and how users can request their data to be deleted. -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Testing Discourse for Debian - Moderation concepts
On Mon, Apr 13, 2020 at 09:33:20PM +, Andy Smith wrote: [...] > Not to speak for Neil, but it's generally argued that private > entities cannot censor, because a nation/state can tell you that you > cannot express an opinion using your own resources. By contrast a > private entity like Debian can only tell you that you cannot express > that opinion using *Debian's* resources [...] This is just the ultra-liberal way to see things. He who owns the resources has absolute say on their use. There are other legal systems and points of view. Absolute is almost always wrong :) Cheers -- "all generalizations suck" tomás signature.asc Description: Digital signature
Re: Testing Discourse for Debian - Moderation concepts
On Mon, Apr 13, 2020 at 02:31:23PM -0700, Sean Whitton wrote: > Hello, > > On Mon 13 Apr 2020 at 10:33PM +02, Mathias Behrle wrote: > > > 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. > > It seems this is indeed so.[1][2] I hope that an official Debian > Discourse instance would find a way to turn this off. > > [1] > https://meta.discourse.org/t/how-does-post-tracking-work-in-discourse/115790 > [2] https://meta.discourse.org/t/discourse-new-user-guide/96331 (item 4) Well, this is downright ugly. Didn't know that, thanks for bringing it up. Cheers -- tomás signature.asc Description: Digital signature
Re: Testing Discourse for Debian - Moderation concepts
Hello, On Mon, Apr 13, 2020 at 10:33:25PM +0200, Mathias Behrle wrote: > * Neil McGovern: " Re: Testing Discourse for Debian - Moderation concepts" > (Mon, 13 Apr 2020 19:56:28 +0100): > > 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? Not to speak for Neil, but it's generally argued that private entities cannot censor, because a nation/state can tell you that you cannot express an opinion using your own resources. By contrast a private entity like Debian can only tell you that you cannot express that opinion using *Debian's* resources: Debian can't prevent you from publishing it independently, So Debian can't, under this line of argument, censor you. And if you look back at some of the most vocal critics of Debian recently, they certainly have not been wanting for ways to express their opinions. But on the other hand a lot of people have a much looser definition of censorship which includes "I wanted to say X on site Y, but site Y's admins said I couldn't." Cheers, Andy
Re: Testing Discourse for Debian - Moderation concepts
Hello, On Mon 13 Apr 2020 at 10:33PM +02, Mathias Behrle wrote: > 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. It seems this is indeed so.[1][2] I hope that an official Debian Discourse instance would find a way to turn this off. [1] https://meta.discourse.org/t/how-does-post-tracking-work-in-discourse/115790 [2] https://meta.discourse.org/t/discourse-new-user-guide/96331 (item 4) -- Sean Whitton signature.asc Description: PGP signature
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: Testing Discourse for Debian - Moderation concepts
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 - especially with Debian being a private entity. 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. Secondly, flags. Discourse has the opinion that moderation cannot be proactive with a small group of users - this doesn't scale. Instead, it 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. I hope this explains how I believe that moderation is more powerful on Discourse, but also more practical, transparent and accountable. Neil
