Proposal:Stop using wikis for tasks for which wikis are not suitable
Every proposal should be tied to one of the strategic priorities below.
Edit this page to help identify the priorities related to this proposal!
- Achieve continued growth in readership
- Focus on quality content
- Increase Participation
- Stabilize and improve the infrastructure
- Encourage Innovation
|
Share this:
|
Summary
Stock MediaWiki software is perfectly adequate for "whiteboard" type of communication, and doing light discussions on various topics. However, around Wikimedia projects, MediaWiki is used for things that go far, far beyond this. For these, we'd need various new forms of software that would be more suited for these tasks.
Proposal
We need something to better enable us to discuss things. Perhaps we need a MediaWiki extension that uses whole new, independent database structures, or a whole new software package that interfaces with MediaWiki seamlessly. Perhaps this could be extended into a "wiki with an integrated learning/discussion environment".
Use case
A user case scenario: Ann User wants to see what sort of discussions the community is currently having, so she opens the forum index - nicely categorised into various subforums. She checks the current discussions on policies, and goes to vote on straw polls she has not yet voted on, and checks any (prominently marked) new comments on the ones she has voted on previously. She finds out that several articles she has interest on have been flagged for deletion for frivolous reasons, so she focuses on improving them and comments on those things. For the rest of the day, she answers newbie questions on the newbie forum and reference desk. (Nice to have a newbie forum that everyone can actually find this time, no?)
Easier things first: Bring in the forums
Noticeboards out, plain old ordinary forum technology in. The first thing I'd replace in Wikipedia are the numerous noticeboards. If we need specialised search engines to handle Admin Noticeboards in en.wp to get anything done, things are not very good.
By "ordinary forum technology", I'm referring to things that are already in all of the existing forum software: Individual, compartmentalised messages that other people can't (necessarily) edit; threading; prominent marking of new comments the user has not yet seen (completely missing currently, and implausible in a wiki-based discussion system).
More ambitious idea: Defining formalised processes
Perhaps we'd need some sort of a system that would allow us to define "Processes". The administrators would define a "cookie-cutter" that would be analogous to the bazillion templates we currently use to handle the formalised discussions - except this doesn't just concern presentation, but also the other parameters.
To explain this best, let's give a concrete example. Let's build a formal model of English Wikipedia's AFD process (not an exact duplicate, but please bear with me):
- Article Deletion Discussion is a process that concerns one or more Articles. It is logged by Opening Date. It may be opened by Anyone. It may be closed by Sysops. It may be related to one or more Interest Topics, which may also be inferred from the related Articles. It has a Deletion Rationale (submitted in the original proposal) consisting of free-form text and Closure Verdict (submitted by closing Sysop), consisting of Result (Keep, Delete, No Consensus, Merge, Redirect, Other) and free-form comment text. The discussion has a Status Whiteboard (editable by Sysops) and Summary of Not-Votes (automatically tallied). Users may provide comments that consist of Not-Votes (possible values: Keep, Delete, Merge, Redirect, WTF, Other, combinations allowed; possible qualifiers Strong or Weak) and a free-form comment text. Replies to comments have only free-form comment text. By default, discussion is open 5 days.
Now picture that in a machine-readable form that could be edited by the sysops of this brand new discussion thingie.
Once the process is defined it just automatically shows up as "Article Deletion Discussions" in the forum index. When you submit a new proposal under the deletion process, you just hit "new Article Deletion Discussion" in either the article itself or in the ADD forum list (in which case you need to provide article title yourself). Provide deletion rationale, tick off Interest Topics in the list. People can then just hit "Add Comment" and Not-Vote and tell how they feel. Admins can close this and put the result and comments in their closure verdict. While open, it gets automatically sorted into daily logs, shows up in the articles themselves, and is also listed under the interest-topic lists. Once it's older than 5 days, it goes under "deletion discussions that needs to be closed". Once it's older than 20 days, it goes under "stuff that is so backlogged that it's not even funny". And so on, and so forth.
Motivation
Our widespread MediaWiki abuse
MediaWiki is well-suited for creating articles. It is somewhat good for discussing articles. The same markup is used for both articles and discussions, which is a little bit infuriating when the discussion grows longer and the markup gets messier and messier and there's a lot of colon-counting and edit conflicts. Despite this inadequacy, we're using this discussion system because it's "good enough" and doesn't require much additional learning.
Yet, we're using wikis for tasks such as:
- generic message boards (all noticeboards)
- conducting straw polls and referendums
- status tracking on articles (various ambox templates, WikiProject lists, quality assessment/GA/FA)
- conducting discussion on articles, people and policies (XFD, RFCs...)
- Activity notifications for people who are interested of certain topics (WikiProjects)
- conducting formal discussions on user conduct (Requests for Arbitration)
- software releases and bug tracking (see wikEd's page in en.wp)
- etc.
All this is built upon a jawdroppingly massive, complex system of templates with messy code, tons and tons of wiki markup, about five squillion subpages, and more MediaWiki markup syntax abuses than you can shake a stick at. Half of the stuff seems to focus on finding new innovative uses for existing, yet originally-inadequate-for-task, MediaWiki features.
Remember how protected titles were implemented before MediaWiki got built-in creation protection? That was an elegant hack, but a hack nonetheless, and was implemented in MediaWiki software in much more elegant manner. What we have missed is that we're using tons of "hacks" - not so elegant ones in nature - to sustain our entire decision-making process.
Regulars abuse MediaWiki daily and don't even notice it, but newbies can't read instructions
I have not followed the English Wikipedia deletion discussions lately, but a year or two ago, there were always newbies who barged in to defend their point of view in a manner that was completely different from the way the seasoned editors did their things. Thus, we inadvertently always got some weird picture of "unruly newbies who have no idea of our community standards or the purpose of the discussion" and "civilised regulars".
And why would newbies inadvertently present themselves in an unruly manner? The XFD system uses wiki markup, which is hard to understand and error-prone unless you know what you're doing. It allows people to mess up other people's comments, and makes it terrifyingly easy to make you stand out of crowd as a person who doesn't know what's going on. We can't expect everyone to read the whole manual to participate in a discussion.
MediaWiki discussions pages don't favour people who don't know the markup and rules of conduct. We need a system that is less reliant on knowing the markup (but is nevertheless compatible with it - I'm not saying it's all bad), is more user-friendly, and more suitable for conducting discussions.
Centralised discussion isn't
The biggest problem with English Wikipedia is that we have so many bureaucratic processes and discussions and noticeboards and Wikiprojects that it's easy to get completely lost. We need indexes that are indexes. We need ways for people to find the discussions on those topics that they have a stake on - be it discussions and status updates on articles they've worked on, or articles on topics that concern them, or even users they're concerned of.
Key Questions
- How this can be integrated into MediaWiki seamlessly?
- Should it extend MediaWiki, or would it be feasible to to create a system that would be independent of it, merely 100% compatible and integrated?
- How to implement this without succumbing to the dreaded second-system effect? Formally defining processes is a good idea, but this could lead to a long, academic debate on how to solve the problems, with few concrete results in sight.
- How to gracefully future-proof the formalised discussions? Our processes change, and the technology should change with us.
Potential Costs
Lots of brainpower and developer time.
References
For a more specific proposal on a related issue, see Proposal:Build WikiProject tools into MediaWiki.
Community Discussion
Do you have a thought about this proposal? A suggestion? Discuss this proposal by going to Proposal talk:Stop using wikis for tasks for which wikis are not suitable.
Want to work on this proposal?
- .. Sign your name here!
- Triona 08:45, 31 August 2010 (UTC)