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 <[email protected]> wrote: > --- On Sat, 26/2/11, John Vandenberg <[email protected]> wrote: > > From: John Vandenberg <[email protected]> > > 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 <[email protected]> > > wrote: > > > On 2/25/11 3:11 PM, John Vandenberg wrote: > > >> On Fri, Feb 25, 2011 at 11:18 PM, <[email protected]> > > 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 > [email protected] > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l > _______________________________________________ foundation-l mailing list [email protected] Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
