I like the way it was changed yesterday. Now once again old-fashioned.

Blue for our talk page messages.

Orange for our Username getting pinged, mentioned in any discussion.

Green for our created pages getting patrolled and when we receive thanks for our edits.

Red when we are warned or other negative things.--Action Hero Shoot! 14:31, 15 September 2015 (UTC)

Hey Action Hero: looks like the change is only temporary. HTH, --Elitre (WMF) (talk) 14:57, 15 September 2015 (UTC)

As the Orangemoody case has illustrated, our new page patrol is vulnerable to circumvention via sockpuppets. It also suffers from ongoing patroller competence issues. Is it time to add a "patroller" user right to help manage these problems? VQuakr (talk) 04:17, 8 September 2015 (UTC)

Better solution: Make it more like "auto-confirmed" (with rarely-used corresponding "patroller" and "no-patroller" user-rights). As a "straw" example I would say to have the "auto" right you would need to have "10 articles/1000 edits/90 days" or "0 articles/4000 edits/1 year" under your belt, where the articles must be at least 7 days old/7 days as an article (i.e. recently moved drafts don't count), at least a certain size (say, 100 bytes), and not up for deletion to count. davidwr/(talk)/(contribs) 04:38, 8 September 2015 (UTC)

Any barrier to reviewing with a new account would be in improvement, but in the abuse case linked above the sockmaster just did dummy edits to game autoconfirmed. Similar "automatic" permissions would similarly be gameable, and would not invite the scrutiny that comes with assigning a permission. Unlike autoconfirmed, a patroller right is one that most editors would not need or use. VQuakr (talk) 04:44, 8 September 2015 (UTC)

I can't see how making it "non-automated" would improve anything with respect to sophisticated sock-farms like Orangemoody case. With such socks, sockmaster would learn the rules and the sockpuppets would fool the admins. The only difference is that either it would suck up admins' time or the admins wouldn't spend more than a minute or two and their "investigation" would be pretty mechanical which would be the de facto equivalent of an "auto-" right except you have to ask for it. In short, this user-right won't be of benefit against sophisticated cases like this, but it probably will help against less-sophisticated sock-farms. Also, there is one big advantage to an "auto-" right vs. a "regular" right: If I'm an experienced editor and I decide on a whim I want to patrol pages today, I don't have to wait for the right to be granted to me. davidwr/(talk)/(contribs) 05:06, 8 September 2015 (UTC)

As someone who started contributing on the new page patrol, no one should start contributing on the new page patrol. I made plenty of mistakes despite reading the relevant policies because I didn't have the experience of context to tag pages properly, and I wouldn't expect any new user to do much better in those circumstances. A user right for patrolling pages is definitely appropriate due to both the Orangemoody incident and the desirability of experienced editors doing the patrolling, so long as the requirements are somewhat low. I'd suggest 45 days, a minimum of 250 or 500 edits, and a demonstrable history of significant edits (to combat the use of slight copyedits or addition of links to reach the threshold, as was the case in Orangemoody). If we go much higher than that, we risk increasing the backlog of the new page patrol significantly. ~ Rob^Talk 05:02, 8 September 2015 (UTC)

Good point. If the backlog gets too long then we might as well ditch "patrolling" entirely. davidwr/(talk)/(contribs) 05:06, 8 September 2015 (UTC)

I don't know who orangemoody is, but his topic definitely desereves attention. I have been the target of many, many undeserved speedy notices by patrollers. I realize not everyone agrees they were undeserved and will be happy to provide some diffs (but only if this is of interest and if I can take my time collecting them). Ottawahitech (talk) 11:38, 8 September 2015 (UTC)

Good to hear from you, Ottawahitech! I hope you have been well. I linked an article about Orangemoody in my post at the start of the section: short story, it was/is a complex exploit of Wikipedia's web presence and open nature to try to extort money from innocent victims. Gaming the new page patrol was a part of that exploit. I don't think diffs are necessary at this time, though, since there is ample evidence of a problem needing a solution here. VQuakr (talk) 21:27, 8 September 2015 (UTC)

Nice to see a familiar face, VQuakr. I wonder why it took such a scandal to finally acknowledge a problem that has been obvious even to someone as clueless as me for years. Are you sure BTW that this acknowledgement is shared by editors who are not participating in this particular thread? Ottawahitech (talk) 13:37, 9 September 2015 (UTC)

• I had suggested something similar at the idea lab: restrict patrol to pending changes reviewers and admins, and possibly create an additional patroller group. There are basically four options :

1. a unique usergroup of reviewers / patrollers
2. two distinct groups with reviewers able to patrol
3. two distinct groups with patrollers able to review
4. two distinct and separate usergroups.

Going with #1 is the simplest option, since many (but not all) users active at NPP are reviewers in the first place, while #4 would involve significant work for admins. #2 would ensure a significant user base for NPP from the start, mitigating concerns of increase in the backlog, and makes more sense than #3.

So I support #2: remove 'patrol' from autoconfirmed, create a new patroller usergroup with 'patrol', but let reviewers 'patrol'. Cenarium (talk) 15:00, 8 September 2015 (UTC)

• • Alternatively, we could introduce a distinct user right but keep "patrol" attached to autoconfirmed for 30 days, giving patrollers a chance to request the right before it's taken away from autoconfirmed users. This would solve the problem of an increase in the backlog during transition to #4. ~ Rob^Talk 15:47, 8 September 2015 (UTC)
• I will simply repeat a portion of what I had to say over at the Idea Lab since this is where the discussion is taking place.

  Whatever regime we set up a dedicated commercial enterprise can find a way around it. It would take some time to work up an account with whatever "NPP reviewer" user-right but it is trivial when there is money on the table. At that point our best option is tying the user right to the Terms of Use by saying anyone with the 'NPP user right' may not receive compensation for their editing (with the usual carve outs for GLAM, WiR, employees of the Foundation etc.). As to detecting Orangemoody type things that requires either mentoring or a lot of experience. AGF ties our hands because we are suposed to deal with each new editor as a naive but well-intentioned person who just needs some proper guidance and each NPP must figure out how to manage that. I have never seen anything that tells us how to spot and deal with bad-faith paid editors etc. If we try to figure it out we are called 'deletionist' and 'over-zealous' which sooner or later leads to people giving up or becoming ass-holes with a smaller number figuring out how to manage on their own. Of course giving guidance on recognizing articles being pushed by puppet-farms will become useless almost as soon as they are posted. It would be so much easier if we just had a WP:CABAL controlling NPP :)[1]

  The only thing we can really do is increase the time/cost required to create an account that can pass our patroler-right criteria. I would also not support and automatic granting of the right upon passing a threshold. One possibility would be to make being confirmed with the user right a two stage process where the NPP is reviewed after 30 days or so by the admin who granted the right or another admin to make sure the right is 1) being used and 2) being used properly. I know this would be a bit of a time sink for our overworked admin corps, particularly when rolling out the new user right (How to grant this right when it is first introduced will have its own logistical and policy questions to be answered) but having a second stage review means even bad-faith accounts must contribute positive work to the project and spend time to do so thereby raising the cost of subverting our system. Jbh^Talk 15:24, 8 September 2015 (UTC)

@Jbhunley: re admin workload, only the actual addition and removal of the permission would need an admin flag. Follow-up "policing" of patrollers can be done via peer review by non-admins. We already have WP:NPP/N for a similar purpose. VQuakr (talk) 19:32, 8 September 2015 (UTC)

@VQuakr: The peer review would be useful to provide adequate feedback to 'grow' good NPP but what I was proposing, probably not clearly, is that the process go something like this:

1. An editor who has (some minimum criteria set by policy) makes a request for NPP-user-right and says they intend to perform new page patrols.
2. Admin looks over request and if no red flags pop up they grant the right. (this is where it would typically end)
3. In 30 or so days another admin (or maybe an NPP peer) reviews the contributions of the editor and makes sure that they have done some minimum number of patrols (say minimim 50 bright-line) and they are correct and do not show any bad behaviors like working in tandem with another editor to get non policy compliant articles into Wikipedia.
4. If the editors fails the, call it 30 day, review the NPP-user-right is removed which is why the admins will see a workload increase beyond what they would see for Rollback or Reviewer as they now are.

This will do several things. First it will insure competence, which can not really be checked before an editor starts doing NPP. It will cut down on hat collecting by insuring that editors with the right are willing to do the work. Most importantly from the perspective of preventing commercial editing rings self-patrolling their articles it increases the cost of getting the right. Time must be spent to get the minimum standards and they must actually learn the page creation policies to stand up to the initial review. A further benefit is that by having an established review process there will be a cadre of editors who can do spot checks of NPP editors and there will be a place to address problems that come up.

Since one of the major purposes of this user right is to prevent paid editing rings from inserting material into Wikipedia without review we must remember that all advanced user rights have an actual cash value to a commercial editing ring. The only way to limit the number of times our process will be subverted is to make the investment in time (Both in account age and work to build 'trust' and policy learning curve) more than or very close to the actual cash value of having the user right. I know that it is kind of bureaucratic and that is antithetical to many Wikipedians but erecting barriers to entry that do not restrict good-faith editors (beyond proving competence) is really the only defense volunteers have against those who are trying to make money off of the project. Jbh^Talk 20:36, 8 September 2015 (UTC)

• Absolutely we need this. As for who gets it, I would say a handful of CSD tags accurately added or removed would be the best qualification for this userright. Aside from future Orangemoody type incidents, a big advantage of such a userright is that it could be easily taken away when needed. I've declined quite a few speedies, many were isolated errors by people who were trying to do the thing correctly, some were correct when the article was tagged but rendered incorrect by subsequent edits to the article. But we do get patrollers who insist on their own interpretation of the speedy deletion criteria. ϢereSpielChequers 15:50, 8 September 2015 (UTC)

• It is indeed absolutely time to focus on the introduction of a minimum set of qualifications for New Page Patroller. As I have stated many times over the years, NPP is our only firewall against unwanted new articles and as an essential core process it needs an almost admin level of clue. Paradoxically, the far less important AfC project requires 500 mainspace edits and 90 days (which I introduced).

The brilliant suite of Page Curation tools that The Blade of the Northern Lights, WereSpielChequers, Scottywong and I fought tooth and nail for has greatly reduced the backlog from over 30,000 to a 'mere' 3,000 articles, but is still of course only as good as the people who can use it intelligently and in the manner for which we had it designed.

Concomitant with the launch of the Page Curation system it was originally intended to introduce a user right for it but at the time, this did not get done. It therefore remains an anomaly that unlike all the functions such as Counter-vandalism and Pending Changes, etc, the essential operation of NPP requires neither training, experience, nor special rights. and in any 1-hour session I spend on NPP, most of my my operations are correcting wrong tags, declining CSD (or changing the criteria), unpartrolling and tagging where tags were not applied, notifiing creators so that they can address the tagged issues, and much more. It's very frustrating that we can't trust our patrollers to do a reasonably good job and it's of even greater concern that no one wants to do anything about it while at AfC for the few pages that pass through their portal, there is more action and noise than at a Mad Hatter's tea party, and our NPP noticeboard and talk page often remain dormant for months.

I strongly suggest bundling AfC reviewier, New Page Patroller, and PC reviewer into one user right with a relatively high threshold. This would reduce bureaucracy, increase the quality of reviewing, and reduce the number of coat pegs for the hat collectors. Moreover, it would technically pave the way for the merging of AfC to NPP for which we already have a consensus.

A proper RfC needs to be launched at Wikipedia:New pages patrol/RfC for a user right for which we are already waiting on some requested stats and tables, and are already redesigning the NPP main page. VQuakr has already designed the dedicated noticeboard and the training department has been created. A lot has been going on and perhaps DGG could weigh in because I understand he also has some interesting ideas. Kudpung กุดผึ้ง (talk) 16:28, 8 September 2015 (UTC)

A "trusted editor" flag with those rights does make sense and reduce the paperwork. Admin granted but with a threshold to give guidance in policy. Dennis Brown - 2¢ 16:38, 8 September 2015 (UTC)

FWIW, I personally don't think that PC reviewer needs to be included in this new NPP right, and should remain a separate thing. PC reviewer is actually useful to the protect in its own right. --IJBall (contribs • talk) 20:26, 8 September 2015 (UTC)

• I was previously very hostile to such an idea, and I'm still quite skeptical of it, but in light of recent developments I must admit we need a minimum bar for new page patrolling. However, I would never support such a high bar as "10 articles/1000 edits/90 days" or "0 articles/4000 edits/1 year". I propose that our NPP system be based upon our current methods for anti-vandalism. We would set up a patroller userright, similar to the 'rollback' right for anti-vandalism. When it is implemented, we would need to more widely advertise the NPP academy, similar to the CVUA. Once the program is completed, the user could apply for the right at WP:RFPERM. I would also be in favor of automatically adding the right to the reviewer package; a person trusted with reviewer would likely be competent enough to review new pages. We might also still allow manual page patrolling (e.g., without the New Pages Feed), as we allow manual reversion without rollback through Special:RecentChanges. --Biblioworm 17:08, 8 September 2015 (UTC)
• I strongly support a dedicated "patroller" right. Wikipedia patrolling quality is slowly but surely approaching nil. However, the bar should focus more on trust and treatment of new page patrolling as serious, not as a shooter game; rather than high standards and inflated requirements. Esquivalience ^t 02:52, 12 September 2015 (UTC)
• A patroller right sounds like a good idea. While, yes, as some people have said above, a financially-motivated bad actor might just acquire the right, having to do so will make their schemes more difficult and easier to expose -- if it takes 100 mainspace edits to get patroller rights, then they will either have to invest time in each patrolling account (and risk discovery if they try to cheat with quick automatic edits), or use a small number of patrolling accounts, and risk discovery if someone notices any unusual patterns in the pages they patrol with them. --Aquillion (talk) 05:40, 12 September 2015 (UTC)
• The problem of performing NPP is the same as that of reviewing RfCs, and the same user right is needed. I would support a high bar for automatic assignment of the right, with the understanding it could be assigned to lower levels also. The NPP portion would still permit tagging new pages, but not marking them as patrolled. The RfC portion would still permit making comments. If the bar is set high enough, this could replace the autopatrolled user right, which exempts the person from needing their articles to be checked. For a grant of the right, I do not think it should require the creation of articles--many--perhaps most--of our most effective reviewers and patrollers have made very few articles from scratch, some of them none at all. I do not disagree with the possibility for automatic grant of the right, but there are many possible hang-ups. Automatic granting should d require creation of articles, but I do not know if this can be automated. For automatic assignment, I would set the bar at a level that would very thoroughly discourage the technique of creating multiple sockpuppets with it, and I think that at least 90 days and 500 edits. (of course, Anyone who deserves it in good faith before that--and many people would--can simply ask for it.) It would be granted -- and removed by admins; I don't see how we could prevent overcoming the removal by reaching the automatic level. I like the earlier suggestion that the first grant be for a limited period & require checking, and I don't see how this checking process could be automated either. A few paid editors do good reviewing, sand deserve the right, but they should never qualify automatically, and I'm not sure that could be automated either. DGG ( talk ) 19:25, 13 September 2015 (UTC)

@DGG: I agree that the technical action of marking a page "patrolled" is what the proposed right should control, but I disagree that it should be synonymous with the autopatrolled right. Creation of quality articles and patrolling are as different skill sets as those of a writer and an editor. There are of course many skilled Wikipedians that merit both permissions but many many more that should have one or the other, but not both (ie, me). VQuakr (talk) 05:03, 16 September 2015 (UTC)

There's a considerable overlap. At present we give autompatrolled very very easily. Large parts of the basic skill set is the same, tho most people do better at one than the other. Just as nobody can be either a writer or editor without a good knowledge of grammar and the principles of composition. DGG ( talk ) 05:19, 16 September 2015 (UTC)

Draft namespace

I'm strongly against stopping good-faith new users create and otherwise work with new articles. What I suggest is better use of the Draft namespace. Maybe 'new' users could automatically have their new articles appear in draft rather than article space? Stuartyeates (talk) 20:17, 13 September 2015 (UTC)

@Stuartyeates: a patroller user right would not affect newbies in any negative way. New editors could still create articles exactly as they can now, but the new pages would be patrolled by a curation team of more uniform competence levels. This would not only mean that new editors would be less likely to be bitten by an ill-considered speedy deletion nomination but also that the patroller would be more familiar with the rest of the patrol checklist. As a result, the new editor would have better odds of getting competent, timely, constructive feedback on their contribution (or even just a "thanks!" for a job well done) to encourage them to improve and continue contributing. VQuakr (talk) 04:50, 16 September 2015 (UTC)

Stuartyeates, expect to see perhaps next week a proposal for exactly that: new and anon user automatically directed to draft. DGG ( talk ) 05:15, 16 September 2015 (UTC)

Moved to Wikipedia talk:Lua

Simply put, I propose that page moves of pages in the "Module:" namespace be restricted to administrators. In other words, I think that the entire namespace should be move-protected. There is one major reason why I think this is necessary, should have been done long ago, and why I don't believe that even template editors should be allowed to move the pages in that namespace. The reason is: when a page gets moved from a title in the "Module:" namespace, it never leaves a redirect. This situation is problematic since, for one, it is the equivalent of having access to the "delete" function while not being an administrator and, for two, if there are any pages that run the module by its previous name (such as pages in the "Template:" namespace), they all break after the move (and since there are no redirects in the "Module:" namespace, there is no way to avoid the pages that run the modules from temporarily going down after the page move.) Steel1943 (talk) 02:39, 18 September 2015 (UTC) This sounds like a deeper problem. Why do Module: namespace pages not leave redirects when moved? That is what seems to be the issue. Dustin (talk) 02:47, 18 September 2015 (UTC) For the same reason there are no redirects in the "MediaWiki:" namespace: the code on the page doesn't run if the request hits a redirect first. Steel1943 (talk) 02:55, 18 September 2015 (UTC) A move can be done without breaking uses of the old module with a copy-and-paste to the new module name (which of course requires attribution back to the original module), and then modifying the old module to simply invoke the new one. isaacl (talk) 02:49, 18 September 2015 (UTC) This solution is problematic since it breaks edit history attribution and in a case where the module may be renamed twice, then there will be a module invoking a module that is invoking a module, and that could blog up the site. Also, if this is the only resolution, it enforces the need to move-protect the namespace. Steel1943 (talk) 02:55, 18 September 2015 (UTC) Yes, I noted the issue with edit history attribution. If a module is renamed again, all of the old module names can be modified to invoke the latest module name directly. I'm not suggesting this is the ideal way, but simply that it is not impossible with the current setup to rename a module without breaking uses of the old module name. isaacl (talk) 03:08, 18 September 2015 (UTC) Right. I'm not doubting what you are saying as a resolution though; from what I see, it's the only resolution. And if this is the only solution, there should be almost no reason why a page move should occur since they will always break something if another page is set up to invoke the module. If anything, maybe a new speedy deletion criterion could be set up if there is proof that a "Module:" has been copied to a new title, and there is proof that there is no longer any pages set up to invoke the module at the old name. Steel1943 (talk) 03:36, 18 September 2015 (UTC) I'm willing to believe you have identified a real problem, but I am not convinced this is the correct solution. The reason is that admins are not by any means experts on the module namespace. I've been an admin for six years and I don't even know what it is, or desire to find out. So, this will inevitably lead to persons who do know what this is and how it works asking for adminship so that there is somebody who is both able to deal with these moves and knows what they are doing, and they will be shot down as single-purpose candidates always are these days. And so these pages will be stuck where they are, or admins will make bad moves of them when someone asks, and the problem will persist, just in a different form. I would suggest that despite your misgivings this should be given to the technically-minded folks in the template editor group, who are more likely to understand the issues involved and respond appropriately than admins at large. Last time I checked, modules, whatever they are, have absolutely nothing to do with site administration. Beeblebrox (talk) 04:27, 18 September 2015 (UTC) @Beeblebrox: That hits a point I meant to bring up in addition to my proposal; possibly an edit notice explaining to administrators performing these moves requirements that have to be met prior to a moving a page in the "Module:" namespace (an explanation that could be understood by any administrator, regardless their technical knowledge; the simplest start to the edit notice would ask the administrator to ensure that no transclusions of the old name exist.) In such a case, if an administrator doesn't feel comfortable that the requirements as outlined in the edit notice are met, then they should not be fulfilling the move request. In fact, on that point, it may just be best to never allow pages in that namespace to be moved, but I know that is kind of crazy and will never happen, so I'm trying to find an acceptable alternative. Steel1943 (talk) 04:44, 18 September 2015 (UTC) Have there been any actual problems with moves by non-admins breaking modules? My first instinct is that this proposal isn't necessary, and that normal page protection will be enough to protect the modules most at risk. However, I could be persuaded otherwise if we are consistently having problems with this. — Mr. Stradivarius ♪ talk ♪ 04:32, 18 September 2015 (UTC) @Mr. Stradivarius: Well, I can tell you that I messed up once, but then had enough common sense to revert myself after realizing that a redirect wasn't created. However, there's no way to guarantee that other editors may realize this if they make a similar mistake. If there is no way to technically move a module without causing problems without the "copy-paste" resolution above, then why should that option even be available? Steel1943 (talk) 04:38, 18 September 2015 (UTC) Also, I can see the move request currently occurring at Module talk:Citation/CS1/Archive 12#Requested move 9 September 2015 turning out disastrous if it is fulfilled by an administrator who is not sure how the "Module:" namespace works. Steel1943 (talk) 05:00, 18 September 2015 (UTC) I agree with Mr. Stradivarius, and was already thinking so much before I read his comment. I don‘t see any problem that needs addressing by this, such as lots of damaging moves. High usage modules are already protected which prevents them being moved, so the scope for damage is therefore minimal even in theory. And there may be good reason for a non-admin/non-TE to move a module. Perhaps they are working on it and need to move it from a temporary name to a permanent one, or for consistency with other modules. It is easy to move most modules without causing problems: just update the template or templates invoking them (which should have the same level of protection). I can't think of any that are invoked directly that this won’t work on. So I don’t see any problem that isn’t already dealt with our current protection policy.--JohnBlackburnewordsdeeds 04:56, 18 September 2015 (UTC) @JohnBlackburne: Actually, there is no way to move a module without causing downtime for any templates that call them. As I stated above, since redirects in the module namespace do not exist, nor do they work since redirects cannot run the code, the only way to prevent any downtime is by the method that Isaacl suggested above (which is essentially a cut-and-paste move which causes WP:CWW issues. That, and I cannot see a valid reason for a module to be moved to another title is it is a module that is transcluded anywhere given these issues. Maybe we need a separate edit notice when a page is created in the "Module:" namespace to ask the editor "Are you sure this is the title you want this page? Afterwards, it cannot be moved." Steel1943 (talk) 05:11, 18 September 2015 (UTC) You can move almost any module without causing problems: simply move the module and update the template at the same time. 'the template' as it is almost always just one. If there are more update them too. As for why one might be moved I gave you some reasons immediately above. Another might be a typo when creating the page. That is probably as likely as any other page but we don’t have special warnings, even though it is more problematic to tidy up after misspelling an article as the redirects need to be deleted. Another reason not to do this: modules are simply not targets of test or bad edits, that I’ve seen. Templates sometimes are, articles often are, but not modules. The module protection policy is based on number of transculsions, not which have been vandalism/disruption targets as none have.--JohnBlackburnewordsdeeds 05:45, 18 September 2015 (UTC) Looking back at the previous discussion you initiated on this topic, it seems there has been progress in implementing a redirect feature, where the Lua code to effectively accomplish a redirect would be treated by the MediaWiki software as a directive to perform a redirect. Whether or not it gets implemented, though, perhaps the move capability can be modified to leave behind the appropriate Lua redirection code in the old module. isaacl (talk) 16:19, 18 September 2015 (UTC) @Isaacl: Good find. Since it seems that there is currently "behind-the-scenes" work happening to get this concern resolved, I'm going to move this discussion away from Wikipedia:Village pump (proposals) to Wikipedia talk:Lua here in a moment. Steel1943 (talk) 16:44, 18 September 2015 (UTC)

1. Should the archive bot not be added to talk pages by default? Its really annoying to see huge length of ancient comments on various talk pages.
2. Why not include talk header by default as well? -- Pankaj Jain Capankajsmilyo (talk · contribs · ) 05:37, 19 September 2015 (UTC)

Please comment at WP:BOTREQ#Bot to undelete 400,000 old IP talk pages - a proposal to use a bot to undelete some 400,000 IP talk pages that were deleted as stale. 103.6.159.88 (talk) 05:59, 19 September 2015 (UTC)

Ahmed has already been invited to the headquarters of some of the biggest internet giants out there. I was thinking that wikimedia should make a similar gesture of support and encouragement. Hence I'm wondering, who is the best person to speak to in regards to a possible wikimedia conference invite or a wikimania invite for Ahmed? I would prefer a link to a wikipedia userpage rather than e-mail. Thank you. Kleinebeesjes (talk) 10:45, 20 September 2015 (UTC)

Bear in mind, Ahmed didn't do anything all that exceptional. He's from an metro area with over 6M people. There are probably hundreds of students in his metropolitan area his age who display similar intellectual talent each year, only most of them either don't bring the results of their hobbies to school or their school, like most schools, is smart enough to not make the mistakes his school make (and IMHO those mistakes were doozies). Dollars to donuts says that if his engineering teacher (yes, he has, or maybe had if he's switched schools by now, an engineering teacher) told his students "make a digital clock and bring it to class tomorrow. If you can't figure out how to do it, spend an hour on it and bring in what you have" at least a few of his students would bring in completed clocks. davidwr/(talk)/(contribs) 20:23, 20 September 2015 (UTC)

discussion below moved from Wikipedia:Bot requests —  Cliftonian (talk)  18:45, 15 September 2015 (UTC)

I see this all over Wikipedia, all the time, especially in the opening sentences of articles about (Jewish) Israeli people. The article will start "X person (born Y date) is an Israeli so-and-so ..."—with the word "Israeli" linking to the article Israeli Jews. This rather pervasive practice is at the very least WP:EASTEREGG linking and, in my opinion, frankly racist. It's as if white American people had their articles opening "X person (born Y date) is an American so-and-so ...", with a link to White American under the word "American". I have removed at least a couple dozen of these usages by hand as I've come across them over the last month or so, but since the number of them seems to be so high (and people with a certain agenda seem to re-add these links occasionally), I think a bot would be advisable to change the wikicode [[Israeli Jews|Israeli]] to just Israeli, without a link. I have no experience in these things so I am listing this here. Any assistance would be appreciated. Cheers, —  Cliftonian (talk)  09:49, 14 September 2015 (UTC)

Needs wider discussion. Can you demonstrate consensus for this task? Because this would affect several articles on a very likely contentious issue. Headbomb {talk / contribs / physics / books} 13:18, 14 September 2015 (UTC)

Thanks for the quick reply Headbomb. I have opened an RFC below. Hope you're well, —  Cliftonian (talk)  08:48, 15 September 2015 (UTC)

Request for comment

Per Headbomb's request above I am opening this up to try to get some more views. I have also posted at WP:ISRAEL to get views from there. I have already posted my rationale above. —  Cliftonian (talk)  08:47, 15 September 2015 (UTC)

• Change the links to point to Israelis (to which Israeli people redirects). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:00, 15 September 2015 (UTC)

• That would also be a satisfactory solution. Thanks Andy. —  Cliftonian (talk)  09:22, 15 September 2015 (UTC)

• Links in all the articles I checked for Israeli Arabs are visibly to Israeli Arab or Arab Israeli. I think that either all the links for Israeli citizens should lead to Israelis or they should lead to the specific nation's article, with the link target clearly visible. “WarKosign” 13:09, 15 September 2015 (UTC)

• @WarKosign: just to clarify, when you say "the specific nation's article" here, am I correct in thinking you mean Israeli Jews/Arab citizens of Israel/Druze in Israel/etc as the case demands? Or do you mean the Israel article for all cases? How to start the biographical articles of Arab Israelis is a much, much more complex issue than this and should, in my opinion, be left for a separate discussion. —  Cliftonian (talk)  14:07, 15 September 2015 (UTC)

@Cliftonian: yes, I used the word Nation meaning an ethnicity, not a state. I think Arab and Jewish Israelis should be described in the same style, so it's not a separate discussion. Jewish Israelis are the majority, but they should not be considered the default case with Israeli citizens of other ethnicity being an exception. “WarKosign” 15:10, 15 September 2015 (UTC)

I looked at several articles on African-American actors, as another case of an ethnicity that is a large minority in its country. The articles that I checked describe them as Americans, without wikilink and without referring to their ethnicity in the article unless it's relevant in some section. The only reference to the ethnicity is by category. “WarKosign” 15:29, 15 September 2015 (UTC)

Please have your discussion somewhere else (WP:VPR). This is supposed to be a page where bot operators can work with people who have a request that has already been discussed or is uncontroversial. Having an RfC here will drown out the useful noise. Legoktm (talk) 15:55, 15 September 2015 (UTC)

discussion above moved from Wikipedia:Bot requests —  Cliftonian (talk)  18:45, 15 September 2015 (UTC)

@WarKosign: please excuse the thread of conversation being moved and broken up slightly. I agree with you that ideally Israelis of all backgrounds would be introduced simply as Israeli, without a wikilink, but I think so far as a bot is concerned it is better to focus on the low-hanging fruit of the [[Israeli Jews|Israeli]] problem first. The rest is another, much longer and much more complicated, discussion. —  Cliftonian (talk)  19:07, 15 September 2015 (UTC)

@Jethro B: apparently made most of the changes, he actually used AutoWikiBrowser. See https://en.wikipedia.org/w/index.php?title=Special:Contributions/Jethro_B&offset=20121031035859 Naraht (talk) 21:36, 15 September 2015 (UTC)

Thanks for this Naraht. —  Cliftonian (talk)  08:05, 16 September 2015 (UTC)

• I agree that these links are not acceptable—at best, they're WP:EASTEREGG links. Cliftonian's suggestion of removing the links altogether and Andy's suggestion of replacing them with links to Israelis are both fine by me. —Granger (talk · contribs) 17:07, 16 September 2015 (UTC)

• It's a minor point, but Israeli Jews are not a race. Hence it is not racism. The alleged behavior could perhaps be characterized as discrimination. Praemonitus (talk)

• For me Israeli should always link to Israel since it refers to the citizenship. Links to Israeli Jew should always be from Israeli Jew. filceolaire (talk) 22:37, 22 September 2015 (UTC)

• These are editorial decisions made by the individual editors of the individual articles in accordance with Wikipedia:Manual of Style/Biographies and Wikipedia:Biographies of living persons. If you want a build a consensus around this, it needs to be based on close reading of those two policies and numerous examples. Stuartyeates (talk) 03:29, 12 September 2016 (UTC)

Problem & Reasons

1. With approaching a hundred years of different political and cultural background, the Chinese language of different places like Hong Kong(1842), Republic of China(1911), People's Republic of China (1949), Macau, Malaysia, Singapore ... etc, have developed different vocabulary, and even different grammar, writing, expressions, strokes...
2. The current simple switching of language encoding between the so-called Traditional/Simplified Chinese text cannot handle many issues, and worse, caused heated argument, offensive & defensive changes of the content.
3. No need to pretend there is no differences. No need to halt the changes. No need to force unification of the new generation of Chinese languages.
4. For the sake of the culture of all human being on Earth, for the culture of all countries,
5. Reducing argument & thus let people of different places/countries use their time and energy to work on Wikipedia content for the passing on of knowledge and culture for future generations of their respective places/countries instead.

Solution

The original concept of Wikipedia has been respected by people all over the world. Wikipedia, please kindly consider for splitting the various Chinese versions into independent sets where the content can become independent of each other and cater mainly for the people of the country or place each set serve...asap. May peace be with you. May all countries and all cultures prosper for many generations to come. --Xaaan5 (talk) 23:46, 14 September 2015 (UTC)

• Anything to do with English wikipedia ?--Antigng (talk) 00:13, 15 September 2015 (UTC)
• Agreeing with Antigng, this sounds like an issue that needs to be hashed out on the existing Chinese-language Wikipedia(s?) and/or at the meta-wiki, not here. davidwr/(talk)/(contribs) 03:02, 15 September 2015 (UTC)

• There has been a problem with Hong Kong articles, where people have been trying to add Mandarin names, where the local language is Cantonese, and other people want to remove them. But I would have considered this a project level problem for here. Graeme Bartlett (talk) 11:57, 17 September 2015 (UTC)

• If I understand what the OP is asking for, I think it's already done, or partly done. Besides the "Chinese" Wikipedia there are already Cantonese, Hakka, Min Nan and other WPs. See meta:List of Wikipedias by language group, Sinitic section.
  As far as the English Wikipedia is concerned, such as the Hong Kong articles that Graeme Bartlett mentions, if edit-warring is going on then it should be resolved by the usual processes. Stanning (talk) 14:12, 17 September 2015 (UTC)
• Xaaan5: This has been raised before. There were proposals, years ago, to split controversial articles here on English wikipedia so we have articles from various points of view instead of one NPOV article. There have been edit wars over US vs English spelling. Our decision, in every case, was to knock heads together and tell the warring editors to work together to create a NPOV article and NPOV is now enshrined as one of our five pillars. This has worked till now and I doubt very much that it will change. On the contrary, I can imagine cases where there are separate wikipedias with the same language but different scripts uniting at some time in the future as tools are developed to auto-transcribe. Just my opinion. filceolaire (talk) 22:48, 22 September 2015 (UTC)

This RfC completely missed the fact that locations that use proxy servers will break secure links since they would end-up proxying the secure link but will not have the certificate. Bad idea. Walter Görlitz (talk) 04:13, 17 October 2015 (UTC)

• I'm not questioning the merit of the RfC, but it is less than optimal that the same user who made the proposal also closed the RfC as "near-unanimous". It is mildly surprising that this was not brought up a month ago. However, I don't think this is the end of the world, so c'est la vie. Regards. --64.85.217.45 (talk) 00:54, 27 October 2015 (UTC)

(Appears to now have been reclosed by an uninvolved editor a few weeks ago, so striking comment.) Rgrds. --64.85.217.45 (talk) 07:16, 7 December 2015 (UTC)

If it is true that this change will make life much more difficult for readers suffering under oppressive regimes and that need to use proxy servers to circumvent oppression, then this is sufficient reason not to make such a change - however many coddled westerners 'vote' for such a change. BushelCandle (talk) 16:01, 28 February 2016 (UTC)

@BushelCandle: In the long-run, even Wikipedia readers from repressive countries will benefit from this decision. Because given HTTPS, repressive regime face an all-or-nothing decision for censoring websites like Google News or Internet Archive (see for instance, Russia's censorship of archive.org in July 2015). --bender235 (talk) 00:35, 12 May 2016 (UTC)

I just want to add a technical opinion. By retrieving the http version and then the https version one can compare if they are the same and then (automatically) change the url protocol. And if the page is loaded any way there's an opportunity to check sum the page while at it and include in the reference. Anyone not able to get to https links can change the protocol manually. Bytesock (talk) 23:16, 19 May 2016 (UTC)

My main reason for thinking that these references may be of use for readers is the prevalence of false accounts. This addition would better enable readers to find official and verified accounts.

The blank template for such a parameter might present something on the lines of:

| Social media = <!-- Due to the prevalence of fake accounts associated to notable people and organisations, all entries must be verified. Use main platforms used preferably using format: [[https://example reference|name of platform]] or, in cases where facility is available -->

Should editors agree to the development of further templates we might also add information on the use of contents such as ((facebook|/example)) ((twitter|/example)) ((youtube|/channel/example)) etc.

These later formats may be of use if at some time in the future, a decision is taken to replace platform names with platform logos/symbols.

GregKaye 07:57, 20 September 2015 (UTC)

Maybe you should get and add these values from Wikidata, so other wiki's can profit from this. There is already some data there. Sjoerd de Bruin (talk) 09:27, 20 September 2015 (UTC)

I'm not sure I understand the reasoning here. But if this proposal would require a social media account in order to get a Wikipedia account, I'm agin it! If it makes it harder for people world such accounts to get Wp accounts, I'm inclined against it. --Thnidu (talk) 02:32, 24 September 2015 (UTC)

Not sure why an encyclopedia would want this information. Also, Info boxes are [should only be used] to summarize what is in the body of the article. GenQuest ^{"Talk to Me"} 12:06, 24 September 2015 (UTC)

Not sure whether, or which, social media sources might be WP:RSes. Wtmitchell (talk) (earlier Boracay Bill) 12:25, 24 September 2015 (UTC)

WP:ELMINOFFICIAL Bazj (talk) 13:00, 24 September 2015 (UTC)

Dear Wikimedia colleagues:

I am developing a proposal for a video series that's designed to introduce Wikimedia to new contributors (particularly in GLAM and education programs), and to motivate them to participate in the community in a constructive way. I would appreciate your input. The video is intended for translation into multiple languages; there are already volunteers for Spanish, German and Greek translation.

The proposal's main draft page is here.

The proposal talk page is here; it includes a draft outline of specific subjects that the video may cover.

Please note that the scope and budget of the project are still under consideration. At this point it would be especially helpful to have input on the subjects that the video should cover, and how best to cover them. This information will help as the project scope and budget are refined.

Please add your questions and comments to the talk page.

If you would like to support the project with your endorsement, please do so here

If you would like to volunteer to translate the video, please email me or comment on the talk page.

Thanks and regards,

--Pine^✉ 22:13, 24 September 2015 (UTC)

Special:WhatLinksHere should allow stopping at any level of redirection, the default being to show the WhatLinksHere page (indented) only up to double redirects. GeoffreyT2000 (talk) 01:02, 17 September 2015 (UTC)

Whenever I see a proposal like this, I feel compelled to ask the proposer to explain why their suggestion is a good one. Double redirects (let alone triple or quadruple) are a bad thing and in most cases are deleted or re-targeted to bypass the second redirect. I'm not at all sure what it is you are even proposing here. Beeblebrox (talk) 04:32, 18 September 2015 (UTC)

I think that it's more critical for WhatLinksHere to allow to sort entries by name, first edit, last edit, number of edits, byte size, traffic, etc. Same with categories, or any arbitrary list. --NaBUru38 (talk) 22:54, 24 September 2015 (UTC)

Please make a global change in how Wikipedia refers to the Catholic Church.

Currently, moderators use the term "Roman Catholic Church", which is NOT how Catholics overwhelmingly refer to themselves.

Since the Catholic Church is comprised of 24 rites, only ONE of which is the Roman Rite, to refer to the whole as the "Roman Catholic Church" is entirely inappropriate and insulting to the other rites. Yes, the Church is 'headquartered' in the Vatican, which in Rome, but that does not justify labeling it as such. No one refers to the LDS church as the "Salt Lake City Church of Latter Day Saints".

"Roman" is at best an out-dated, archaic term. At worst, it is a subtle political label meant to qualify the Church as but one Catholic church among many (e.g. the Anglican Church). The insistence on denominating the Church as "Roman" seems to indicate a deep anti-Catholic, Protestant bias within Wikipedia. Anti-Catholic Protestants for centuries have insisted on denigrating the Catholic Church as merely "Roman". Terms such as "the Roman Church" and "Romanism" were used to smear the Church and cast it as foreign and particular, rather than universal. Since in the Apostles' Creed and Nicene Creed many profess belief in "one, holy, catholic, and apostolic Church" - many Protestants insisted on referring to the Catholic Church as simply the Roman Church. There is also an historical confusion with the Holy Roman Empire, which was a political kingdom unrelated to the Church.

Since there is no "official" name of the Church (it is simply the Church!), we must rely on common usage. Both historically and around the globe, the overwhelming usage of Catholics is to refer to the Church as the Catholic Church. Please update Wikipedia's terminology to reflect both fact and common usage as well as self-identified consensus.

Sincerely,

mnewhous

I always understood the "Roman" to refer to acknowledging the Roman Pontiff", not the Roman rite. There are now and have always been other rites in use. The problem with "Catholic Church" is that many other Christian denominations consider themselves Catholic. DGG ( talk ) 04:20, 24 September 2015 (UTC)

Mnewhous, Apart from

• your bias in overlooking the Old Catholic Church, Anglo-Catholicism and many other "catholic" flavours of christianity, and
• your historical errors regarding the Holy Roman Empire which, in every version I've ever seen, starts off with Pope Leo III slapping a crown on Charlemagne in Rome in 800 - how much more HOLY and ROMAN could it get? - then

you'd like us to ditch the pillar of Wikipedia which requires neutrality and fall into line with (what you percieve to be) the RC view and start using a non-specific term? Shall we start referring to Mormons as Saints then, to fall in line with their usage? Or change all references to any faith to "the church"?

Context is everything. You may refer to the RC church as "the church", but would you do so if talking to a protestant and the context could be misconstrued? Would you refer to it as the Catholic church if you were talking to an Old Catholic? Well here, on Wikipedia, you're talking to everybody. Assume nothing, be specific. Regards, Bazj (talk) 14:26, 24 September 2015 (UTC)

I would generally assume a reference to the 'Roman Catholic Church' to be a reference to the largest Catholic church; whether or not it includes the other particular Catholic churches (such as the Maronites) - which in the narrowest sense it should not - depends on context. Insisting on the church's own usage as the only correct usage would seem to be unduly biased. (But then I'm an Anglo-Catholic, so I'm also biased.) AlexTiefling (talk) 14:31, 24 September 2015 (UTC)

Dear AlexTiefling, I seriously doubt that the original poster would "like us to ditch the neutrality pillar". If you think that renaming the "Roman Catholic Church" to "Catholic Church" wouldn't be neutral, please explain it politely. -NaBUru38 (talk) 23:06, 24 September 2015 (UTC)

NaBUru38, The comment you're complaining about is mine, not Alex's. Re-reading it, in its entirety, and in the context of Mnewhous' edit history and the cautions on his/her talk page, I'm quite content with the message. Bazj (talk) 08:38, 25 September 2015 (UTC)

Article titles can be a really hard thing to do neutrally, because there isn't the possibility of explaining the controversy in the title itself. You'll see that Catholic Church is the main article for the church, as you would desire, and Roman Catholic (term) explains the problems with names. I (not a Catholic-in-communion-with-the-bishop-of-Rome) agree that, in the absence of ambiguity, "Catholic" can be used to refer to the Church-in-communion-with-the-bishop-of-Rome. But there are times when ambiguity is present, and there the word "Roman" is not itself derogatory. (Though "the Roman Church", "the Church of Rome" and "Romanism" all are.) Indeed, the PCPCU use the word "Roman" where not to do so would cause offence/confusion.

Finally, note that "Roman Catholic" and "Latin Rite Catholic" are entirely different terms. There are "Roman Catholics" of other rites, and there are (arguably) Latin Rite Catholics who are not "Roman Catholic".

It's complicated and difficult, but I think Wikipedia's articles on the subject do a reasonably neutral job. Relentlessly (talk) 08:31, 25 September 2015 (UTC)

Now that we have size options, including newest "400px" option, for image display, we should respect people's image preferences per WP:IUP. Somehow, the model of using "px" in infoboxes is detrimental to others wanting to see a big (or small) image initially. Perhaps we should change settings from px to image size percentage/upright. Agree? --George Ho (talk) 06:46, 23 September 2015 (UTC)

@George Ho: It's been agreed to scrap the "upright" option for images in the next few months/years, so I'd recommend against that. Jdforrester (WMF) (talk) 08:41, 23 September 2015 (UTC)

If they decided to scrap out "upright" option, how would this affect WP:IUP? Are we gonna use "px" again for all users? --George Ho (talk) 08:45, 23 September 2015 (UTC)

@George Ho: I believe the aspiration is also to deprecate pixel-specifying too, and instead move to semantic image types, but that's not agreed yet (and I'm not working on it myself, sorry). There are more details at the RfC to which I linked. Jdforrester (WMF) (talk) 08:46, 23 September 2015 (UTC)

I don't think scrapping out "px" works well. It would affect very tiny icons, like flags and checkmarks. Reading that link, I wonder whether they were discussing frameless images (with or without |frameless|). --George Ho (talk) 08:57, 23 September 2015 (UTC)

@George Ho: It's quite a wide-ranging proposal to totally change how media transclusions work, yeah. Needs some serious thought, as you say. Jdforrester (WMF) (talk) 17:33, 23 September 2015 (UTC)

•  United States
•  Ireland
•  Germany
•  Switzerland
•  Nepal

It's already bad that Template:Flag has different flag widths, just because it was preferred to have a standard height (if I'm not mistaken).

If fixed pixel parameters are removed, it would get even worse. --NaBUru38 (talk) 22:59, 24 September 2015 (UTC)

It's not true that flag icons "have a standard height". Both the width and the height are fixed (the default is 23x15px), so whichever size (23px width or 15px height) causes a smaller icon is used. The same list looks like this with fixed width:

•  United States
•  Ireland
•  Germany
•   Switzerland
•    Nepal

And like this with fixed height:

•  United States
•  Ireland
•  Germany
•   Switzerland
•    Nepal

WT:WPFT or Template talk:Flag would be a better place to discuss the default size of flag templates, though. SiBr₄ (talk) 12:06, 25 September 2015 (UTC)

Should ((db-c1)) be able to be removed by the creator? Discuss below. --189.25.240.76 (talk) 16:11, 24 September 2015 (UTC)

Why? --Jayron32 12:02, 25 September 2015 (UTC)

I've removed speedy templates from template categories I created several times, where pages had actually been added but were not shown yet; e.g. this one. (When templates are categorized through their documentation subpages, they may not show up in the category until days or even weeks afterwards, because the job queue has to catch up.)

A more frequent scenario may be that a user creates a category, forgets (or doesn't know how) to add pages to it, sees the C1 tag after a few days, and only then adds pages to the category. SiBr₄ (talk) 12:51, 25 September 2015 (UTC)

Then create the category page again. No big whoop. --Jayron32 16:07, 25 September 2015 (UTC)

Recently, the move form has been switched to OOUI. The upload wizard will switch to OOUI next week. The deletion confirmation form (for administrators) should also be switched to OOUI. GeoffreyT2000 (talk) 15:58, 25 September 2015 (UTC)

@GeoffreyT2000: I've created T113758 for this; thanks for the reminder. Jdforrester (WMF) (talk) 16:49, 25 September 2015 (UTC)

@Jdforrester (WMF): What necessitates OOUI? Any form? Any form with multiple end states? I'm thinking special:log and special:Contributions off the cuff, though special:preferences has a button here or there. Special:MIMESearch too? Maybe someone should scrub the Special:Specialpages. There didn't seem to be a task for all of those. --Izno (talk) 17:24, 25 September 2015 (UTC)

@Izno: The plan is to eventually replace every UI interface component with OOUI, and delete e.g. jQuery.UI and other deprecated systems. T100161 is the overall ticket for converting all of MediaWiki. T107037 is for all special pages, but there aren't yet sub-tickets for Log, Contributions or indeed most of them. Jdforrester (WMF) (talk) 11:35, 26 September 2015 (UTC)

Would this discussion be better suited for WP:VPT. Your magical incantations don't really make much sense to us Muggles, and you're likely to get better participation from more knowledgeable people over there. --Jayron32 17:35, 25 September 2015 (UTC)

@Jayron32: VPT isn't the right venue either for asking for participation for writing code; input is welcome in the form of git patches, which go on gerrit:. :-) Jdforrester (WMF) (talk) 11:35, 26 September 2015 (UTC)

Ok. I'll bite. What the heck is an OOUI? And that gerritt thing; is that in the same family as a ferret? GenQuest ^{"Talk to Me"} 11:48, 26 September 2015 (UTC)

OOUI. "Gerrit" is the given name of Gerrit Rietveld. --83.255.51.226 (talk) 08:17, 29 September 2015 (UTC)

Can someone explain to me what the benefit of "OOUI" is? I've read the article linked above, but I fail to see how the new move form is more "object-oriented" than the old one. Jenks24 (talk) 14:23, 29 September 2015 (UTC)

OOUI when in the context of MediaWiki refers to OOjs UI (demo). This is a modern widget toolkit written with the goals of MediaWiki and Wikipedia in mind. It can be generated in both PHP and Javascript, is accessible, consistent, skinnable, mobile optimized etc. It also allows for easy creation of MediaWiki specific widgets such as an input field for Article titles with autocompletion. It's first user was Visual Editor and the long term plan is that this will be used for all controls at some point. The idea is that not every developer has to reinvent the wheel. You use what is in OOUI already, or you build something new on the foundations that this platform provides you, but you don't start from scratch. —TheDJ (talk • contribs) 15:54, 29 September 2015 (UTC)

Thanks for the response. So basically it makes things easier for devs? And also it would be nice for things to be consistent? Both of these seem like good things so that's fine. But the change to the move interface has made my work here more difficult. I've now had to file two bugs about it and even once they are both fixed, the old interface will still have been quicker for me (and most others, I assume) to use. Is there any guarantee a change to the deletion interface won't have the same problems? Or am I understating how useful this is on the backend and these minor hassles for editors are worth it? (I realise you, TheDJ, might not necessarily have answers to these questions, they're more general for anyone with knowledge on the subject.) Jenks24 (talk) 16:46, 29 September 2015 (UTC)

Let's put it like this: I'm sure you love your house full of unique, handcrafted, slightly imperfect yet beautiful, efficient and very expensive furniture, but IKEA has a lot of benefits to it. Currently a lot of community requests are about making things more 'interactive', 'smarter', 'n00b proof' etc. But without changing some fundamentals, many of those requests are actually difficult and expensive to implement consistently in multiple areas of the wiki, for multiple target audiences and multiple target devices (and not breaking on browsers without Javascript). OOjs UI will create new handles for both community and developers to provide some of those changes. —TheDJ (talk • contribs) 17:36, 29 September 2015 (UTC)

To: WhatamIdoing, Mdennis (WMF), Jimbo Wales, iridescent, User:Coren

We have accomplished the task of creating a visual, scrolling timeline of every Wikipedia article. Of course, not every article is historical in nature. Of the 5,000,000 English Wikipedia articles, our estimates are that around 250,000 could use a decent visual, contemporaneous presentation. That is a lot of timelines. We believe it would be one of the most exciting things to happen to history, on the internet, in a long time.

We have put a (mind blowing) demo together at:

http://wikitimelines.net/

In regards to potentially placing timelines on select Wikipedia articles. It would be just 1 small SCRIPT tag and 1 small DIV tag, per Wikipedia article.

It is surprisingly simple to do now.

All I am asking for is a Wikipedia server to install this on. Wikipedia would, of course, have complete authentication authority over this server. This will take less than one day to do.

OR:

I could give Wikipedia.org authentication authority over my "Amazon Web Services" server and Wikipedia would give me permission to use it (I will even pay for it).

Then we can test it on 1 Wikipedia.org article and see what happens.

We cannot believe how well this turned out. We can't stop timelining Wikipedia articles, it is so compelling and fun.

I forgot to mention. This whole thing is NEW. Nobody has ever seen this as of today (making timelines out of Wikipedia articles). We have only shown this technology to like 3 other people.

Thanks Jeff Roehl

Jroehl (talk) 21:54, 13 September 2015 (UTC)

Have you considered making this tool work using dumps of the Wikipedia database or other "local copy" of Wikipedia? davidwr/(talk)/(contribs) 23:16, 13 September 2015 (UTC)

To davidwr

I am not sure what you mean by: "dumps of the Wikipedia database"

Can you be more specific?

Thanks

Jeff Roehl

Jroehl (talk) 23:46, 13 September 2015 (UTC)

See Wikipedia:Database download. davidwr/(talk)/(contribs) 00:30, 14 September 2015 (UTC)

David = davidwr,

Yes, I would like to get the data from wherever Wikipedia is getting it. If we could get this to run on the same rackspace as the core of Wikipedia. That would be super-fast. And it would be very inexpensive, not taking any TCP/IP resources. Could I get the data in HTML? I am not sure if you guys take your Wiki language and immediately parse out the HTML on an article edit/save. My widget is pretty straight forward. It is aware of what page it is on. So if we placed the widget on:

https://en.wikipedia.org/wiki/Queen_Victoria

And the widget was on a LAN at Wikipedia, this could be translated as:

c:\wikidata\articles\Queen_Victoria\index.htm

Or what ever it is there and serve it out to the user. The key to me is to parse out the current version of the article. So the timeline will exactly match the article every single time. All I need to do is pull the article (locally) and pull the paragraphs out of the article. If I can pull the article in milliseconds, it would be super fast. The slowest part would be serving up the javascript to the widget on the users page. So all I would need is a big outbound pipe.

And I really don't need a lot of diskspace. My biggest worry, in processing millions of timelines a day is deletion of temporary files and releasing that diskspace back to the operating system. Each request for a timeline will produce 5 or so temporary files (SQL output). But those will be deleted within milliseconds after processing. We just have to make sure they are getting deleted. I can set the location of the temporary file location, so we can monitor this.

I may be able to write the system to work with no disk writes (convert all the tables to memory arrays), but that would be a LOT of work. That would be a multi week thing, for sure. So we should leave it the way it is now and see if it ramps up well.

Just my professional assessment, your experience may be different.

Thanks Jeff Roehl Jroehl (talk) 16:01, 14 September 2015 (UTC)

David = davidwr,

One more thing. Of course we don't want a timeline loading up on a historical Wikipedia article, every time it is accessed. What we really like is the "collapseButton" span tags, usually at the bottom of substantial articles. They are very classy. All we would have to do is add a "collapseButton" to the Queen Victoria page and put my SCRIPT tag and DIV tag in there. So when you opened up the "collapseButton" the widget JavaScript would be fired off and populate this area with the timeline HTML and JavaScript.

And if we could get my brilliant http://184.72.231.130/load1.js to fire at that point it would be all "no worries" after that.

Of course, the problem with this is the "collapseButton" controls are way at the bottom of the Wikipedia pages. I mean WAY down at the bottom. Below the Citations. And that is not good for "our team". Then again, timelines in Wikipedia may be so compelling that everybody might know where they are, by word of mouth, within a short time.

Thanks Jeff Roehl Jroehl (talk) 17:07, 14 September 2015 (UTC)

I tried it on Timeline of women's basketball for which it would seem to be uniquely well-suited. It was a bust. Did I do something wrong?--S Philbrick(Talk) 19:20, 15 September 2015 (UTC)

No S Philbrick you did nothing wrong. As of this writing, for the sake of speed and narrative content, we are only placing data on the timeline that is part of a paragraph in any Wikipedia article. That is any content that inside paragraph tags. We will eventually have to write a separate parser for "Wikipedia timelines". One issue is there is no standard format for Wikipedia timeline lists, so it is a trick to parse them. We will be happy to do this, even to the point of writing a program to re-write all Wikipedia timelines into one standard format. Try https://en.wikipedia.org/wiki/Women%27s_basketball which has some paragraph tags with content.

Thanks

Jeff Roehl Jroehl (talk) 18:06, 18 September 2015 (UTC)

I also recall seeing this a few weeks ago despite the claim that it's new today. I didn't save the link to the discussion and can't seem to find it easily at the moment. Found it Wikipedia:Village_pump_(proposals)/Archive_126#I_would_like_to_put_a_timeline_on_a_wikipedia_page I know there was discussion about getting the Foundation involved so I'd like to hear what is happening on that front.--S Philbrick(Talk) 19:24, 15 September 2015 (UTC)

Yes S Philbrick not much has happened. Rome wasn't built in a day. All we are requesting is 1 computer to display 1 timeline on 1 Wikipedia article. And then we might see where this goes. We have a 6 month period of time chunked out right now where we can focus on this. From 15 October 2015 to 15 March 2015, possibly 8 hours a day or 1000 hours (if not total hours of work, but our undivided attention and full measure of our devotion). I can't guarantee resources like this will be available after that. I think timelines would be much better understood if we could place a timeline on 10 Wikipedia pages. Then we could debate this content and then possibly take a consensus vote on inclusion. Some articles make better timelines than others and consensus would dictate inclusion in any article.

All we need is 1 server that "The Foundation" has administrative privileges/authentication on, whether that is a server we pay for or not. That is not a very big first step.

We are also going to write a grant application for this and related endeavors (also within the scope of the 1000 hours mentioned above). Any help with this would also be greatly appreciated. So anybody who knows of any organizations issuing grants for "Comparative History" or history in general, give us a heads up on that.

Thanks Jeff Roehl Jroehl (talk) 18:42, 18 September 2015 (UTC)

Who would make the decision to put 1 timeline on 1 article in Wikipedia?

Thanks Jeff Roehl 64.39.94.189 (talk) 17:11, 23 September 2015 (UTC)

Ok, lets go back a step.

Who would make a decision to allow me to install and configure a Wikipedia server with my timelining widget software backend?

Jroehl (talk) 15:20, 27 September 2015 (UTC)

It … doesn't work like that. I'd recommend installing a copy of your software on your own server and using the API to retrieve content on which to render a timeline. If that works well, your next step would presumably be to rewrite your software as a MediaWiki extension (and make it free and open-source if it isn't already), and then campaign for it to be added to Wikipedia proper. ((Nihiltres |talk |edits)) 17:34, 27 September 2015 (UTC)

Thankyou Nihiltres. I will have my guys look into this. Doing something like this, you never know until somebody tells you how things work. Jroehl (talk) 14:52, 30 September 2015 (UTC)

And we took the demonstration site down for now. Jroehl (talk) 15:52, 30 September 2015 (UTC)

The Arbitration Committee is currently examining several reforms of the Audit Subcommittee and asks for community input on how they would like to see the Subcommittee function in the future. Because of this, the current Audit Subcommittee (AUSC) members' terms are hereby extended to 23:59, 30 September 2015 (UTC).

Supporting: AGK, Doug Weller, GorillaWarfare, Guerillero, LFaraone, NativeForeigner, Salvio giuliano, Thryduulf, Yunshui

Opposing: Courcelles

For the Arbitration Committee, --Guerillero | Parlez Moi 02:10, 5 September 2015 (UTC)

Discuss this and the future of the AUSC at: Wikipedia talk:Arbitration Committee/Noticeboard#Motion: AUSC Extension

When you attempt to create a description page here for an image that's on Commons, you're presented with the message from MediaWiki:Sharedupload-desc-create, basically a little warning of "This image is on Commons, so please don't create this page", and a link to the Commons URL is provided. See [8] for an example of this message in use. I went to WP:HD asking how to change the URL. Right now, when you go to File:Armed Klansman in southeastern Ohio, 1987.jpg and try to edit its page, the URL in the message is [9], while I was planning to edit the MediaWiki page so that it instead went to [10], the edit page instead of the description page. PrimeHunter gave me the code, but he also opposed the idea, so I'm not going to make the change without chatting here first.

Proposal Change the URL in the MediaWiki page so that it sends you directly to the screen to edit the Commons description page, rather than sending you to the page itself. My rationale was "it seems reasonable that the typical person editing the page was intending to edit the Commons page, so it will save a step by sending them directly to the edit page instead of making them detour through the description page." PrimeHunter opposed with "[the local file] is missing several features on [the Commons description page] such as Commons categories, section edit links, History tab, and links to the uploader and their contributions...I don't like the idea of cross-wiki edit links. I think users should at least view a wiki before trying to edit it. I wouldn't want Commons or other wikis to have direct edit links to us."

So which is it? Should we change the link as I want it, or keep it unchanged, or modify some other way? Nyttend (talk) 00:33, 2 October 2015 (UTC)

When an administrator moves a page, an existing talk page under the new title should be deleted if the "Move associated talk page" box is checked. Also, existing subpages of the new title should be deleted if the "Move subpages" box is checked, and if the "Move associated talk page" box is checked, also subpages of the talk page. GeoffreyT2000 (talk) 14:33, 1 October 2015 (UTC)

Not quite [edit: "Not quite agreeing with everything"], but if the "Delete this page" is marked for the article, it should delete the old talk page and move the new one. I'm often opposed to this kind of thing [edit: "I'm often opposed to proposals of this sort, because they enable foolish or uninformed editors to do stupid things"], but here the admin can always just delete the talk page and do the move manually: your proposal wouldn't do much to retard the foolish admin, but it would make it a lot simpler for ordinary moves. I am, however, opposed to deleting subpages: unlike main talk pages, talk page subpages are very easy to overlook, very easy to miss by accident, because if nothing else they don't cause tabs to change from red to blue. I don't want to run the risk of trashing subpages that I never knew about, especially because the pages to be deleted are pages that I might never have seen or edited. Nyttend (talk) 00:39, 2 October 2015 (UTC)

Completely agreed with Nyttend. A tick box to also 'delete and move' for the talk page would be handy, but having it for subpages is a recipe for disaster, especially in cases where a page and its subpages have been moved back and forth – you'd end up with cases where the actual content is deleted to move a redirect over the top of it. Jenks24 (talk) 01:13, 2 October 2015 (UTC)

I've interpolated a couple of things just now, so Jenks' comments don't necessarily apply to them. Nyttend (talk) 12:20, 2 October 2015 (UTC)

Rather than enabling automatic deletion, I think it would be better if the UI could provide an alert that sub-pages exist and that the person moving should assess what should be done with them. older ≠ wiser 12:45, 2 October 2015 (UTC)

Yes, that's a good idea. Both currently and under this proposal, the only effect of having subpages is the extra check box to "Move subpages (up to 100), if applicable". It would be quite helpful if we had an automated notice saying that subpages exist. Nyttend (talk) 13:15, 2 October 2015 (UTC)

Giving a courtesy link to the poll. Adam Cuerden ^(talk) 10:30, 3 October 2015 (UTC)

When renaming a user, existing user pages, user talk pages, and their subpages under the new username should be properly deleted with MediaWiki:Delete and move reason (on each individual wiki) for the reason. Currently, the existing pages have no deletion log and the moves are "over redirect". GeoffreyT2000 (talk) 03:49, 7 October 2015 (UTC)