On 06/09/14 06:13, Erik Moeller wrote:
On Fri, Sep 5, 2014 at 10:42 PM, Risker <risker...@gmail.com> wrote:
The major deficiencies that have long been identified in the current
discussion system (and that can be addressed by technology) are all able to
be addressed in MediaWiki software or by extensions. Automatic signatures
have been done by bots for years; indenting could be added to the editing
function gadget and moved to an extension; much work has already been done
on graceful resolution of edit conflicts. The ability to watchlist an
individual thread or section of a page is more challenging but, I have been
told, still possible.
Let's just acknowledge that the limitations of what can reasonably be
layered onto wikitext-based representation of comments have not been
fully explored, rather than jumping to conclusions about what's easy
to address and what's hard. As noted separately, I agree it may be
worth pushing the boundaries a bit more on this, if only to know
exactly where they are, and to achieve short term improvements.
But many of these things have been explored and experimented with.
That's just it. We have extensions to create a whole new discussion
system already which get some things right and others no so much, like
LQT and Comments, and various bots and gadgets that do smaller tasks
(auto-signing, indentation, cleanup, etc).
Have the successes and failures of the existing approaches and tools
been considered? Are things LQT got right present in Flow?
Automatic signature (something that is currently
functional on Flow, but is not customizable) turns out to be more of a
challenge when users are widely known by a signature line that doesn't
match their username,
I've not talked to them about it explicitly, but I'd guess that the PM
and the UX folks have a negative aversion against custom signatures
because of their free-form nature (including sometimes
layout-exploding ones). Perhaps a middle-ground can be found here,
with some more sanitization applied to prevent some of the
sigs-from-hell occasionally found. Other than that I can't see a good
reason to not just show them when they're set, and it's certainly
technically trivial to do so.
Signatures that break the page are currently dealt with by yelling at
the user to fix their sig and then blocking them if need be. I dunno how
a structured talkpage would necessarily change that, though having the
signatures automatically tidied might be useful in general, as it should
at least help prevent unclosed tags. Beyond that what they allow really
depends on the project, but any structured formatting with sensible
padding should work fine no matter what they do (I mean, I've never seen
any issues with that with LQT).
and there is no method by which users can add an
"explanatory" note to their signature such as "formerly known as
User:Whatever".
From the point forward that Flow is in wide use, a user rename would
be automatically reflected in old comments if desired, much as it is
reflected in old edits. But if signatures were supported, as above,
you could still use them for these types of indicators, as well.
The "more efficient" indenting has reduced possible
indents to three levels, without exception;
This seems to be the most religious topic when it comes to Flow. The
database stores all threading information. It'd be trivial to expand
the threading level if that's more popular and usable.
How is this religious? Something is needed to show progression, and
lacking anything else, threading has already been proven to work. Just
chopping it off has been shown time and again not to (you see it
particularly often on blog and news comments).
I've heard the argument that this doesn't work on mobile, but we could
just set a different threading level on mobile.
I think it's worth experimenting with flat pages (with quoting) for
certain purposes, and Danny wants to, but it strikes me as most
reasonable to start with something that more closely resembles talk
pages as they are now (which is why we did that with LQT originally).
Formatting the pages as flat with just ids and links to what the things
are replying to could be an interesting option experiment with,
especially when you don't have a lot of space. Like boards. Be like
4chan! Everyone loves 4chan.
"Rigid predictable technical
restrictions on who can edit what" has resulted in inability to remove
posts that are obviously unsuitable (there's no "undo" or "revert"
function), replaced with a "hide" function that can only be applied by
certain users that's practically a red flag for people to look-see what the
problem edit is.
The team has pretty strong arguments why they don't want posts to be
editable (the gist is, they fear that no other discussion system does
this, and it will freak people out -- they see the introduction of a
new system as a good opportunity to reset expectations). I personaly
am not religious about it; when we built LQT we made posts editable
(and made it clear who had edited someone else's posts) to preserve
that normal aspect of wiki-style editing. I think we should keep
talking about this.
Why in the world would posts not be editable? I've never used a platform
where discussion was important in which users couldn't at least edit
their own posts (along with mods) where the lack of such wasn't often
complained about (for instance bugzilla and gerrit don't allow it;
moodle and tumblr do). The whole idea of wikis is that they are more
open than most platforms, and what that means in practice is that we
trust users to act as mods too. The power structure is generally much
less rigid where security isn't a major concern, and social norms take
its place. And this is true across many, many mw-based projects I've
used and/or contributed to.
I've not seen it named as a dealbreaker for small scale deployments.
The architecture can easily support both models.
At the core is whether or not there is value in developing a "discussion
system" that is radically divorced from any other interface used by the
system.
That's a legitimate question, although it's not as "radically
divorced" as you would think; ultimately it'll use the VisualEditor
(probably with a simplified toolbar by default) just like Flow does.
As for the claim that the team never looked at current use cases,
having spent hours in rooms with them where they pored over printouts
of hundreds of talk pages, analyzed use cases, categorized them,
prioritized them, etc., I can assure you there's been a lot more of
this kind of thinking than you appreciate. There also have been round
tables and other outreach efforts, and a dedicated community liaison
from the start. Still, I don't think there's been enough talking to
each other -- we're still getting better at doing that, collectively,
and trusting in the value of conversation even when there's a lot of
noise and a lot of heat.
So they did look and this is what they came up with? Interesting.
This is an opportunity for me to remind folks that the cost of heat
(accusations, insults, reverts, etc.) is that people withdraw. We
(WMF) have to do our part to prevent things from getting heated, but
I'd ask folks who notice this kind of thing and who understand why
it's harmful to help step in and contribute to a calm, rational,
constructive dialog, as well. I can take a lot of heat, as you may
have noticed, but a lot of folks just tend to back away when things
get personal.
Thanks,
Erik
_______________________________________________
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>
