[Overload-sig] Experimenting on real-world groups with potential solutions

[Stephen J. Turnbull]

Donald Stufft writes:

 > * Topic based workflow that includes built in support for moderation.
 >     * Close a topic to new replies when it’s obvious that
 >       discussion is not productive.

That would not have worked in the security discussion.  There was
still work for Guido and mostly Larry to do even after pronouncement,
and there were useful comments from third parties.  Yes, they could
have moved to private email, but doing that would have made the
security advocates even less happy.

In general I don't think python-{dev,ideas} has a problem with
unproductive threads.  It has a problem with unproductive posts, and
(rarely) unproductive posters.

Anyway, in development channels, you often do want to be able to
reopen old topics (when they regress or when new technology becomes
available that obsoletes the old solution).  This operation shouldn't
be limited to a 100-hit-point BDFL with a +32 magic sword, any J.
Random User should be able to do so.

 >     * Move topics to the correct category (e.g. move from
 >       python-dev to python-list) instead of having 12 people reply
 >       “wrong list!”.

True, but a fairly minor example.  I think the thread-splitting case
is where this is a killer feature.  Assuming people will actually
split threads more effectively than they do in email.  I think that's
quite possible (likely, if you like), because of the synchronous
nature of posting, and because it will be cheap for people who accept
the responsibility to curate the threads.

 >     * The ability to automatically allow long term, good users to
 >       move up in “level” to gain additional privileges to help
 >       moderate the community (similar to StackOverflow).

This doesn't actually work very well in some contexts (eg,
Wikipedia).  On SO, I've noticed that I frequently disagree pretty
strongly with the relative ratings of posts.

 > * Features to reduce the need for new messages and reduce repetition .
 >     * Notification *while* you’re writing that new posts have been
 >       added so you can scroll down and read them to see if someone
 >       else already said what you were going to say.

+1

 >     * Ability to multi quote in a single response in a structured
 >       way, and compose those multi quotes as you read

+1  But then I already have that, because I use XEmacs.  There rest of
the world doesn't, because they use GMail.  Granted, that battle is
long since lost.  Mail clients are by and large going to suck for the
rest of eternity, because they're the low-denominated commoners. :-(

 >       (adding a reply is done inline as you read down the thread,
 >       and you can click a button to quote another post as you read
 >       down further).

And this works well on a smartphone in your experience?  Smartphones
are the bane of email IMO.

 >     * “Likes” on posts to remove mindless +1’s

Excuse me, but they're not mindless.  Most people who +1 do trim,
which is more than most people who write longer replies seem capable
of these days.  Agreed, having the UI track this as a count rather
than as separate messages is a very good thing.

 >     * A suggestion of possible duplicated topics when posting a new
 >       topic to try and guide people towards previous or ongoing
 >       discussions instead of rehashing the same thing over and over
 >       again.

I suspect that the AI isn't good enough for a dev channel.  Fine
distinctions matter more than for blog comments or user support where
90% of the queries refer to FAQs.

 >    * A “Summarize” topic button that filters the topic down to
 >      the "most interesting posts as determined by the community”
 >      (I don’t know how well this actually works in practice).

This is bad IMHO, whether it works well or not.  Guido is going to get
lots of likes no matter what.  The problem is people who are coming
out of lurking for the first time will get ignored unless the bar is
so low that little gets excluded.  People who write English as a
second language are not going to get as many "likes".  Etc.

 > * Features to make inter-related discussions work better.
 >    * Ability to split a topic into two different topics.

This is easy enough to do in email; people just fail.  Perhaps Guido
is right on this one, the technology may make it easy enough that
people will do it.  Specifically, the ability to move inadvertant
posts to the old topic to the new one as appropriate -- email
threading won't permit that.

 > Now, all of the above is theoretically achievable with a
 > traditional mailing list, but I think that discourse offers a
 > better medium for achieving those things. Largely for one main
 > reason: Mailing lists push the burden of achieving all of that onto
 > each and every individual participating in the discussion whereas
 > discourse (and other “forum”-esque software) tends to push the
 > burden of that onto the software itself.

Wishful thinking.  What makes discourse civilized in Jeff Atwood's
forums is Jeff Atwood, mostly.  He does not hesitate to come down hard
on barbarians.  The software may facilitate this, but the work has to
be done by people.  We have people who have the social standing and
interpersonal skills to do this well; it remains to be seen if they
also have the time.

Also remember, StackExchange is a discussion/user support forum, not a
development channel (at least as far as I've seen).  Coding Horror is
a blog.  The stakes are small and the cost of booting a French soldier
for farting in your general direction is small.  Compare that to
os.urandom() or %-formatting for bytes or even making type annotations
the standard use for function annotations -- where the first is what
inspired this whole channel because people were so wound up in the
discussion that they unsubscribed.

 > For instance, if you want to split a discussion out into a
 > different thread, you have to change the subject of the new thread
 > and make a post, possibly quoting the old post in that. However you’
 > re relying on social convention that people aren’t going to keep
 > responding to that split discussion in the original thread. This
 > sort of works but it also sort of doesn’t, particularly when
 > dealing with mail clients that will render the new thread as part
 > of the sub thread causing people to not realize that it was ever
 > split out to begin with.

This will be just as true in Discourse, I think -- except that (1) you
can provide a link to parallel threads and (2) moderators can move
posts.  (1) is a burden on the software, but if people by and large
can't distinguish HTTP connections from HTTPS connections in their
browser nor phishing from a real Christmas e-card from Grandma, I
wonder if they'll actually notice the split thread.  (2) is work for
people.

Bottom line: I'm not as enthusiastic as Guido about the theory, but I
agree Discourse has a lot of interesting features and is well worth
trying.  Just be careful to configure it so that newbies (who may
actually be long-term lurkers or even Uncle Timmy who hasn't posted in
two years! -- well, it seemed like that long) are visible to the Cabal
(even though there is no Cabal).