Proposal talk:Stop using wikis for tasks for which wikis are not suitable

From Strategic Planning

I believe this is a really important proposal that aims at alleviating enormously the amount of janitorial work done by Wikipedians and bots. MediaWiki is a content management system, but unlike other CMSs, it lacks of a workflow which allow us to formalize processes. Like you said there are lots of wiki-processes (deletions, FAC, PR, RFCs...) that are managed in a manual and awkward fashion (create a subpage, rename it, remove it, index it) by editors or bots. Formalizing them may take out a lot of this work, and make archives more consistent. The problem that I can think of right now are: First, some editors may see it as a new layer of bureaucracy. Second, and most importantly, the flexible model of a wiki has allowed the community to come up with tons of new wiki-processes, and allow it to modify and tweak them over time. Unless, the architecture of the new software is really well though-through, I think it will never be flexible enough to allow for a never thought before wiki-process. This proposal means that MediaWiki should be revamped totally to scale, which I strongly believe it should be, but it is highly unlikely. 16:06, 18 August 2009 (UTC)[reply]

Interesting, but I'm not sure it's a correct proposal. Nemo 00:27, 20 August 2009 (UTC)[reply]

You are right, Media Wiki was not made for this and esp. for newbies its hard to use it. --Hannes Röst 12:38, 22 August 2009 (UTC)[reply]

I agree with the analysis, i.e., that many things done in project namespace do not fit the "wiki" metaphor at all. On the other hand, this seems to involve a major rewrite of MediaWiki, which seems rather unrealistic to me. --B. Wolterding 22:15, 22 August 2009 (UTC)[reply]

It would be a major change, but not necessarily unrealistic. Is there open source forum software that we can adapt? How would we indicate to MediaWiki that we wanted to use the new platform(s) instead of classic pages? HereToHelp (talk) 17:03, 23 August 2009 (UTC)[reply]

Why we use wikis for these tasks in the first place

An open Swiss Army knife, displaying a variety of tools.
Wikis are like Swiss Army knives: each tool might be mediocre, but the versatility and compactness are unbeatable.

On certain levels, I agree with this proposal: it would make certain processes much more efficient, user-friendly, and simple were we to code them into software. I seem to recall seeing some brainstorming somewhere for software that could implement a deletion queue for automating most of the deletion process, for example, and that seemed like a good idea.

That being said, one of the great strengths of a wiki is that can be adapted to fit the situation at hand. As the proposal itself points out, wikis have been used for a myriad number of tasks. It's like a pocketknife: while each individual tool it contains may be inferior to a standalone version, the fact remains that one has all the tools in a single, compact package with the pocketknife. Being able to design templates and processes on a wiki is like a tinker taking apart his pocketknife and adding a new tool to it. That flexibility is something that we should be wary of sacrificing. When you move to dedicated software for some task, you adopt the restrictions and idiosyncrasies of that software. Although I'd love to see some "deletion queue" software, what if the community decided they wanted a new deletion process? Under the wiki model, a template wizard could set up a new system within an hour. With specialized "deletion queue" software, the community would likely be waiting days, weeks, or even months while developers coded, debugged, and tested a new system.

The danger in adopting such specialized tools is crystallization in community processes. When you need a developer to write new code, the process gains an extra, difficult and even sometimes expensive (if you pay developers) step, decreasing the motivation to try something new, to innovate. That bar to innovation is dangerous. If Nupedia hadn't tried a wiki in the first place, we wouldn't be here discussing this today. Nihiltres 23:30, 26 August 2009 (UTC)[reply]

Cautious support

I think I like it, as far as I understand it, which means incorporating proven technology for some tasks not directly involving the articles. Another question which immediately suggests itself is that if part of the process (like a forum) is taken out of the Mediawiki software if it thereby becomes a good idea to take them out of GFDL as well. At present everything that anybody enters is released under GFDL (or ...) and can be edited by anybody. If instead we have a 'normal' forum with contributions that cannot be edited (censored) by others, these need not necessarily be released under GFDL. A proposal like this could potentially have far-reaching results (not necessarily good or bad by themselves). - Brya 17:56, 27 August 2009 (UTC)[reply]


Some proposals will have massive impact on end-users, including non-editors. Some will have minimal impact. What will be the impact of this proposal on our end-users? -- Philippe 00:17, 3 September 2009 (UTC)[reply]

I support this proposals, it goes hand in hand with other proposals questioning the use of MediaWiki for Commons for example. This could have huge impact, as it is about very software fundaments.--Kozuch 15:27, 9 September 2009 (UTC)[reply]

Wikiversity:THREADNAV - the power of the wikicode

I think people should be free to do with whatever tools they like for whatever jobs they like.

The power of MediaWiki is that it is almost a programming language (see: meta:recursive conversion if you want to know what I mean).

I have developed a system of threaded discussions entirely within MediaWiki syntax (ie no extra .php extension needed) which show how much you can achieve with MediaWiki. Hillgentleman 20:18, 12 September 2009 (UTC)[reply]

"We're [correctly] using wikis for...".

Surely, we're using wikis for lots of things, but most of the items on the list you provide are uses I wholeheartedly approve of. Yes, we have some problems in centralizing discussion, but in my view that is a navigation and oversight problem, not a problem of not adopting some rigid BBS system.

I think you bring up some interesting points when it comes to votes and concise voting. I feel however, less discussion-centric technology would be not be worth the trade-off in hindering the ability for analysis.

I absolutely love the idea of a "forum index" for very important discussions/pages but I don't think it necessitates using actual BBS technology. Bulletin board threads are no more complex than new pages of discussion, except they don't allow complex sub-threading of conversations.

Whatever new technologies you might suggest, I encourage you to give some specific examples of what we could use. I also think this idea would be much more likely to be welcomed if it introduced concrete new apps within the wiki framework, and didn't require people to go off site to discuss something on the site. That's all. --Lyc. cooperi 09:17, 1 October 2009 (UTC)[reply]

We can do complex threading with wiki-codes. The con is that it is a little tricky; the pro is that wiki-code gives you a lot of freedom to do anything to the threads. Hillgentleman 17:34, 18 October 2009 (UTC)[reply]