On 3/13/06, The Cunctator <cunctator(a)gmail.com>
wrote:
On 3/13/06, Anthony DiPierro <wikilegal(a)inbox.org> wrote:
On 3/13/06, The Cunctator
<cunctator(a)gmail.com> wrote:
> On 3/13/06, Anthony DiPierro <wikilegal(a)inbox.org> wrote:
> > Just allowing people to report errors isn't a problem. The problems
> > are acting on those reports without first verifying the true facts,
> > and removing entire articles simply because some of the facts in
that
>
article are inaccurate. Then of course there's the problem of
> protecting articles, though that one's probably arguable (now that
> semi-protection exists I can't personally think of a scenario where
> full protection is *ever* a good idea).
>
The argument is that since any form of protection is an unwanted
state, it's in certain senses better when it bothers more people -- it
motivates people to fix the underlying problems.
[....]
If this doesn't make sense I can try to do a
better job of explaining.
No, that does make sense. Though the way I see it, especially since
the advent of the three revert rule, page protection only makes sense
when dealing with sockpuppets, and semi-protection is a good
protection against that which still allows established editors.
And if page protection is only used in that way - in the face of a
distributed sockpuppet attack, I really don't see how semi-protection
hinders solving the underlying problems.
But I suppose this presumes that page protection is only used in this
limited sense, which doesn't reflect how it is actually used in
practice.
To my mind, a fully protected page is the absolute worst state a page
can be in. A vandalized but editable page is even better, in my
opinion.
Do you see how a semi-protected page could be worse than a fully protected
page?
Not particularly.
Or, rather, having significant numbers of semi-protected pages could
be worse than significant numbers of fully
protected pages?
Let's try to quantify the problem here. There are currently over a million
articles on Wikipedia. Of them 14 (or 0.0014%) are currently permanently
protected, and 43 (or 0.0043%) are currently semi-protected. Of the
semi-protected articles only two appear to be, for want of a better term,
"permanently semi-protected", George W. Bush and Jew; in the case of those
articles, the contributions by IP editors tend to consist almost exclusively
of vandalism, which usually starts up minutes after unprotection. I can't
see how we're facing any sort of crisis at this point.
The argument hinges upon the assumptions such as that it's important
to Wikipedia to a) encourage 1st-time editing or
b) creating different
classes of users is a long-term bad thing.
Given that 99.98% of Wikipedia articles are editable by first time editors,
I'm not seeing the relevance. As for "different classes of users",
we've
always had them, and I can't imagine how we wouldn't have them going
forward. There are admins, bureaucrats, stewards, developers, etc. As
well, because of page move vandalism, IP and new accounts have fewer
abilities than established accounts.
We haven't always had them. Back in the UseMod days there was just
about one class of user. Each year a few new layers of hierarchy and
bureaucracy are added.
Wikipedia is a project which is attempting to create a
great on-line
encyclopedia. That is the goal. Creating an on-line democracy, or
libertarian anarchy, is not the goal.
Right. But one might convincingly argue that certain architectural
principles are central to the success of the project. One important
principle should be that the only reason an article should get more
difficult to improve over time is that it is approaching perfection.
It shouldn't become more difficult because editing would require
engaging a thicket of non-human-understandable templates or dealing
with a 100,000 word document, or satisfying anything other than
objective criteria to make a change.
If Wikipedia articles get frozen in stone we lose in the long run.
Stuff like that.
It's not a coincidence that Wikipedia is a successful project and that
Wikipedia has an open structure, process, and architecture.