On Mon, Dec 1, 2008 at 4:29 AM, Lars Aronsson <lars(a)aronsson.se> wrote:
After some more thought on the origins of stub
articles and a
better overview of the contents of the Swedish Wikipedia, it is
clear that very few individuals are responsible for creating large
numbers of stubs, a few years back. Now, depending on religion
(mergists, deletionists...), these should either be deleted,
improved, merged or put on lists of necessary quality
improvements. Either way, it's a lot of work and it would have
been better to have stopped those invidiuals back then. At least
we want to stop such individuals today, so the same mistake isn't
repeated while the old mess is being cleaned up.
That depends on your point of view. An inclusionist might well say
that they should be kept and improved, but that in the meantime,
better to have the stubs than not. After all, that might encourage
people to improve them more than having nothing at all; it allows them
to be categorized so that people interested in the subject can go
through the stubs in their specialty systematically; a couple of
sentences can sometimes be useful; etc. That would be my personal
position, in fact.
But instead of increased patrolling and speedy
deletions, this
could be implemented in the Mediawiki software. If a user (logged
in or IP address) tries to create a new page, their recent
contribution history could be checked, and if any of their five
most recently created articles (except redirects) are shorter
than, say, 300 bytes, they would simply be unable to create
another article. This would be a very soft kind of blocking (as
soon as you have improved your existing article, you can start the
next one), each case being completely an affair between the user
and the software, not involving opinions of individual admins.
Such an extension (is there an "article creation hook"?) could be
fully parameterized, so each community could decide where to set
the limits (5 recently created articles, 300 bytes), and what
message to show to the user who violates these limits.
It would be quite easy to do this. However, usually we shy away from
granular access control in the software. The usual thought is that
this sort of policy should be enforced by the community, not the
software. Rather than outright blocking edits, people could keep an
eye on article creation and suggest to prolific stub creators that
they spend more effort on each article. Likewise there's no facility
for blocking a user from a specific activity (e.g., a specific page,
namespace, uploading, etc.): just tell them not to do it, and threaten
to block them from everything if they refuse.
Of course, I'm not the one who gets to decide whether a particular
extension should be allowed, so this is just my take on it.