Re: Testing Discourse for Debian - Moderation concepts

[tomas]

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

[Dan Purgert]

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

[Florian Weimer]

* 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

[MJ Ray]

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

[Marco Möller]

On 14.04.20 16:01, Marco Möller wrote:

(...)
If Discourse could be configured towards these ideas, then it would be a 
win for the communication (...)


Following the discussion, having investigated more how discourse 
actually can be used, and also having received and read helpful answers 
on  https://discourse.debian.net  or here in the email threads, I am 
confident that configurations could indeed be tailored to the needs of 
Debian.


As I received the answer, that editing of messages is logged in a way 
that the former content can still be accessed, my initial concerns about 
editing of messages are smoothed already.
And the Trust Level systems and badges also seem to be highly 
configurable, even Debian tailored new plugins seem to be possible.


It opened my eyes to see in the offered test instance of the Discourse 
platform how it could be configured with obviously many default settings 
still in place. Although audacious to ask for it, I will do so: would it 
be possible to provide a second instance "tailored-discourse.debian.net" 
for testing Debian specific configurations? The first instance would 
continue to show what ALL could be possible, and the second instance 
could develop towards a _possible_ consensus? I am aware about the work 
load, I am just asking with the intention to help pushing all the 
discussion forward towards productive steps, so that everybody can see 
more easily what we are actually discussing about.


In a first step I suggest to deactivate and hide almost all the badges 
in order to get the simply cosmetic objections out of the line.
I myself felt immediately annoyed by the many badges, which did not let 
the platform appear to be made for a seriously working community, but 
initially let it appear silly. Now, this is obviously a cosmetic thing 
only, but as it affected me right away in a negative way, it also might 
affect others. So, why not get rid of this first and afterwards add only 
badges again, if it becomes clearer what badges or Trust Levels major 
parts of the community would like to see.
For the beginning I suggest to only stay with badges which indicate the 
amount of allover received Likes for a member's posts, nothing else.


The second step would then be to get email integration configured to the 
maximum possible extend, so that everybody is respected and indeed 
everybody can stay included.


The third step would be to care for the backup, the long term documentation.

The fourth step would be to adjust the message editing and moderation 
possibilities.


The fifth step would be to return to the mailing lists and ask newly if 
a Discourse instance as developed so far would find major support by the 
community.


Meanwhile, as a real world test, discussion about the discourse instance 
under development could mainly be discussed in that instance, where the 
initially in place Like system would show if discussions indeed would 
benefit from it. I am pretty sure that my proposed fourth step is a hot 
candidate for a perfect test scenario.
We would smooth the eyes, we would get some needed technical things set 
up, and then populate the waters in order to see if a shark tank changed 
to a lily pond.

Re: Testing Discourse for Debian - Moderation concepts

[Neil McGovern]

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: "From" at beginning of line gets escaped (was: Re: Testing Discourse for Debian)

[rhkramer]

The following is the text of an email that got generated as I tried to make a 
comment on the bug report you filed.  I'm not sure how soon the comment might 
appear on the bug report, so I decided to add it here as a reply.

I guess I should add one thing, that I presume the people who deal with the 
bug report will recognize: I don't know how much legacy software would be 
affected if the described behavior changed.


#956806 lists.debian.org: changes messages with lines starting with "From", 
breaking DKIM signature
From: rhkra...@gmail.com
  To: 956...@bugs.debian.org
  Date: Wed Apr 15 11:22:37 2020
   
Aside: This may be the first time that I've responded to a Debian bug -- I 
expected that when I clicked on reply, I'd be given a text box on the bug 
report web page to make my comment, instead, I'm apparently writing an email.  
I presume this will get to the right place.

Hmm, I probably should not respond to this as I cannot do a complete or maybe 
even an adequate job.

I do know this.  When mail is stored in an mbox file, From at the beginning of 
a line (admittedly with other requirements after the From) can indicated the 
beginning of an mbox header, which separates one email from another.

A "real" mbox header has other stuff on that line that can and should be parsed 
and considered to determine if it really is an mbox header, but some software 
in the email chain typically escapes a From at the beginning of a line (by 
prefixing it with a >, iirc) to, well, distinguish it from an mbox header and 
make it easier on the mbox software somewhere in the chain.

I'd hesitate to suggest that "feature" should be disabled, there are probably 
lots of places where that would cause a problem.

I don't know if there is another solution.


On Wednesday, April 15, 2020 10:42:10 AM Ansgar wrote:
> On Wed, 2020-04-15 at 20:18 +0900, Charles Plessy wrote:
> > as we discuss about proper quoting, I would like to take the opportunity
> > of Ansgar's email to note that each time a line starts with "From" in a
> > plain text email, something in the pipeline that delivers emails (at
> > least to me) inserts a ">" sign, which is then misinterpreted as a
> > quotation character.  See above…
> 
> Hmm, indeed. And I was wondering what was breaking the DKIM
> signature...
> 
> Looking at the headers of my mail I find:
> | X-Amavis-Spam-Status: No, score=-12.6 required=4.0
> | 
> |  tests=DKIM_INVALID,DKIM_SIGNED,
> 
> with an invalid signature, but below that (earlier in the pipeline)
> 
> this signature was still valid:
> | X-Amavis-Spam-Status: No, score=-8.863 tagged_above=-1 required=5.3
> | 
> |  tests=[BAYES_00=-2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
> |  DKIM_VALID_AU=-0.1,
> 
> So it looks like the lists setup somehow breaks this...
> 
> I reported this problem as https://bugs.debian.org/956806
> 
> Ansgar

"From" at beginning of line gets escaped (was: Re: Testing Discourse for Debian)

[Ansgar]

On Wed, 2020-04-15 at 20:18 +0900, Charles Plessy wrote:
> as we discuss about proper quoting, I would like to take the opportunity
> of Ansgar's email to note that each time a line starts with "From" in a
> plain text email, something in the pipeline that delivers emails (at
> least to me) inserts a ">" sign, which is then misinterpreted as a
> quotation character.  See above…

Hmm, indeed. And I was wondering what was breaking the DKIM
signature...

Looking at the headers of my mail I find:

| X-Amavis-Spam-Status: No, score=-12.6 required=4.0
|  tests=DKIM_INVALID,DKIM_SIGNED,

with an invalid signature, but below that (earlier in the pipeline)
this signature was still valid:

| X-Amavis-Spam-Status: No, score=-8.863 tagged_above=-1 required=5.3
|  tests=[BAYES_00=-2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,

So it looks like the lists setup somehow breaks this...

I reported this problem as https://bugs.debian.org/956806

Ansgar

Re: Testing Discourse for Debian - Moderation concepts

[rhkramer]

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

[rhkramer]

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

[Ansgar]

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

[Martin]

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

[Neil McGovern]

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

[Charles Plessy]

Le Wed, Apr 15, 2020 at 12:47:06PM +0200, Ansgar a écrit :
> 
> >From my tries with Discourse, it just silently stripped all quotes out
> from the reply.

Hello everybody,

as we discuss about proper quoting, I would like to take the opportunity
of Ansgar's email to note that each time a line starts with "From" in a
plain text email, something in the pipeline that delivers emails (at
least to me) inserts a ">" sign, which is then misinterpreted as a
quotation character.  See above…

In that sense, the syntax for quotes in Discourse is perhaps better.  If
mutt would learn to color them in green, that would be enough for me.

Have a nice day,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Akano, Uruma, Okinawa, Japan

Re: Testing Discourse for Debian - Moderation concepts

[Ansgar]

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

[Neil McGovern]

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

[Martin]

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

[Neil McGovern]

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

Real Name was:Re: Testing Discourse for Debian

[Scott Kitterman]

On April 14, 2020 11:12:10 PM UTC, Sean Whitton  
wrote:
>Hello Raphael,
>
>On Tue 14 Apr 2020 at 12:28PM +02, Raphael Hertzog wrote:
...
>
>> He was also concerned with the need to do all work under our real
>> identity. Looking into contributors.d.o and db.debian.org, he might
>> have requested his data to be dropped...
>
>This is a separate issue, surely -- mailing lists do not inherently
>require you to use your real name.

We don't actually have a requirement for that in any case.  We require someone 
in the project know who you are (which I think is a definite minimum standard 
we need to maintain), but there is a process for becoming a member of the 
project without publicly disclosing your identity.  For non-members whose 
contributions are sponsored, we have no requirement even for that.

Scott K

Re: Testing Discourse for Debian

[Sean Whitton]

Hello Raphael,

On Tue 14 Apr 2020 at 12:28PM +02, Raphael Hertzog wrote:

> I remember a discussion with Ryan Murray (who was very involved a long
> time ago!)  and he expressed concerns over our use of email and
> GPG. And the fact that you must share your email to everybody to be
> able to take part into conversations (in particular given how this
> leads to spam).

We share e-mail addresses in changelogs and git commit messages, so I
don't think we're going to be able to do anything about this any time
soon.

> He was also concerned with the need to do all work under our real
> identity. Looking into contributors.d.o and db.debian.org, he might
> have requested his data to be dropped...

This is a separate issue, surely -- mailing lists do not inherently
require you to use your real name.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Testing Discourse for Debian

[Sean Whitton]

Hello,

On Tue 14 Apr 2020 at 01:49PM +01, Neil McGovern wrote:

> On Mon, Apr 13, 2020 at 02:16:48PM -0700, Sean Whitton wrote:
>> Do you think that would end up capturing all discussions, with possibly
>> a few weeks delay?  Is it typical in Discourse use to lock/close threads
>> after a certain point?  And do you think the API is stable enough for us
>> to start doing something like this?
>>
>
> That's entirely dependant on the configuration :) For example, on
> GNOME's Discourse instance, I have a few categories where it is set to
> close 14 days after the last reply.
>
> Then again, people can also request that they're reopened...
>
> I suspect the API should be stable enough for this, if people wanted to
> store discussions in a form that isn't discourse itself.

Based on other posts in the thread it sounds like the API is not
actually stable enough to support this sort of thing, but of course that
could change.

It sounds like we would need to disable the unlocking functionality you
mention in order for offline longterm storage to be feasible.

To be honest, the lack of any proper archival means that I am reluctant
to start any meaningful discussions on the test instance you've set up,
but then it is rather difficult to test whether it's a good platform for
us to have meaningful discussions...

Is it perhaps possible for us to subscribe a mailing list to all posts
from the instance, so that we know that there's a copy somewhere?

On Tue 14 Apr 2020 at 05:17PM +02, Martin wrote:

> On 2020-04-14 15:49, Neil McGovern wrote:
>> If you're using the stable branch of Discourse, then the API is stable
>> :)
>
> Ha! ;-) This leads a little bit off-topic here, maybe it's
> better off-list, on #956705, or elsewhere:
>
> Can I expect API stability cycles of Discourse long enough, that
> it were practical to have a client (library) in stable?

If others share my concerns about posterity then it is not off-topic.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: tracking our readers? (Re: Testing Discourse for Debian - Moderation concepts)

[Sean Whitton]

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: Testing Discourse for Debian

[Sean Whitton]

Hello Andrei,

On Tue 14 Apr 2020 at 09:21AM +03, Andrei POPESCU wrote:

> On Lu, 13 apr 20, 14:23:30, Sean Whitton wrote:
>>
>> (a) would more clearly benefit from having more structure.  It is less
>> clear that (b) would benefit, and (b) benefits from the posting of diffs
>> and replying using inline comments.
>
> It seems like Salsa would be better suited for commenting on actual
> code, though splitting the discussion is obviously not be optimal.

That has the problem of it being difficult to archive those discussions
for posterity.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: tracking our readers? (Re: Testing Discourse for Debian - Moderation concepts)

[Sean Whitton]

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

[Martin]

On 2020-04-14 15:49, Neil McGovern wrote:
> If you're using the stable branch of Discourse, then the API is stable
> :)

Ha! ;-) This leads a little bit off-topic here, maybe it's
better off-list, on #956705, or elsewhere:

Can I expect API stability cycles of Discourse long enough, that
it were practical to have a client (library) in stable?

I'm not talking about one site running on nightlies, but
something serious, e.g. the Gnome instance.

> The documentation is at
> docs.discourse.org.

Nothing shown by default, but when I unblock CDNs, there is a
long "Loading...", then "A script on this page may be busy, or
it may have stopped responding", but finally a download link:

https://docs.discourse.org/swagger.json

In which I read:

> Note: This documentation is not complete, so for missing parts
> you may have to\n[reverse engineer the Discourse API](https://
> meta.discourse.org/t/how-to-reverse-engineer-the-discourse-api
> /20576) to figure out how to use an API endpoint.

My fear is, that an un(der)documented API might also not be
long-term stable, even if such a disclaimer is not present.

Re: Testing Discourse for Debian

[Neil McGovern]

On Tue, Apr 14, 2020 at 03:57:08PM +0200, Martin wrote:
> Is the API stable in general, or only this particular function?

If you're using the stable branch of Discourse, then the API is stable
:)

> I ask in the context of #956705: "ITP: python-pydiscourse --
> Python library for working with Discourse". Upstream says:
> 
> > * Provide functional parity with the Discourse API, for the
> >   currently supported version of Discourse (something of a
> >   moving target)
> >
> > The order here is important. The Discourse API is itself
> > poorly documented
> 

The head version is indeed in flux somewhat, although I'm personally
running the "tests-passed" branch in production with API integrations,
and I've not had any incompatability problems. The documentation is at
docs.discourse.org.
I woudn't say it's poorly documented, but possibly incomplete.

Neil
-- 


signature.asc
Description: PGP signature

Re: Testing Discourse for Debian - Moderation concepts

[Sam Hartman]

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

[Marco Möller]

In order to improve the communication methods, the question is, if 
aspired improvements could be implemented for the email lists or not. If 
they cannot be implemented for the email lists, then improvements are 
unlikely to ever happen unless moving on to another communication 
platform where the improvements are possible.


The very good things already achieved by email lists are:
(1) messages cannot be changed with retrospective effect; all 
discussions stay well documented
(2) the structured view in threads and various search options, as 
usually provided by the mail clients, help to effectively manage the 
vast amount of messages


The things which need improvement are the messages themselves:
(3) quality over quantity
(4) more feedback without unnecessarily texting

To this regard, addressing (3) and (4) at the same time by the same 
measure, various platforms introduced a scoring system for messages by 
analyzing the explicitly provided reader's feedback about the quality of 
messages and also building up a reputation score for the author. If the 
scoring algorithm is well selected, then an improvement of communication 
is indeed achieved by steadily stimulating the community to please not 
shine through by the number of comments but to instead search for 
satisfying reputation by considerably adding information to the topics.


Now, could the feedback be collected by a mailing list, and could each 
message come accompanied by some reputation score? I doubt so. If the 
list server would add a score to the mail subject, then the email client 
would no more be able to view messages threaded, and if the score is not 
added there, then the user will not have the score information available 
at a glance. But without the score, no improvement of the communication 
is systematically stimulated.


Could Discord (or other contenders) achieve this? Concerns (3) and (4) 
are addressed at the push of a button by what you could call an 
"Upvote", "Like", "Helpful", or alike feedback mechanism.
Concern (2) is addressed for the web interface, and an email interface 
seems to be available for those who prefer this and could accept to stay 
without the steady reputation stimulus.


Could Discord (or other contenders) achieve (1) ?   I don't know.


In my opinion an improvement in communication would result from a 
reputation generating scoring system, IF relying on an algorithm tuned 
for quality in community participation. The default Trust Levels as 
offered by Discourse are tuned for the opposite! They do not only rate 
higher the amount of participation, the frequency of input from 
chatterers, than the quality of participation, but even assign to 
members with a higher score the right to edit the messages of others! 
This violates above mentioned point (1) unless there would be a 
possibility to reliably configure this towards the real needs of Debian.
The same need for a strongly adopted configuration targets the absurd 
and ludicrous default set of "badges".


I suggest to have only one required badge available, and this to always 
overlay to the avatar in order to be visible at a glance for each single 
message displayed in the web interface: the score for the “Likes:Post 
ratio” (or something similar pointing towards a quality:quantity ratio 
of a member’s posts). The scoring algorithm could produce the integer 
numbers 0 to 9, normalizing to the member with the best ratio receiving 
a 9, and in general only placing a score number if the member has posted 
already 20 posts. If in a rush browsing for some fast help to a problem 
and not out for reading seesaw discussions about the preferences in the 
personal workflow of some individuals, then I would find some kind of 
guide in it for where it might be worth to start or stop reading a 
thread. Finally I could honor the seminal messages by myself providing 
my feedback at a push of a button. It would be helpful if a member "A" 
is limited to not honor more than 20 messages of a member "B" in order 
to prevent bias from personal friendships, and it would be great if 
reputation scores could be calculated for each topical channel individually.


But trust levels which allow for editing posts are VERY problematic, 
especially in the Debian community! Maybe allow to the original editor 
of a post to correct its post in a short time window AND as long as no 
reply was posted - for correcting of typos and alike. But beyond this I 
doubt that giving somebody the possibility to edit a post - even if in 
practice never becoming used - would destroy confidence in the medium 
for discussing issues. The already difficult mixture of characters 
making up Debian would not receive help by using such medium, but would 
divide even more, if someone could impute message editing to some other 
person.


If Discourse could be configured towards these ideas, then it would be a 
win for the communication, if not then it would simply be another 
platform but not an improvement 

Re: Testing Discourse for Debian

[Martin]

On 2020-04-14 13:49, Neil McGovern wrote:
> I suspect the API should be stable enough for this, if people wanted to
> store discussions in a form that isn't discourse itself.

Is the API stable in general, or only this particular function?
I ask in the context of #956705: "ITP: python-pydiscourse --
Python library for working with Discourse". Upstream says:

> * Provide functional parity with the Discourse API, for the
>   currently supported version of Discourse (something of a
>   moving target)
>
> The order here is important. The Discourse API is itself
> poorly documented

Maybe the README is just outdated.

Re: Testing Discourse for Debian - Moderation concepts

[Martin]

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

[Neil McGovern]

On Mon, Apr 13, 2020 at 02:16:48PM -0700, Sean Whitton wrote:
> Do you think that would end up capturing all discussions, with possibly
> a few weeks delay?  Is it typical in Discourse use to lock/close threads
> after a certain point?  And do you think the API is stable enough for us
> to start doing something like this?
> 

That's entirely dependant on the configuration :) For example, on
GNOME's Discourse instance, I have a few categories where it is set to
close 14 days after the last reply.

Then again, people can also request that they're reopened...

I suspect the API should be stable enough for this, if people wanted to
store discussions in a form that isn't discourse itself.

Neil


signature.asc
Description: PGP signature

Re: Testing Discourse for Debian - Moderation concepts

[Ansgar]

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

[rhkramer]

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

[Christian Kastner]

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

[Raphael Hertzog]

On Mon, 13 Apr 2020, Steve McIntyre wrote:
> Hell, there's a strong confirmation bias here too - how many
> potentially great future developers have we lost at a very early stage
> because our email-centric workflow didn't appeal to them initially?

We already lost existing Debian developers due to this. I remember a
discussion with Ryan Murray (who was very involved a long time ago!)
and he expressed concerns over our use of email and GPG. And the fact
that you must share your email to everybody to be able to take part
into conversations (in particular given how this leads to spam).

He was also concerned with the need to do all work under our real
identity. Looking into contributors.d.o and db.debian.org, he might
have requested his data to be dropped...

Email mailing lists are driving some people away. It's a fact.
Web forum discussions are also driving some people away. I'm an email
guy too, but I find discourse really interesting and I'm ready to give it
a try (even if I'm above 40!).

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: Testing Discourse for Debian - Moderation concepts

[Dan Purgert]

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)

[Dan Purgert]

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

[Andrei POPESCU]

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)

[tomas]

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)

[Holger Levsen]

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

[tomas]

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

[tomas]

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

[Andrei POPESCU]

On Lu, 13 apr 20, 15:23:28, Dan Purgert wrote:
> On Apr 13, 2020, Russ Allbery wrote:
> 
> The thing with the "newer" projects that I've seen (and maybe I'm just a
> curmudgeon trapped in a young person's body) is that they come off to me
> as the early dotcom "exactly like X, except on the internet!" stuff.  
> 
> > Now, in a lot of cases the real conversation happens on GitHub, which
> > isn't exactly the same thing as a forum.  But forums seem to play a large
> > role in some of the more vibrant communities (Rust, for instance).
> 
> Haven't really gone there - I have noticed a lot of forums in regards to
> microcontrollers; but I tend to just leech off of them as I can't stand
> the whole "5th post on basically the same subject on the first page"
> garbage that (beginner) fora tend to cultivate.

Forums probably qualify for "like e-mail, except on the web", as they 
don't bring enough advantages to make them significantly better than 
e-mail.

Discourse does have some advantages over forums.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Testing Discourse for Debian

[Andrei POPESCU]

On Lu, 13 apr 20, 14:23:30, Sean Whitton wrote:
> 
> (a) would more clearly benefit from having more structure.  It is less
> clear that (b) would benefit, and (b) benefits from the posting of diffs
> and replying using inline comments.

It seems like Salsa would be better suited for commenting on actual 
code, though splitting the discussion is obviously not be optimal.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Testing Discourse for Debian - Moderation concepts

[Andy Smith]

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

[Sean Whitton]

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

[Sean Whitton]

Hello,

On Mon 13 Apr 2020 at 04:54AM +09, Charles Plessy wrote:

> Le Sat, Apr 11, 2020 at 03:05:12PM -0700, Sean Whitton a écrit :
>>
>> For any technical topic (including DEPs) it is important that we can
>> find old discussions in the future, easily, and without there being too
>> many entrypoints into the search.
>
> Hi Sean,
>
> in my experience of DEP driver and Policy editor, long discussion
> archives, especially when they spread over multiple years, are a barrier
> to contribution.  Not only they are increadibly noisy (think for
> instance of discussion archives in the BTS mostly made of quotes of the
> previous messages), but also they are not even comprehensive (for
> instance when part of the discussion happens on IRC or at Debconf).
>
> In that sense, I would expect structured discussion systems such as
> Discourse to be a potential time saver, and therefore lower the barrier
> for contribution to everybody: those who contribute their point of view,
> and those who summarise them.

I agree that it could be useful to impose more structure on archived
discussions than we can do at present.  From other posts in the thread,
it sounds like it might be possible to do this using some sort of
Discourse API-to-mbox scraper, though this software does not exist yet.

Thinking about Policy in particular, it would seem that bugs divide into
(a) coming up with a proposal which has consensus; and (b) coming up
with Policy text.

(a) would more clearly benefit from having more structure.  It is less
clear that (b) would benefit, and (b) benefits from the posting of diffs
and replying using inline comments.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Testing Discourse for Debian

[Sean Whitton]

Hello,

On Mon 13 Apr 2020 at 08:38PM +01, Neil McGovern wrote:

> On Sun, Apr 12, 2020 at 07:39:34PM +0200, Enrico Zini wrote:
>> Does Discourse have some kind of export feature, that one could
>> postprocess to get for example a mailbox of annotated emails?
>>
>
> Yes, though I think there's just automated ways of doing this for the
> entire database, or for your *own* data at the moment. It would be
> fairly trivial to do this yourself though, as Discoruse is primarily two
> things:
> 1) An API
> 2) A webpage that consumes that API.
>
> If you can do it via the web, you can do it via the API.

Great!  Assuming the API is sufficiently stable, we could start
archiving locked/closed threads to monthly mboxes on master.d.o

Do you think that would end up capturing all discussions, with possibly
a few weeks delay?  Is it typical in Discourse use to lock/close threads
after a certain point?  And do you think the API is stable enough for us
to start doing something like this?

Thank you for your input.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Testing Discourse for Debian

[Sean Whitton]

Hello,

On Sun 12 Apr 2020 at 07:39PM +02, Enrico Zini wrote:

> Things that the current list discussion doesn't easily give:
>
>  - +1 kind of feedback, or simple agreement, tends to unexpressed:
>people only reply if they have a problem with things, and shut up
>otherwise.
>
>For example, the recent Salsa as OIDC provider discussion had a
>relatively small amount of people contributing: does it mean that a
>lot of people just agree, or does it mean that only few people care?
>
>Silent assent and only negative feedback is a very demotivating
>process to go through putting a proposal up for discussion.

That makes sense.  Thanks.  I do not find "+1" feedback particular
valuable in most contexts, but I understand your explanation for how
it could be valuable and am grateful for it.

>  - Some kind of weighting of posts. Sometimes I wonder: "is it just me,
>or this objection is not that relevant?", and I have no real way to
>know, besides maybe polling my social bubble, which could be biased.
>
>Ranking of perceived importants of topics or aspects discussed might
>have helped me manage the energy I put into the whole discussion,
>going into more detail where I could see there was more interest or
>concern.

Well, I for one trust your judgement as to whether the objection is
relevant :)  But indeed, if you didn't have to spend the time making
that judgement, it would be beneficial.

>> I am concerned that the problem is basically a social one, and so cannot
>> be solved just by using a different software stack to host discussions.
>
> Ish. I think there are may social aspects involved, and the same time
> the process that we currently use has technical or traditional limits
> which filter against various kinds of feedback which people would
> socially be happy to give.
>
> I follow list discussions and some messages make me go "yay! Standing
> ovation!" and some messages I skip after reading part of the first line,
> and some messages make me furious. Socially we might able to express
> that in a way that feeds into the quality and direction of discussions,
> but technically, we currently cannot.

Let me say a bit more.  I tend to think that the bad threads we have are
mainly due to limitations in our communicative skills.  We do not always
succeed in saying what is worth saying in as few words as possible. And,
you can't solve a problem which is due to a lack of human skill by
writing software.

I am open to the possibility that this is not the right perspective to
have.  I have a bias towards assuming that communicative and
informational problems are caused by people not behaving skillfully
enough, when the cause is not otherwise clear.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Testing Discourse for Debian

[Scott Kitterman]

On Monday, April 13, 2020 3:38:45 PM EDT Neil McGovern wrote:
> On Sun, Apr 12, 2020 at 07:39:34PM +0200, Enrico Zini wrote:
> > Does Discourse have some kind of export feature, that one could
> > postprocess to get for example a mailbox of annotated emails?
> 
> Yes, though I think there's just automated ways of doing this for the
> entire database, or for your *own* data at the moment. It would be
> fairly trivial to do this yourself though, as Discoruse is primarily two
> things:
> 1) An API
> 2) A webpage that consumes that API.
> 
> If you can do it via the web, you can do it via the API.

For me, having an equivalent to lists.debian.org archive is critical.  I 
routinely go there to find posts on lists to which I am not subscribed.  

I've only used discourse a little for upstream Python things and I haven't had 
much luck with understanding the structure of things so I can find them later.

I don't keep my own archives of all the Debian mailing lists and I certainly 
wouldn't do it for something new.

And yes, I'm not in the demographic that's impressed by these shiny new toys.  
I still have yet to figure out any meaningful advantage Slack has over IRC 
despite having worked on projects where I had to use it a lot.

Scott K

signature.asc
Description: This is a digitally signed message part.

Re: Testing Discourse for Debian - Moderation concepts

[Mathias Behrle]

* 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

[Sean Whitton]

Hello Ihor,

On Sun 12 Apr 2020 at 05:12PM -07, Ihor Antonov wrote:

> I much more like what https://sourcehut.org is doing. They are working on
> improving email workflows without forcing users into web browsers and I think
> this is something we should do to.

It is worth noting that Sourcehut is focusing on using e-mail for purely
technical discussions, such as review of patches by others with the
relevant highly specialised knowledge.

I think Debian is mostly interested in an alternative to mailing lists
for other sorts of discussions, at least at first.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Testing Discourse for Debian

[Dan Purgert]

On Apr 13, 2020, Russ Allbery wrote:
> Dan Purgert  writes:
> 
> > I think your younger colleagues are perhaps in a similar situation as me
> > then -- the first place they've experienced *real* email volumes is at
> > their first actual professional position; and they don't know how to
> > cope with *everything* being placed into their inbox. I mean, I can't
> > think of any other time before "work" wherein I was getting more than a
> > handful of "important[1]" emails per day; and now I'm suddenly in a
> > position where 30 people all have something "important[2]" to send me.
> 
> I have had this conversation with people before about filtering.  The
> valuable counterpoint is "rather than investing time and effort into
> filtering email into buckets and then working out a strategy for when to
> read those buckets, how about instead we adopt a system that discourages
> people from filling my inbox with crap, and instead allows me to find that
> information when I need it rather than broadcasting it to the world just
> in case?"

It's certainly a good question.  In my case, the "different buckets" are
for "different projects", and as such, "different people external to my
employer, who don't have access to our systems ... and shouldn't be
trusted making tickets in any capacity in the first place."

The company has tried it in the past; but it has usually resulted in
more behind-the-scenes work to delete the few thousand incorrectly made
tickets that blow up the monthly metrics and cost more to correct than a
couple more (American/Western European) tier-1 desk people manning the
phones.

Granted, there might be something better on the project side than
"email"; but honestly, with as much trouble as we have getting on
$external_conf_platform (other than the ones that offer dial-in
numbers), I'd honestly rather just stick to the "unmodern" email and
telephone.

> 
> It's rather hard to argue with that.  My current employer uses email so
> little that at least half the time I go more than a day without bothering
> to open my work email.  All the important stuff is in a ticket system, on
> pull requests, or in tech notes that are indexed and searchable.  I
> haven't missed the email at all.

For the teams that use those platforms, they're absolutely wonderful;
and between groups within our company, we use them pretty regularly
(well, I don't - I'm one of the few teams that doesn't use "ticket
bucket" as a definition of "today's work"; but I fully admit and
understand that I am the oddity here).

> 
> I too am very proud of my email filters, but the best email filters are
> the ones that prevent the email from being sent in the first place.

Well, I mean, I'm totally for getting rid of all users too; but then I
wouldn't be getting paid :)

-- 
|_|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 - Alternate interactions

[Russ Allbery]

Ihor Antonov  writes:

> I do apologize if I came across offensively in this thread. English is
> not my native language and often I lack communication skills to express
> what I want in a less blunt way. And often re-reading my own emails It
> picture myself as an angry enraged, which is not how it really is :) On
> top of that I tend to get carried away with metaphors, which was aptly
> noted by Russ.

Thank you very much for saying this, and no worries at all here.  I know
all too well how sometimes I run away with a figure of speech in the
middle of writing a message.

I completely understand your reluctance to assume that everyone has
Firefox or Chrome and wants to interact with a web site.  And I also do
appreciate people watching out for overuse of moderation!  I personally
don't think Debian is likely to have that problem, but other organizations
have, and it's always worth being thoughtful about.

-- 
Russ Allbery (r...@debian.org)  

Re: Testing Discourse for Debian

[Russ Allbery]

Dan Purgert  writes:

> I think your younger colleagues are perhaps in a similar situation as me
> then -- the first place they've experienced *real* email volumes is at
> their first actual professional position; and they don't know how to
> cope with *everything* being placed into their inbox. I mean, I can't
> think of any other time before "work" wherein I was getting more than a
> handful of "important[1]" emails per day; and now I'm suddenly in a
> position where 30 people all have something "important[2]" to send me.

I have had this conversation with people before about filtering.  The
valuable counterpoint is "rather than investing time and effort into
filtering email into buckets and then working out a strategy for when to
read those buckets, how about instead we adopt a system that discourages
people from filling my inbox with crap, and instead allows me to find that
information when I need it rather than broadcasting it to the world just
in case?"

It's rather hard to argue with that.  My current employer uses email so
little that at least half the time I go more than a day without bothering
to open my work email.  All the important stuff is in a ticket system, on
pull requests, or in tech notes that are indexed and searchable.  I
haven't missed the email at all.

I too am very proud of my email filters, but the best email filters are
the ones that prevent the email from being sent in the first place.

-- 
Russ Allbery (r...@debian.org)  

Re: Testing Discourse for Debian - Alternate interactions

[Ihor Antonov]

On Monday, April 13, 2020 12:20:28 PM PDT Neil McGovern wrote:

> There is a commitment to improve the email integration from at least one
> Discourse employee, who also happens to be a Debian Developer. I but do
> 
> want to emphasise the point I made in my original mail:
> > It should be noted however, that there is not 1:1 feature partiy with
> > email and the web interface, as Discorse does things that can't easily
> > be done with email. For the majority of users though, email
> > interaction should be "good enough".
> 
> Neil

Thanks for following up, Neil.

I do apologize if I came across offensively in this thread. English is not my 
native language and often I lack communication skills to express what I want 
in a less blunt way. And often re-reading my own emails It picture myself as 
an angry enraged, which is not how it really is :) On top of that I tend to 
get carried away with metaphors, which was aptly noted by Russ.

Considering everything said about Discourse it sounds like it might be 
possible to make mailing list and Discourse web interface co-exist 
(technically Mailman server is going to be replaced by Discourse) and it 
indeed may provide more visibility into moderation.

I care about opening web browser less often as I have emails from multiple 
projects in one convenient Kmail inbox, so if this introduction of Discourse  
will not force me to change that I have nothing to object personally.

Although the tendency of everything migrating to browsers with javascripts 
does worry me, but I think this as off-topic for this conversation.

Thanks.

-- 
Ihor Antonov
https://useplaintext.email

Re: Testing Discourse for Debian

[Neil McGovern]

On Sun, Apr 12, 2020 at 07:39:34PM +0200, Enrico Zini wrote:
> Does Discourse have some kind of export feature, that one could
> postprocess to get for example a mailbox of annotated emails?
> 

Yes, though I think there's just automated ways of doing this for the
entire database, or for your *own* data at the moment. It would be
fairly trivial to do this yourself though, as Discoruse is primarily two
things:
1) An API
2) A webpage that consumes that API.

If you can do it via the web, you can do it via the API.

Neil
-- 


signature.asc
Description: PGP signature

Re: Testing Discourse for Debian

[Dan Purgert]

On Apr 13, 2020, Russ Allbery wrote:
> Dan Purgert  writes:
> 
> > Who makes up the "younger" crowd?  sub 30? sub 20? I mean, I personally
> > was in my mid-20s when I first started using Linux (college), and I had
> > otherwise only been introduced to the internet via AOL.
> 
> Sub 30 was what I was thinking of.  I'm only saying there's a bit of a
> statistical tendency, not that this applies to everyone, obviously.  But
> when I look around at the broader development world, the majority of the
> newer projects seem to not use email at all.  Even when they do, it's not
> where the most useful conversation happens.

Ah, guess I'm just old enough to miss that mark (although, I still do
tend to fall into the "younger" part of the Linux crowd).

The thing with the "newer" projects that I've seen (and maybe I'm just a
curmudgeon trapped in a young person's body) is that they come off to me
as the early dotcom "exactly like X, except on the internet!" stuff.  

> 
> Now, in a lot of cases the real conversation happens on GitHub, which
> isn't exactly the same thing as a forum.  But forums seem to play a large
> role in some of the more vibrant communities (Rust, for instance).

Haven't really gone there - I have noticed a lot of forums in regards to
microcontrollers; but I tend to just leech off of them as I can't stand
the whole "5th post on basically the same subject on the first page"
garbage that (beginner) fora tend to cultivate.

> [...]
> Professionally, I can tell you that my younger colleagues tend to hate
> email and far prefer other communication mechanisms, and that's not
> because they're unaware of how email is used.  The most commonly stated
> reason is that email is full of noise and pointless messages that aren't
> worth reading, compared to other approaches.  That's just anecdotes, not
> data, obviously, but it made me curious to understand what I might be
> missing.  (My past experience is that when younger colleagues get excited
> about a new way of doing things, I should pay attention, because there are
> probably things that I'm missing and that I will appreciate if I look into
> them more deeply.)

I think your younger colleagues are perhaps in a similar situation as me
then -- the first place they've experienced *real* email volumes is at
their first actual professional position; and they don't know how to
cope with *everything* being placed into their inbox. I mean, I can't
think of any other time before "work" wherein I was getting more than a
handful of "important[1]" emails per day; and now I'm suddenly in a
position where 30 people all have something "important[2]" to send me.

It took me several years to finally get an organization system in place
that made the volume not so distracting -- and the first indication my
initial scheme wasn't as good as it could be was seeing an older
colleague's inbox hierarchy (granted, I had a leg up on some other young
people in that I had already been involved with mailing lists in the
past -- my solution just wasn't as refined as it could have been,
because, well work is outlook, and I was a thunderbird guy, so ... )


[1] As in "I need to do something with this"
[2] As in "Probably not directly for me, but I should have a passing
familiarity in case bossman asks"

-- 
|_|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 - Alternate interactions

[Neil McGovern]

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:
> - There are only 2 browsers out there in existence (Firefox and Chrome
> variants) and duopoly in browser market is already alarming enough.
> There are much more email clients available.
> 

I have tried Epiphany, which works fine for reading and replying.
I have tried with dillo and lynx, which work fine without Javascript
enabled at all for reading.

You can also interact with Discourse via email.

> 2. I can't now use email the way I did. Discord's email interface is
> subpar in spite of what sales people tell you. So If I want "a
> first-class citizen" experience I am stuck with option 1 
> 

This is correct. Discourse interaction by email can never be as good as
interacting with it via a fully featured web browser. This is because,
well, email isn't a fully featured web browser.

There is a commitment to improve the email integration from at least one
Discourse employee, who also happens to be a Debian Developer. I but do
want to emphasise the point I made in my original mail:
> It should be noted however, that there is not 1:1 feature partiy with
> email and the web interface, as Discorse does things that can't easily
> be done with email. For the majority of users though, email
> interaction should be "good enough".

Neil

Re: Testing Discourse for Debian

[Steve McIntyre]

On Mon, Apr 13, 2020 at 10:51:21AM -0700, Russ Allbery wrote:
>
>Sub 30 was what I was thinking of.  I'm only saying there's a bit of a
>statistical tendency, not that this applies to everyone, obviously.  But
>when I look around at the broader development world, the majority of the
>newer projects seem to not use email at all.  Even when they do, it's not
>where the most useful conversation happens.
>
>Now, in a lot of cases the real conversation happens on GitHub, which
>isn't exactly the same thing as a forum.  But forums seem to play a large
>role in some of the more vibrant communities (Rust, for instance).

There was a good talk about this topic at FOSDEM this year:

  https://fosdem.org/2020/schedule/event/nextgencontributors/

>> There is something to be said for educating "younger people" with the
>> old ways -- I mean how many of these "Modern" things are just
>> re-implementations of what previously existed (except with centralized
>> control and "oh yeah, pay us").
>
>This may be the case, but I think those of us who are familiar with email
>have a bit of a tendency (I'm *definitely* including myself in this) to
>jump straight to "let me explain to you how email already does everything
>you want if you just use it properly" without bothering to ask people what
>features they like and really listen to them.
>
>Professionally, I can tell you that my younger colleagues tend to hate
>email and far prefer other communication mechanisms, and that's not
>because they're unaware of how email is used.  The most commonly stated
>reason is that email is full of noise and pointless messages that aren't
>worth reading, compared to other approaches.  That's just anecdotes, not
>data, obviously, but it made me curious to understand what I might be
>missing.  (My past experience is that when younger colleagues get excited
>about a new way of doing things, I should pay attention, because there are
>probably things that I'm missing and that I will appreciate if I look into
>them more deeply.)

Nod. Much as we're comfortable and happy with email, it's important to
keep open-minded and be ready to evaluate other things too. Just
because we happen to like it now, that doesn't mean it's guaranteed to
be the best possible way to communicate *ever*.

Hell, there's a strong confirmation bias here too - how many
potentially great future developers have we lost at a very early stage
because our email-centric workflow didn't appeal to them initially?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
You raise the blade, you make the change... You re-arrange me 'til I'm sane...

Re: Testing Discourse for Debian - Moderation concepts

[Neil McGovern]

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

Re: Testing Discourse for Debian

[Neil McGovern]

On Mon, Apr 13, 2020 at 04:54:28AM +0900, Charles Plessy wrote:
> In that sense, I would expect structured discussion systems such as
> Discourse to be a potential time saver, and therefore lower the barrier
> for contribution to everybody: those who contribute their point of view,
> and those who summarise them.
> 

Just on this point, Discourse has an auto-summarise feature. This isn't
meant to replace a human summary creator, but should help with
megathreads and save people time.

For example:
https://meta.discourse.org/t/feedback-on-new-hamburger-and-user-menus/32519
has 231 posts, and an estimated read time of 29 minutes. If you click on
"Summarize this Topic", it drops that down to less than 50 posts.

Neil
-- 


signature.asc
Description: PGP signature

Re: Testing Discourse for Debian

[Russ Allbery]

Dan Purgert  writes:

> Who makes up the "younger" crowd?  sub 30? sub 20? I mean, I personally
> was in my mid-20s when I first started using Linux (college), and I had
> otherwise only been introduced to the internet via AOL.

Sub 30 was what I was thinking of.  I'm only saying there's a bit of a
statistical tendency, not that this applies to everyone, obviously.  But
when I look around at the broader development world, the majority of the
newer projects seem to not use email at all.  Even when they do, it's not
where the most useful conversation happens.

Now, in a lot of cases the real conversation happens on GitHub, which
isn't exactly the same thing as a forum.  But forums seem to play a large
role in some of the more vibrant communities (Rust, for instance).

> There is something to be said for educating "younger people" with the
> old ways -- I mean how many of these "Modern" things are just
> re-implementations of what previously existed (except with centralized
> control and "oh yeah, pay us").

This may be the case, but I think those of us who are familiar with email
have a bit of a tendency (I'm *definitely* including myself in this) to
jump straight to "let me explain to you how email already does everything
you want if you just use it properly" without bothering to ask people what
features they like and really listen to them.

Professionally, I can tell you that my younger colleagues tend to hate
email and far prefer other communication mechanisms, and that's not
because they're unaware of how email is used.  The most commonly stated
reason is that email is full of noise and pointless messages that aren't
worth reading, compared to other approaches.  That's just anecdotes, not
data, obviously, but it made me curious to understand what I might be
missing.  (My past experience is that when younger colleagues get excited
about a new way of doing things, I should pay attention, because there are
probably things that I'm missing and that I will appreciate if I look into
them more deeply.)

-- 
Russ Allbery (r...@debian.org)  

Re: Re: Testing Discourse for Debian

[tomas]

On Mon, Apr 13, 2020 at 09:33:27AM -0400, Dan Purgert wrote:

[...]

> > In-reply-to header of your mail, then ;-D
> 
> Drat, didn't realize that didn't pull in :( ; sorry for the gaffe. 

;-D

> > Brought to you by some dinosaur
> 
> I should be getting off your lawn then, right?

:-)

Had I a lawn, and in less strange times than currently, I'd be glad
to invite you to a glass of wine there.

Cheers
-- t


signature.asc
Description: Digital signature

Re: Re: Testing Discourse for Debian

[Dan Purgert]

On Apr 13, 2020, to...@tuxteam.de wrote:
> On Mon, Apr 13, 2020 at 08:46:02AM -0400, Dan Purgert wrote:
> > On April 12, 2020, Russ Allbery wrote:
> > > [...]
> > > There is some age correlation with the type of communication mechanism
> > > one is comfortable with [...]
> 
> > Who makes up the "younger" crowd? [...]
> 
> > (Aside, apologies if this is goofy / breaks threading - I had to pull
> > the reply-to out of lists.debian.org)
> 
> At least copy the Message-id from https://lists.debian.org into the
> In-reply-to header of your mail, then ;-D

Drat, didn't realize that didn't pull in :( ; sorry for the gaffe. 

> 
> Brought to you by some dinosaur

I should be getting off your lawn then, right?




-- 
|_|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: Re: Testing Discourse for Debian

[tomas]

On Mon, Apr 13, 2020 at 08:46:02AM -0400, Dan Purgert wrote:
> On April 12, 2020, Russ Allbery wrote:
> > [...]
> > There is some age correlation with the type of communication mechanism
> > one is comfortable with [...]

> Who makes up the "younger" crowd? [...]

> (Aside, apologies if this is goofy / breaks threading - I had to pull
> the reply-to out of lists.debian.org)

At least copy the Message-id from https://lists.debian.org into the
In-reply-to header of your mail, then ;-D

Brought to you by some dinosaur

Cheers
-- t


signature.asc
Description: Digital signature

Re: Re: Testing Discourse for Debian

[Dan Purgert]

On April 12, 2020, Russ Allbery wrote:
> [...]
> There is some age correlation with the type of communication mechanism
> one is comfortable with, and reason to believe that younger people
> skew towards being more comfortable with forums than with email.

Who makes up the "younger" crowd?  sub 30? sub 20? I mean, I personally
was in my mid-20s when I first started using Linux (college), and I had
otherwise only been introduced to the internet via AOL.

Learning that there was so much more beyond "AOL Keywords" took a while
(and then that there was stuff even older took even longer); but I
eventually stumbled upon things like Usenet and mailing lists -- and I'm
personally finding that, once the rules are ingrained; they are
significantly more comfortable to use than the "Modern(tm)"
alternatives.

There is something to be said for educating "younger people" with the
old ways -- I mean how many of these "Modern" things are just
re-implementations of what previously existed (except with centralized
control and "oh yeah, pay us").

(Aside, apologies if this is goofy / breaks threading - I had to pull
the reply-to out of lists.debian.org)


-- 
|_|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

[tomas]

On Mon, Apr 13, 2020 at 06:55:25AM +0100, Marcin Kulisz wrote:

[Gigantic quote elided]

> This is not true, and this email is proof of this

What is "this", and then... what is "this"? And "this"?

One of the nicest things in (nearly lost) mails and usenet
culture is the right quoting style.

If you (as you did) copy the entirety of the message you
are replying to and then say "this" (as you did three
times in that short sentence of yours), your readers are
guaranteed to not understand what you are talking of.

Care to explain?

Cheers
-- tomás


signature.asc
Description: Digital signature

Re: Testing Discourse for Debian

[Marcin Kulisz]

On 12 April 2020 22:43:31 BST, Ihor Antonov  wrote:
>On Sunday, April 12, 2020 1:15:23 PM PDT Russ Allbery wrote:
>
>> 1. A database-driven discussion system that supports updates lets you
>go
>>beyond the moderation that you're worried about (rejecting
>messages)
>>and do other forms of moderation that help improve the quality of
>>discussion without removing messages.  Examples include splitting
>>threads that have digressed from the original topic to create more
>>focused discussions, pinning important summaries so that people
>see the
>>current status of the discusison quickly, closing old threads so
>that
>>people properly open a new discussion instead of replying to some
>>resolved discussion with a different problem, and even just
>sorting,
>>classifying, and tagging threads so that people can find the
>>discussions they care about more easily.
>> 
>> 2. You can indicate agreement with a proposal or message without
>adding
>>more words that everyone has to read.  The +1 reply in email is
>clunky
>>and adds a lot of noise.  Often it's useful to be able to get a
>quick
>>count of participants who agree with an idea but don't want to
>write
>>their own extended message about it.
>
>The usability concerns that you outlined are legitimate. And some
>usability perks are 
>indeed nice to have. But the price is too high:
>
>1. I am now limited to Web Browser with JavaScript enabled. On mobile I
>am limited to the 
>browser or centrally owned and developed app.
>
>Here is what is wrong with this:
>
>- You are making a God-like judgement call that everyone must have
>graphical 
>environment running, with a hardware powerful enough to run a browser
>with  
>JavaScript. 

This is not true, and this email is proof of this

Re: Testing Discourse for Debian

[Ihor Antonov]

Unfortunately part of my original message was truncated so I will continue it 
here:

On Sunday, April 12, 2020 1:15:23 PM PDT Russ Allbery wrote:

> > Coming from a corrupted-to-the-bone post USSR country I speak from
> > personal experience of being on receiving end of that situation. You may
> > think that it is for the best, but it is not.
> 
> This is a common argument, but I find it entirely unpersuasive.
> Censorship is highly concerning when done by a government because the
> government can use force to prevent any other form of discussion except
> the one the government controls.  The idea that Debian could do this is
> absurd.
> 
> If moderation of Debian forums suppressed some problem that a lot of
> people really cared about, there would be an explosion of discussion
> elsewhere, huge uptake of the discussion in other places over which Debian
> has no control (LWN, for instance), and alternative forums being
> repurposed or newly created all over the place.
 
> This is a community full of people entirely capable of setting up a new
> mailing list or forum on the fly in an afternoon.  Debian doesn't have a
> monopoly on the press, or any realistic ability to suppress discussions.
> We couldn't be more unlike a government.
> 
> It's sadly common for people who want to fight about something on project
> forums to claim that they're being censored and unable to get their
> message out.  It's also quite dubious.  People love controversy and free
> software developers tend to be a suspicious and anti-establishment lot.
> Actual controversies with even a hint of credibility spread like wildfire.
> If no one is willing to pick up on a controversy and amplify it, it's
> worth considering the possibility that's because everyone who looked at it
> seriously has decided it's bullshit.


While I agree that there are usability aspects of email driven workflow that 
are far from being perfect, Discourse, as well as any other web browser 
focused solution is a step in wrong direction.

I much more like what https://sourcehut.org is doing. They are working on 
improving email workflows without forcing users into web browsers and I think 
this is something we should do to.

Thanks
-- 
Ihor Antonov
https://useplaintext.email

Re: Testing Discourse for Debian

[Russ Allbery]

Russ Allbery  writes:

> There does indeed appear to be some sort of problem (I haven't received
> the list copy of your message either), but your message was approved two
> minutes after you sent it, so I don't think it's with the moderation.

Ah, apologies, I was also confused by a change we made in how the messages
were processed and thought it was approved when it wasn't.

-- 
Russ Allbery (r...@debian.org)  

Re: Testing Discourse for Debian

[Russ Allbery]

Ihor Antonov  writes:

> Well, now I notice, thank you very much.

> Apr 12 21:43:38 mail.antonovs.family smtpd[46138]: bcb7c45eb6e6a5bf mta 
> delivery evpid=95394d1f34ea1dd5 from= to= proj...@lists.debian.org> rcpt=<-> source="10.193.1.100" relay="82.195.75.100 
> (bendel.debian.org)" delay=6s result="Ok" stat="250 >

> Apr 12 21:43:48 mail.antonovs.family smtpd[46138]: bcb7c45eb6e6a5bf mta 
> disconnected reason=quit messages=1

> 2 hours later it is still not in the list
> As far as I can tell my message was dropped after MTA accepted it.

There does indeed appear to be some sort of problem (I haven't received
the list copy of your message either), but your message was approved two
minutes after you sent it, so I don't think it's with the moderation.

-- 
Russ Allbery (r...@debian.org)  

Re: Testing Discourse for Debian

[Stephen Frost]

Greetings,

* Ihor Antonov (ihor@antonovs.family) wrote:
> On Sunday, April 12, 2020 1:15:23 PM PDT Russ Allbery wrote:
> > Ihor Antonov  writes:
> > > On Sunday, April 12, 2020 11:51:27 AM PDT Russ Allbery wrote:
> > >> The forum to which you sent this message is already moderated and has
> > >> been for months.  I suspect you didn't even notice.
> > > 
> > > So how then you need more moderation possibilities with Discourse?
> 
> Well, now I notice, thank you very much.
> 
> Apr 12 21:43:38 mail.antonovs.family smtpd[46138]: bcb7c45eb6e6a5bf mta 
> delivery evpid=95394d1f34ea1dd5 from= to= proj...@lists.debian.org> rcpt=<-> source="10.193.1.100" relay="82.195.75.100 
> (bendel.debian.org)" delay=6s result="Ok" stat="250 >
> 
> Apr 12 21:43:48 mail.antonovs.family smtpd[46138]: bcb7c45eb6e6a5bf mta 
> disconnected reason=quit messages=1
> 
> 2 hours later it is still not in the list
> As far as I can tell my message was dropped after MTA accepted it.

No, just held up in moderation due to, I believe, a bit of confusion
about how moderation is being done now that we have a dedicated list
alias.  I *think* the one you mentioned has now been released and is now
included- if not, please let me know.  If you see any others not
included, please also feel free to speak up, I'm fairly confident that
any which were missed from moderation were not done so intentionally.

> So much for freedom, huh?

I don't think that's terribly constructive.

Thanks,

Stephen


signature.asc
Description: PGP signature

Re: Testing Discourse for Debian

[Ihor Antonov]

On Sunday, April 12, 2020 1:15:23 PM PDT Russ Allbery wrote:

> 1. A database-driven discussion system that supports updates lets you go
>beyond the moderation that you're worried about (rejecting messages)
>and do other forms of moderation that help improve the quality of
>discussion without removing messages.  Examples include splitting
>threads that have digressed from the original topic to create more
>focused discussions, pinning important summaries so that people see the
>current status of the discusison quickly, closing old threads so that
>people properly open a new discussion instead of replying to some
>resolved discussion with a different problem, and even just sorting,
>classifying, and tagging threads so that people can find the
>discussions they care about more easily.
> 
> 2. You can indicate agreement with a proposal or message without adding
>more words that everyone has to read.  The +1 reply in email is clunky
>and adds a lot of noise.  Often it's useful to be able to get a quick
>count of participants who agree with an idea but don't want to write
>their own extended message about it.

The usability concerns that you outlined are legitimate. And some usability 
perks are 
indeed nice to have. But the price is too high:

1. I am now limited to Web Browser with JavaScript enabled. On mobile I am 
limited to the 
browser or centrally owned and developed app.

Here is what is wrong with this:

 - You are making a God-like judgement call that everyone must have graphical 
environment running, with a hardware powerful enough to run a browser with  
JavaScript. 

This line of thinking is very much alike to racial and gender inclusion 
problems. Why do 
you think you can make this call for everyone?

You can run email client on a much weaker and non-mainstream hardware.
On top of that try feeding HTML into a TTS and put yourself in a position of 
people with 
limited abilities. 

- There are only 2 browsers out there in existence (Firefox and Chrome 
variants) and 
duopoly in browser market is already alarming enough. There are much more email 
clients available.

2. I can't now use email the way I did. Discord's email interface is subpar in 
spite of what 
sales people tell you. So If I want "a first-class citizen" experience I am 
stuck with option 1 

> 3. There is some age correlation with the type of communication mechanism
>one is comfortable with, and reason to believe that younger people skew
>towards being more comfortable with forums than with email.  If you
>didn't have to learn email client skills (particularly the type that
>Debian demands, which are drastically different than how email is used
>in most jobs), it's not very welcoming to have to learn those skills in
>order to participate in the project.  

It is similar to saying that learning language, etiquette and how to be polite, 
how to listen 
to others is too hard and not welcoming to those barbarians toddlers that don't 
know 
how to talk. If all they want to eat is sugar and candy it doesn't mean that it 
the right 
thing to do.

>They're a lot less trivial than I
>think people who have been using email for a long time realize.  I've
>had nearly 30 years to hone my ability to quickly sort through huge
>quantities of email and reply in a readable way, which means it's easy
>for me to forget how much work that took, how much effort I've put into
>customizing and learning a top-end email client, and how many of the
>rules are inobvious and arcane.

Not everyone is like you.

> And yet the Internet is full of successfully moderated forums that create
> very little drama because they're just quietly more usable.

The definition of success is disputable here. "Heroin is so cool because there 
are so many 
junkies! Lets give Debian users some too"

> 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 think it's also worth pointing out that Debian users currently trust
> Debian developers with the security of their computers, which I think is a
> higher bar than trusting other Debian developers with the moderation of
> our discussions.  > These discussions often strike me as being weirdly
> disproportional and inconsistent about how we extend trust. 

Nothing disproportionate. I can inspect their work in source code. How will I 
inspect the 
results of moderation (especially with the "Ask forgiveness not permission" 
kind of 
attitude that you are advocating)

Re: Testing Discourse for Debian

[Ihor Antonov]

On Sunday, April 12, 2020 1:15:23 PM PDT Russ Allbery wrote:
> Ihor Antonov  writes:
> > On Sunday, April 12, 2020 11:51:27 AM PDT Russ Allbery wrote:
> >> The forum to which you sent this message is already moderated and has
> >> been for months.  I suspect you didn't even notice.
> > 
> > So how then you need more moderation possibilities with Discourse?

Well, now I notice, thank you very much.

Apr 12 21:43:38 mail.antonovs.family smtpd[46138]: bcb7c45eb6e6a5bf mta 
delivery evpid=95394d1f34ea1dd5 from= to= rcpt=<-> source="10.193.1.100" relay="82.195.75.100 
(bendel.debian.org)" delay=6s result="Ok" stat="250 >

Apr 12 21:43:48 mail.antonovs.family smtpd[46138]: bcb7c45eb6e6a5bf mta 
disconnected reason=quit messages=1

2 hours later it is still not in the list
As far as I can tell my message was dropped after MTA accepted it.

So much for freedom, huh?

-- 
Ihor Antonov
https://useplaintext.email

Re: Testing Discourse for Debian

[Michael Lustfield]

On Sun, 12 Apr 2020 13:15:23 -0700
Russ Allbery  wrote:

> Ihor Antonov  writes:
> > On Sunday, April 12, 2020 11:51:27 AM PDT Russ Allbery wrote:  
> 
> [...]
> So, I should be clear that I personally have only a small amount of
> experience with Discourse and haven't looked into the details of its
> features.  But there are a lot of reasons for investigating that sort of
> forum software, more generically.  Here are a few.
> [...]

+1

Obligatory: https://xkcd.com/1782/

[I really wanted to just leave it at that, but...]

I think being able to easily indicate a +/-1 would be a huge benefit for
debian-style conversations. There are four distinct long-winded discussions
that I can immediately recall over the last year where people have reached out
to me or others over IRC to express frustration/agreement with a topic/email,
but they never mentioned it on the mailing list. These same people (myself
included) would likely have added a simple indication of approval/disagreement,
especially knowing it is not an entirely new email to be read by every reader.

I haven't used discourse yet, but if it's able to send me an email for new
conversations and updates for conversations/categories I'm subscribed to, that
means an infinitely smaller inbox, less noise, and more time/attention on the
things I care about. ... I'm sure it can, those seem like standard features.

Speaking of more recent events, I can see where certain longer-lived topic
categories would be helpful, such as a help-needed (or team-needs-help)
category. Rather than the FTP-Masters team firing off periodic emails hoping
that someone this round reads it and bites, they could create the topic in that
help-needed category and leave it for people interested in seeing how they can
help Debian.

I'm sure that same logic applies to many teams, where burn-out and and serious
demotivation happens long before anyone external to the team is aware of the
problem, which exasperates simpler problems. Continuing to pick on my favorite
team... this is applies ftp-masters, where the training process itself is
extremely demotivating simply because of the lack of manpower available for
reviewing our reviews.

A lot of these supposed benefits are speculation, since I haven't used the
service yet, but it's probably time to check out this new-fangled forum stuff.
At a glance, it looks like these features (and other subscription refinements)
are available. They sound like they could (possibly) drastically improve how we
communicate, raise concerns, gather consensus, etc.

Cheers,
-- 
Michael Lustfield

Re: Testing Discourse for Debian

[Russ Allbery]

Ihor Antonov  writes:
> On Sunday, April 12, 2020 11:51:27 AM PDT Russ Allbery wrote:

>> The forum to which you sent this message is already moderated and has
>> been for months.  I suspect you didn't even notice.

> So how then you need more moderation possibilities with Discourse? 

So, I should be clear that I personally have only a small amount of
experience with Discourse and haven't looked into the details of its
features.  But there are a lot of reasons for investigating that sort of
forum software, more generically.  Here are a few.

1. A database-driven discussion system that supports updates lets you go
   beyond the moderation that you're worried about (rejecting messages)
   and do other forms of moderation that help improve the quality of
   discussion without removing messages.  Examples include splitting
   threads that have digressed from the original topic to create more
   focused discussions, pinning important summaries so that people see the
   current status of the discusison quickly, closing old threads so that
   people properly open a new discussion instead of replying to some
   resolved discussion with a different problem, and even just sorting,
   classifying, and tagging threads so that people can find the
   discussions they care about more easily.

2. You can indicate agreement with a proposal or message without adding
   more words that everyone has to read.  The +1 reply in email is clunky
   and adds a lot of noise.  Often it's useful to be able to get a quick
   count of participants who agree with an idea but don't want to write
   their own extended message about it.

3. There is some age correlation with the type of communication mechanism
   one is comfortable with, and reason to believe that younger people skew
   towards being more comfortable with forums than with email.  If you
   didn't have to learn email client skills (particularly the type that
   Debian demands, which are drastically different than how email is used
   in most jobs), it's not very welcoming to have to learn those skills in
   order to participate in the project.  They're a lot less trivial than I
   think people who have been using email for a long time realize.  I've
   had nearly 30 years to hone my ability to quickly sort through huge
   quantities of email and reply in a readable way, which means it's easy
   for me to forget how much work that took, how much effort I've put into
   customizing and learning a top-end email client, and how many of the
   rules are inobvious and arcane.

Not everyone cares about this sort of thing, but I would wager that Debian
is currently skewed towards people who cope well with email because we
have good email skills as a bar to entry.  Expanding the set of people who
can effectively contribute requires looking outside our own comfort zone.

> I do not advocate for free-for-all. It is just the ability to decide on
> who gets to say what should not be in the hands of a single person /
> small group, it is way to easy to get corrupted/biased/controlled.

And yet the Internet is full of successfully moderated forums that create
very little drama because they're just quietly more usable.

You have to trust the moderators, and you have to have some mechanism to
evaluate that trust and to discuss it and possibly revoke it if something
goes horribly awry.  This is work that should be done, but it's work
that's very doable.

I think it's also worth pointing out that Debian users currently trust
Debian developers with the security of their computers, which I think is a
higher bar than trusting other Debian developers with the moderation of
our discussions.  These discussions often strike me as being weirdly
disproportional and inconsistent about how we extend trust.  We trust each
other with hugely important and critical things, and then are full of
mistrust about minor and often quite trivial things, such as whether or
not one gets to have the final word in some war of words that nearly
everyone will have forgotten by next month.

> Coming from a corrupted-to-the-bone post USSR country I speak from
> personal experience of being on receiving end of that situation. You may
> think that it is for the best, but it is not.

This is a common argument, but I find it entirely unpersuasive.
Censorship is highly concerning when done by a government because the
government can use force to prevent any other form of discussion except
the one the government controls.  The idea that Debian could do this is
absurd.

If moderation of Debian forums suppressed some problem that a lot of
people really cared about, there would be an explosion of discussion
elsewhere, huge uptake of the discussion in other places over which Debian
has no control (LWN, for instance), and alternative forums being
repurposed or newly created all over the place.

This is a community full of people entirely capable of setting up a new
mailing list or forum on the fly in an afternoon.  Debian doesn't 

Re: Testing Discourse for Debian

[Charles Plessy]

Le Sat, Apr 11, 2020 at 03:05:12PM -0700, Sean Whitton a écrit :
> 
> For any technical topic (including DEPs) it is important that we can
> find old discussions in the future, easily, and without there being too
> many entrypoints into the search.

Hi Sean,

in my experience of DEP driver and Policy editor, long discussion
archives, especially when they spread over multiple years, are a barrier
to contribution.  Not only they are increadibly noisy (think for
instance of discussion archives in the BTS mostly made of quotes of the
previous messages), but also they are not even comprehensive (for
instance when part of the discussion happens on IRC or at Debconf).

In that sense, I would expect structured discussion systems such as
Discourse to be a potential time saver, and therefore lower the barrier
for contribution to everybody: those who contribute their point of view,
and those who summarise them.

Have a nice day,

Charles

-- 
Charles Plessy
Akano, Uruma, Okinawa, Japan

Re: Testing Discourse for Debian

[Ihor Antonov]

On Sunday, April 12, 2020 11:51:27 AM PDT Russ Allbery wrote:
> Ihor Antonov  writes:
> > And separately, I got interested in Debian because it was using mailing
> > lists in the first place.  Mail is decentralized by design and this is
> > why it is so important for freedom of speech.
> 
> I don't understand this comment.  Mailing lists are inherently centralized
> by design.
> 
> > Now you suggest a centralized platform for communication, because it is
> > easier to moderate (oppress freedom of speech). To me it sounds like:
> > "Yes you can talk, but only if you do it on my terms, on my territory".
> > Moderation is a slippery slope, using centralized communication platform
> > is one step closer to dictatorship.
> 
> The forum to which you sent this message is already moderated and has been
> for months.  I suspect you didn't even notice.

So how then you need more moderation possibilities with Discourse? 

> That said, I will argue that "yes, you can talk, but only if you do it on
> my terms, on my territory" is a message that the Debian project should
> send about its own communication channels.  (Obviously people can go
> create their own and that's no business of ours.)  That's how we create a
> community that can get things done together, rather than a 4chan
> free-for-all full of abuse and trolling.

> We should think carefully about both the terms and the territory and be
> both gentle and understanding, but we will not successfully create a free
> Linux distribution (the actual point, after all) within the noise of
> complete freedom from consequences in communication.
> 
> I don't believe Debian is or should be a welcoming home for people who
> care more about the ability to say anything they want whenever they want
> in project forums than about making a free software distribution together.
> And yes, these two goals do sometimes come into conflict (although we can
> try to minimize how often that happens).

I do not advocate for free-for-all. It is just the ability to decide on who 
gets to say 
what should not be in the hands of a single person / small group, it is way to 
easy to 
get corrupted/biased/controlled.

Coming from a corrupted-to-the-bone post USSR country I speak from personal 
experience of being on receiving end of that situation. You may think that it 
is for the 
best, but it is not.


-- 
Ihor Antonov
https://useplaintext.email

Re: Testing Discourse for Debian

[Russ Allbery]

Ihor Antonov  writes:

> And separately, I got interested in Debian because it was using mailing
> lists in the first place.  Mail is decentralized by design and this is
> why it is so important for freedom of speech.

I don't understand this comment.  Mailing lists are inherently centralized
by design.

> Now you suggest a centralized platform for communication, because it is
> easier to moderate (oppress freedom of speech). To me it sounds like:
> "Yes you can talk, but only if you do it on my terms, on my territory".
> Moderation is a slippery slope, using centralized communication platform
> is one step closer to dictatorship.

The forum to which you sent this message is already moderated and has been
for months.  I suspect you didn't even notice.

That said, I will argue that "yes, you can talk, but only if you do it on
my terms, on my territory" is a message that the Debian project should
send about its own communication channels.  (Obviously people can go
create their own and that's no business of ours.)  That's how we create a
community that can get things done together, rather than a 4chan
free-for-all full of abuse and trolling.

We should think carefully about both the terms and the territory and be
both gentle and understanding, but we will not successfully create a free
Linux distribution (the actual point, after all) within the noise of
complete freedom from consequences in communication.

I don't believe Debian is or should be a welcoming home for people who
care more about the ability to say anything they want whenever they want
in project forums than about making a free software distribution together.
And yes, these two goals do sometimes come into conflict (although we can
try to minimize how often that happens).

-- 
Russ Allbery (r...@debian.org)  

Re: Testing Discourse for Debian

[Ihor Antonov]

On Friday, April 10, 2020 11:59:59 AM PDT Neil McGovern wrote:
> 
> What about forums.debian.net?
>   I have no interest in interacting with a community of users and
>   moderators who allow blatent Code of Conduct violations to go
>   unchecked.

As a newcomer I am genuinely interested to understand this. 

Readings this it looks like there is a split in Debian community.
And Instead of fixing problems with people who moderate forums Debian
just decides to throw in another tool into the mix? And part ways with Debian 
Forum 
community? 
Sorry, makes little sense to me.

And separately, I got interested in  Debian because it was using mailing lists 
in the first 
place.  Mail is decentralized by design and this is why it is so important for 
freedom of 
speech.  Now you suggest a centralized platform
for communication, because it is easier to moderate (oppress freedom of 
speech). To me 
it sounds like: "Yes you can talk, but only if you do it on my terms, on my 
territory". 
Moderation is a slippery slope, using centralized communication platform is one 
step 
closer to dictatorship.


-- 
Ihor Antonov
https://useplaintext.email

Re: Testing Discourse for Debian

[Enrico Zini]

On Sat, Apr 11, 2020 at 03:05:12PM -0700, Sean Whitton wrote:

> Right now I can rely on my notmuch database to pull basically any Debian
> discussion, because it includes the BTS, lists, and mail which I was
> CCed on or received through an alias like ftpmaster@.  And one can
> easily incorporate mboxes from master.d.o or bugs.d.o to get any missing
> context.[1]

I think archival's a very good point, especially for a DEP-like
discussion. You also implicitly propose an archiveal format that I like,
namely some kind of email mailbox.

I'd say that having a mailbox for archival would not be necessarily
needed during a discussion, and would make sense once the discussion is
declared closed.

Discourse has some email gatewaying, which as far as I understand loses
some metainformation like reactions or polls. It would be something I
thing should be preserved from an archival point of view.

Does Discourse have some kind of export feature, that one could
postprocess to get for example a mailbox of annotated emails?


> Could you say more about how you think Discourse would have changed how
> the discussion went?

Things that the current list discussion doesn't easily give:

 - +1 kind of feedback, or simple agreement, tends to unexpressed:
   people only reply if they have a problem with things, and shut up
   otherwise.
   
   For example, the recent Salsa as OIDC provider discussion had a
   relatively small amount of people contributing: does it mean that a
   lot of people just agree, or does it mean that only few people care?

   Silent assent and only negative feedback is a very demotivating
   process to go through putting a proposal up for discussion.

 - Some kind of weighting of posts. Sometimes I wonder: "is it just me,
   or this objection is not that relevant?", and I have no real way to
   know, besides maybe polling my social bubble, which could be biased.

   Ranking of perceived importants of topics or aspects discussed might
   have helped me manage the energy I put into the whole discussion,
   going into more detail where I could see there was more interest or
   concern.


> I am concerned that the problem is basically a social one, and so cannot
> be solved just by using a different software stack to host discussions.

Ish. I think there are may social aspects involved, and the same time
the process that we currently use has technical or traditional limits
which filter against various kinds of feedback which people would
socially be happy to give.

I follow list discussions and some messages make me go "yay! Standing
ovation!" and some messages I skip after reading part of the first line,
and some messages make me furious. Socially we might able to express
that in a way that feeds into the quality and direction of discussions,
but technically, we currently cannot.


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Re: Testing Discourse for Debian

[Olek Wojnar]

If we were having this discussion on Discourse I would give this idea a +1.
:)

Well... technically a <3 but...

On Fri, Apr 10, 2020 at 3:02 PM Neil McGovern  wrote:

> Hi folks,
>
> For a little while, I've been keen to see how we can improve our
> communication methods, both to make it more accessible to newcomers and to
> take advantage of more featureful tooling than has been traditionally
> possible with email lists.
>
> As such, I set up an instance of Discourse[0] at
> https://discourse.debian.net, and am now asking for a wider input on if
> this is something the project wishes to use and if I should spend my
> time pursuing.
>
> FAQ
> ===
>
> Is it Free Software?
>   Yes. It's GPLv2+.
>
> Who else uses it?
>   Lots of people. GNOME, Mozilla, Ubuntu, Fedora to name a few
>
> What about the mailing lists?
>   This may or may not be a replacement for any particular list. I suspect
>   there are some thet would benefit greatly from having Discourse be the
>   primary interaction, and other places where this would be less suitable.
>
> Be specific!
>   Ok... I think debian-user, debian-vote and possibly debian-project would
>   be better off in Discourse. I think debian-devel-announce should stay as
>   an email list (for now). However, I am not suddenly proposing that we
> shut
>   those lists down. The aim of this exercise is to see if Discourse would
>   work well for us.
>
> Email is still important to me!
>   Fine, you can interact with Discorse by email rather than the web
>   interface. It should be noted however, that there is not 1:1 feature
>   partiy with email and the web interface, as Discorse does things that
>   can't easily be done with email. For the majority of users though,
>   email interaction should be "good enough".
>
> Why are you doing this?
>   I have two motivations. First, is moderation. Discourse has built in
> tools
>   to allow community moderation on a much better scale than our email
> lists.
>   Secondly, I genuinely believe that ease of access to new contributors is
>   of paramount importance to the project.
>
> What about X software instead?
>   Feel free to explore other solutions. I've already done evaluations, and
>   I'm pretty much set on this as the correct way forward. If there is
>   insufficient interest in moving forward with Discourse, I'll leave it to
>   others to invest time.
>
> What about forums.debian.net?
>   I have no interest in interacting with a community of users and
>   moderators who allow blatent Code of Conduct violations to go
>   unchecked.
>
> What's next?
>   I'd appreciate people testing Discourse. If you have any questions, then
>   I'm happy to answer them.
>
> Thanks,
> Neil
>
> [0] https://www.discourse.org/
>

Re: Testing Discourse for Debian

[Sean Whitton]

Hello,

On Sat 11 Apr 2020 at 11:11PM +02, Enrico Zini wrote:

> The recent difficult discussion on SSO here on -project made me think of
> a use case for which Discourse might be just the thing: Debian
> Enhancement Proposals[0].
>
> I get the impression that having proposals discussed/peer reviewed on
> Discourse might be easier and more pleasant than on lists. For example,
> it would give a way to express agreement with something more visible
> than silence, it would give a way to get visible feedback other than
> negative, and give some measure of perceived relevance to the various
> contributions made to the discussion.

One concern I'd like to raise posterity.  It is not clear to me that
discussions on a platform like Discourse can be sufficiently well
archived.

For any technical topic (including DEPs) it is important that we can
find old discussions in the future, easily, and without there being too
many entrypoints into the search.

Right now I can rely on my notmuch database to pull basically any Debian
discussion, because it includes the BTS, lists, and mail which I was
CCed on or received through an alias like ftpmaster@.  And one can
easily incorporate mboxes from master.d.o or bugs.d.o to get any missing
context.[1]

Perhaps Discourse's e-mail integration would be sufficient for me to be
able to search my personal archive for the content of past discussions,
but it would be very difficult for others not present for the discussion
to incorporate the text of everyone's messages into their information
stores.  You'd have to use your browser's File->Save Page As or similar,
which is difficult to search later.

> I'm not sure if I would be motivated right now, or ever, to have another
> round of "peer review" like the one I just had, on a list. Discourse
> seems like it might be a venue for peer review that wouldn't make me
> feel like leaving the project after a couple of days of interaction.

Yes.  I would like us to be able to handle this communicative function
better.

Could you say more about how you think Discourse would have changed how
the discussion went?

I am concerned that the problem is basically a social one, and so cannot
be solved just by using a different software stack to host discussions.

[1]  E.g. `M-x notmuch-slurp-this-debbug` in the elpa-mailscripts package.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Testing Discourse for Debian

[Enrico Zini]

On Fri, Apr 10, 2020 at 07:59:59PM +0100, Neil McGovern wrote:

> For a little while, I've been keen to see how we can improve our
> communication methods, both to make it more accessible to newcomers and to
> take advantage of more featureful tooling than has been traditionally
> possible with email lists.
> 
> As such, I set up an instance of Discourse[0] at
> https://discourse.debian.net, and am now asking for a wider input on if
> this is something the project wishes to use and if I should spend my
> time pursuing.

The recent difficult discussion on SSO here on -project made me think of
a use case for which Discourse might be just the thing: Debian
Enhancement Proposals[0].

I get the impression that having proposals discussed/peer reviewed on
Discourse might be easier and more pleasant than on lists. For example,
it would give a way to express agreement with something more visible
than silence, it would give a way to get visible feedback other than
negative, and give some measure of perceived relevance to the various
contributions made to the discussion.

I'm not sure if I would be motivated right now, or ever, to have another
round of "peer review" like the one I just had, on a list. Discourse
seems like it might be a venue for peer review that wouldn't make me
feel like leaving the project after a couple of days of interaction.


Enrico

[0] https://dep-team.pages.debian.net/deps/dep0/
-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

too many acronyms [was: Testing Discourse for Debian]

[Luca Filipozzi]

On Fri, Apr 10, 2020 at 03:26:16PM -0400, rhkra...@gmail.com wrote:
> On Friday, April 10, 2020 02:59:59 PM Neil McGovern wrote:
> > For a little while, I've been keen to see how we can improve our
> > communication methods, both to make it more accessible to newcomers 
> 
> Hmm, from the peanut gallery, if you really want things accessible to 
> newcomers, it would be nice if fewer abbreviations were used -- things like 
> DPL, CP, SP, ...
> 
> I'm not particularly talking to you, but more to the participants in the 
> "Salsa as authentication provider for Debian" thread.

Good point. There's a mix of Debian and Identity acronyms in that
thread. Here's a couple of links to help, I hope:

https://www.identropy.com/blog/iam-blog/bid/77844/commonly-used-acronyms-in-identity-and-access-management

https://wiki.debian.org/Glossary

-- 
Luca Filipozzi

Re: Testing Discourse for Debian

[rhkramer]

On Friday, April 10, 2020 02:59:59 PM Neil McGovern wrote:
> For a little while, I've been keen to see how we can improve our
> communication methods, both to make it more accessible to newcomers 

Hmm, from the peanut gallery, if you really want things accessible to 
newcomers, it would be nice if fewer abbreviations were used -- things like 
DPL, CP, SP, ...

I'm not particularly talking to you, but more to the participants in the 
"Salsa as authentication provider for Debian" thread.


> and to
> take advantage of more featureful tooling than has been traditionally
> possible with email lists.

Testing Discourse for Debian

[Neil McGovern]

Hi folks,

For a little while, I've been keen to see how we can improve our
communication methods, both to make it more accessible to newcomers and to
take advantage of more featureful tooling than has been traditionally
possible with email lists.

As such, I set up an instance of Discourse[0] at
https://discourse.debian.net, and am now asking for a wider input on if
this is something the project wishes to use and if I should spend my
time pursuing.

FAQ
===

Is it Free Software?
  Yes. It's GPLv2+.

Who else uses it?
  Lots of people. GNOME, Mozilla, Ubuntu, Fedora to name a few

What about the mailing lists?
  This may or may not be a replacement for any particular list. I suspect
  there are some thet would benefit greatly from having Discourse be the
  primary interaction, and other places where this would be less suitable.

Be specific!
  Ok... I think debian-user, debian-vote and possibly debian-project would
  be better off in Discourse. I think debian-devel-announce should stay as
  an email list (for now). However, I am not suddenly proposing that we shut
  those lists down. The aim of this exercise is to see if Discourse would
  work well for us.

Email is still important to me!
  Fine, you can interact with Discorse by email rather than the web
  interface. It should be noted however, that there is not 1:1 feature
  partiy with email and the web interface, as Discorse does things that
  can't easily be done with email. For the majority of users though,
  email interaction should be "good enough".

Why are you doing this?
  I have two motivations. First, is moderation. Discourse has built in tools
  to allow community moderation on a much better scale than our email lists.
  Secondly, I genuinely believe that ease of access to new contributors is
  of paramount importance to the project.

What about X software instead?
  Feel free to explore other solutions. I've already done evaluations, and
  I'm pretty much set on this as the correct way forward. If there is
  insufficient interest in moving forward with Discourse, I'll leave it to
  others to invest time.

What about forums.debian.net?
  I have no interest in interacting with a community of users and
  moderators who allow blatent Code of Conduct violations to go
  unchecked.

What's next?
  I'd appreciate people testing Discourse. If you have any questions, then
  I'm happy to answer them.

Thanks,
Neil

[0] https://www.discourse.org/


signature.asc
Description: PGP signature