[Foundation-l] breaking English Wikipedia apart

Andreas Kolbe jayen466 at yahoo.com
Mon Mar 14 10:13:33 UTC 2011


--- On Sat, 26/2/11, John Vandenberg <jayvdb at gmail.com> wrote:
> From: John Vandenberg <jayvdb at gmail.com>
> Was: Re: [Foundation-l] Friendliness
> (was: Missing Wikipedians: An Essay)
> Was: Re: [Foundation-l] Friendliness
> 
> On Sat, Feb 26, 2011 at 10:17 AM, Ryan Kaldari <rkaldari at wikimedia.org>
> wrote:
> > On 2/25/11 3:11 PM, John Vandenberg wrote:
> >> On Fri, Feb 25, 2011 at 11:18 PM,  <dex2000 at pc.dk>
> wrote:
> >>> ..
> >>> I think it could also be considered to divide
> our huge language wikis
> >>> into smaller parts. The existing WikiProjects
> could be made virtual wikis
> >>> with their own admins, recent changes etc.
> That way, each project is in
> >>> fact like a small wiki to which the newbie
> could sign up according to
> >>> 'hers' area of interest and where the clarrity
> and friendlier atmosphere
> >>> of the smaller wikis could prevail.
> >>
> >> This is the best solution, in my opinion.
> >
> > Yes, the larger wikis need to become
> WikiProject-centric. First step in
> > doing this would be to create a WikiProject namespace.
> Second step would
> > be to make WikiProject article tagging/assessment part
> of the software
> > instead of template-based.
> 
> I can see how those would be useful steps, however I think
> those steps
> are part of a 10 year plan.
> 
> A 10 year plan will be overrun by events.
> 
> We need a much more direct plan.
> 
> I recommend breaking enWP apart by finding easy chunks and
> moving them
> to a separate instance, and having readonly copies on the
> main project
> like we do for File: pages from Commons.
> 
> IMO, the simplest and most useful set of articles to break
> apart is BLPs.
> The criteria is really simple, and those articles already
> have lots of
> policy differences around them.
> 
> By the time we have perfected this system with the BLPs,
> the community
> will have come to understand the costs/benefits of moving
> other
> clusters of articles to separate projects, and we'll see
> other
> clusters of articles migrated to sub-projects.
> 
> btw, this idea is not new, but maybe its time has come.
> http://wikipediareview.com/index.php?showtopic=29729
> 
> --
> John Vandenberg


Rather than breaking the project up, one way to achieve the same thing would 
be to apply a type of protection to BLPs that restricts BLP editing to 
users who have a "BLP flag" set on their account. Having that flag would be
like having a user right, a privilege that can be earned or lost, for 
example by adding unsourced negative material to a BLP.

In terms of administration, you could create a noticeboard where non-policy-
compliant edits are reported, along with an elected BLP committee that can 
remove the flag from an account for a certain time period, just like arbcom 
does desysops today. I guess the rules would need to be applied leniently at 
first, to allow newbies to learn, and to avoid excessive drama. Perhaps a 
three-strikes-and-you're-out system might work to address good-faith errors
(edits that are correctly sourced but constitute undue weight, etc.).

One thing is certain: reducing the number of people able to edit BLPs would
make BLPs a lot more stable, and less likely to contain libel or vandalism.

It would reduce the amount of real-life drama for BLP subjects and OTRS
volunteers - see

http://www.independent.co.uk/opinion/commentators/fisk/robert-fisk-caught-in-the-deadly-web-of-the-internet-445561.html

while probably increasing the amount of drama inside Wikipedia. That's a
problem, but in the end, if you think about it, the concerns of BLP subjects
should take precedence over community concerns. It's just a question of
being responsible about things; losing the BLP flag doesn't ruin anyone's 
life, whereas losing the ability to travel because of what a Wikipedia article
says about you does.

Not sure how you'd handle the ability of newbie accounts to create BLPs. It 
would be invidious for a new account to be able to create a poorly sourced 
but good-faith BLP, and then not be able to correct a typo once it's been 
categorised as a BLP.

Thoughts? 


      



More information about the foundation-l mailing list