On Mon, Dec 1, 2008 at 4:29 AM, Lars Aronsson lars@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.