[WikiEN-l] Eschatology and Wikipedia - Liquid threads

Stephanie Daugherty sdaugherty at gmail.com
Sun Dec 26 13:34:58 UTC 2010


Maybe it would be better to try to define what the features we need for
better communication are. I'm not quite awake yet, but here are a few
thoughts:

   - Ability to follow conversations without having to jump around across
   multiple talk pages.
   - Ability to be notified of conversations that are interesting, for broad
   values of "interesting". (Conversations about watchlisted pages, in
   particular categories, or part of particular wikiprojects for a start.)
   - A single page "newsfeed" of comments that combines conversations we are
   following and topics we've defined as interesting, as well as optionally RC
   feeds.
   - Ability to comment directly from a particular change, which could
   supplement or replace the edit summary. This also gets a lot of
   conversations off the traditional user talk page, because much of what we
   bring up on a user's talk page is about some edit they made. Keeping this
   with the change in question makes it easier for others to join the
   conversation.
   - Complete replacement for threadmode talk pages, possibly to the point
   where the "talk" tab gets replaced with a "discuss" tab.
   - Ability to tie in conversations elsewhere seemlessly without
   duplication. For example, a conversation may start over a particular page,
   but the issue being discussed is really a particular infobox. A "cc" feature
   used judiciously (and possibly one that's editable) would help this. This
   would be most helpful if you could CC another article's discussion, a
   wikiproject, and/or particular individuals.
   - Whatever solution needs to eliminate archives and hatboxes as we know
   them now. If conversations are to "archive" it should be straightforward to
   restart them, and doing so shouldn't be considered a taboo.


Liquidthreads is a start, but it seems to me like the mission was "figure
out how to bolt forums onto an existing talk page", without enough
consideration as to what problems need to be solved. It's an interesting
hack, and it has let us experiment about what works and what doesn't, but
without change it's not going anywhere.

It's been my experience that talk pages melt down around 15 or so
participants if the topic is contentious. A little below that and you can
have a productive discussion, too much below that and you aren't getting
anywhere. I think many of our best collaborations are small teams of 2-4
dedicated people, with a few more that come and go.

Discussions between collaborators tend to fit into several categories:

   - One on one discussions between editors for mentoring, collaboration, or
   simply to find out "WTF?"
   - Asking "is this ok?" before making a change. (This is fine, but some of
   these would be better to just be bold.)
   - Asking "what was wrong with that?" after making a change that was
   reverted.
   - Small collaborations.
   - "Local" uncontroversial applications of policy and process. (Local, as
   in local to an article). The typical AFD falls into this one, with 2-20
   participants.
   - Controversial applications of policy and process. Highly contentious
   AFDs, and virtually all requests for advanced permissions. Reason tends to
   go out the window on these, and the signal to noise can be really bad.
   - Global applications of policy and process. (Mass deletion, or
   controversial mass-changes.)
   - Dispute resolution and arbitration processes.
   - Project-wide discussions. Policy changes and the like.

We need to have effective communication for all of these that can preserve a
high signal to noise ratio, and that can scale well all the way from one on
one to project-wide discussions. Right now, we're fairly strong at small
discussions, but we break down horribly on big ones. It's also too easy to
disrupt a large-scale discussion, and since we rely on consensus to make
decisions, a little disruption can sometimes delay reaching consensus
indefinantely, and can do so without crossing the thin line into what
is perceived as misconduct.

Also worth considering are social problems. Disruptive editing, personal
attacks, privacy violations, and the like, although not technical problems,
do have to be considered when designing discussion systems, because they are
social issues that can be partly solved through good implementation.



On Sun, Dec 26, 2010 at 7:37 AM, David Gerard <dgerard at gmail.com> wrote:

> On 26 December 2010 00:28, geni <geniice at gmail.com> wrote:
>
> > TVTropes has forums which see some use:
> > http://tvtropes.org/pmwiki/topics.php
>
>
> Yep. Note that those are running on separate forum software, rather
> than something added to their wiki software. (Also that TVtropes pages
> have talk pages too, though they generally don't see a lot of action.)
>
>
> - d.
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at lists.wikimedia.org
> To unsubscribe from this mailing list, visit:
> https://lists.wikimedia.org/mailman/listinfo/wikien-l
>



-- 
Faith is about what you really truly believe in, not about what you are
taught to believe.


More information about the WikiEN-l mailing list