I'd like to know if it's possible under the current system to require contributors to register a user account before they may make edits to any pages. I realize that this isn't exactly in the spirit of the wiki system, but we've had a problem with a user lately who hasn't been paying attention to our repeated requests to follow the rules. One of the options we'd like to consider is requiring contributors to register first.
But, is that possible using the current software? How could I set that up? I've taken a look at DefaultSettings.php, and I see the variable $wgWhitelistEdit and the array $wgWhitelistAccount, and I was wondering if those have anything to do with what I'm looking for.
Thanks, Dan
On Apr 1, 2004, at 13:49, Dan Carlson wrote:
I'd like to know if it's possible under the current system to require contributors to register a user account before they may make edits to any pages. I realize that this isn't exactly in the spirit of the wiki system, but we've had a problem with a user lately who hasn't been paying attention to our repeated requests to follow the rules. One of the options we'd like to consider is requiring contributors to register first.
But, is that possible using the current software? How could I set that up? I've taken a look at DefaultSettings.php, and I see the variable $wgWhitelistEdit and the array $wgWhitelistAccount, and I was wondering if those have anything to do with what I'm looking for.
Yep. Set $wgWhitelistEdit = true; in LocalSettings.php to require logins.
-- brion vibber (brion @ pobox.com)
"DC" == Dan Carlson minutiaeman@st-minutiae.com writes:
DC> I'd like to know if it's possible under the current system to DC> require contributors to register a user account before they DC> may make edits to any pages. I realize that this isn't DC> exactly in the spirit of the wiki system, but we've had a DC> problem with a user lately who hasn't been paying attention to DC> our repeated requests to follow the rules.
Not to preach too hard, but: I suggest you think hard about what you're doing.
It is a hassle dealing with unwanted edits, I know. Rolling back unwanted edits takes time and effort. But if you think about it, it's also an exercise in strengthening your community.
Other members of your wiki will know that they can count on each other to maintain the editorial integrity of the site. And they know that it's their job to do it, too.
Best of all, they know that Wiki Works. And it does. There are hundreds if not thousands of open-editable wikis around the Internet. They have great information, they work well, and they have robust communities that keep them in good shape. And, trust me: you're not the first wiki to have to deal with an uncooperative editor.
If you implement technological measures to maintain editorial integrity, that means there's now one person who's responsible: you. Or, rather, you, plus whoever's working on MediaWiki.
Not only that, but you'd be letting one person set your entire site policy. And just by not following your rules! One person! Against all of you! You're putting down your community by doing that, and you're making this disruptive person a Super Giant!
Now, specifically on the point of disallowing anonymous edits: first, you lose a lot of the advantage of wiki. People now, when they are browsing your site for the first time, can see something misspelled or bad grammar or a factual error can just edit the page and fix it. If you disallow anonymous edits, they have to sign up to make changes. Will they? Some will, some won't. But it stops the "impulse edit", most of which are benign.
But also: what's to stop your disruptive visitor from creating a user account? Or another user account, when you block that one? And another? How much time has been saved, over simply rolling back edits? And now there's just one, or a few, people who are able to take active measures... meaning things get out of hand faster.
You _could_ set up a system where only people you know and trust can get user accounts... and then you have just a few editors. So your site's editorial content and robustness goes down quite a bit. You'll have lost both anonymous editors and people you don't know.
Consider the other possibility: your community keeps patiently rolling back or correcting unwanted edits from this one person. They eventually get sick of wasting their time, and either start dialoguing to come up with a compromise, or just give up. And your community wins! You guys did it! The next time someone pulls this kind of stunt, you know you can do it again.
Anyways, just a long speech to suggest you think it over again. You might want to read up on SoftSecurity at the MeatballWiki, for advice and a little encouragement:
http://www.usemod.com/cgi-bin/mb.pl?SoftSecurity
Good luck!
~ESP
"EP" == Evan Prodromou evan@wikitravel.org writes:
EP> But also: what's to stop your disruptive visitor from creating EP> a user account? Or another user account, when you block that EP> one? And another? How much time has been saved, over simply EP> rolling back edits? And now there's just one, or a few, EP> people who are able to take active measures... meaning things EP> get out of hand faster.
I forgot to mention one more thing: once you start taking these technological steps, you change the focus of the problem from the unwanted _edits_, to the unwanted _editor_.
Someone who's been told they're not wanted will either a) walk away dejectedly, b) learn an important lesson about themselves, or c) do everything in their power to prove that YOU are wrong for rejecting them.
If you concentrate on the problem edits, there's a chance that a compromise can still be reached. If you concentrate on the problem editor, those chances go down precipitously.
~ESP
I am working on setting up a community portal. Your thoughts on wiki are very encouraging and wise. thank you for sharing.
Selva. On Apr 1, 2004, at 6:58 PM, Evan Prodromou wrote:
"EP" == Evan Prodromou evan@wikitravel.org writes:
EP> But also: what's to stop your disruptive visitor from creating EP> a user account? Or another user account, when you block that EP> one? And another? How much time has been saved, over simply EP> rolling back edits? And now there's just one, or a few, EP> people who are able to take active measures... meaning things EP> get out of hand faster.I forgot to mention one more thing: once you start taking these technological steps, you change the focus of the problem from the unwanted _edits_, to the unwanted _editor_.
Someone who's been told they're not wanted will either a) walk away dejectedly, b) learn an important lesson about themselves, or c) do everything in their power to prove that YOU are wrong for rejecting them.
If you concentrate on the problem edits, there's a chance that a compromise can still be reached. If you concentrate on the problem editor, those chances go down precipitously.
~ESP
-- Evan Prodromou evan@wikitravel.org Wikitravel - http://www.wikitravel.org/ The free, complete, up-to-date and reliable world-wide travel guide _______________________________________________ MediaWiki-l mailing list MediaWiki-l@Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
"S" == Selva selva@thescian.com writes:
S> I am working on setting up a community portal. Your thoughts on S> wiki are very encouraging and wise. thank you for sharing.
Thanks! I wish I could take credit, but most of what I know about wiki comes from Meatball, CommunityWiki, and Ward's Wiki:
http://www.usemod.com/cgi-bin/mb.pl?MeatballWiki http://www.emacswiki.org/cgi-bin/community http://c2.com/cgi/wiki
I've had a lot of "aha!" moments reading these sites, and I highly recommend them to anyone working with wiki software and wiki communities.
~ESP
mediawiki-l@lists.wikimedia.org