Wikimedia Forum/Archives/2013-12

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search
Archive This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

CYR/LAT solution in Serbian Wikipedia

Hello! I would like to learn in detail about principles and technology used in Serbian Wikipedia to create/store/update twin articles in CYR/LAT. I'm from Tatar Wikipedia, where we also write in both Latin and Cyrillic scripts. Our articles are available in either or both scripts (linked via manually added TwinLAT/TwinCYR templates) which is not very convenient.
The need to learn about such principles and technologies is relatively urgent for us, as the issue of ArticleCount has now caused a contentious vote about forced deletion/merging of such articles (closed yesterday), which wouldn't allow people who can use only one script, to contribute into Tatar Wikipedia articles originally created in another script.
History of the issue: Latin script was used for Tatar language in parallel with Arabic from the end of 19th century, gaining wide acceptance by early 1920s, both choked in USSR following Stalin's 1939 decision to enforce Cyrillic. Now predominantly Cyrillic Tatar Wikipedia started as TATLAT by Tatar diaspora outside of Russia, currently ~20% of Tatars live outside of Cyrillic use area. On Dec.24, 2012 Tatarstan parliament has formally approved use of Latin & Arabic scripts again (see TATWIKi CYR article, Radio Free Europe/Radio Liberty published article in TATCYR or Tatar-Inform.ru Tatarstan's official news-agency article in TATLAT). Currently, active user contributions are ~ 50/50 in Latin & Cyrillic. - Frhdkazan (talk) 06:04, 24 October 2013 (UTC)

@Frhdkazan: They use "LanguageConverter". There is already a request to enabled conversion of Tatar (see bugzilla:25537), but it seems to be going nowhere. Maybe you could comment on the bug (you need to register on bugzilla, there are instructions here). PiRSquared17 (talk) 17:32, 24 October 2013 (UTC)
Many thanks. This one was created before 24.12.2012 parliament approved TATLAT script publication, but I'll certainly start from learning how it works. - Frhdkazan (talk) 18:34, 24 October 2013 (UTC)
When you have it working pretty well, could you please submit it as an attachment to that bug (or on gerrit)? PiRSquared17 (talk) 19:41, 24 October 2013 (UTC)
Sure. Please be patient with me though - in my home wiki we face a number of issues somewhat milder than those of Croatian colleagues, so I'll probably concentrate on translating global principles, policies, Wikimedia projects' concepts and other "soft" infrastructure into Tatar here @ Meta first. - Frhdkazan (talk) 11:38, 9 November 2013 (UTC)

Last policy vote in Tatar Wikipedia introduced a ban for creation of LAT-CYR twin articles beginning from Oct.24, 2013: the first one stays, the twin will be a redirect - presumably to make tt.wiki ArticleCount statistics more reliable. At the same time, LAT-CYR twin articles created before that date are to be protected by the previous rule (to keep CYR twins of originally LAT articles). This clearly discriminates against LAT twins deleted in violation of the earlier policy. Would requesting tt.wiki admins to un-delete those be appropriate in this case? -Frhdkazan (talk) 19:37, 1 December 2013 (UTC)

"Signpost"-type newsletter for distribution across WF entities?

OK, I hope that heading makes some sense, and provides some sort of indicator of the proposal here. The Wikipedia Signpost is the English-language weekly bulletin (for lack of a better word) about developments in the English language wikipedia, including news from arbitration, recent promotions to Featured statuses, interviews, etc.

Given that the English wikipedia is probably the most frequently accessed English language entity of the Foundation, I think it might be useful to some of the other entities, like WikiQuote, WikiVoyage, WikiSource, etc., etc., to have some sort of similar bulletin which could be circulated to editors throughout these entities on a user talk page of their choice describing some of the recent developments there, interviews, and possibly, hopefully, collaborations, possibly including collaborations across the WF entities. One example might be a collaboration between wikipedia and WikiQuote for quotes from a given figure. I figure it could easily, at least initially, be a monthly, and maybe distributed in conjunction with the Signpost for those who choose to receive it at their English wikipedia user talk page.

Would anyone here have any interest in maybe helping develop and/or contribute to such a bulletin/newsletter? John Carter (talk) 01:40, 2 December 2013 (UTC)

You are, of course, welcome to start something like this. The closest things to this might be WQ and Wikizine, both of which failed. Wikimedia Highlights also, but that focuses on WMF-internal stuff. It could be distributed with MassMessage. (mail:daily-article-l features articles from various [en] Wikimedia projects) PiRSquared17 (talk) 02:05, 2 December 2013 (UTC)
I'd love to see something like this succeed; it would foster better inter-project coordination, I think. Nevertheless, I think there are logistical problems along the way: finding and retaining contributors will be a challenge, as will getting a readership.
If this idea goes anywhere, please leave me a message, I would like to keep up with it. Tempodivalse [talk] 03:03, 2 December 2013 (UTC)
If this is planned to be included in the Signpost, or distributed alongside with it, I would suggest getting in touch with the Signpost team first. FWIW, the Signpost had/has an irregular but well-received "Sister projects" series covering non-WP Wikimedia projects (to view past issues, go to the most recent one and keep clicking "PREVIOUS 'Sister projects'", or search the yearly archive pages for "Sister projects").
Regarding the Wikimedia Highlights, about half of their news coverage (i.e. disregarding their "Data and Trends" and "Financials" sections which are more of a bookkeeping nature) is about non-WMF items (current example). Anybody is welcome to suggest news to cover at Talk:Wikimedia Highlights - for the upcoming November issue, until next Wednesday, December 4. Keep in mind though that this format is optimized for translation, so the text needs to be concise and of an international nature, and there is only room for about 3-4 such items each month.
You could also take a look at "This month in GLAM", an inter-project newsletter with a specialized topic which will soon complete its third year of continuous publication.
Regards, Tbayer (WMF) (talk) 05:45, 2 December 2013 (UTC)
I don't know if "well-received" is the best way to put it, there has been some criticism over some of the recent editorials attacking Commons, Wikinews, and Wikivoyage. I personally think that a newsletter independent of the English Wikipedia would be better for covering sister projects. --Rschen7754 06:29, 2 December 2013 (UTC)
I think you might mean something else (recent coverage in the Signpost's "News and notes" section). The last issue of the "Sister projects" series (linked above) came out in 2012, and it was usually written by users who were themselves active on the respective sister projects - at least that's how I understood the series when I solicited contributions for it while I was the editor of the Signpost in 2010/11. Regards, Tbayer (WMF) (talk) 06:43, 2 December 2013 (UTC)
Managing something like this ... isn't easy. :-) There are a lot (over 700) wiki projects to keep up with!
What you're describing in some ways overlaps with the Wikimedia blog a bit. It may also overlap with some of the newsletters being distributed regularly (i.e., this list, which includes [for example] a Wikidata-specific distribution list). You should also check out Wikimedia newsletter, of course. --MZMcBride (talk) 06:06, 2 December 2013 (UTC)
I used to do this in WMIT's monthly bulletin for the Italian-language projects (and some other chapters had followed, e.g. WMPL which also had other nice sections). I suspect this sort of thing is impossible nowadays in a broader way, for two connected reasons. First, the editing activity has stalled (almost) everywhere and the very active editors are an increasingly old population: there's just not much to tell in this literary genre during a recession; even when there is, you don't know who you're talking to if any. Second, in each project (with the exception of de.wiki and few others) and even more so globally, I suspect a vanishing of the sense of belonging to "one" community (which has always existed alongside and not above the many niche communities a project is composed of, not above it and not all the time), which you can see e.g. if there's some place where (some relevant portion of the) editors gather to talk each other or not. In short, nowadays the (almost) only hyperactive talkative newbies (excited about everything new they or others did) are paid staff.
In the meanwhile, it's useful if each community, for the benefit on their project and those outside it, maintains a central noticeboard (in the true sense of the word, i.e. a place with announces, not a discussion venue) or calendar listing something more than the usual milestones, e.g. conclusions of big discussion, guidelines/policy changes, results of elections. Even just one line, or just date with a link, is useful for all those who are not there daily and makes the job of the people compiling newsletters and other aggregated material much easier. Even if you don't participate in a sister project in your language, you can still maintain such a thing just by reading all the biggest discussions once in a month or two. --Nemo 06:20, 2 December 2013 (UTC)
Thanks for pointing to Wikimedia newsletter (there is also Internal news media, btw) and to the blog, which welcomes submissions at Wikimedia Blog/Drafts. Regards, Tbayer (WMF) (talk) 06:43, 2 December 2013 (UTC)
Rschen, beware what you wish for: how do you know that "sister" projects wouldn't receive negative editorial coverage in a non-en.WP-based publication? Tony (talk) 10:26, 2 December 2013 (UTC)
Indeed; although there's probably some correlation between Signpost's attacks on sisters and its Wikipedia-based viewpoint, a more basic problem may be the lack of an adequate concept of neutrality as applied to a newsletter. Wikinews has a strong principle of neutrality as it applies to news, particularly designed to help individual reporters to consistently write neutral articles even about topics they have strong opinions on, but it doesn't obviously apply to a newsletter (just for instance, Wikinews pointedly does not run editorials — though it's generally agreed on Wikinews that Signpost's non-neutrality isn't limited to editorials). Wikipedia gets at neutrality by an entirely different route, relying on iterative edits by many editors over time, but that clearly doesn't apply to a newsletter either. It seems a newsletter would need to approach neutrality by some fundamentally different path than either of these. (As a sometime-Wikipedian and current Wikinewsie, I've puzzled over this quite a bit, without so far any great solutions to show for it.) --Pi zero (talk) 17:58, 2 December 2013 (UTC)

FlaggedRevs enabled on meta for Zero namespace only

moved to Meta:Babel. --MF-W 11:15, 5 December 2013 (UTC)

Help:Setting up an internal Wikimedia wiki

Hi. Does anyone know if the page Help:Setting up an internal Wikimedia wiki is still valid? I mean, can local Wikimedia Chapters still request an internal wiki? And if yes, how? (as user User:Cary Bass seems to be inactive.) --vacio 12:48, 5 December 2013 (UTC)

Global JS and CSS

Hello,

I filed bugzilla:57891 which requests the deployment of mw:Extension:GlobalCssJs, to provide real support for global CSS and JS. Any content in at User:username/global.js and User:username/global.css will automatically be loaded on any site where you have an account. MediaWiki:Global.js and MediaWiki:Global.css will also load JS/CSS Wikimedia-wide. Those pages will only work on meta though. Users must have a global account attached both here on meta and the site they are visiting.

One side-effect of this is that if you have your global.js imported via your common.js (example), your JavaScript will be loaded twice, which might cause issues in some scripts. It would be helpful if someone could write a script or tool of some sort that would remove manual inclusions of user's global.js to be run whenever this is deployed.

Just leaving this here as a heads up, it's unlikely to be deployed immediately, but shouldn't take longer than 2-3 months (I hope!). Legoktm (talk) 02:06, 3 December 2013 (UTC)

Great to hear this! :D Would an easy solution be to replace every global.js file with
if (typeof alreadyLoadedGlobalJs === 'undefined') {
    alreadyLoadedGlobalJs = true;
    // <insert old JS here>
}
? If not, should we just delete all the common.js files that just load global.js from Meta using a bot? PiRSquared17 (talk) 02:30, 3 December 2013 (UTC)
That would work as a temporary solution, and would un-break any scripts that have issues due to double-loading, however it would still be making an extra request that doesn't do anything. Legoktm (talk) 03:51, 4 December 2013 (UTC)
"any site" → "any public Wikimedia wiki where you own the global (and local) account", I believe.
For preëxisting global.css/global.js inclusions, we should just write a script to find instances and fix them manually. No bots mucking with users' JS/CSS, please. The new search backend (Extension:CirrusSearch) should be able to do this pretty easily, I think. --MZMcBride (talk) 02:48, 3 December 2013 (UTC)
Correct. To be more specific, it would be any WMF site with CentralAuth installed that is not loginwiki. Legoktm (talk) 03:51, 4 December 2013 (UTC)
And what should users like me do who created a global.js/global.css for most but not all wikis? Will my whole configuration be messed up by this extension if I don't rename them and modify all my local common.js/common.css's? Vogone talk 19:58, 5 December 2013 (UTC)
For now, you can just do what I said above (and I mean to do that to global.js on Meta, not on each wiki). We need a better permanent solution, however. PiRSquared17 (talk) 20:49, 5 December 2013 (UTC)
Hooray! --MF-W 21:09, 3 December 2013 (UTC)

Wikipedia Kids

Hi, just an odd question: is there an interest for a Wikipedia kids? Lotje (talk) 07:00, 10 December 2013 (UTC)

See Wikikids, which is the main and most updated proposal. PiRSquared17 (talk) 18:03, 10 December 2013 (UTC)

Creative Commons 4.0 licenses

I'm just wondering, would there be anything formally stopping us from migrating the Wikimedia projects to use the Creative Commons BY-SA 4.0 license? (as seen in its glory here, plus the details on the changes here) ViperSnake151 (talk) 04:06, 29 November 2013 (UTC)

See wmfblog:2013/11/26/creative-commons-version-4-0, especially the last paragraph. PiRSquared17 (talk) 04:11, 29 November 2013 (UTC)
I just opened a discussion over at the English Wikipedia's village pump. Maybe it should go here instead? Edit: Copied text from there to here:
I believe we should upgrade. CC-BY-SA 4.0 provides a more comprehensive grant of non-copyright rights (e.g. database, moral, privacy and personality rights) if they exist in the relevant jurisdiction and are held by the licensor.
The new license is offered in one international version with deed translations rather than national "ports". It is designed to cover all jurisdictions, which might please international contributors.
It looks like we can upgrade due to clauses in our current license (CC-BY-SA 3.0 Unported):
  • 4(b) "You may Distribute or Publicly Perform an Adaptation only under the terms of:"
    • (2) "a later version of this License with the same License Elements as this License" [Attribution, ShareAlike], and/or
    • (3) "a Creative Commons jurisdiction license (either this or a later license version) that contains the same License Elements as this License"
Other sites may need to upgrade to CC-BY-SA 4.0 to continue to import from us, per the equivalent clause [3(b)(1)]. That might be seen as an advantage, as it drives adoptions of a stronger license. I upgraded WikiFur in minutes; it's not a challenge. (We can import from them regardless, due to the 2.0/3.0 upgrade rights.) GreenReaper (talk) 02:08, 30 November 2013 (UTC)
As I interpret the new license, it would still be necessary to state in the copyright footer that everything added before the license change is licensed under 3.0, but then IANAL. It is, in any case, already possible to upload files under the new licenses to Commons. As for upgrading, note that Wikinews is to this date licensed under CC-BY-2.5. darkweasel94 (talk) 16:17, 29 November 2013 (UTC)
CC-BY-2.5 does not contain a ShareAlike component and so does not contain the upgrade provisions ("You may distribute, publicly display, publicly perform, or publicly digitally perform the Work only under the terms of this License"). GreenReaper (talk) 00:38, 30 November 2013 (UTC)
  • I think there is a real risk that people will perceive 4.0, with its added grant of non-copyright rights, as a threat and start to use older versions to prevent unknown future changes that hand away more rights. Saffron Blaze (talk) 04:51, 30 November 2013 (UTC)
  • Do you mean this? JKadavoor Jee 11:30, 1 December 2013 (UTC)
  • No Jee, in 4.0 the licensor waives certain copyright like rights. This provision was not there in 3.0 and earlier. However I read where people can licence adapted 3.0 works as 4.0 because the "license elements" of BY and SA have not materially changed. This could be construed as a an unwelcome rights grab that could not have been envisioned when originally licensed under 3.0. Did that make sense? Saffron Blaze (talk) 23:19, 3 December 2013 (UTC)
In 4.0 you are giving away rights that you didn't give away in earlier CC-BY-SA versions. These rights have nothing to do with BY-SA license elements. What you are implying is any BY-SA compatible licese is OK for adpations regardless of the additional rights give aways the other license contains? That is absurd. Then you create license templates that don't even link directly to the license text, just the deed, thereby hiding these rights give aways at least one or two layers deep. Free Culture FTW. 131.137.245.207 14:26, 4 December 2013 (UTC)
That's not the case. When an adapted work is released under an upgraded license only the adapted aspects are affected by the upgrade. As such the upgrader can't give away the original author's personality rights (in the case of a selfie). Saffron Blaze (talk) 02:27, 11 December 2013 (UTC)
FYI, Commons is discussing this here. -LVilla (WMF) (talk) 17:57, 2 December 2013 (UTC)
That's okay, as they deal with licenses a lot, but any discussion affecting all wikis should be here, on Meta, like the last Licensing update. PiRSquared17 (talk) 18:13, 2 December 2013 (UTC)
Yes, I agree; that link was merely for reference. -LVilla (WMF) (talk) 18:20, 3 December 2013 (UTC)

Complete Sumary

One large What-is-Wikimedia- answer please. Pending(tell me I screwed up and where)

@Pending: See Wikimedia, wmf:FAQ/en, etc. Basically it is a "movement" with the goal of giving free knowledge to everyone, using wikis (and other collaborative software in the future?). PiRSquared17 (talk) 22:04, 10 December 2013 (UTC)

Community can edit Zero starting page

I have posted an email to wikimedia-l, seeking input on how to manage Wikipedia Zero starting page. This page is different from the www.wikipedia.org because it has to be created differently for each specific telecom partner. Yet, I feel there should be some common HTML inserted there that the community controls, just like the WWW page. Please comment what you would like to see there and what the best process would be to organize it. Remember - this is the page that most new users would see when they follow telecom advertising such as "we now offer wikipedia for free on your mobile device", and most of the users will be from the developing countries, so they might never have heard of us. Thanks! --Yurik (talk) 23:08, 7 December 2013 (UTC)

cf. Wikipedia Zero Starting Page. PiRSquared17 (talk) 20:37, 11 December 2013 (UTC)

Etherpad move

Hello. Since Etherpad is changing, I was wondering whether it would be possible to move all the pads we care about to the new etherpad (and keep a list of authors). Let me clarify: all the pads that are linked from any Wikimedia project, either through an interwiki or external link. Maybe User:Nemo_bis can help to generate the list of pads that are linked-to. I would hate to see broken links. PiRSquared17 (talk) 20:39, 10 December 2013 (UTC)

Nemo had in fact already generated such a list in August (just a few days before the old installation was moved to etherpad-old.wikimedia.org). Regards, Tbayer (WMF) (talk) 21:57, 10 December 2013 (UTC)
That seems to be a list of etherpad.wmflabs.org links, not etherpad.wikimedia.org. PiRSquared17 (talk) 22:01, 10 December 2013 (UTC)
You're right, I misread your question. Note though that, as Alexandros said in the email that you linked, pads were already automatically imported in bulk from the old installation to the new one, so this would be about detecting those where the import script has failed for whatever reason (rather than simply going through all pads linked from the wikis). Also, since this is about long-term archiving and the new Etherpad installation is still discouraged for that purpose, exporting those pads to wiki pages might make more sense. Regards, Tbayer (WMF) (talk) 23:03, 10 December 2013 (UTC)
I had also made a list of etherpad.wikimedia.org pads, at mw:User:Nemo_bis/Etherpad. Those URLs I mostly submitted to the Wayback machine, but nasty JavaScript and unwise robots.txt combined mean that probably it didn't actually save anything. Tilman is right, but I have no idea how to identify pads in a way allowing even just random sampling for errors. Links are not only incomplete but also often wrong, so for instance we've lost several WMCON pads which someone had the bright idea of creating on etherpad.wmflabs.org (nobody should ever have used that instance, but nobody listened to me). --Nemo 00:04, 11 December 2013 (UTC)
Ah, that's more like it. Tilman, unless you know which pads the import-script failed on, I think we should just go through the linked pads and make sure they have been moved. Nemo, can you also check the interwiki links, and HTTPS links? That should cover the most important ones. The easiest solution would obviously be to have the Wayback machine archive them, but the devs don't seem to want to change the robots.txt. PiRSquared17 (talk) 00:21, 11 December 2013 (UTC)
IIRC that page already includes interwiki and https links (though normalised for the sake of deduplication). --Nemo 00:16, 12 December 2013 (UTC)

How has the duration of CU data changed over these years?

I just read some old discussions, and found that in a case in 2007, the CU data seemed to have a duration of 2 weeks, compared to 90 days now.--朝鲜的轮子 (talk) 23:02, 11 December 2013 (UTC)

I expect that two weeks was too short to be practically useful. That said, I was a checkuser in 2007, and I don't recall it ever being two weeks. Could you link to that discussion? --Deskana (talk) 00:22, 12 December 2013 (UTC)
[1]That discussion is in Chinese, which mentioned a case of checkuser on suspected sockpuppetery. At that moment there was no checkusers on CHinese wp, So I think they applied for CU on meta. And the results are like: "some users used the same IP; some users shares some IP; one user did not edit recently, and since CU can only check edits within 2 weeks, nothing can be concluded for this user."--朝鲜的轮子 (talk) 03:26, 12 December 2013 (UTC)

Flow on MediaWiki.org

mw:Talk:Flow: deployed. PiRSquared17 (talk) 23:30, 11 December 2013 (UTC)

The horror. --MF-W 23:53, 11 December 2013 (UTC) (Like I predicted btw. Not that I like to be right. --MF-W 00:05, 12 December 2013 (UTC))

Wikimedia Highlights from November 2013

Highlights from the Wikimedia Foundation Report and the Wikimedia engineering report for November 2013, with a selection of other important events from the Wikimedia movement
Wikimedia Foundation RGB logo with text.svg
About · Subscribe/unsubscribe · Distributed via Global message delivery, 04:48, 12 December 2013 (UTC)

Notifications and Thanks projects

I came here to find more info regarding the Notifications and Thanks projects but all I get is an empty page for Notifications saying it was G7'ed. Should I try to recreate a new page with information, soft-redirect, leave it as is, or do something else with it? TeleComNasSprVen (talk) 18:31, 12 December 2013 (UTC)

You could either write a bit about it or create a soft-redirect. In either case, you should link to mw:Extension:Notifications and its help pages, so interested users can learn more. PiRSquared17 (talk) 18:33, 12 December 2013 (UTC)

Global CSS and JS scripts

Is there a place where personal user settings from Special:MyPage/common.css and Special:MyPage/common.js files would apply globally to all Wikimedia projects? TeleComNasSprVen (talk) 05:01, 13 December 2013 (UTC)

Not yet. There's a related discussion above (#Global JS and CSS). --MZMcBride (talk) 05:05, 13 December 2013 (UTC)
To note that some people have a personal global.js file here at meta, and then call it via resourceloader at each wiki where they edit. So that at least lessens the subsequent amount of editing to be done after you have set up the framework. There is a steward-driven bot that will write the file to wikis that you identify, if you wish to use it for the distribution. — billinghurst sDrewth 10:44, 13 December 2013 (UTC)
Billinghurst is referring to Synchbot. I would personally recommend using Greasemonkey to do this, so we have less of a mess to clean up when we get "real" global JS/CSS. I created this client-side equivalent to Synchbot, but you might want to just wait per the section above. PiRSquared17 (talk) 14:28, 13 December 2013 (UTC)

Wikimedia will obey which country's law enforcement?

[2] says:

It is the policy of Wikimedia that personally identifiable data collected in the server logs, or through records in the database via the CheckUser feature, or through other non-publicly-available methods, may be released by Wikimedia volunteers or staff, in any of the following situations:

In response to a valid subpoena or other compulsory request from law enforcement,

.......

What does it mean? Does it mean Wikimedia volunteers or staff will release personally identifiable data to valid subpoena or other compulsory request from law enforcement from any country? Or US only?--維基小霸王 (talk) 14:32, 5 December 2013 (UTC)

Hi 維基小霸王! Generally, we ask requesting parties to provide us with a valid US subpoena or other compulsory request. While WMF's legal team evaluates every request for personal information on a case-by-case basis and there may be some unforeseeable scenario where we would consider complying with a valid subpoena or other compulsory request from law enforcement originating from a country other than the US, we have not done so in the past and have no plans to do so in the future. Hope that helps. Mpaulson (WMF) (talk) 17:50, 6 December 2013 (UTC)
Hi, I am also interested in this question. So do every Checkuser and other users with access to private data have to consukt WMF's legal team before taking action to release those information? I think it can be a recommendation, but there might be some cases where Checkusers giving out information without letting the community know.--163.125.81.16 00:32, 7 December 2013 (UTC)
Thank you for replying. I have the same question with the ip user. I asked this question after in a checkuser election, one user asked the candidate what he will do if the Chinese authority request the checkuser information from him, and another user responded with the first article of Checkuser policy#Privacy policy.--維基小霸王 (talk) 05:14, 8 December 2013 (UTC)
Can I have an answer?--維基小霸王 (talk) 10:16, 13 December 2013 (UTC)
Hi Anonymous and 維基小霸王. I apologize for not responding sooner. I didn't see that you had responded to my previous post. To answer your question -- no, Checkusers and other users with access to nonpublic information are not currently required to consult WMF's legal team before taking action (although they are more than welcome to). The new Access to Nonpublic Information Policy draft, if approved by the Board, explains under what circumstances a user may disclose user information and would require users to notify the Foundation of disclosures under certain circumstances within 10 days of such disclosure. The policy draft is still in the community consultation period, so I very much encourage you to voice your opinions and concerns in the discussion page. Mpaulson (WMF) (talk) 20:27, 16 December 2013 (UTC)

renaming of user

I ask members to rename participants name offends Muslims. Account created for vandalism. -- Дагиров Умар (talk) 16:14, 24 December 2013 (UTC)

What is the name of the party is not important. -- Дагиров Умар (talk) 17:04, 24 December 2013 (UTC)
The account has already been blocked for a year, and very few accounts are resurrected after that long a block. For the curious, the account name translates approximately as "Goat God's-son". I might be (barely) willing to believe that this could be a reference to en:Pan (god) of Greek mythology, except that the only (visible) edit is a request to change the account name to something that begins with "Prophet". WhatamIdoing (talk) 19:41, 24 December 2013 (UTC)
Hello. There wasn't "Goat God's-son", but exactly "Goat Allah's-son", so it wasn't Greek mythology, as you see. But I think that Umar can hide this name technically as sysop.--Soul Train (talk) 08:29, 25 December 2013 (UTC)

How can I apply to hide some of my personal information via oversight?

Hi, I have once posted some personal information on some page. Though I asked administrators to remove these revisions, I think removal via oversight would be more complete since those revisions would not be available to local adminstrators. My local wiki does not have oversights now, and I don't know where to apply for oversight now.--Nuwath (talk) 04:39, 25 December 2013 (UTC)

You can email stewards at wikimedia dot org. --Rschen7754 04:40, 25 December 2013 (UTC)

Diversifying Editors and Augmenting Information Sources

I read MIT Technological Review's article The Decline of Wikipedia: Even As More People Than Ever Rely on It, Fewer People Create It. It raises some very interesting issues.

I would like to suggest an idea that would hopefully serve to attract new editors from diverse backgrounds; thereby alleviating the problems identified in the article. Furthermore, I hope this suggestion would go towards improving Wikipedia overall.

I would like to start off with three observations:

1: Writing a good article requires two very different types of work: the accumulation of factual information, and its expression in a single, consolidated, well-organized, coherent, clear, fluid piece of writing.

2: The latter requires practice. Experienced Wikipedians have honed their skills (dating back to when the quality standards were more forgiving), and it is unrealistic to expect most newcomers to meet this standard right away.

3: Writing a decent article requires significant effort, especially for the inexperienced. Many people who are not currently editors may very well be reluctant to invest the required time and effort.

As observed in the article, social networking sites such as Facebook and Twitter excel at aggregating information. Many people generate quite a lot of data - some even publish books consisting of their Tweets. Still, it should be noted that the effort expended is cumulative; each entry is as simple as putting down a sentence or two. It is not an undertaking.

My suggestion is to implement a system that takes advantage of this phenomenon in the accumulation of factual information for Wikipedia articles. In essence, everyone should be able to submit chunks of information that are associated with a particular topic. This information would be aggregated and processed. This processing should include clever magic, grouping and consolidating submissions that are referring to the same thing. What should emerge is a crowd-sourced brainstorm map that spans the topic. The idea is to present this as a guide to the editor who does the actual writing. This editor stitches together the information that has been laid out before him/her, creating a well-formed article.

The submissions should carry the features of social networking, so that contributors can be acknowledged. It is important to enable the contributors to track the inclusion of their knowledge into the article. Perhaps such contributors will later on take a step towards being an actual editor.

Each submission could become more prominent through popularity (i.e. more people submitting the same thing) or quality (a submission widely acknowledged by the community). New concepts relating to particular topics becoming prominent can prompt for the related articles to be updated to include them.

The key is to facilitate the process of submitting raw knowledge into Wikipedia. Not only does it broaden Wikipedia's sources, it also involves more people in the system. —The preceding unsigned comment was added by Oralokan (talk)

Have you looked into mw:Article feedback? The last versions tried to do something like that, in a way. Long story short: it didn't go well, most readers have no idea what's ok for an encyclopedia. "Proposed text" goes straight into articles and then gets refactored; it's not obvious that the problem to address is an insufficient number of such raw submissions and/or of manpower to review them, as you argue. --Nemo 12:16, 19 December 2013 (UTC)
May be we could have a system in which each article has a list of raw submissions. They are inernally signed automatically by their submitter, and then displayed in an abbreviated list (with also an automatic summary generated from the start of the sentence. The tool could be limited to one per user, until the submission is accepted by enough positive votes, or when the submitter reaches the autovalidation level.
Formatting the content would be not critical, in fact the presention would not matter much ad should be limited (no use of templates for example, basic Wiki syntax, or probably not more than preformated plain text. These submissions would be non modifiable by others except by the submitter (admins however could hide some of them if the are spamming the list). Also the content length would be limited for exampel to 4KB (this would force the sumitters to create abstracts or provide a link to some external source. Of ourse these submissions would be licenced in the same condition as the rest of the Wikimedia site content.
Then other users would interact only by voting positively or negatively for the exposed idea or fact. These votes would be used to order the list by relevance.
The sorted list could be used by article reviewers to insert the missing contents or corrections that appear at top of the list: the wiki editor would allow select an item in the list to insert it in the article. This would automatically purge the proposed item from the list of proposals. Then the reviewer would reformat the inserted content (the wikieditor would maintain internally the link to the proposal, which will be marked as handled only when the newly edited page is validated by the reviewer.
The proposed items could also be attached in the article with a position like if it was a sticker note or post-it. Reviewers could hide/display these notes in the article (reviewer could reposition temporarily these notes during the edit, the new position would only be saved when the reviewer submits the validated page. When saving the page, several versions would be applied at the same time: one for each intem coming from an accepted proposal, followed by the version of the reviweer after he has edited/formated the proposed content. The reviewer could also keep the note attached if the integration is incomplete, by marking the integrated parts with "del" marks (by default a note would be fully considered handled, but the reviewer could just indicate that he only used a part of the proposal, leaving the rest to be handled later (this is the only case where a note will be versioned by others than the submitter).
The concept could be used to manage "TODO" lists in an article, including by the reviewer itself would could post its own ideas).
None of these notes would be visible when reading the article (but a small banner or icon indicator at top of page could indicate the presence of notes attached to the page by submitters, and clicking it would reveal them either in a side list, and optionally as positioned notes when selecting an item from the list ordered by relevance/votes). These accepted notes could be also posted verbatim in the talk page once they are handled and have been accepted.
Notes that go below a too low negative ranking would be eliminated or could be eliminated by reviewers.
It would be a simplified version of the current review system for semi-protected pages that require approval, but it could still work on protected pages. verdy_p (talk) 21:01, 29 December 2013 (UTC)