I am a moderator in a community about a game. We have both a forum and a wiki. Our forum has some very knowledgeable users who make great in-depth posts.

However, I noticed the following phenomenons several times:

  1. Someone posts on the forum (in one case someone even registered just for this purpose) to complain about an obvious mistake on the wiki they could easily fix themselves. I asked the user why they go through the trouble to post on the forum instead of just editing the wiki, but got no meaningful response.

  2. During a forum discussion, user A cites the wiki to support their argument. User B points out that this information on the wiki is wrong, always was wrong and it being wrong is well known in the community. I asked why they know about a mistake on the wiki but don't correct it. The user said that he doesn't feel responsible for the wiki. I wonder why they feel responsible for correcting someone posting something wrong on the forum but not on the wiki.

What could be the reason why people avoid editing our wiki and how can we encourage them?

Some background info:

  • Our forum runs on phpBB
  • Our wiki runs on Mediawiki
  • Accounts are separate. Wiki accounts require moderator approval, because it was the only way we found to keep the spambots away.
  • why they go through the trouble to post on the forum instead of just editing the wiki, but got no meaningful response. Accounts are separate. Wiki accounts require moderator approval, because it was the only way we found to keep the spambots away. There's your problem.
    – William
    Commented Apr 27, 2015 at 12:33

3 Answers 3


Accounts are separate. Wiki accounts require moderator approval, because it was the only way we found to keep the spambots away.

I suspect that this is a major factor in keeping people from editing the wiki. It probably doesn't feel like the wiki is owned by the community and having to register with a separate account won't help that feeling.

I have no idea whether this is technically possible, but if you can, link the wiki accounts to the main forum accounts so that users don't have to log in twice. This will hopefully give the feeling that the wiki is a real part of the community and owned by the community.

So other ideas you could consider:

  • You could have a scheme where good forum posts are nominated to be converted into wiki entries - again this might help foster the feeling of ownership.

  • Run a competition whereby the best new and edited wiki posts win a prize - the prize doesn't have to be much - a T-shirt would probably work. Again this is to encourage people to edit the wiki. Hopefully they'll continue to edit and expand the wiki once the competition is over.

  • 2
    One more: when asking them to edit the wiki, go ahead and give them the specific link to edit the page they're complaining about -- one click to get them into an edit window. I've seen that, versus a general directive to edit, get newer users to actually do so. Commented Oct 27, 2014 at 1:13
  • It looks like MediaWiki provides a single signon method. There is a lot of code modification (like installing an old Mod that doesn't install automatically)
    – Andy
    Commented Oct 27, 2014 at 3:17

You could try finding another way to control spambots on your MediaWiki that is more convenient for new users than requiring moderator approval. The following policy has worked well for two wikis that I admin:

  • Creating an account is open.
  • Everyone, including anons, can edit pages in talk namespaces but cannot edit main until an account is confirmed. This happens when a user A. confirms an e-mail address, B. gains autoconfirmed status (set to 4 days and 2 talk edits on my wikis), or C. completes what amounts to your current process of contacting a wiki administrator out of band through a related means where the user is already known (such as a forum or IRC channel).
  • Install the ConfirmEdit extension with QuestyCaptcha, customize its questions and answers to relate to the community's topic, and rotate the questions out every few months. This way, a generic MediaWiki spambot not targeted to your particular site will fail to create accounts and fail to post links. I have had bad experience with ReCAPTCHA; because it's so widely used, generic spambots target it far more than they would a simple game-specific Q&A.
  • Install the AbuseFilter extension to stop spambots that have discernable patterns in their spam or discernable patterns in their usernames.

Here's the spam control stuff from my LocalSettings.php:

// Don't allow anyone other than site staff to edit non-talk pages
// until they've confirmed their e-mail address or waited a few days.
$wgNamespaceProtection[NS_MAIN]     = array('editmain');
$wgNamespaceProtection[NS_USER]     = array('editmain');
$wgNamespaceProtection[NS_PROJECT]  = array('editmain');
$wgNamespaceProtection[NS_IMAGE]    = array('editmain');
$wgNamespaceProtection[NS_TEMPLATE] = array('editmain');
$wgNamespaceProtection[NS_HELP]     = array('editmain');
$wgNamespaceProtection[NS_CATEGORY] = array('editmain');
$wgAutopromote['emailconfirmed'] = APCOND_EMAILCONFIRMED;
$wgImplicitGroups[] = 'emailconfirmed';  // Hide group from user list
$wgGroupPermissions['emailconfirmed']['editmain'] = true;
$wgGroupPermissions['autoconfirmed']['editmain'] = true;
$wgGroupPermissions['confirmed']['editmain'] = true;
$wgGroupPermissions['emailconfirmed']['skipcaptcha'] = true;
$wgGroupPermissions['confirmed']['skipcaptcha'] = true;

// Four days and two edits to become autoconfirmed.
// If not also emailconfirmed, these have to be talk page edits.
$wgAutoConfirmAge = 4 * 86400;
$wgAutoConfirmCount = 2;

// Make page moves and uploads also require confirmation
$wgGroupPermissions['user']['move'] = false;
$wgGroupPermissions['autoconfirmed']['move'] = true;
$wgGroupPermissions['confirmed']['move'] = true;
$wgGroupPermissions['user']['upload'] = false;
$wgGroupPermissions['autoconfirmed']['upload'] = true;
$wgGroupPermissions['confirmed']['upload'] = true;

// Configure QuestyCaptcha from its own file

// https://www.mediawiki.org/wiki/Extension:AntiSpoof
// Makes sure that usernames aren't too similar to other usernames.
// We need it before we can install the ABUSE filter.

// https://www.mediawiki.org/wiki/Extension:AbuseFilter
// Allows flagging, warning, or rejecting edits by heuristics
// including regular expressions, user groups, and more
require_once( "$IP/extensions/AbuseFilter/AbuseFilter.php" );
$wgGroupPermissions['sysop']['abusefilter-modify'] = true;
$wgGroupPermissions['*']['abusefilter-log-detail'] = true;
$wgGroupPermissions['*']['abusefilter-view'] = true;
$wgGroupPermissions['*']['abusefilter-log'] = true;
$wgGroupPermissions['sysop']['abusefilter-private'] = true;
$wgGroupPermissions['sysop']['abusefilter-modify-restricted'] = true;
$wgGroupPermissions['sysop']['abusefilter-revert'] = true;

// https://www.mediawiki.org/wiki/Extension:User_Merge_and_Delete
// Allows merging a user's contributions into another user and then
// deleting the old user.  Experimental use to merge spambots.
require_once( "$IP/extensions/UserMerge/UserMerge.php" );
$wgGroupPermissions['bureaucrat']['usermerge'] = true;

// https://www.mediawiki.org/wiki/Extension:Renameuser
// Lets bureaucrats rename users, such as users with offensive names
// or users whose fursonas have changed

// https://www.mediawiki.org/wiki/Extension:Recent_Changes_Cleanup
// Lets sysops and users with 100+ edits turn on the bot flag of edits
// Good for hiding spam and reverts that have been taken care of
$wgGroupPermissions['sysop']['recentchangescleanup'] = true;
$wgGroupPermissions['recentchangescleanup']['recentchangescleanup'] = true;

And the separate CAPTCHA configuration file questy.php:

require_once( "$IP/extensions/ConfirmEdit/ConfirmEdit.php");
require_once( "$IP/extensions/ConfirmEdit/QuestyCaptcha.php");
$wgCaptchaClass = 'QuestyCaptcha';

$wgCaptchaQuestions[] = array(
  'question' => 'What is the name of the NES\'s light gun?',
  'answer' => 'zapper'

// these aren't my real questions
$wgCaptchaQuestions[] = array(
  'question' => 'Ennyn Durin Aran Moria: pedo mellon a minno.',
  'answer' => 'mellon'

I ran into a similar (but not exactly the same) position years ago, but everything I have done wasn't successful. So my points may not worth much.

From what I have known:

  • A forum almost always has greater influence than a wiki of the similar size to average users participated in both, and encourages contributions more. (A StackExchange-like model lies between them, and there is nothing else between the three.)
  • Forums are much harder to maintain than a wiki, when there are too many users (1,000,000 or even 10,000,000 users, say). That might be a big number. But for a single user, it is still easier to join many wikis with a total of 1,000,000 users, than many forums with that many users. That's how a wiki can be successful.

For your question, there are two obvious (and conflicting) ways based on these assumptions:

  • Try to attract some users outside your forum, and try to make your wiki not very forum-centric. It's fine that your wiki has less quality, and only a few users are active and volunteers to move the conclusions from the forum to the wiki (at least they save time for reading the whole thread; but users already always reading whole threads may not be interested). And of course, don't require moderator approval to edit. Wikis need less moderation but they still need some, and there are also spambots on forums. You could also try some automatic filters, or setting minimum time to wait before first edit after registration.
  • Or try to make the wiki something inside your forum. At least wiki edits should be scored, being indistinguishable with a forum post. And other users can reply to or argue with those edits, and also scored, in the same way like the forum. This may nullify everything good for a wiki, and stop attracting more users than the forum. For example, some may say the current revision is far from the conclusion, but based on personal opinions, and don't want others to remove it without good reasons (much better than nobody ever tries to write something in the perspective of forums). But it's fine if you don't have those 1,000,000 users, and you just want to use the wiki as a tool.
    • But well, we didn't have enough programmers for that non-profit wiki to make them real.
    • An easier way is to link the announcements to the wiki, and link from the wiki back to the original posts. It may make users complain less but I'm not sure about anything else.

Another option which seemed not to be what you want: Chatrooms seemed to be more compatible with a wiki than a forum because they don't share functionalities. I don't see a feasible way converting a forum to be like a chatroom. But one way is to let the forum users also join some chatrooms they like, and introduce the wiki to some chatroom users who aren't really interested in forums. Though it may be not easy to do it right.

Restricting the forum to talk about topics on the wiki may also work, but that's stupid since you had a successful forum but not a successful wiki.

TL;DR: Who will decide who is right and who is wrong when two users don't agree with a wiki edit? Think of that. If you don't like those arguments, you have to move them elsewhere, or move to some earlier time.

Wikis aren't automatically having a higher quality. Either improve that or let your users know. When users are saying "wiki is good", they are in fact referring to some unknown wiki editors being good, which probably means they are not editors either. If there are someone don't agree anyway, it's reasonable to think arguing with someone known and being serious better.

Instead, if they are changing the wiki after those arguments ended, they are on the right way.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.