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

From Strategic Planning
Jump to: navigation, search


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. 212.98.136.42 16:06, 18 August 2009 (UTC)

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

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)

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)

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)

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)

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)

Impact?

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)

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)

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)

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

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)

LiquidThreads

LiquidThreads seems to tick all the boxes that are asked for in the proposal.

Should we mark the proposal as complete, or use this proposal to promote the adoption of LiquidThreads more widely across the Wikimedia sites?

InfantGorilla14:15, 1 November 2010

How to gracefully future-proof the formalised discussions? Our processes change, and the technology should change with us.

Workflow systems would do a lot for simplifying formalized discussions, at least for those discussions which are required for a process to go forward. Basically, it should be based on rules, states, tags, queues, requests, and actions.

  • Actions would be things that actually affect the wiki - end results of processes. They would be able to be "gated" through not only permissions, but also on on rules.
  • A request is a means of starting a "gated" process, presumably to accomplish a given action. Requests would themselves have states and would be filed into queues corresponding to their state.
  • Rules define how requests, actions, tags, queues, states, permissions, and actions interact. For example, a rule defining deletion processes would:
    Offer an administrator a set of actions corresponding to speedy deletion criteria.
    Offer non-administrators the ability to start a request for speedy deletion:
    Request for speedy deletion has a state deletion = requested, denied, approved
    Request for speedy deletion has a state review = requested, upheld, overturned (for deletion review tracking)
    Request for speedy deletion has fields for the rationale.
    Request for speedy deletion has the ability for comments to be made upon the request by any user.
    Request for speedy deletion has a state holdon = no, yes, denied - non administrators can change to yes to stop the deletion, but an admin can change to denied to be allowed to proceed.
    Request for speedy deletion has a trigger, which notifies article creators upon the filing of a request.
    Request for speedy deletion has actions defined for combinations of the deletion, holdon, and review states. The administrator changes the action to approved to delete the article, then the holdon state is checked. If it is no, or denied, the article is then deleted. If it is yes, the administrator is prompted to examine further as a safety measure. Non-administrators can only make a change from a holdon state of no to a holdon state of yes by making a comment with the "holdon" checkbox ticked, or reverse their own holdon, by unchecking the tickbox on their own prior comment, which only takes effect if noone else ticks holdon for their own comment.

This is all really complex, but it gives an idea how rules based processes can work in software. The end result of all this, all users (or at least all established ones) see a delete tab on articles which gives the options for deletion that are accessible to them. For administrators, that would be performing a speedy deletion, requesting a speedy deletion (in case they want a second opinion), requesting proposed deletion, or requesting XFD. A non-admin user would have requests for speedy deletion, request for prod (if it hadn't previously been denied), and request for XFD. All of these options would be very transparent. Click the button, answer a question or two, and the process is on it's way, and the user is back to editing.

Making all this work well would also need "dashboards" for users and admins. Dashboards would show your own requests so that you could follow them to completion, queues you belonged to or were watching (so the inclusionists and deletionists can still fight over XFD), certain system notifications, and would probably merge in information from watchlists for good measure.

Defining processes with rules like this has the distinct advantage that they can be changed relatively easily. While it's not as easy to alter these processes as a wiki page, its easy enough that it's not impractical. That said, it should also be difficult enough to do that change for the sake of change is inherently frustrated and undesirable, thus making the cost of instruction creep high enough that processes don't bloat out of proportion. Triona 09:29, 31 August 2010 (UTC)

Triona09:29, 31 August 2010