[WikiEN-l] Re: Sub-stub city

Mon Aug 9 02:10:30 UTC 2004

see below :-)

On 9 Aug 2004, at 03:23, Daniel Mayer <maveric149 at yahoo.com> wrote:

> Message: 6
> Date: Sun, 8 Aug 2004 18:10:09 -0700 (PDT)
> From: Daniel Mayer <maveric149 at yahoo.com>
> Subject: Re: [WikiEN-l] Re: Sub-stub city
> To: English Wikipedia <wikien-l at Wikipedia.org>
> Message-ID: <20040809011009.77996.qmail at web51606.mail.yahoo.com>
> Content-Type: text/plain; charset=us-ascii
>
> --- Timwi <timwi at gmx.net> wrote:
>> ...
>> Wikipedia brags about its self-healing abilities. People patrolling RC
>> and NP are valuable because they make this self-healing work. The
>> "correct" way to "fix" this situation is what Daniel Mayer mentioned:
>> Allowing logged-in users (or only admins) to "flag" an edit to show
>> others that it's been looked at. This eliminates duplicate work, but 
>> it
>> does not restrict the ability of anyone to post new articles or make 
>> any
>> other edit.
>
> If we did have such a team-based approach to patrol, then we may be 
> able to
> delay having to start locking things up for some time - perhaps 
> indefinitely.
>
> So yes, that would be the best of all proposed options.
>
> -- Daniel Mayer (aka mav)

Couple of points:
1. <AOL>Me too!!!</AOL> -- translation: I agree that an "I'm already 
looking at it" flag would reduce a lot of work and frustration AND make 
it very visible that Ed Stubhunter isn't the only poor soul out there 
struggling against the deluge. This is the best solution to the said 
problems, NOT a 200b limit.
2. Remember Sturgeon's Law: Ninety percent of everything is crap. -- 
Why am I saying that? Well, 90% of WP articles that are written new are 
curd. JUST LIKE 90% of everything else is. 90% fluff stubs may LOOK 
alarming (especially if you're only looking at new articles), but the 
secret of our success lies in our cycle of incremental improvement, 
which is what allows us to exceed the 90% rate by far. But looking at 
the things that stand at the very beginning of that cycle, it just 
shouldn't alarm or surprise _anybody_ that there's a lotta Mullarkey 
out there. (Hey, and I /know/ Sturgeon's Law is not a natural law. I'm 
making a point here.)
3. Have a break. -- Again, if you're sifting through new articles and 
stubs all day, it WILL get very frustrating very quickly. See point 
(2). So don't. Don't feel you had to fight the good fight 
uninterruptedly. You don't. If you're an eager stubhunter, enjoy some 
mature articles in-between. It will help you and re-adjust your 
perception.
4. I acknowledge the 200b limit is not a totally insane idea. I can see 
the sense and rationale in it. I just don't think is the way to go.
5. It still takes people time to discover the Wikipedia and figure it 
out. It took me months and years after first seeing it, before I 
finally stopped browsing past it ("Just another webbased 
definition/article DB. Next.") and finally actually looked at it enough 
to realize "Hey, I can REALLY EDIT THIS and do great stuff here." On a 
similar vein, it took me an hour or so to explain the workings (and 
incredible proposition) of the Wikipedia to an alert and studied 
intellectual. Why am I saying this? - Well, we need to have _as few as 
possible_ bars to entry. See next point.
6. Not only is the ad-nauseam repeated point about stubs growing into 
brilliant articles nevertheless true, but - MUCH more importantly: 
Fluff _contributors_ grow into valuable and respected Wikipedians. Lets 
not raise the bar for entry. For the sake of future Wikipedians, who 
will soon go beyond writing fluff. Their future contributions are worth 
their erstwhile fluff articles many times over. (And if existing, loyal 
Wikipedians really do keep writing silly stubs -- that's what Talk 
pages are for.)

Thanks and regards,
Jens Ropers

There are two types of IT techs: The ones who watch soap operas and the 
ones who watch progress bars.
http://www.ropersonline.com/elmo/#108681741955837683

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 3979 bytes
Desc: not available
Url : http://lists.wikimedia.org/pipermail/wikien-l/attachments/20040809/cf0c6072/attachment.bin 