[Foundation-l] breaking English Wikipedia apart

FT2 ft2.wiki at gmail.com
Mon Mar 14 11:35:25 UTC 2011


During the strategy taskforce, the quality team came to two conclusions that
are similar to some ideas in this thread, but avoid the issues mentioned.

We didn't consider breaking up the projects, but we did feel that the
concept of subject-related collaboration (ie WikiProjects) were not being
used to best advantage. We considered it could help the project if
WikiProjects were accessible between different wikis, so that users would
more commonly work with others on a topic area and gain from doing so.
 Specifically
we thought about the advantages of global WikiProjects. By way of example, a
global MilHist WikiProject would allow all editors with an interest in
Military History to collaborate across different wikis. It would give users
editing in that field in small wikis access to the resources, information,
collaborative support of those on larger projects and users on larger
projects access to knowledge from countries they might not cover well for
lack of knowledge. It would mean that sources could be located in foreign
languages (including English sources which are "foreign" on most wikis by
definition). Users who might feel isolated could find peers on other
projects in the same field. Knowledge could better flow between wikis to the
benefit of smaller projects needing help.  users who might be the only ones
focusing on a topic area on a smaller wiki could be part of a larger
collaboration on that subject with users from other cultures rather than
isolated.  It would also mean that experts who did not want to argue with
trolls, high school editors or POV warriors could have a more clear role
where they could help, providing responses and reviewing articles as
requested, within the topic area WikiProject, where trolling is unlikely.
(To clarify one point,  the concept is one of collaborative editorship and
support across projects, we rejected any kind of control over articles or
wikis, nor overriding local WikiProjects)

The other thing we thought was that there is benefit in recognizing editors
whom the community agrees are competent, edit well sourced neutral good
quality material, and act well, across the board.  If that's what we want
then let's find ways to develop and encourage it.  At the moment adminship
is granted following a searching process but there is no equivalent for
editors who seek recognition as competent and consistently good quality
editors.  If there were some way to communally recognize such users (call
them "proven editors" lacking a better term) it would have some immense
advantages.  Right now every editor who is autoconfirmed but doesn't write
FA's is pretty much in the same category of editorship. Newcomers can't
distinguish those who edit well and those not shown to edit well. Users
should be helped to improve themselves as editors - setting some kind of
formal recognition they can achieve will help focus that. Recognition becomes
something all good-faith users aspire to, and once acquired they will not
want to lose it by poor editing or poor conduct.  So it locks in our goals
as a community (good editors) and aligns them with a personal motive.

The aim is to make recognition of this kind very widespread within the
community and to actively coach and encourage uptake and success -- a
recognition routinely won by many editors who have been active for over a
year or so.  It means that one can see easily in an article history which
edits were made by users the community recognizes as proven editors and one
can focus on other edits for issues. It encourages holders to act to the
standards expected and encourages others to seek that recognition for
themselves, and therefore to learn to be better editors.  In edit wars it
provides a bias towards endorsement of probably better edits. In the case of
massively disputed topics such as ethnic wars it provides a dispute
resolution tool - editing might be restricted for a time to those editors
considered "proven" by the community. Finally it is egalitarian (or at least
as much so as anything on the wikis) -- it is a recognition anyone can
achieve from the community by editing and behaving well, and anyone can lose
by editing or behaving to a visibly poor standard. It carries no formal
powers, but by peer pressure alone encourages improvement generally.
Two ideas.

FT2



On Mon, Mar 14, 2011 at 10:13 AM, Andreas Kolbe <jayen466 at yahoo.com> wrote:

> --- 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?
>
>
>
>
> _______________________________________________
> foundation-l mailing list
> foundation-l at lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>


More information about the foundation-l mailing list