[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wikien-l
Subject:    Re: [WikiEN-l] Eschatology and Wikipedia - Liquid threads
From:       Carcharoth <carcharothwp () googlemail ! com>
Date:       2010-12-26 16:25:39
Message-ID: AANLkTin=h_X4=3GHsOR5iKyw22UUPQe3Kxxyg5hTrASM () mail ! gmail ! com
[Download RAW message or body]

On Sun, Dec 26, 2010 at 1:34 PM, Stephanie Daugherty
<sdaugherty@gmail.com> wrote:
> 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.

At the end of the day, they are separate talk pages that the majority
of people will want to follow separately, so any such function to
follow things across multiple pages would require the user concerned
to mark the pages as such.

This seems like additional watchlist functionality is what you are
after (i.e. sub-watchlists). The current workarounds are: (a) to
create accounts purely to maintain separate watchlists on separate
topics; or (b) to list pages you want to watch on a subpage of your
userspace and use "related changes" on that page. The latter has a few
disadvantages: (i) less easy to maintain than a system where you click
pages to watch and unwatch them; (ii) others can publicly see which
pages you are watching; (iii) some of the additional features of
watchlists are not available through 'related changes'.

>   - 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.)

This requires either people to categorise/tag the threads
appropriately (this is done already for AfD), or for those wanting to
follow the topics to tag them accordingly. I would love to be able to
split up my watchlist several times over by topic, and tag them
according to why I've watchlisted them. The ability to tag individual
threads is, I believe, one of the big advantages of LiquidThreads or
any forum-based approach.

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

Sometimes combining everything into one feed is the wrong way to go.
The option should be available, but some people skim the surface too
much when overloaded this way, and end up contributing quantity,
rather than quality. Sometimes you can't live life at a frenetic pace,
and you have to slow down and accept that some discussions and some
activities take time to do properly.

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

This sounds like conducting parallel conversations via edit summaries.
I would be dead set against this, as in my experience you end up with
some people chattering away to each other in edit summaries, and
others using the talk page and, others not talking at all. It tends to
promote edit warring if people feel they can revert and talk to each
other in edit summaries at the same time. There is a reason why a
common edit summary is "revert, please take this to the talk page",
rather than "revert, let's edit war and discuss in the edit summaries
why we are making these changes".

>   - Complete replacement for threadmode talk pages, possibly to the point
>   where the "talk" tab gets replaced with a "discuss" tab.

In articlespace, the "talk" tab was renamed some time ago now to say
"discussion", and from the looks of it in all other namespaces as
well. Maybe I've misunderstood what you are proposing here? Are you
using an old Wikipedia viewing skin, possibly?

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

I tend to add a "see also" template to the front of all such
discussions to tie them together. If done early enough, this works and
discussion does tend to split the right way among the venues, or
centralise (if that is more appropriate). Wikilinks are the logical
way to tie such discussions together. The more annoying thing is how
archived threads change location and so links made previously break
and don't work. If that was fixed, the current system would be fine.

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

I think hatboxes are OK. I agree archiving is clunky in the current set-up.

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

No comment as I don't know enough of the history here.

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

Agreed, with the proviso that large discussions can work if a single
person or a group moderates and leads the discussion in a clueful way,
and the other participants don't let any one participant disrupt
proceedings and back-up the "moderators" when they need to step in.

> Discussions between collaborators tend to fit into several categories:

This is why namespaces were invented... (maybe suggest a new namespace
if you think that would help).

>   - One on one discussions between editors for mentoring, collaboration, or
>   simply to find out "WTF?"

Can start on talk pages and then (though this is not done enough) move
to a more public location so others can join in.

>   - Asking "is this ok?" before making a change. (This is fine, but some of
>   these would be better to just be bold.)

Article or projectspace talk pages.

>   - Asking "what was wrong with that?" after making a change that was
>   reverted.

Again, article talk pages are for this sort of thing.

>   - Small collaborations.

Article talk page, subpage of article talk page, or WikiProject draft
page, or userspace draft page.

>   - "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.

AfD is a bit of a special case. Technically, it doesn't apply *all*
policy and process to an article. It should only apply the question of
whether an article on this topic with this title should exist on
Wikipedia. Other stuff should, really, be dealt with by direct editing
of the article (e.g. merging, removing contested unverifiable
information, removing BLP violations, removing copyright violations,
and so on). None of those examples require AfD, and you will find that
AfD regulars *should* tell people that they shouldn't use AfD when
their objections to the article can be addressed by normal editing.

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

Moderation is what is really needed here, not semi-controlled chaos.

>   - Global applications of policy and process. (Mass deletion, or
>   controversial mass-changes.)

These tend to be discussed on noticeboards or other centralised
venues. As long as the appropriate notices are given, these tend to be
OK. The current system seems flexible enough to handle this sort of
thing.

>   - Dispute resolution and arbitration processes.

Have their own pages. Though possibly this is one place where a more
forum-like interface would actually help a lot.

>   - Project-wide discussions. Policy changes and the like.

Again, I agree that forum-like interfaces would help here.

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

Agreed. If people see this happening, they should say so, but the
unfortunate effect tends to be that the discussion then gets
sidetracked into drama, rather than the original discussion. Also,
some people game the situation to accuse others spuriously to merely
disrupt the existing discussion. The key thing, it seems, would be to
have discussion of disruption of a discussion take place in a
*different venue* to that where the discussion is taking place (or
even just a different thread on the same page). This allows the
discussion of potential disruption to take place without itself
disrupting the discussion.

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

You still need effective moderation of discussions, though. Merely
having good implementations doesn't solve everything.

Carcharoth

_______________________________________________
WikiEN-l mailing list
WikiEN-l@lists.wikimedia.org
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l

[prev in list] [next in list] [prev in thread] [next in thread]