Wikipedia:Village pump (proposals): Difference between revisions

Browse history interactively

← Previous edit Next edit →

Content deleted Content added

VisualWikitext

Inline

Revision as of 04:31, 12 September 2015

Table of contents
First discussion
End of page
New post

Shortcuts

New ideas and proposals are discussed here. Before submitting:

Check to see whether your proposal is already described at Perennial proposals. You may also wish to search the FAQ.
Consider developing your proposal at the idea lab.
Proposed software changes should be filed at Phabricator (configuration changes should have gained a consensus).
Proposed policy changes belong at Wikipedia:Village pump (policy).
Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
Proposed new wikis belong at meta:Proposals for new projects.
Proposed new articles belong at Wikipedia:Requested articles.

« Archives, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213

Log of articles proposed for deletion

There should be a log of articles proposed for deletion on each day; the daily log being a subpage of Wikipedia:Proposed deletion. That makes it easier to see whether an article has been prodded before. If you use Twinkle to prod an article, Twinkle should automatically add the article to the daily log. Finally, if you manually prod an article without using Twinkle, a bot should automatically add the article to the daily log if you have not already done so. GeoffreyT2000 (talk) 01:37, 29 August 2015 (UTC)[reply]

Support – I believe there's already a category of PRODed articles. It seems like it ~~should~~ shouldn't be too tough to create a 'By day' list of PROD articles at WP:Proposed deletion, like the ones at WP:RM or WP:TfD, etc. --IJBall (contribs • talk) 15:38, 30 August 2015 (UTC)[reply]
- @IJBall: I think you meant "it shouldn't be too tough". nyuszika7h (talk) 11:54, 31 August 2015 (UTC)[reply]
  - Yes - fixed! --IJBall (contribs • talk) 13:12, 31 August 2015 (UTC)[reply]
Here is a list of all the Prods in chronological order, User:DumbBOT/ProdSummary. Does that work for what you want? -- GB fan 12:05, 31 August 2015 (UTC)[reply]
Support as long as someone's willing to operate the bot that you suggest. I've never prodded a page except by manually adding the prod template, and I doubt that I'd remember to log it manually, so my prodding would never get logged except with bot assistance. Nyttend (talk) 00:04, 6 September 2015 (UTC)[reply]

Prefix suggestion: TP: for Template:

My idea is so that we could make search "fstr". We already have WP: for Wikipedia:, so let us have that prefix. ~~Gamingforfun~~³⁶⁵ (talk) 01:26, 30 August 2015 (UTC)[reply]

Oppose For the reasons in WP:PEREN#Create shortcut namespace aliases for various namespaces. In particular, the Template namespace is generally not linked often enough that saving the typing of 6 characters is likely to be at all worthwhile and there's nothing available to use for the corresponding talk pages. Anomie ⚔ 13:27, 30 August 2015 (UTC)[reply]
"TL:" would be a much better suggestion for this, as templates can already be linked to with the {{tl}} template. --IJBall (contribs • talk) 15:43, 30 August 2015 (UTC)[reply]
Won't work, because "tl:" is the interwiki prefix for the Tagalog Wikipedia. "tp:" is currently not an existing interwiki prefix (and an unassigned ISO 639-1 code). SiBr₄ (talk) 16:01, 30 August 2015 (UTC)[reply]
support Definitely useful, as a guy who pulls up templates more that articles.—^cyberpower_Chat:Online 20:19, 30 August 2015 (UTC)[reply]
Support as TP:. But what about the template talk namespace? TT: is the Tatar language, so TPT? Eman235/talk 22:46, 30 August 2015 (UTC)[reply]
"tpt" is Tlachichilco Tepehua in ISO 639-3. Anomie ⚔ 22:11, 31 August 2015 (UTC)[reply]
Question: Why not just use {{tl}}? Seems to me a Template talk shortcut would be more useful. —67.14.236.50 (talk) 04:18, 31 August 2015 (UTC)[reply]
The idea is to be able to write TP: (case insensitive) in the search box to save typing six characters. But if an alias is made then some editors will also write it in saved links. TP sounds like talk page so it may confuse some users. Assuming TP is only defined for the English Wikipedia or Wikimedia wikis in English, it may also confuse people who expect it to work at other wikis. PrimeHunter (talk) 13:26, 31 August 2015 (UTC)[reply]
That can easily be addressed by creating a T prefix for Talk: TP for Template: and TT: for Template talk:—^cyberpower_Chat:Online 14:52, 31 August 2015 (UTC)[reply]
That would require either changing the existing tt: prefix or making all namespace and interwiki prefixes case-sensitive (both of which would break a lot of links globally), as well as deleting/renaming all pages starting with T:, which include some often-used shortcuts to template pages. Hardly easy. SiBr₄ (talk) 15:29, 31 August 2015 (UTC)[reply]
Support, for ease of finding templates. bd2412 T 13:41, 31 August 2015 (UTC)[reply]
Support for search box usability. —67.14.236.50 (talk) 22:24, 1 September 2015 (UTC)[reply]
Comment Since {{tl}} and similar templates can be used for linking to templates in discussions, a shortcut like this would only really be useful in the search box (and maybe edit summaries). I just recalled Kipod having written a user script that gives Template: namespace search results in the search dropdown for queries starting with "{{" about a year ago (discussion), and wrote this simple JS script to expand "TP:" as well as "{{" into "Template:" in the search box. That allows the functionality of the proposed namespace alias, without it needing to actually be created (and changed in case of a conflicting future namespace/interwiki prefix). SiBr₄ (talk) 14:22, 3 September 2015 (UTC)[reply]
Support as a pretty useful suggestion. APerson (talk!) 02:21, 7 September 2015 (UTC)[reply]
Oppose People have to refer to Wikipedia a lot, and "WP" is a useful contraction that is widely used and recognizable. The same is not true regarding Template/TP. People fiddling with templates would quickly learn to use TP if they wanted, but TP would be pointless jargon for many people encountering the term. If the only reason for wanting TP is to enter the namespace in search, another method is needed. For example, use the "Remember selection for future searches" after selecting Template in the list of namespaces at the Advanced search. Johnuniq (talk) 21:27, 7 September 2015 (UTC)[reply]
Oppose - I honestly don't see much point to this as no one ever uses templates as they do Wikipedia pages, Plus I (and I assume others) are used to searching "Template:" anyway. –Davey2010^Talk 01:21, 12 September 2015 (UTC)[reply]
Oppose, per Anomie. {{Nihiltres |talk |edits}} 02:42, 12 September 2015 (UTC)[reply]

Efficient search for policies and guidelines

I have a request for improvement, and I was advised to bring it here from WP:Teahouse/Questions by User:Cullen328.

It’s possible to search through the whole of Wikipedia's style guidelines by using the search box at WP:MOS. Could the same be done for all policies and guidelines (and other widely accepted pages), without having to sift through things like deletion discussions and controversial essays? Thanks. —67.14.236.50 (talk) 03:31, 31 August 2015 (UTC)[reply]

The obvious solution that comes to mind is to make it work the same as MOS by e.g. moving WP:V to Wikipedia:Policies and guidelines/Verifiability. Is this a bad idea? —67.14.236.50 (talk) 03:36, 31 August 2015 (UTC)[reply]

In that conversation, I recommended Wikipedia:List of policies and guidelines as a starting point. Cullen³²⁸ Let's discuss it 03:39, 31 August 2015 (UTC)[reply]

@Cullen328: That would mean clicking on each link, doing a ctrl+F, navigating back, clicking on the next link, etc. Far more tedious than what I’m asking for here, which is a list of policies and guidelines containing the search term. But thanks anyway. —67.14.236.50 (talk) 04:03, 31 August 2015 (UTC)[reply]

I am not saying that the list provides the full functionality of the MOS search box, but rather that if such a search function is established, those are the pages that should be searched. So, this list would be an essential tool implementing that search function. — Cullen328 — continues after insertion below

Ohhh. Sorry for misinterpreting. Yes, that’s a good idea, to start whatever the solution might be with those pages first. —67.14.236.50 (talk) 04:27, 31 August 2015 (UTC)[reply]

In the interim, let's say for example, that I am looking for our notability guideline for people. I look at the list, see that it has a section on notability guidelines, click that, and see our notability guideline for people. Very intuitive and easy to navigate. So, I would not dismiss the every day usefulness of that list. Cullen³²⁸ Let's discuss it 04:19, 31 August 2015 (UTC)[reply]

A more generally useful solution might be a search function that searched all articles linked to in the given article without recursion (i.e. not searching the articles linked in the linked articles, etc.). That would allow searching the list of Policies and Guidelines as well as other lists. --agr (talk) 12:14, 31 August 2015 (UTC)[reply]

You might be able to achieve the desired goal by searching for any page that contains {{Policy}} or {{Guideline}} (and similar). WhatamIdoing (talk) 17:37, 1 September 2015 (UTC)[reply]

I didn’t think wikitext was searchable. Is it? And what if you don’t know whether there exists a policy, guideline, information page, etc. about the subject at hand? A custom boolean search may be an option, if raw wikitext is searchable. —67.14.236.50 (talk) 22:28, 1 September 2015 (UTC)[reply]

The new CirrusSearch engine has the insource: keyword for searching pages' wikitext source, and support for regex search. There is also hastemplate: to search for pages using a certain template. SiBr₄ (talk) 08:58, 2 September 2015 (UTC)[reply]

All of which adds up to: I think you should post a question at WP:VPT about whether any of the Cirrus search/regex experts over there can think of a way to build a link that will search policies and guidelines. WhatamIdoing (talk) 17:47, 2 September 2015 (UTC)[reply]

I posted a notification of this discussion, since it seemed to make more sense to have this in one place. Thanks. —67.14.236.50 (talk) 23:21, 2 September 2015 (UTC)[reply]

This is not possible right now, without changes to Extension:Inputbox. I was hoping that abusing it's prefix param would work, but it seems prefix search is in a category of it's own and doesn't mix well with other search options. There are multiple ways that the search itself can support this usecase though Higher prio for pages containing the relevant header templates or search in pages that link to Wikipedia:Policies and guidelines. Neither is perfect of course, but it sort of works. To make it as accurate as possible, we could let the header templates add a hidden category, so that we could use the "incategory:" modifier (modifiers only really work as ANDs, not as ORs). But first, you'd have to adapt the extension I fear. —TheDJ (talk • contribs) 16:05, 3 September 2015 (UTC)[reply]

So if I understand, our best options are either we add all P&G pages to the same category, or we add a prefix (à la “Manual of Style/…”) to their titles. Is this right? And would we be able to include essays and supplementary pages like WP:BRD in whatever we might end up doing? —67.14.236.50 (talk) 22:35, 3 September 2015 (UTC)[reply]

Does anyone have any opinions on moving all policies and (non-style) guidelines to share a common prefix, like the MOS pages do? —67.14.236.50 (talk) 21:43, 6 September 2015 (UTC)[reply]

Enabling VisualEditor for existing accounts which are dormant or inexperienced

Over the last few months, we slowly expanded the availability of VisualEditor as an option for new editors. This is now complete, which means that all accounts registered from now on get the choice to use VisualEditor.

Though VisualEditor is useful to both experienced and new users alike, we are yet to offer any choice to existing, inexperienced users. People with an existing account can and do opt-in to use VisualEditor, and there are a number of experienced editors (like those who read this page) who choose to use it. However, the vast majority of people are casual, irregular editors who come back every few months or so (or never). They do not change any of their settings, and most of them likely don’t even know they can. Offering VisualEditor to them as merely an opt-in preference is hiding it away.

Consequently, I think we should make VisualEditor available to all existing, inexperienced accounts, and for dormant accounts. By this I mean those who have not yet made many edits (fewer than 1000), and those who haven’t edited at all for a while (perhaps three to six months). I am not suggesting a change of status for active, experienced editors, as many of you have made the decision to not use VisualEditor, which I respect. This change would also not provide VisualEditor to anonymous editors, who I think deserve a separate community conversation about how that can take place, at some point in the future.

For casual, inexperienced editors, this would mean that they don't need to know about preferences to have access to both the wikitext editor and VisualEditor.
For any returning experienced editors, access to both the wikitext editor and VisualEditor would just be one of the many other changes in the software that will have rolled out each week since they were last around (like the performance improvements to MediaWiki made over the last few months).
For all experienced, active editors, your current preferences will of course be honoured. For the thresholds I have proposed, about 20,000 editors; if you are reading this, you know about the Village Pump, so this almost certainly means you. If you have VisualEditor enabled, it would remain enabled. If you don't, then it would remain disabled.

The location of the preference switch will be moving soon to the "Editing section of Special:Preferences. This will bring the English Wikipedia into line with the majority of other Wikipedias, like French, Russian, or Italian; see this link to the French Wikipedia's preference screen for what that will look like. This will not mean that VisualEditor is "complete" or that it is out of "beta" though – there are still lots of improvements yet to make, not least integrating wikitext and visual editing together properly and removing the hack of having a second edit tab that jumbles up the interface. I have no intention of forcing anyone to use VisualEditor.

The choices about whether, at which thresholds, and exactly when to do this, are up for a discussion, and I would appreciate suggestions. I think this change would be a reasonable change without disrupting things for most users. Thoughts?

Jdforrester (WMF) (talk), Product Manager, VisualEditor – 17:55, 2 September 2015 (UTC)[reply]

Discussion

Sounds like a low impact plan to me. —TheDJ (talk • contribs) 15:33, 3 September 2015 (UTC)[reply]

+1. This would be very helpful for the education program, especially for making sure all the student editors who just created accounts in the period before the VE rollout hit 100% all end up with the same settings.--ragesoss (talk) 16:51, 3 September 2015 (UTC)[reply]

Hold on. Where is the statistical data on the impact of the change with new editors that was promised? And what is the advantage of changing the preferences of accounts that are minimally or not active? And since the issue of preferences is raised, would it not be better to do some user education on preferences instead of changing them without editor participation? On what basis is it assumed that the editors had not made a conscious decision to leave VE not included? That calls for some A/B testing before implementation. I'm still baffled why VE has been activated in the Wikipedia/project namespace, an area that requires user signatures on more than half its pages, based on a single user's request. Risker (talk) 19:00, 3 September 2015 (UTC)[reply]
@Risker:

TL;DR: This proposal is mostly based on what is best for inexperienced users, and server performance issues. The real question is how to solve the server issues without adversely disrupting things for any editor group.
Where is the statistical data on the impact of the change with new editors that was promised?

Did you mean the statistical data about the A/B test? The report and data from that is on meta. Did you mean the gradual release to new users? As promised, after the first step in that process last month, I reported back on how well it went, before increasing the rate to a larger proportion and monitoring from there.

If you're looking for detailed numbers, there's an awful lot of statistical data provided in our dashboard at https://edit-analysis.wmflabs.org/compare/ but it's not very friendly, I'm afraid. (Cleaning that dashboard up so that those who don't have as much time and patience to pour through it is on our list of things to fix.)
And what is the advantage of changing the preferences of accounts that are minimally or not active?

Enabling VisualEditor in Beta Features for ever-more users adds a mess and (albeit minor) cost to the database, and thus site performance. There are already almost a quarter of a million accounts opted-in to VisualEditor, and letting this continue to grow (by more than another hundred thousand each month) is not great, technologically, and needs to be fixed for site stability reasons. (I hate to invoke WP:PERF, but…)

More importantly, however, Beta Features is not and has never been designed for anything other than users actively opting in to new things – it's both confusing and poorly designed for this use case, wherein ever more users get accounts only to find that the system has them "opted in" to having something they haven’t actually explicitly opted into. I don't to be part of adding even more confusion to editing Wikipedia; it's already too hard.
And since the issue of preferences is raised, would it not be better to do some user education on preferences instead of changing them without editor participation?

Though I think that educating users is a worthy initiative, that's the equivalent of suggesting we write clearer warning labels on people’s tax forms – for most people in the target audience they would never be seen, and for everyone who already knows, it would just get in the way. Education features are a serious area for further work, regardless of whether the user is writing content or engaging in a discussion.
On what basis is it assumed that the editors had not made a conscious decision to leave VE not included?

As you will see in the A/B test report, over 99% of users made no changes to their preferences about VisualEditor; 35 users opted out, and 110 opted in.
That calls for some A/B testing before implementation.

A careful A/B test over several months might be worth considering with some interstitial or otherwise calls to action ("Hey there, do you want to opt in to our old skin with more buttons?" and so on for a variety of options), but I do not think it would be appropriate for this use case.

Yours, Jdforrester (WMF) (talk) 00:30, 4 September 2015 (UTC)[reply]

No for experienced editors. It's annoying as hell when you step away for a few months and have your preferences changed. They were not set the way they are by accident. Additionally, the changes are often incredibly difficult to figure out how to reverse for the average editor. I often spend the first day after I come back from a long break reading VPT archives which is frankly ridiculous. Ambivalent for new editors, though looking at the last half hour on my watchlist I note VE still has serious problems. Jenks24 (talk) 19:44, 3 September 2015 (UTC)[reply]
@Jenks24: Understood. How many months do you think would be adequate, if not three? Six? Nine? The scientific research done on people who stop editing shows that a timespan longer than a month and less than six months is most likely to be useful for this. If an editor is inactive for more than a month, they are likely to not be active for a long while. If they are going to come back after this long period of inactivity, it will mostly likely be between six months and one year since their most recent edit. [1] and [2] (PDFs both) may be of interest. I appreciate that there are always outliers, but the goal is to set preferences in a way that works for the majority of users. Jdforrester (WMF) (talk) 01:10, 4 September 2015 (UTC)[reply]
@Jdforrester (WMF): what benefit will it be to the long-term user if they return? I admit I haven't read either of those papers, but just skimming the abstracts it doesn't seem to address that? If someone has made 50,000 edits in the 'old', wikimarkup style, surely getting used to VE will actually be more difficult than just doing things as they've always done. From personal perspective, the more things that are different coming back from a break the more difficult it is to get back into the swing of editing. I appreciate that in a lot of cases changes need to be made and I'm not saying "change nothing", but I fail to see the benefit of making an unasked for change to long-term experienced editors simply because they take an extended break. For example, look at all the unlinked names at WP:WBE (meaning they haven't edited for a month) – can you imagine any of them being pleasantly surprised when they log back in to find that VE has been activated on their account? If things are too hard or too different these returning editors will simply not bother. I don't think timeframe is the right way to be looking at this. Jenks24 (talk) 02:01, 4 September 2015 (UTC)[reply]
@Jenks24: You're right, those papers aren't specific to any one change, but are about user behaviour and how likely people are to come back and edit once they've ceased editing for a while. I understand your concern about not adding any extra ramps and bumps that might dissuade returning editors from, well, returning. However, several long-term editors, especially returning long-term editors, tell us that they actually prefer VisualEditor, and have found that it increases their productivity. Consequently, I would realistically expect even long-term editors who are battle-hardened in using wikitext to be pleasantly surprised to discover that Wikipedia can be edited in the same "visual" ways that they use every day for editing word processing documents and e-mail messages. If you don't think timeframe of last edit is the right way, what way would you recommend? Jdforrester (WMF) (talk) 20:50, 4 September 2015 (UTC)[reply]
@Jdforrester (WMF):Hmmm, fair enough, it could just be that I'm stuck in my ways and others are more embracing of change. I still generally dislike the idea of changing the preferences of editors simply because they are away for an extended period though. I prefer Kerry's suggestion below using a combination of how old the account is and how many edits it's made – obviously that's not an exact science, but still gives a reasonable indicator of how experienced an account is. I don't mind trying it on all accounts <1000 edits and then if that's successful maybe moving on to <5000, but that's about as far as I think it should go. If there is a concern that editors with more experience than this who have been away would miss out on learning about VE, I would not be opposed to some sort of automatic talk page message for anyone who takes a break of, say, six months or more between edits (it could even be less than six months if you thought it really necessary). Jenks24 (talk) 02:33, 5 September 2015 (UTC)[reply]

+1. That VE would just be one of the many other changes in the software that will have rolled out each week since they were last around (like the performance improvements to MediaWiki made over the last few months) is quite a stretch to claim. By "performance improvements", I presume you mean HHVM, which is AFAICT a totally back-end change having no effect whatsoever on user settings, quite unlike VE. BethNaught (talk) 19:49, 3 September 2015 (UTC)[reply]
@BethNaught: About 150 changes went live to this wiki just this morning (as happens every Thursday for all Wikipedias), and though individually most of the changes are relatively minor, collectively they make quite a change over time, especially when we’re talking about several months.

HHVM, though an excellent piece of work, was done almost a year ago, and wasn't what I meant. Beyond my team working on VisualEditor to make it faster, I'm talking about the brilliant work done by my colleagues working on other things, from the Performance team to the Discovery department. For example, in just the last month the former have cut the average "firstPaint” time from roughly 1.3s to 0.8s, making the site feel massively faster for the majority of users. (You can play with a few of their numbers on their performance dashboard.) Similarly, the latter are working to redesign of the Search interface, over-hauling it to provide better, more accurate and more useful results for our readers and editors alike. Some early examples were presented at the public meeting this morning, and the slides are on Commons (PDF).

By the bye, the impact of HHVM was to make loading VisualEditor about 10% faster, which we believe led to an increase in VisualEditor's use on wikis where it is used more widely, so it's not quite true to claim that back-end changes have no effect on user experience and take-up. :-) Jdforrester (WMF) (talk) 01:25, 4 September 2015 (UTC)[reply]
If I'm not mistaken, all of the things you specifically mention are back-end changes. None of those things change the way people edit – they may have effects on it, but they do not change the manner of editing. Enabling VE would be totally different. I imagine a returning experienced editor who had had VE enabled in this proposed change would feel exactly like I do when I visit other Wikipedias: click on Edit, curse with surprise and/or confusion, and have to work out how to leave VE. Then they would have to either find the setting to turn it off or break the habit of a Wikipedia lifetime and relearn the meaning of the most fundamental button on the site. – This is no way to welcome returning editors back. BethNaught (talk) 20:48, 8 September 2015 (UTC)[reply]
Beth, it seems that not everyone has the same experience. A more typical reaction to discovering VisualEditor appears to be surprise and interest, or even surprise and pleasure, rather than surprise and cursing. Given the opt-out rates, I believe that your personal reaction is not typical – though naturally one of the goals is to avoid offering VisualEditor to people who are likely to share your reaction, just as one of the goals is to offer it to the people whose reaction is likely to be the opposite.
But I think you're missing the main point: At what point do you think we can assume that this probably won't be a disturbing for most of the accounts? When the accounts in a given group are so stale that 90% of them won't ever edit again? When 95% of them won't? When 99% of them won't? There will (I hope) be a few false positives (because I still hope that all of my long-absent friends will return, even if all they do is tell me that they're alive), but what level of false positive (=we thought they wouldn't return, but they did) are we willing to tolerate? Similarly, at what point does one typically acquire "the habit of a Wikipedia lifetime", and therefore the presence of two editing buttons might cause temporary disruption? After 500 edits? After 1000? After 5000? Or is there some other quality that is more predictive than how recently the person edited and how many edits have been made? Whatamidoing (WMF) (talk) 22:54, 8 September 2015 (UTC)[reply]

Jenks24, that is a direct result of VisualEditor having been activated in Wikipedia namespace without any notice or discussion with the community as a whole. Editors who are used to working in project space all know that VE doesn't work there - or it didn't until about 36 hours ago. The majority of edits to Wikipedia space require either (a) a signature - not possible to do in VE or (b) a template that isn't in VE's "dictionary" or (c) both. I've asked for this to be reverted at T100067. Risker (talk) 20:22, 3 September 2015 (UTC)[reply]
This was us responding to a user request, and has been reverted pending community reconsideration. It’s off-topic to this proposal, but happy to discuss in another thread or (probably better) on the discussion on WP:VE/F? Jdforrester (WMF) (talk) 00:32, 4 September 2015 (UTC)[reply]
As someone both using the VE for a lot of my edits (not all) and someone who teaches new users to edit with Wikipedia, I think the Visual Editor does make life a lot easier for the inexperienced editor. I doubt most of these recent signups who wer not currently opted-in even know that the Visual Editor exists, let alone have made a conscious choice to stay opted-out. I don't think it unreasonable to roll it out to these folks (assuming some clear explanation is put on their User Talk page along with step-by-step opt-out instructions, if they desire to do so). What the threshold of "newness"/"inexperienced" should be? I'd say start small - signedup in the last 2 months and less than 100 edits. Wait and see how that group react. Do they rush to opt-out? Do they use the VE? Do they complain? If nothing very bad happens, gradually expand the parameters to increasingly wider groups of people while there appears to be benefit in doing so. Then when it's only the more experienced editors left (say, signup over 1 year ago or more than 1000 edits), leave a message on their User Talk page reminding them of the availability of the VE and how to opt in.Kerry (talk) 07:29, 4 September 2015 (UTC)[reply]
I like Kerry Raymond's idea. ~ ONUnicorn^{(Talk|Contribs)}problem solving 15:28, 4 September 2015 (UTC)[reply]

@Kerry Raymond: Thank you for your support, and the huge amount of feedback you've provided in the past few months. You have been a key part of making VisualEditor what it is today. Unfortunately, the kind of high-scale ramped approach you suggest would exacerbate the performance problems I mentioned above. (After all, we're talking about 26,109,385, of whom over 99.5% are currently inactive, and probably 98% will never edit again—but all of whom would have to have their preferences set.)

I have considered options around this. If it is really important, we could do a fairly expensive (in computing terms) pilot. We could opt-in about 50,000 of the new-ish, active accounts that would be affected under this proposal. Based on the opt-out results that we saw with the A/B test back in May, we realistically expect that about ten out of the 50,000 accounts would both be active and choose to opt-out of VisualEditor. (About three times as many accounts switched the other way when we tested.) I’m not sure this would be the kind of information for which you're looking, though?

Alternatively, we could assume that the experience here would be similar to the experience at other large Wikipedias. Even if you include active, experienced editors (which I am not proposing), the opt-out rate at other Wikipedias amounts to maybe less than 0.1% of all accounts. Less-experienced editors are less likely to opt out, and of course unused accounts never change their preferences. Even if the English Wikipedia opted out at a rate ten times the typical rate, it would still be a relatively small group of editors affected. Jdforrester (WMF) (talk) 00:35, 5 September 2015 (UTC)[reply]

Sorry if I was not clear. I was only proposing a rollout to inexperienced editors (at whatever pace is reasonable for performance considerations) and was not suggesting roll-out to dormant accounts (say, inactive over a year). I think the best action with dormant accounts would be to be trigger a "Welcome back" talk message on any reactivation of the account letting them know what's changed since they've been last been on-wiki (which is worth doing for reasons other than just the VE, e.g. paid editing policy). Kerry (talk) 02:25, 5 September 2015 (UTC)[reply]

Although I agree that would be nice in an ideal world, in a world with 150 changes going out each week, that would be .. difficult. What makes the list ? How big can the list be ? isn't 99.9% (even of the most important changes) going to 'off' the list by definition ?? —TheDJ (talk • contribs) 10:22, 6 September 2015 (UTC)[reply]

This might be a red herring but in terms of confusing existing editors, the only thing I can see that is confusing if the VE were to be enabled without their knowledge is that they would go from having one "Edit" tab to two "Edit source" and "Edit" tabs where the meaning of "Edit" has changed from source to visual. I can see that as potentially confusing. But if the tabs were "Edit" and "Edit visual", then that confusion would be reduced. Their familiar Edit tab would do what they expected (invoke the wikitext editor) and the "Edit visual" would be new and I think moderately self-explanatory. Having said all that, statistically do we actually have a problem with experienced editors trying to return from a break and being unable to edit? We know we have a problem getting people over their "early edit" curve, which this conversation is about. Kerry (talk) 03:01, 5 September 2015 (UTC)[reply]

Just a question on the performance impacts. Why not do a mass rollout the other way around, make it default? Instead of tracking opt-ins, track opt-outs. Do it in steps, anyone (like me) who currently doesn't use VE would get a notice saying it was going to become the default and have us choose to opt-out if we don't want to use it. After an arbitrary length of time, switch, so that only those who opt-out don't have it. Same with new users, instead of letting them opt-in to using it, have them opt-out of not using it. I'd assume fewer would ever opt-out than have currently opt-in. Jerod Lycett (talk) 02:51, 5 September 2015 (UTC)[reply]
@Jerodlycett: I'm not sure mass-messaging 28 million accounts (either on their talk pages or in some other way) telling them we're about to opt them in, and that if they don't want it they'll have to opt themselves back out once it's done is a very friendly step. :-) Also, all new accounts already get opted-in to having both available; this is about how to move to a better situation technically without disrupting things for existing editors for whom we don't want to suddenly change things. Note that "doing it in steps" means keeping track of millions of users with different preferences, which is the exact thing we're trying to avoid performance-wise. Jdforrester (WMF) (talk) 16:07, 7 September 2015 (UTC)[reply]
@Jdforrester (WMF):I must have misread the conversation. It seemed like right now you have an ever-growing table of people who choose to use VE, and if it was set as default that would balloon the table. My question was about instead having a table of opt-outs. So that right now we'd switch it so that all new users would have to opt-out (I'm assuming, and this is the question part, that fewer would opt-out than would opt-in). Also for messaging, I suggested a notification, like when you get pinged, not a message on the talk page. A question on that, if there was a change made to the default skin how would you go about the change? I've just assumed that it'd just be "All these editors chose to use the default, the default is changing, they're still using the default." and the same logic seems to apply here. All these old editors chose to use the default editor, and the default editor will have changed. They can choose to not use it. Anyway, the steps would be to use both opt-in and opt-out tables for a time, then drop the opt-in table and only use the opt-out table. Either table will (potentially) grow to infinity, I just think opt-out would grow slower. Another question though, what happens if I opt-in, decided I don't like VE, and opt-out, is there an entry in there for me, or does it drop that entry? Jerod Lycett (talk) 17:00, 7 September 2015 (UTC)[reply]
A few points that may be useful for consideration (pinging Jerod Lycett and James F.):

As noted above, all brand-new accounts already have access to VisualEditor. It's available, but they don't have to use it. If they don't want to even see the option, then they can opt out. When we did a 50-50 test in May, about 99% stayed with whatever they were given. Of the remaining 1%, about three new editors opted in for every one editor who opted out. I think you are correct to assume that fewer people will opt-out than will opt-in, at least among inexperienced editors.

You are correct that the main problem is "an ever-growing table" of prefs settings. However, because of the sheer number of accounts involved, it doesn't matter much whether the setting is a million accounts opted in via Beta Features or a million accounts opted out via regular preferences. "Do it in steps" is not technologically feasible. The developers cannot gradually opt in a million here and a million there until all 26,132,779 have been processed. This will (unfortunately) need to be an "all at once" thing.

However, it does not need to be an "all the same" thing. The devs can set prefs on or off for each group of accounts. Whether any given account is on or off can be based on our best estimate about which types of accounts would prefer which settings (including which ones are unlikely to ever be used again, so that it just doesn't matter).

Consequently, this is the main Question: What are the characteristics of accounts that will (mostly) want to be opted in, and what are the characteristics of accounts that will (mostly) want to be opted out? For example:
We should probably put the 280K (and rising rapidly) accounts that are already opted in into the list of people who will probably want access to VisualEditor. This will prevent changes for those editors.

The many millions of accounts who haven't edited for months or years should probably go in the "do whatever is least strain on the servers" list (which happens to mean opting them in).

Relatively recent newbies should probably go in the "get VisualEditor" list, since we already know that three times as many choose to opt-in as choose to opt-out.

Active editors without VisualEditor but with advanced user rights (e.g., admins) should probably go in the "don't touch my preferences" list. (On second thought, maybe I shouldn't have pinged James F. while mentioning another way to complicate the database work. ;-)

—and so forth, through whatever characteristics you think are important.

The system doesn't allow multiple prefs settings for the same thing. This prevents editors from setting contradictory preferences, i.e., both opting in and opting out. As a result, we can move from one system to the other (this is the proposal), but we cannot maintain the current opt-in prefs list and a separate opt-out prefs list at the same time.

Sadly, one cannot use Notifications ("Echo") to send a mass message. The software does not have the ability to do so; this is long-requested (phab:T58361 and phab:T77347). Whatamidoing (WMF) (talk) 23:54, 7 September 2015 (UTC)[reply]
Absolutely not While I understand WMF believes Visual Editor is a good thing, I disagree. Visual Editor doesn't work as well as learning the coding. It doesn't help new editors learn what they need to know and actually makes editing hard when new users attempt it at edit-a-thons led by experienced Wikipedians that don't use Visual Editor. There's no reason to punish "dormant" accounts with VE, either. Just kill off Visual Editor and admit it's a lost cause. Chris Troutman (talk) 22:14, 8 September 2015 (UTC)[reply]
Strong Oppose - I'd rather not have the possibility of returning editors erroneously clicking on a gadget they didn't enable and getting confused when looking for the normal editing system. Though I don't care for the gadget, I can understand the argument for better presenting the option to brand new editors (though they may have edited as an IP). Personally I think editors should be encouraged to use the traditional editing system.—Godsy^(TALK_CONT) 12:08, 9 September 2015 (UTC)[reply]
Oppose This strikes me as an attempt to jam VE's foot further in the door so it'd be harder to shut. The logic of this proposal is also warped. It says that because we offer a choice to all new editors yet some inexperienced editors didn't have a choice, we will make the choice for them for them. Send them a message asking them to try VisualEditor. Show them how to switch between the choices and ask them to complete a survey in a week and say with they prefer and why. Jason Quinn (talk) 14:55, 9 September 2015 (UTC)[reply]
Strong Oppose Visual Editor sucks. It sucks. It absolutely, completely, totally, and utterly SUCKS. It sucks now. It always has sucked. Outside the realm of misty-eyed wishful thinking, it always will suck. Fiddling with it, tweaking it, enabling it under certain conditions, and so on is really just polishing a turd (see also sunk cost fallacy). I admit that that's a flawed metaphor though: turds are unpleasant, but they certainly are cheap. Visual Editor, on the other hand, has wasted incalculable amounts of donors' money and volunteers' time. But the solution is the same: they both need to be flushed and forgotten. Andrew Lenahan - Starblind 15:26, 9 September 2015 (UTC)[reply]
Opposed. Please don't fiddle with my food while I'm away from the dinner table. GenQuest ^{"Talk to Me"} 15:36, 9 September 2015 (UTC)[reply]
Support 0.5% accounts are active. Let's face the reality. We may consider deactivating/closing old accounts altogether instead of discussing what would their default preferences be on a website they don't use at all for years. On the other hand, I miss the Wordperfect possibility to edit code every time I use MSWord, FWTW I still do not understand why a wikicode edit interface such as WikEd is not available for experienced users or at the very least, a default editor with syntax highlighting. Afernand74 (talk) 17:08, 9 September 2015 (UTC)[reply]
Um, wikEd is available for all logged-in users? What are you trying to say? BethNaught (talk) 20:20, 9 September 2015 (UTC)[reply]
I was trying to say that the WP default wikicode editor is not really human friendly imho. Some improvement here would be welcomed.
In my opinion this proposal, as it regards inactive users, sends a symbolic message which is highly undesirable, namely: "we wrote some new software but the existing software can't cope with it being on by default, therefore we are going to unilaterally change your fundamental editing experience to gloss over the difficulty we've been having in implementing our controversial new software." What I'm trying to say is, don't use the limitations of the MediaWiki preference system as an excuse to force VE on currently inactive accounts (conveniently increasing the VE adoption rate), instead fix the preferences system. I don't care how small the percentage of pissed-off returners may be, there is morally no need for it to be greater than zero. BethNaught (talk) 20:20, 9 September 2015 (UTC)[reply]
Strong Oppose. Based on my reading of the results here, the Visual Editor simply doesn't seem to helpful in any significant way (and, depending on how you read the slightly longer time to save, may even be harder to use.) In particular, the total failure to show any improvement in editor retention undermines the entire reason the Visual Editor was created in the first place, doesn't it? Given that splitting the userbase and offering multiple ways of editing has intrinsic disadvantages, the negative results from that study strike me as enough of a reason to halt any efforts to encourage its use. It was an experiment with noble goals, but it was still ultimately just an experiment, and it hasn't worked out -- continuing to try and push adaptation at this point, with no evidence that it's actually achieving anything worthwhile, strikes me as falling into a sunk cost fallacy with regards to the amount of resources that were already wasted developing it. --Aquillion (talk) 21:56, 9 September 2015 (UTC)[reply]
Strong Oppose as my concerns raised at Wikipedia:Village_pump_(proposals)/Archive_125#Gradually_enabling_VisualEditor_for_new_accounts still haven't been addressed. There is no proven benefit to Visual Editor, and it still has significant issues that have not been fixed. The May 2015 study looked at a population of 20,000 editors, half of whom had VisualEditor enabled as default. Of these two groups, nearly identical numbers (3386 vs 3363) made an edit, nearly identical numbers (2502 vs 2551) edited more than one article, nearly identical numbers made productive unreverted edits (1778 vs 1772), and an identical number were still editing 3-7 days after registration (287). If anything, this shows that Wikicode doesn't scare off new editors any more than VE does. So what's the reason for the switch? What problem are you trying to fix? I'd want to see evidence that VisualEditor has a significant positive impact on editor retention and constructive contributions before it's rolled out. We shouldn't have to start cleaning up <nowiki/> tags everywhere for no good reason. --Ahecht (TALK
PAGE) 22:51, 9 September 2015 (UTC)[reply]
Strong oppose If people want their settings changes they can change them. We do ourselves a disservice by hiding the complexity of wiki code from them with a pretty GUI, using automated tools to edit manually created mark up is only going to result in people changing things they do not understand. That editor is a pain in the ass and frankly I think if it was really something the community wanted it is something they would have embraced, rather than something that needs to be slowly pushed on them. The lack of interest should be a strong clue. I understand the foundation is invested in this, but the community rejects things that people have invested in all the time, we all of to deal with that. Chillum 15:10, 11 September 2015 (UTC)[reply]
Question For people who have Visual Editor enabled, is there any data on what percentage of their edits are made using it vs. editing the code? I saw it as a beta testing option and enabled it, but I rarely use it because unless it's a simple typo fix (e.g. adn -> and) editing the code is much easier (for me at least). Before enabling it for more people, I'd like statistics on how much use it gets amongst people who already have it enabled. ~ ONUnicorn^{(Talk|Contribs)}problem solving 17:37, 11 September 2015 (UTC)[reply]

@ONUnicorn: For your question about how much people are using the visual editor, this dashboard has some specific numbers – on Wednesday, about 1000 editors who joined post-2013 used the visual editor, against about 3000 who used the wikitext editor (some will have used both, of course). For "old hands” editing from before 2013, the numbers are 168 and about 5000. By comparison, for the French Wikipedia (where the visual editor has been available to all for years), the equivalent numbers are 229 using the visual editor and 352 using the wikitext editor for newer editors, and 118 against 802 for older editors; both groups edit less than logged-out editors, however.

There's a whole bunch of other data that we now publish at our more modern dashboard, and that might interest you as well. This covers numbers related to editing tools, each split between the wikitext editor and the visual editor. It's a bit of a thicket, but you can learn some odd things from the data (when it isn't subject to data interruptions and corruptions; it's still a work in progress).

For example, here's the last fortnight's average data of 'edit success' (what proportion of times the editor was loaded and the resulting edit was finished and saved), comparing the visual editor to the wikitext editor by the 'cohort' of how many edits the user (account) had ever made before that edit:

Cohort	All wikis		English Wikipedia		French Wikipedia		Δ between editor software
Cohort	VE	WT	VE	WT	VE	WT	Δ between editor software
IP editors	16%	3%	N/A	6%	20%	2%	Greatly better with the visual editor
1^st edit	31%	18%	34%	18%	35%	18%	Much better
2^nd–5^th edit	41%	28%	42%	35%	44%	32%	A fair bit better
6^th–100^th edit	51%	45%	51%	51%	55%	49%	A bit better
101^st+ edit	59%	58%	61%	58%	55%	61%	About the same

As you can see, there's a dramatic difference for the first few edits, but it's not as profound once you've learnt the ropes of what kinds of edit get reverted and how to write an edit that other people will like. There's also plenty of anecdotes about how using the visual editor is pleasing for some experienced editors, but that kind of fuzzy happiness won't have much impact on the hard numbers that this dashboard shows.

If you want, you can play with this data for yourself at https://edit-analysis.wmflabs.org/compare/ as different wikis have different editing patterns. (Note that data for some wikis' cohorts are very shallow as they don’t get many edits – for example, here on the English Wikipedia, IP editors don’t see a tab for the visual editor, so numbers there are for the few developers and test bots loading the editor in testing.)

When we talk about the value of the visual editor for editors, it sounds abstract and possibly wrong, but hopefully this gives some context. It's used millions of times (over a million times on this wiki alone), and is clearly liked and useful, however much those of us who prefer wikitext don't want or need it. :-)

Jdforrester (WMF) (talk) 21:08, 11 September 2015 (UTC)[reply]

Strong Oppose - To be absolute blunt it's shite - It was shite last year and it's shite now, Learning how to use wikitext is great and can help you develop skills in the IT area whereas using a crappy editor that does everything for you gives you no knowledge at all, I know this may sound sad but when MySpace was the new thing and everyone could use HTML/CSS - I loved it and at that time so did everyone else, So personally I feel Wikitext is far more knowledgeable to people than VE and so I don't believe it should be enabled for inexperienced/dormant accounts. –Davey2010^Talk 01:15, 12 September 2015 (UTC)[reply]

Motion: AUSC Extension

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)[reply]

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

Change the default AfD template to include wording that it's a discussion

{{Afd2}} is currently the template we use on new AfD by default. I'm proposing that we include wording such as is found on {{Not a ballot}} by default, rather than waiting. While the wording may need tweaked slightly for this purpose I think the relevant section that should be included is:

please note that this is not a majority vote, but instead a discussion among Wikipedia contributors. Wikipedia has policies and guidelines regarding the encyclopedia's content, and consensus (agreement) is gauged based on the merits of the arguments, not by counting votes.

I would hope that this would preclude needing to use {{not a ballot}} as often. Jerod Lycett (talk) 02:32, 5 September 2015 (UTC)[reply]

Auto sign on talkpages

Moved from Wikipedia:Village pump (idea lab)

– Mz7 (talk) 22:34, 5 September 2015 (UTC)[reply]

Now that Flow is deprioritised, I suggest we default all new accounts to autosign on talkpages.

This would require a new preference "autosign on talk" which would default to signing all your posts on talkpages, and a new tick box on the edit screen "sign this edit".

Existing editors could blithely ignore this if they wished, but simply clicking "sign this edit" would be a new way to add a space and four tildas when wanted. New editors and editors who opt in by changing their preferences could still untick "sign this edit" when fixing a typo in their previous talkpage comment.

RFA and certain other pages where you are expected to sign could have a special template to enable autosigning

All welcome templates could have the clunky, offputting and very silly looking bit about please sign your posts on talkpages with ~~~~ removed.

The WMF is asking for community input into things they could do instead of FLOW - this could be one of them. Ϣere SpielChequers 13:37, 3 September 2015 (UTC)[reply]

Support - Good idea that's long overdue. The User:Sinebot does this as a cleanup measure anyway, and this would help demystify/declutter talk pages, which by almost every measure are a usability nightmare for newbies. -- Fuzheado | Talk 14:11, 3 September 2015 (UTC)[reply]
Support - frankly this should be in MediaWiki itself. Suggested method: if it doesn't detect a ~~~~ it adds one. You can switch this off in your preferences. Everyone who already has an account starts with it switched off, everyone creating a new account starts with it switched on - David Gerard (talk) 14:15, 3 September 2015 (UTC)[reply]
Support in the model suggested by David Gerard -> I have never understood why we rely on a bot to do this work, when we could just be signing as part of the software, Sadads (talk) 14:16, 3 September 2015 (UTC)[reply]
One limitation should prevent edits to the header section of an article (such as infoboxes) from being signed. Sadads (talk) 14:17, 3 September 2015 (UTC)[reply]
Comment How does Sinebot determine where to put the signature? Presumably this would use a similar algorithm. We would need some sophisticated algorithms or very clear opt-out boxes to avoid messing up e.g. talk page refactoring and archiving. BethNaught (talk) 14:20, 3 September 2015 (UTC)[reply]
- There would be a new tick box on the edit screen "sign this edit". If you don't want to sign you untick it. Ϣere SpielChequers 14:43, 3 September 2015 (UTC)[reply]
Support, should indeed be in MediaWiki itself. Fundamentally a talk page should be more like a blog page with threaded comments. As an ordinary non-admin user, I should be able to make posts like this one with the software autosigning, and edit them afterwards without having to specially turn off autosign but with the software either replacing the autosignature (not adding another one) or adding a small text such as "edited [timestamp]". But as an ordinary non-admin user, I shouldn't be able to edit other people's posts, which AFAIK I can, though I've never tried. Stanning (talk) 14:48, 3 September 2015 (UTC)[reply]
Support This is a great idea. I have proposed an addon on below.—^cyberpower_Chat:Online 15:24, 3 September 2015 (UTC)[reply]
Support, provided there is a clear opt-out so correcting a typo etc. does not result in another signature. If the function could be clever enough to detect when I am just editing my own, already-signed post, all the better. Andreas JN466 16:11, 3 September 2015 (UTC)[reply]
Comment If implemented it in JavaScript it could be running by next week. Doing it JS gives us better interactivity with the user and it would be open source unlike User:SineBot. Why wasn't it suggested before? Oh right: "FLOW is going to fix discussions". — Dispenser 17:39, 3 September 2015 (UTC)[reply]
Support. I didn't even know WP:FLOW had been deemphasized! --IJBall (contribs • talk) 19:46, 3 September 2015 (UTC)[reply]
Support. A sensible improvement to the current talk system. Should really be in core MediaWiki. MER-C 01:11, 4 September 2015 (UTC)[reply]
Support - as long as there is the choice to untick the box, e.g. for minor corrections to talk posts that I've already signed. Smallbones_(smalltalk) 13:41, 4 September 2015 (UTC)[reply]
Support, especially the "special template" to enable autosigning, which is a great idea. APerson (talk!) 18:25, 4 September 2015 (UTC)[reply]
Support a great idea, new users can integrate more easily with one less of Wikipedia's many idiosyncracies to master. --Tom (LT) (talk) 00:49, 5 September 2015 (UTC)[reply]
Support - I concur with the above this really should be part of the MediaWiki software, I have a quite few newbies who post on my TP and never sign there posts and seeing as the bot never shows up it means I have to do it myself and quite frankly it's a pain in the arse at times (Admittingly I don't have to do it but I prefer them all signed & dated), Anyway it's a great idea!. –Davey2010^Talk 01:08, 5 September 2015 (UTC)[reply]
Oppose as proposed. Many, many users have different signatures from their usernames, or have designed personalized signatures well within our signature guideline that are as much a part of their Wikipedia identity as their contributions history. The four tildes is what pretty much every experienced Wikipedian uses, not the "sign this edit" button (which on my screen is in the middle of a long string of small boxes and it doesn't even say "sign", it's just a representation of cursive writing). It also disenfranchises new users from participating in non-talk pages where signatures are expected, which encompasses most pages in Wikipedia space, and some in other areas, because they will never figure out how to do it. Risker (talk) 03:05, 5 September 2015 (UTC)[reply]
- @Risker:, We are not proposing to replace tildes with a button, we are proposing to allow users to eliminate both. The intention is that the page is automatically signed with your signature, not a generic one. If you set the auto-sign user preference, you wouldn't need to type tildes or click a button, it would just do it for you like it should. Also, using categories or magic words, the software would also sign pages that are used as discussions even if they don't have talk in the name. Oiyarbepsy (talk) 00:00, 6 September 2015 (UTC)[reply]
Support although it's pointless to do so, since AFAIK this is a WONTFIX issue; would've been done a long time ago if it weren't. Signing is one of our more ridiculous and archaic-looking insider shibboleths. It's also a PITA on mobile, and anything that can make editing on mobile less of a dumpster fire of awfulness is a good idea. Opabinia regalis (talk) 03:59, 5 September 2015 (UTC)[reply]
Support If a bot can figure out how to do this then the interface can just use similar logic. Andrew D. (talk) 09:59, 5 September 2015 (UTC)[reply]
I think Sinebot limits itself to new posts at the end of a section. This is precisely because it couldn't reliably figure out the correct action in other situations. If you add a new unsigned comment in the middle of a thread, the bot won't help you. The bot is also restricted to certain talk spaces. Thus a bot comparison isn't particularly apt. ―Mandruss ☎ 09:20, 6 September 2015 (UTC)[reply]
Conditional support - I think this is a good idea, particularly for mobile devices, as in some mobile keyboards the tilde "key" is hard to find. However, I have one issue regarding how this could work: how would this work if a user adds more than one paragraph or replies to separate paragraphs in the same edit? For example, what if I reply at this section and the section below in the same edit? Would it only sign one of my additions or both? Also, if this proposal is to pass, the coverage could also be expanded to include pages outside of Talk namespaces, such as noticeboards and the Reference desk (i.e. any page in Category:Non-talk pages that are automatically signed. Narutolovehinata5 ^tccsdnew 15:48, 5 September 2015 (UTC)[reply]
Good point, but probably a rare/advanced user one. I suspect if you reply to more than one thread in the same edit it will only sign one of them, however by the time people are doing that they are likely to have learned how to get round that. Ϣere SpielChequers 09:52, 7 September 2015 (UTC)[reply]
Support We already have bots that do this, so I see no reason why it can't just be done automatically whenever a talk page edit is made. Spirit of Eagle (talk) 22:41, 5 September 2015 (UTC)[reply]
Oppose People often edit their own comments or make other talk-page edits that don't involve the addition of new comments and shouldn't be signed. Sometimes, people even remove their own comments that they believe to be inappropriate. Even IPs often do this, especially in the case of people who edit frequently without accounts. These edits should never be signed; how would the software detect this kind of thing? However, I would support auto-signing of comments added through the add-a-new-section button, since those always should get signatures. Nyttend (talk) 23:52, 5 September 2015 (UTC)[reply]
- @Nyttend: There would be a checkbox saying sign this post that would be automatically checked. Users who are deleting or editing would simply uncheck the box. Oiyarbepsy (talk) 00:03, 6 September 2015 (UTC)[reply]
Oppose A lot of article talk pages have a large top section that that contains things like ArbCom notices, old AfD notices, GA nom notices, etc. There is also the issue where at times you'll want your signature to be one space behind you post, at other times on a new line below it. It also lets you know about a user's competency as to whether they add a signature or not. Jerod Lycett (talk) 08:59, 6 September 2015 (UTC)[reply]
~~Support~~ ~~Support as opt-in, Oppose as opt-out~~ Oppose - Which is harder, typing the tildes or clicking the button when you need a sig, or unchecking the box when you don't? Seems like a wash to me, but I'm willing to support giving it a try if WMF is willing to do it. It's completely opt-in, it affects no one who doesn't want it, so the worst case is that we keep a former Flow developer employed for awhile and then have to yank the feature back out in a few years because of lack of use. I could live with that worst case. ―Mandruss ☎ 09:37, 6 September 2015 (UTC)[reply]
- The proposal by DavidGerard is opt-out, not opt-in. The proposal is to give this to everyone by default and then to let people opt-out if they don't like it (and if they can find a prefs switch in the long list of gadgets). I'd be opting out immediately, of course. WhatamIdoing (talk) 16:06, 6 September 2015 (UTC)[reply]
  - @WhatamIdoing: That's incorrect. This proposal is as I said at the top for "New editors and editors who opt in" David Gerrard added a suggested methodology, but he stuck with the same "opt in for existing accounts, opt out for new ones" logic. Nobody is suggesting the opt everyone in approach that WhatamIdoing opposes. Ϣere SpielChequers 16:08, 8 September 2015 (UTC)[reply]
  - I stand corrected, thanks. New optional features should generally be opt-in, and this is especially true when a feature affects everyday work to such a degree. It would be highly disruptive to throw this in and force everyone to adapt immediately or change their prefs immediately. Modified my !vote. ―Mandruss ☎ 00:29, 7 September 2015 (UTC)[reply]
  - The ideal would be opt-in for existing users and opt-out for new users, making this even more messy. If this was at VPI first, I'm surprised this didn't come up there, or, if it did, I'm surprised the consensus there was opt-out for everyone. Sorry I missed that. But this Wikipedia thing is a messy business all around. ―Mandruss ☎ 01:55, 7 September 2015 (UTC)[reply]
    - That might be possible, although it's my impression that it would not be quick and easy. WhatamIdoing (talk) 02:50, 7 September 2015 (UTC)[reply]
      - Although I know nothing of the internals, the impression I have from decades in development is that it shouldn't be any harder at all. Seems to me there will be necessarily be two pieces of software involved: (1) a one-time mass update to add the new field to existing prefs, and (2) the code to create a new user. If that's the case, the former could set the fields to "off" and the latter to "on". But who knows. ―Mandruss ☎ 04:59, 8 September 2015 (UTC)[reply]
- Alrighty Then. Per WereSpielChequers's comment above, there's apparently some confusion here as a result of failure to nail down the particulars at VPI first. In any case, if Quiddity (WMF) is to be believed below, and they are in a position to know, opt-in for existing users is not a practical possibility. Since I can't live with opt-out for existing users, I'm left to Oppose. As I said, it's a wash anyway, largely trading one editor effort for another. I'm modifying my !vote, again. ―Mandruss ☎ 09:26, 10 September 2015 (UTC)[reply]
Strongest possible support. The Opt-OUT idea is good as are some of the other technical suggestions for identifying the kind of pages or edits. Kudpung กุดผึ้ง (talk) 05:26, 8 September 2015 (UTC)r.[reply]
Comment There are a couple of key points:

This proposal is not possible as phrased, because it is asking to turn the gadget off for 25 million existing accounts, but to turn it on for two or three million new accounts each year. This is not possible without some big changes to the performance of the preferences system in MediaWiki, and hacks to implement it would lead to the same performance issues described in the discussion about how to solve exactly this performance problem for VisualEditor (i.e. millions of accounts adding a new preference). Ultimately the developers would come in and switch anything like this off to save the site from falling over.
If a gadget is used, then to satisfy the requirements of being available for all newcomers (optionally including IP-editors), it would need to be "default on for everyone", with the usual gadget opt-out possibility for experienced users (as we have with Reference Tooltips, for example).

If we do decide to experiment with a gadget, there's an existing userscript at Dewiki (w:de:Benutzer:Perhelion/signing), which appears to generally work as expected. It will have all the limitations that Sinebot does, and possibly more. Creating something more reliable is an extremely difficult goal (because of all the edge-cases), which is why it hasn't been solved in the last 15 years. HTH. Quiddity (WMF) (talk) 18:03, 9 September 2015 (UTC)[reply]

- We now have a range of opinions on the technical side from this needing a week to it not being possible. While I'm not a mediawiki coder, I've been in IT for long enough to know that if the decision is to go ahead the reality will be somewhere in between. We might at worst have an entirely opt in system where we can at least amend all our welcome templates to give people a choice between learning to type tildas or clicking something to set a user preference; That would of course still be a big win. In the meantime can I suggest that we focus this discussion on whether we want to introduce an autosign system with an opt out for existing accounts and an opt in for new ones; And can I point out to those who believe in Flow, that Flow would be resented by fewer if its price didn't include a blanket veto on any attempt to improve the existing software. Ϣere SpielChequers 11:00, 10 September 2015 (UTC)[reply]
Oppose per Nyttend. New editors will be annoyed with the fact that their copyedits will be auto-signed, causing a random signature to show up at the end of their copy edits. Also, this proposal assumes that the editor will be knowledgable enough to navigate to the preferences page to disable this feature, which is bad to assume. It would be more efficient for a bot to place an {{Unsigned}} template after the comment, then place some sort of warning message on accounts that fall under the "new" criterion as outlined in this discussion (provided that bot had not already been created.) Steel1943 (talk) 22:28, 11 September 2015 (UTC)[reply]

Set default discussion pages

In conjunction to the proposal above, I believe it is technically possible to implement this. All odd numbered namespaces are talk pages are extremely likely to be talk pages. The system could have magic words such as __NODISCUSSION__ and __ISDISCUSSION__, where the automatically leave the option unticked, or automatically tick it, respectively.

Support as proposer.—^cyberpower_Chat:Online 15:24, 3 September 2015 (UTC)[reply]

Magic words that could be used for this purpose already exist: NONEWSECTIONLINK and NEWSECTIONLINK. Cenarium (talk) 16:57, 3 September 2015 (UTC)[reply]
Fair enough.—^cyberpower_{Chat:Limited Access} 17:19, 3 September 2015 (UTC)[reply]

@Cenarium and Cyberpower678: Wait, unless I've misunderstood something, there are some discussion pages that do not use the "new section" link, AfD discussions being the first that come to mind. Mz7 (talk) 00:43, 6 September 2015 (UTC)[reply]

Comment: any subpages of Wikipedia talk:Articles for creation need to be excluded are they are article drafts. BethNaught (talk) 21:11, 5 September 2015 (UTC)[reply]

Last year, the AFC project made the change from the Wikipedia talk namespace to the Drafts namespace. ~~I do not believe there are still AFC drafts in the Wikipedia talk namespace, so I'm not sure if this exclusion would be necessary.~~ Mz7 (talk) 00:46, 6 September 2015 (UTC)[reply]

Doesn't look necessary. Eman235/talk 00:59, 6 September 2015 (UTC)[reply]

Slipped my mind to do a prefix search. It actually does look like it might be necessary. (The prefix is "Articles for creation" not "WikiProject Articles for creation".) While there aren't any pending drafts currently in the Wikipedia namespace, there does appear to be a significant number of declined and old WP:CSD#G13-postponed drafts still there. Mz7 (talk) 02:13, 6 September 2015 (UTC)[reply]

Comment 2 We already have Category:Non-talk pages that are automatically signed Oiyarbepsy (talk) 23:55, 5 September 2015 (UTC)[reply]

Move to Wikipedia:Village pump (proposals)?

I was going to add my support to the discussion above, but I was hit by the edit notice for the page, which says it's not for consensus polling. Since there has been a rather overwhelming outpouring of support for this idea, and also since it's been listed on WP:CENT, I think this idea should be given the okay to move to the proposals village pump (the entire discussion above should probably be moved there). Mz7 (talk) 02:44, 5 September 2015 (UTC)[reply]

Agreed. This is no longer an idea lab.—^cyberpower_{Chat:Limited Access} 15:02, 5 September 2015 (UTC)[reply]

Done Mz7 (talk) 22:34, 5 September 2015 (UTC)[reply]

New user right: Gadget editor

A new user right called "Gadget editor" should be created. Gadget editors are allowed to create, edit, and move pages in the "Gadget" and "Gadget definition" namespaces. Also, administrators should be given the Gadget editor right and in addition, they should be allowed to delete pages in the aforementioned namespaces. GeoffreyT2000 (talk) 00:12, 7 September 2015 (UTC)[reply]

An observation: no "Gadget" or "Gadget definition" namespaces exist, these pages are in mediawiki namespace. What you suggest would require modifying the gadgets extension. Cenarium (talk) 00:54, 7 September 2015 (UTC)[reply]
Check your recent changes filter dropdown. The namespaces exist now, but are unused. --Izno (talk) 02:19, 7 September 2015 (UTC)[reply]
Indeed, I hadn't noticed them, they were recently added by phab:T106177. Even sysops can't edit them at the moment. A gadget editor usergroup seems like a good idea. Cenarium (talk) 13:11, 7 September 2015 (UTC)[reply]
Who should hold that user right? The amount of trust necessary is so high that I can't imagine giving it to anyone but admins. —Kusma (t·c) 14:32, 7 September 2015 (UTC)[reply]
- Seriously: The amount of damage that can be done with Javascript is so high, that maybe we ought to have a "two-key" system and use proper code review techniques. That way, if the first admin (or person who is an admin and a technically competent dev) happens to overlook a typo, then there's a chance that a second admin would notice before it breaks the wiki. WhatamIdoing (talk) 16:13, 7 September 2015 (UTC)[reply]

Please Contribute!!!

It has come to my attention that some users experience a serious glitch on the community portal that puts half of the content off of the page (I have a photo listed at the discussion I am about to refer to.). Also the community portal seems a bit outdated. So I created a new portal here and began discussion for consensus to implement the newly designed page. (I have not implemented a color scheme yet other than greys so that would be to be decided on if implemented.) Only one user contributed and I fine tuned the new page to resolve all of their concerns but I would appreciate more users to give their opinion (as only one has contributed in over a week) and hopefully come to consensus on this matter. The discussion is going on under the "A Proposal" section here. Thanks and please do not comment under this post!Tortle (talk) 01:41, 7 September 2015 (UTC)[reply]

Time for a patroller user right?

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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 :

a unique usergroup of reviewers / patrollers
two distinct groups with reviewers able to patrol
two distinct groups with patrollers able to review
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)[reply]

- 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)[reply]
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 :)[3]
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)[reply]

@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)[reply]

@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:

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.
Admin looks over request and if no red flags pop up they grant the right. (this is where it would typically end)
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.
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)[reply]

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. Ϣere SpielChequers 15:50, 8 September 2015 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]
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)[reply]

one article for all the languages (translated to all the languages)

Hello.

I use all the time en.wikipedia (english) and es.wikipedia (spanish).

I think the best it would be to have only ONE WIKIPEDIA translated to all the languages. Only one article translated to all the languages. This would be a lot better for everyone, for many obvious reasons. This would reduce the number of writers to only the experts.

I think also it would be better to ease the process of sending and publishing comments. I've found errors in articles and I don't know how to publish my corrections. By looking how to send this suggestion I think I found how but it would be better to make it easier (like writing a comment in youtube)

Thank you for listening me and for wikipedia. What would be the world without wikipedia. Carlos Arellano — Preceding unsigned comment added by 201.161.151.249 (talk • contribs) 05:09, 8 September 2015‎

Having only 1 article translated into all languages is not feasible yet. Maybe when machine-translation gets better it will be. HOWEVER, in the English Wikipedia at least you can enable the en:User:Equazcion/SidebarTranslate "gadget", which lets you see a rough machine-translation of the articles in the other-language Wikipedias.

On your other question: A good place to get help editing Wikipedia articles is WP:HELP. davidwr/(talk)/(contribs) 06:05, 8 September 2015 (UTC)[reply]

There is also the Content Translation tool available (when logged in) in Beta features. Keegan (WMF) (talk) 18:00, 8 September 2015 (UTC)[reply]

Removing Persondata

Persondata was been deprecated by an RfC held here, which closed with "Consensus is to deprecate and remove". A bot is needed, to remove it from all articles. However, my request for a bot to do so was closed with the claim "a discussion about a bot operation of this magnitude needs to be held in a broader forum, with more participants and a more focused discussion". I therefore seek agreement here, to have a bot carry out this task. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:12, 8 September 2015 (UTC)[reply]

Wikipedia:Bot requests/Archive 64#Remove persondata is the request for a bot that Andy mentions. --Izno (talk) 15:59, 9 September 2015 (UTC)[reply]

Conditinal support. As the template has been marked as being deprecated for three months, it makes sense to begin removing it from articles in a methodical fashion. A bot is the most logical means to perform this task. My concern is that some portion of the Wikipedia community is unaware that {{Persondata}} has been deprecated and as a result is still adding useful information in calls to the template. To deal with this concern, when a bot is in the process of removing the template from an article it should check Wikidata to see if the data items defined in the template have been migrated to Wikidata. If a data item is missing from Wikidata, then the bot should copy the information there before completing the removal. I am agnostic on how the bot should behave when a conflict between Persondata and Wikidata is detected and will defer to the bot's designer on how to best proceed in such cases. --Allen3 ^talk 11:10, 8 September 2015 (UTC)[reply]
- @Allen3: Please note the discussion of this point in the RfC. All the data that can be reliably ported to Wikidata automatically has been ported. Wikidata does not want further automated import of Persondata. I share your concerns that some editors are still expending time and energy updating this template - that's why we need to remove it from pages, ASAP. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:33, 8 September 2015 (UTC)[reply]
Question - Has all of the Persondata been migrated to Wikidata? That would seem to be a prerequisite. - MrX 13:33, 8 September 2015 (UTC)[reply]
- Please note the discussion of this point in the RfC. All the data that can be reliably ported to Wikidata automatically has been ported. Anyone wishing to port any remaining data manually may work from articles as they were at the time of Persondata's deprecation. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:29, 8 September 2015 (UTC)[reply]
Support. While I respect and endorse the BOTREQ groups desire for caution, that discussion already happened. Reso lute 13:38, 8 September 2015 (UTC)[reply]
Support - I and a few other editors have been manually removing them ourselves but it would honestly be a lot easier if a bot could do it for us considering there's over 4 million articles on here, I understand the need for caution but IMHO something needs to be done as it'll take forever to remove them all manually here. –Davey2010^Talk 17:00, 8 September 2015 (UTC)[reply]
Oppose using a bot or any automation to remove any persondata until such time that it can be demonstrated that it has been fully migrated to Wikidata, or that it persists in some other machine readable field in each article, for example in infoboxes. Dirtlawyer1 raises some very valid concerns and Andy Mabbett's responses don't exactly fill me with confidence that a bot will handle this properly. Removing persondata is not an emergency, and more harm could come from rushing this through with automation.~~that has not been migrated to Wikidata. Support removing persondata that has been migrated to Wikidata.~~ - Mr X 18:46, 8 September 2015 (UTC), 23:49, 9 September 2015 (UTC)[reply]
Support – it's definitely time to do this now. --IJBall (contribs • talk) 20:28, 8 September 2015 (UTC)[reply]
Support - given that the purpose of Persondata was for automated cataloguing, and an automated tool has already pulled any information useful for that purpose (the rest is unreliable, and Wikidata doesn't want it) then the time is right to programmatically remove all instances of the template. As Andy said, users wishing to port additional information can work from the page history. Ivanvector 🍁 (talk) 21:38, 8 September 2015 (UTC)[reply]
Comment - As a Wikidata editor, on the random of BLPs (and some dead people) on my watchlist that I've edited and noticed the persondata, I've found that not always is the data on Wikidata. This usually pertains to the alternate names, for which Wikidata has not pulled in as either aliases or as statements. A handful of times it has been differing birthdates. To suggest that everything has been moved over when not even aliases have captured the notion of alternative names is odd. --Izno (talk) 21:55, 8 September 2015 (UTC)[reply]
- Once again: Please note the discussion of this point in the RfC. All the data that can be reliably ported to Wikidata automatically has been ported. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:20, 9 September 2015 (UTC)[reply]
  - Your snark ("once again") is unnecessary and unappreciated. The point I am making is that there are data which have not been provided to Wikidata; that such data cannot be automatically provided to Wikidata reliably (we agree!); and that mass-removal by bot is thus inappropriate. Except I nowhere opposed or supported. Would you like me to do so now on ad hominem grounds or the actual logical ones of my comment?
    A more sensible approach as provided at WP:Bot requests is to remove the ones by bot which can trivially be shown to have had all their information migrated. In fact, none of the very reasonable suggestions for a bot were presented in this RFC, which I find somewhat specious, since that discussion has gone unlinked in the opening statement of the RFC. Obnoxious. --Izno (talk) 15:49, 9 September 2015 (UTC)[reply]
    - There was no snark in my comment; unlike yours. You'll note I referred to "my request for a bot to do so...". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:12, 9 September 2015 (UTC)[reply]
  - Misleading statements alert - Andy, that just ain't so, fella. Please see my extended comments below: virtually no alternate form names have been transferred -- birth names, maiden names, married names, etc. -- and that represents a significant loss of USABLE information. Sorry, but you're wrong. Dirtlawyer1 (talk) 17:27, 9 September 2015 (UTC)[reply]
    - Anyone is welcome to do as I suggest, and read the discussion of this point in the RfC (and for that matter the discussion on Wikidata to which that links). They'll soon see that the misleading statements are not mine. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:12, 9 September 2015 (UTC)[reply]
Support - having a bot remove deprecated persondata and complete the task. As stated above "Wikidata does not want further automated import of Persondata" so no need to match or compare persondata to wikidata prior to removal. The sooner the removal of persondata, the better - especially since consensus was to remove persondata three months ago. Thank you Andy for following up on this. Gmcbjames (talk) 23:45, 8 September 2015 (UTC)[reply]
- Taking into consideration further discussion, my opinion has not changed. When Persondata is bot removed, information will not be lost - the information is in the article either in the text body or infobox (if used). This information has been visible for anyone to correct misinformation, unlike the invisible and unreliable Persondata. I would suggest editors porting Persondata into Wikidata to carefully double-check the persondata with the article for accuracy. The best solution is to remove Persondata completely at this point of time, as I doubt editors will take the extra time and effort to double-check information prior to porting persondata into Wikidata. As time progresses, the information in Persondata only becomes more stale, so delaying will only compound the problems. Gmcbjames (talk) 05:54, 10 September 2015 (UTC)[reply]
Support Helder 00:23, 9 September 2015 (UTC)[reply]
Support – RGloucester — ☎ 01:24, 9 September 2015 (UTC)[reply]
Support for all the obvious reasons. ~ Rob^Talk 01:38, 9 September 2015 (UTC) Oppose. It appears some editors do think valuable information remains and are working to manually transfer it. I would likely support more limited attempts to remove those which are not useful (i.e. blank persondata transclusions or those with only name filled in), but if there is actual data remaining, keeping a comment in the text hurts little to nothing. As we verify that everything has transferred, these templates can be gradually removed. ~ Rob^Talk 21:07, 9 September 2015 (UTC)[reply]
Support the bot program, and the sooner implemented the better. Four million articles await, and even with the bot it'll take some time to accomplish. Can we publish this deprecation better so editors don't keep wasting time on updating/maintaining these templates? GenQuest ^{"Talk to Me"} 04:00, 9 September 2015 (UTC)[reply]
- Neutral Changed per the below information. Was the deprecation RfC regarding Persondata and its resultant "Consensus is to deprecate and remove" widely published? If so, the results (if you can call them that), have been poorly implemented. If not, then it seems that someone, somewhere has jumped the gun and the deprecation decision needs to be reversed and a newer discussion held in the broader community. As to @Dirtlawyer1: stating that people wasting time on updating the existing templates is "a red herring", I can assure you that I, who really, really have limited time these days to edit, have indeed been wasting my time on updating/fixing/editing them.
  This is turning into more bureaucratic horse pucky, and there Ain't nobody got time for that... GenQuest ^{"Talk to Me"} 22:05, 9 September 2015 (UTC)[reply]
  - @GenQuest: Yes, the decision to deprecate has been widely publicised. removing the template, completely, by bot, ASAP, would prevent other editors from having their time wasted, as yours has unfortunately been, because it was not removed already. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:16, 9 September 2015 (UTC)[reply]
Oppose This discussion is missing an important point. How do you get persondata information into wikidata in the future, if this established workflow of persondata at wikipedia is deleted? The situation is: enwiki persondata was imported in the last months to wikidata, ok. Comparing persondata form enwiki to wikidata has shown very similar quality, no surprise. Now tell me: How many new biographic articles were created at enwiki in the last 2 months? (How do you even find them without persondata?) Does wikidata contain the same data as enwiki-persondata about these new articles? How was this data entered into wikidata, by a wikidata-bot using enwiki-persondata? By a wikidata-bot using dbpedia-data that is harvested from enwiki-persondata? By a wikidata-bot harvesting enwiki-person-infoboxes, if and only if they are available? Or has wikidata no data about those new person-articles, because this dataflow to wikidata is now broken, because enwiki deprecates persondata? Show me the data! How is this going to work in the future? Who is supposed to enter new persondata in wikidata, some magic wikidata-workforce that doesn't exist? Magic bots? Show me the workflow! --Atlasowa (talk) 09:48, 9 September 2015 (UTC)[reply]
- There is no workflow necessary. Once persondata is removed from articles, it will be deleted and the template will no longer exist. From there, if editors care to edit such data, they can put it directly into WikiData. In the meantime, all we're doing by waiting is allowing more editors to waste their time adding information that is no longer being used. ~ Rob^Talk 11:29, 9 September 2015 (UTC)[reply]
  - @BU Rob13: That's simply not true, Rob. Many editors, myself included, are manually transferring remaining usable persondata -- including multiple name variants -- to Wikidata. I have not seen more than 2 or 3 instances of editors updating Persondata in the last three months, and I have over 6,000 articles on my various watchlists. No one is wasting significant efforts updating Persondata, and we could significantly improve Wikidata if we had widespread notice and explanation of what usable Persondata remains. Instead, we seem to have a "not invented here" mentality driving the desire for the immediate deletion of Persondata. There is ZERO reason to immediately delete all Persondata, and there is no harm in keeping ti for a while longer. Dirtlawyer1 (talk) 17:22, 9 September 2015 (UTC)[reply]
    - As noted above "Anyone wishing to port any remaining data manually may work from articles as they were at the time of Persondata's deprecation". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:15, 9 September 2015 (UTC)[reply]
- You appear to be opposing the deprecation of Persondata. That has already been decided and enacted. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:28, 9 September 2015 (UTC)[reply]
Strongly Support Given that wikidata has decided to no longer have data pulled over from persondata and therefore any information entered in it from this point on is about as useful as scribbling it on your wall, it should be removed. Jerod Lycett (talk) 11:24, 9 September 2015 (UTC)[reply]
The Persondata data could be archived on Tools or something. We don't need to keep it lying around in articles; as the bot is removing Persondata, it could be storing it at an off-site location, for interested parties to review at a later time. This would be similar to what's been done with {{Authority control}} (see T.seppelt's Authority control validator). Alakzi (talk) 12:44, 9 September 2015 (UTC)[reply]
Pinging users of the discussion from the bot requests page (whom have not yet commented somewhere above): @Magioladitis, Gerda Arendt, RexxS, Dirtlawyer1, Hawkeye7, SLBedit, Francis Schonken, and Andy Dingley: @Jared Preston, GoingBatty, Jc3s5h, MSGJ, and C678: (Cyberpower as closing bot op). --Izno (talk) 16:06, 9 September 2015 (UTC)[reply]
- I've been closely monitoring this discussion since it made its appearance here. It's good to see that this discussion is more focused. At current it's looking like immediate removal is the preferred outcome at the moment, but this clearly needs to stay open longer.—^cyberpower_Chat:Online 20:10, 9 September 2015 (UTC)[reply]
- And @Periglio:, too. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:09, 9 September 2015 (UTC)[reply]
Support, --Gerda Arendt (talk) 16:36, 9 September 2015 (UTC)[reply]
Support The sooner we get rid of this practically unused misfeature the better. Many of the oppose votes are bringing up the same tired objections that have already been discussed. Jason Quinn (talk) 11:32, 11 September 2015 (UTC)[reply]
Strongly OPPOSE at this time - A lot of misleading comments have been made regarding the status of the migration of Persondata to Wikidata. I know this first hand because I have manually transferred the Persondata from over 1,000 articles to Wikidata in the last 90 days, and I have had ample opportunity to review a sizable sample of Persondata that I entered into the templates myself. In many instances, the following information has not been transferred:

Alternate names - many, if not most alternate names have not been transferred from Personata to Wikidata by bot action; birth names, maiden names, married names, etc., probably represent the largest potential loss of valid, usable information from Persondata; and
Brief descriptions - in many instances, the brief descriptions have not been transferred by bot action; and
Updated information - as best I can tell, no new or updated descriptions -- or new or updated Persondata information generally -- have been transferred since at least November 2014; this includes new or updated names, descriptions, birth dates, birth places, death dates, death places.

The claim that there is no remaining usable Persondata to be transferred vastly understates the usable information remaining to be transferred. Persondata has been deprecated because a better long-term solution for biographical meta data -- i.e., Wikidata -- has been created. That does not excuse throwing away reliable information from Persondata, information that has not been transferred to Wikidata, without making a better effort to transfer what reliable and usable information remains. That's not undermining Wikidata, that's supporting and improving Wikidata. I am pinging "support" voters above (i.e., @Allen3, MrX, Resolute, IJBall, Gmcbjames, He7d3r, and RGloucester:@Davey2010, BU Rob13, GenQuest, Jerodlycett, and Gerda Arendt:) to reconsider their support for the immediate automate removal of remaining Persondata. Few editors have committed more personal editing time to manually transferring remaining usable Persondata to Wikidata than I have (see [4] for my Wikidata contributions), and few editors have better first-hand knowledge of what remains than I do. Simply deleting all remaining Persondata represents an amazingly foolish waste of past efforts, and the loss of an opportunity to improve Wikidata, educate editors about Wikidata, and recruit more editors to improving Wikidata. What is needed is project-wide notice and explanation to all editors and a concerted, a coordinated effort to transfer what remaining Persondata is usable, and a hard deadline for completion. There is nothing to be gained -- nothing at all -- by the immediate automated deletion of remaining Persondata, and much that may be lost. Dirtlawyer1 (talk) 17:16, 9 September 2015 (UTC)[reply]

Have you read my comment above? Would you support with the caveat that a copy of all data is made available elsewhere? Alakzi (talk) 17:26, 9 September 2015 (UTC)[reply]

@Alakzi: Yes, I did read your suggestion, A. It's a political solution that, as a practical matter, will simply lead to the removal of existing Persondata with virtually no transfer of remaining usable information. Once the Persondata templates are removed from our articles, it's gone. The solution is notify everyone about the status of Persondata, educate our editors about Wikidata and manual transfer of usable Persondata to Wikidata, create a simple set of instructions, and then set a hard deadline. In the mean time, remaining Persondata does ZERO harm, and immediately removing it by bot action represents the loss of usable information -- alternate name forms, in particular -- in many instances. Dirtlawyer1 (talk) 17:34, 9 September 2015 (UTC)[reply]

As far as I understand it, the concern is that, so long as {{Persondata}} remains in widespread use, people will blindly copy it over to new articles, or waste their time updating it, etc. The solution is notify everyone ... Instead, we could notify everyone that the data can now be found over yonder at that "toollab", and that they can transfer it to Wikidata at a leisurely pace, without having to mind any deadlines. Alakzi (talk) 18:01, 9 September 2015 (UTC)[reply]

Alakzi, I do new page patrol for articles within my subject areas, and I am seeing virtually no new persondata templates being added to new articles. The concern for lost efforts of editors is a huge red herring; where is the concern for the lost efforts of editors who added valid and usable Persondata that has not been transferred to Wikidata? There is no urgent reason to delete all remaining Persondata, and, and based on my first hand review of a relatively large sample, there is much that will be lost. If we simply transfer Persondata to a holding tank, it's as good as deleted, because once it's out of sight, it's out of mind. We both know this. Dirtlawyer1 (talk) 19:14, 9 September 2015 (UTC)[reply]

I'm no expert, being an engineer (and previously a software engineer) but is it really beyond the realms of possibility that a bot can sift through article histories and find the last one with the Persondata template and transfer that good stuff to Wikidata? The Rambling Man (talk) 19:49, 9 September 2015 (UTC)[reply]

@The Rambling Man: Andy maintains there is no way to engineer the further automated transfers of usable information from Persondata to Wikidata (please see above). If I understand him correctly, in fact, he maintains there is no usable Persondata left to transfer. I can tell you, based on over 1,000 manual transfers that proposition is incorrect. Dirtlawyer1 (talk) 20:31, 9 September 2015 (UTC)[reply]

Of course it's possible to do what I suggested. It's trivial. If WMF want me to help out with that, just send me an email. The Rambling Man (talk) 20:34, 9 September 2015 (UTC)[reply]

@The Rambling Man: I have little doubt that depends on the skill of the personnel involved. FYI, if WMF has been involved directly in the previous bot transfers of information from Persondata to Wikidata, it's not been mentioned in the previous discussions. This looks like a volunteer effort, not professionally managed. Dirtlawyer1 (talk) 20:57, 9 September 2015 (UTC)[reply]

(edit conflict) @Dirtlawyer1: It was my understanding that all automated transfer of persondata is complete. What do you believe needs a manual transfer, and why couldn't that be handled by an automatic transfer? I'm willing to reconsider if given a good reason to do so. ~ Rob^Talk 19:52, 9 September 2015 (UTC)[reply]

Rob, I see two primary areas of concern: (1) First, most alternate names -- birth names, maiden names, married names, nicknames, etc. -- were never transferred, perhaps because no one wanted to deal with the comma-delimited last-name-first format of the Persondata template. Frankly, from what I've seen, I would not be surprised if no serious automated effort was ever made to transfer alternate names from Persondata to Wikidata. (2) Second, based on my own own observations, I don't think any of the automated bot transfers ever updated any Wikidata fields once they had information present within those fields, and there was no effort made to reconcile conflicting information. Apart from those issues, I have also not observed any attempt to auto-transfer updated Persondata for the past ten months. And then there is the "error factor": dates and places of birth and death which were simply never transferred for some unidentified reason. The automated transfers appear to have been very "down and dirty" -- transfer as much as possible as quickly as possible, and ignore errors, conflicts and omissions. If we care about Wikidata and believe in its importance, we should be systematically reviewing it and comparing to remaining Persondata before it's deleted. In the mean time, it's not harming anything, and we should be encouraging people to review it and start utilizing Wikidata. If we don't, it's a lost opportunity on two levels. Dirtlawyer1 (talk) 20:31, 9 September 2015 (UTC)[reply]

You support removing Persondata from any article that has had all appropriate information transferred already, correct? ~ Rob^Talk 20:33, 9 September 2015 (UTC)[reply]

@BU Rob13: In theory, yes, I do, Rob. The question is how is that determined, and who will make that determination? Andy maintains that "all appropriate information" has already been transferred; frankly, that's simply not accurate. I have three months of first-hand experience in manually transferring usable information from Persondata to Wikidata, and I know that proposition is factually incorrect. Furthermore, I seriously question whether further automated transfers of remaining Persondata -- alternate names, in particular -- are technically infeasible. See The Rambling Man's comments above. Dirtlawyer1 (talk) 21:04, 9 September 2015 (UTC)[reply]

You're misquoting me. Please desist. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:19, 9 September 2015 (UTC)[reply]

No such claim was made. Please stop tilting at windmills. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:15, 9 September 2015 (UTC)[reply]

"All the data that can be reliably ported to Wikidata automatically has been ported." Pigsonthewing @16:33, 8 September 2015. You have now been quoted verbatim. And I hotly dispute the accuracy of your quoted statement: apparently no real attempt has ever been made to "port" alternate names. And your quoted statement raises more questions than it answers; it reads like a lawyer's non-answer. Dirtlawyer1 (talk) 21:52, 9 September 2015 (UTC)[reply]

Your claim about alternate names is bogus; they were discussed both on Wikidata and in the RfC which found consensus to deprecate and remove persondata. If you dispute the accuracy of my statement, it is open to you to attempt to disprove it, by showing a method, acceptable to the Wikidata community, by which further data from persondata templates can be transferred, with confidence as to its accuracy, to Wikidata. Please do so, or admit that you cannot. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:04, 9 September 2015 (UTC)[reply]

I think that you two are focused on different aspects. Andy is talking about "all the data that can reliably be ported automatically"; Dirtlawyer cares about "all the data", full stop. I tend to agree with Dirtlawyer's suspicion that blanking the remaining data will, for all practical purposes, mean losing the remaining data. However, could we not blank the pieces that we know have been ported reliably, and keep the rest—perhaps with an in-article note that says not to restore what's been ported? Then we could at least clean up some and see the scope of the remaining problem. WhatamIdoing (talk) 00:08, 10 September 2015 (UTC)[reply]

@WhatamIdoing: To be clear, WAID, 100% is an unattainable standard, and I understand that perfectly. My primary concern, as I and other have noted above, is that most alternate names have never been transferred, and Andy and others are apparently aware of this fact. I have manually transferred the Persondata from over 1,000 Wikipedia articles since June 2015; well over half required the transfer of alternate names -- i.e., birth names, maiden names, married names, nicknames, etc. -- that were not transferred by bot action. As a result, I quite reasonably question the accuracy of the statement "all the data that can reliably be ported automatically" has been; in fact, I would say that it's pretty serious misrepresentation of reality. If that is the best "that can reliably be ported automatically, then we need to find better solutions. Please note I support GoingBatty's modified RFBA proposal to remove Persondata templates that are empty except for the primary name field. No one is questioning that Wikidata is the better long-term solution, or the deprecation of Persondata; I am seriously questioning whether we have made a best-efforts attempt to transfer all elements of usable Persondata, and alternate names in particular. My first-hand review suggests we have not, representations to the contrary notwithstanding. Dirtlawyer1 (talk) 01:51, 10 September 2015 (UTC)[reply]

Once again, you "question the accuracy of the statement 'all the data that can reliably be ported automatically' has been", with no evidence to support your claim; one again, I challenge you to show a method, acceptable to the Wikidata community, by which such data can be automatically transferred, with confidence as to its accuracy, to Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:47, 10 September 2015 (UTC)[reply]

Two sets of questions:

When do those arguing that data should be maintained, pending manual checking, expect to complete that task? On what calculations are those estimates based? Why can such manual checking not be done using old versions of articles?
How do those arguing for further automated transfer plan to carry out such transfer? And is this agreeable to the Wikidata community?

If sensible and workable answers are provided, I'll strike my request; if none are, the "oppose" !votes should be struck. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:25, 9 September 2015 (UTC)[reply]

If the answer to #1 were 2200, would it matter? Persondata templates do not change the rendering of an article whatsoever. They're not so costly to keep for now as to cause any real issues. A more workable proposal, and one I'm working on fine tuning, is to remove those instances of Persondata where we can reasonably assume everything has transferred to help those doing manual conversion focus on what actually needs doing. For instance, any transclusion of persondata that only has a name can obviously go, and I'm having some discussions on user talk pages about other combinations that could be removed with no data loss. That is a reasonable compromise route that you may wish to consider. ~ Rob^Talk 21:32, 9 September 2015 (UTC)[reply]

Yes, it would matter (and it would likely be an underestimate of the time required). We already have an RfC which found consensus to remove persondata. This is a discussion about using a bot to do so, not about re-running the original RfC. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:44, 9 September 2015 (UTC)[reply]

There was consensus to remove after the useful stuff was moved to WikiData, as far as I can see. A few editors close to the template who have been trying to carry out the consensus to transfer stuff over have stated this isn't complete, and I see no evidence that it is. All persondata should be removed eventually, yes. When depends on how long the transfer takes. ~ Rob^Talk 22:44, 9 September 2015 (UTC)[reply]

No. The closer stated Consensus is to deprecate and remove. No qualifiers; no waiting period. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:10, 9 September 2015 (UTC)[reply]

BRFA filed based on my prior suggestion, which is intended to be a compromise to respect both sides of this issue. GoingBatty (talk) 23:25, 9 September 2015 (UTC)[reply]
With respect, @Dirtlawyer1:, I will not change my vote. If nobody has found the need to save what data is not already at Wikidata in the last few months, I see no reason to expect it to happen in the next few months. The consensus of the May RFC should not be set aside because doing nothing is more convenient. The community already spoke, and I do not see value into essentially turning this into a rehash of that RFC. Resolute 23:29, 9 September 2015 (UTC)[reply]
- @Resolute: You know me from previous discussions where we have been on the same side of the fence, and occasionally on opposite sides, as reasonable, intelligent people sometimes are. One thing you should know about me by now: I don't bulls@#$. With regard to the original RfC: (1) it did not specify how Persondata was to be removed, and bot deletions require additional approvals; and (2) the original RfC -- how shall I put this delicately? -- misrepresented the status of some usable Persondata, alternate names, in particular: based on my personal review and manual transfer of Persondata from over 1,000 articles to Wikidata, very few birth names, maiden names, married names, etc., were transferred by bot action. You're welcome to review my contributions to Wikidata since May 2015: [5]. I would say that the misrepresentation(s) regarding the "porting" of all usable information should come pretty close to voiding what validity the underlying RfC had/has, but that still does not address the question of bot action required for immediate removal. Mindlessly deleting all Persondata -- including alternate names, most of which have not been transferred -- is just that: mindless. There are multiple solutions here, all of which would be better outcomes for Wikipedia and Wikidata, than the immediate deletion of all Persondata. Dirtlawyer1 (talk) 23:54, 9 September 2015 (UTC)[reply]
  - Your claim that "the original RfC... misrepresented the status of some usable Persondata" is fatuous, and made, as usual, without evidence. The removal of Persondata templates would not me "mindless"; it has been well-considered. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:44, 10 September 2015 (UTC)[reply]
  - Sorry Dirtlawyer. I wasn't intending to target a general response to you personally. Also in general, when push comes to shove, I put very little stock into the needs of machines. So while I respect the work you are doing to aid WikiData, I find it preferable to dump the entire mess entirely since I do not believe it adds much value to the project. Reso lute 15:05, 10 September 2015 (UTC)[reply]

Suggestion: Templates with no unique information are deleted. If there is potentially usable info then comment out the template. The comment may include a link for why it is commented out. That link would say the template is deprecated, include instructions for submitting any reliable useful info to wikidata, and say to delete the comment&template when done. Alsee (talk) 02:07, 10 September 2015 (UTC)[reply]
- @Alsee: This comment actually functions as something that's commented out. It doesn't change the rendering of the page whatsoever and exists only to store metadata that is easily readable by machines; something WikiData was designed to take over. That's why we're interested in conversion to there. ~ Rob^Talk 21:32, 10 September 2015 (UTC)[reply]
  - The factlets in persondata which have not already been transferred are not "easily readable by machines", that's why they were not transferred, and why consensus to deprecate and remove them was reached. Yet again I suggest reading the RfC discussion, and the Wikidata discussion to which it linked. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:10, 11 September 2015 (UTC)[reply]
Oppose As one who has worked with the migration of Persondata to Wikidata, I want to see Persondata disappear, the data within it is just not reliable. For birth/death dates and places, there are more reliable templates to use as a source.

Up until now, I have ignored the alternative name parameter as personally I found it too random to be of any use. However, @Dirtlawyer1: has convinced me that there is data that would be lost. My suggestion of a way forward would be be to remove persondata. If there is an alternative name, create a {{aka}} template. Make this visible at the top of the article and the community would correct the dodgy ones. Periglio (talk) 02:38, 10 September 2015 (UTC)[reply]

Suggestion: I was pinged, and now don't know where to add. I have personally replaced Persondata by infoboxes, much more useful because visible. {{Infobox person}} can hold alternate names easily. I imagine that a bot could check, when removing Persondata, if all information is already in an infobox, if not transfer it there, and if none exists, propose one on the talk page, again to keep the data somewhere visible. (It's not the first time I suggest this. I try to avoid mentioning infoboxes because some don't like them but can't stop thinking that they are useful.) --Gerda Arendt (talk) 08:59, 11 September 2015 (UTC)[reply]

Multiphase removal

As I botop, I have a suggestion. It's clear consensus supports removal, at some point, but nobody can seem to agree when that removal should happen. So let's take it at chunks at a time. Here are the phases:

Remove all blank templates...
Decide on parameters of the persondata template that can be ignored and make another passtrhu with the bot.
Repeat 2 until templates with useful information are left.
Decide on suitable replacements for the remaining parameters of remaining templates.
Implement suggestion with a bot
Make a final deletion passthru with the bot
Have champagne and beer to celebrate.

How does that sound?—^cyberpower_Chat:Offline 09:21, 11 September 2015 (UTC)[reply]

I should point out that number 1 is already being worked on.—^cyberpower_Chat:Offline 09:24, 11 September 2015 (UTC)[reply]

I've never seen a blank persondata template in an article; do you have examples? What do you mean by "suitable replacements for the remaining parameters"? And can you relate this proposal to the parallel discussion on Dirtlawyer1's talk page, where a different approach is being proposed? How do you propose to mitigate the apparent "error/conflict rate of 10+%" disclosed there? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:03, 11 September 2015 (UTC)[reply]

In which case, Andy, that step should be quick and painless.

Cyberpower, what do you think about changing the "final deletion passthru" to a "copy it to the talk page and remove from the article passthru"? That increases the odds that someone would look into it. WhatamIdoing (talk) 15:04, 11 September 2015 (UTC)[reply]

No objections

The BRFA is approved and there are edits that prove the template. Just go there. Each parameter it seems describes an attribute about the person that can be moved to a category, infobox, or whatever. That's what I mean. I'm not proposing anything, I'm suggestion a method of discussion that involves the creation of multiple proposals and them being acted on accordingly, where the final end result is the complete removal of persondata. I'm suggesting a method that might work.—^cyberpower_Chat:Online 21:11, 11 September 2015 (UTC)[reply]

You wrote above "I have a suggestion", so you definitely are proposing something. Much of the data is not fit for moving to a category or infobox, as discussed in the aforesaid RfC and on Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:54, 11 September 2015 (UTC)[reply]

Which step? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:54, 11 September 2015 (UTC)[reply]

The one in which the non-existent (according to you) templates are removed. If none exist, then performing that step should be quick, easy, and painless. WhatamIdoing (talk) 02:47, 12 September 2015 (UTC)[reply]

@C678: My proposal is to delete Persondata only if all of its values are found elsewhere in the article. For example:

Persondata |ALTERNATIVE NAMES= = Infobox |birth_name=
Persondata |ALTERNATIVE NAMES= = Infobox |other_names=
Persondata |NAME= = Persondata |ALTERNATIVE NAMES=
Persondata |SHORT DESCRIPTION= = Category
Persondata |DATE OF BIRTH= and/or |DATE OF DEATH= = birth date and/or death date from lead
Persondata |DATE OF BIRTH= = Infobox |birth_date=
Persondata |DATE OF BIRTH= = Category:#### births
Persondata |PLACE OF BIRTH= = Infobox |birth_place=
Persondata |PLACE OF BIRTH= = Category:People from xxx
Persondata |DATE OF DEATH= = Infobox |death_date=
Persondata |DATE OF BIRTH= = Category:#### deaths
Persondata |PLACE OF DEATH= = Infobox |death_place=

I created a custom module at User:BattyBot/Persondata and submitted a bot request for this, but the bot request was only approved to remove those templates that only have |NAME= populated. Any suggestions for careful removal of Persondata templates that doesn't prohibit the copying of data to Wikidata would be appreciated. Thanks! GoingBatty (talk) 04:28, 12 September 2015 (UTC)[reply]

Userpage drafts shown in search engines

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

While not necessary to mention because of the WP:SNOW outcome, there is consensus to add NOINDEX. Closing this to box it up. AlbinoFerret 14:54, 9 September 2015 (UTC)[reply]

Tracked in Phabricator
Task T104797

Hello,

I recently realised that if you try to Google for any topic, you also get userpage drafts in the search results. For example, see this wikipedia entry and the corresponding search query. In most userspace drafts, it is not obvious that the article is a draft under progress, causing readers to possibly get confused.

To deal with it, I can possibly see two ways out -

All userspace draftspages have NOINDEX added to them. If I remember correctly, all drafts currently in the Draftspace use something similar and this should solve the issue for us. If there is no such easy option to locate drafts in the Userspace, we could consider if putting NOINDEX on the entire userspace itself is feasible
Consider having a policy to move Userspace drafts, atleast for retired users to Drafts namespace.

What do others think?

Soni (talk) 09:36, 1 July 2015 (UTC)[reply]

The whole of userspace desperately needs to be NOINDEXed because it is very lightly patrolled. There's too much spam and other self-promotional crap around and not enough people deleting it -- not to mention copyright problems, attack, BLP and child protection issues. MER-C 13:01, 1 July 2015 (UTC)[reply]

I'd support a NOINDEX of the userspace. But perhaps there's a way to make them default to NOINDEX and allow that state to be overridden on individual pages? Praemonitus (talk) 21:24, 1 July 2015 (UTC)[reply]

I'd support a blanket NOINDEX of the userspace as well. I can't think of a good reason not to. --Ahecht (TALK
PAGE) 23:11, 1 July 2015 (UTC)[reply]

NOINDEX all of userspace. I already do that with all of my own for quasi-privacy reasons, anyway. (BTW you can NOINDEX JavaScript with // __NOINDEX__ and both JS and CSS with /* __NOINDEX__ */) --Unready (talk) 00:06, 2 July 2015 (UTC)[reply]

Support NOINDEX also. These pages are not really of interest to the average internet user and might confuse them. Happy Squirrel (talk) 01:37, 2 July 2015 (UTC)[reply]

Support a blanket NOINDEX of all userspace. Geogene (talk) 18:24, 2 July 2015 (UTC)[reply]
Yes, I agree. I have long NOINDEXed my user page and sandbox. We tell people WP is not a web host and then provide a web host. Thincat (talk) 18:35, 2 July 2015 (UTC)[reply]

Support. I can think of no legitimate reason why userspace content needs to show up on search engines - and many good reasons why it shouldn't. AndyTheGrump (talk) 18:49, 2 July 2015 (UTC)[reply]

Hrrm, I'm going to noindex my page right now! Very good idea. Eman235/talk 19:38, 2 July 2015 (UTC)[reply]
Support, makes sense to me. Surprising this hasn't been done already actually. Andrew Lenahan - Starblind 18:22, 3 July 2015 (UTC)[reply]
Strong Support of setting all userspace as noindex, I do not see nay reason that it is not already. All pages are still locatable through the internal search engine.- McMatter ^(talk)/_(contrib) 18:27, 3 July 2015 (UTC)[reply]
I think I always assumed it was, though I know I've seen userspace pages in searches. I can't think of any good reason not to NOINDEX. Sam Walton (talk) 19:37, 3 July 2015 (UTC)[reply]
See Wikipedia:Requests for comment/User page indexing for a prior RFC on this subject. Cenarium (talk) 22:11, 3 July 2015 (UTC)[reply]

I agree, all drafts and user subpages should be NOINDEXed. FWIW, I've put User:Nobleeagle/India as an emerging superpower up for deletion as a G13. Joseph2302 (talk) 23:14, 3 July 2015 (UTC)[reply]

Comment: {{Userspace draft}}, marks all such pages as noindex'ed. —TheDJ (talk • contribs) 23:25, 5 July 2015 (UTC)[reply]
In my opinion this is unnecessarily breaking search engines, mostly because according to the comments above, 1 we don't check userspace much, 2 we allow people to do everything they want with it. Seems to me like we have our problems mixed up... —TheDJ (talk • contribs) 23:25, 5 July 2015 (UTC)[reply]
Oppose I agree with TheDJ. I find external search better for most purposes. There is not a big enough problem here to break functionality over. --99of9 (talk) 04:26, 9 July 2015 (UTC)[reply]

Given how many editors seem to agree on having NOINDEX enabled by default on Userspace, I would be initiating an RFC on the same to discuss and reach a clear consensus to act. For the moment, I will be writing the RFC at User:Soni/sandbox5 but if anyone is ready to assist with writing down all the reasons for why we should/shouldnt NOINDEX the entire userspace, please ping me on my talk page.

Soni (talk) 06:42, 9 July 2015 (UTC)[reply]

I always though user pages were already No INDEX. Silly me. Let's get it done. Kudpung กุดผึ้ง (talk) 11:24, 15 July 2015 (UTC)[reply]

I've tracked this in phab already, however the foundation is looking into this. Mdann52 (talk) 16:27, 17 July 2015 (UTC)[reply]

Support enabling NOINDEX by default for all userspace pages. I just went through and slapped {{NOINDEX}} throughout my userspace as a temporary remedy. –Prototime (talk · contribs) 19:35, 17 July 2015 (UTC)[reply]
Support Marking content that isn't supposed to be searched to actually prevent it from being searched is not "breaking" search engines. --NeilN ^{talk to me} 06:52, 19 July 2015 (UTC)[reply]

Supoort NOINDEXing all of userspace, except main user page. Libelous drafts, copyvios, and other such stuff are too much of a risk. WP's own search crappiness is a matter for the devs to fix. I sympathize with the external search preferences, but legal matters trump convenience workarounds. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 16:38, 22 July 2015 (UTC)[reply]

Support The very strong consensus here should be sufficient to get it implemented. I'm not sure if it's feasible to exempt the main user page and noindex the subpages. If so, It would be better to even noindex the main user page than let the subpages be indexed. DGG ( talk ) 21:11, 23 July 2015 (UTC)[reply]
Support blanket NOINDEX of User: space, and all spaces which are not article space. I really thought this was already the case. We shouldn't have material that is not published to main space showing up in searches and attributed to Wikipedia. Ivanvector 🍁 (talk) 21:14, 23 July 2015 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal: SPA template should not be used for dynamic IPs

When an unregistered user's IP address is dynamic, each IP they edit from is used only for a few hours, so the list of contributions from any one of their IPs generally is confined to whatever article they were editing at the time. On that basis, one user has tagged each IP I've used in this discussion with the "single purpose account" template. (See also the discussion here.) The SPA tag is intended to indicate something about the nature of the user whose posts are being tagged, but the way it's used in this case it only indicates something about the user's internet connection. This use seems contrary to the tag's purpose, but according to the one admin I've discussed it with (user:Nyttend), using it this way technically is allowed. Would it be possible to change the instructions for this tag so that it only can be used for either registered editors, or unregistered editors whose IP address stays the same over a long period? 43.228.158.49 (talk) 15:45, 9 September 2015 (UTC)[reply]

RfC: Should we convert existing Google and Internet Archive links to HTTPS?

Moved from WP:VPT upon request.

Please consider joining the feedback request service.

An editor has requested comments from other editors for this discussion. This page has been added to the following lists:

When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.

As an extension of the discussion on WP:VPT, I decided to file this Request for Comments. The question is straightforward and has two parts:

“Should we convert existing Google and Internet Archive links to HTTPS, and is this protection of readers' privacy enough to merit a solitary edit?”

The reason for this action is Wikimedia's recent switch to HTTPS-by-default for all projects. If we are truly concerned with readers' privacy as they enter Wikipedia, we should be equally concerned with it as they follow an external link that serves as a reference to what they just read. The issue concerns all existing external links to Google services (Google Books, Google News, YouTube, etc.) and the Internet Archive domain (*.archive.org), and only those two, because Google Books, Google News and the Internet Archive's Wayback Machine are among the most linked-to references on Wikipedia, with literally millions of external links.

Frequently Asked Questions:

Won't this break existing links? What if the HTTPS versions is different from the HTTP version? As far as Google and the Internet Archive are concerned, HTTP and HTTPS versions are identical. In fact, both services have switched to HTTPS-by-default years ago, and only maintain HTTP support to not break existing inbound links.
This seems like a mere technicality. Why not just be bold and do it? I would like to and, in fact, I did just "do it" over the past months, until Wikibureaucracy stopped me. It was pointed out to me that the rules of AutoWikiBrowser do not allow "insignificant or inconsequential edits," so the question that needs to be addressed here also is whether securing readers' privacy is to be considered "significant" or not.
I don't like HTTPS. Why did Wikipedia switch to HTTPS-by-default in the first place? Please do not make this debate a proxy war for an already settled issue. If you have questions about the purpose of HTTPS, please have a look at this info website by the Federal CIO.

Please leave your comments and concerns below. --bender235 (talk) 14:10, 10 September 2015 (UTC)[reply]

Question: In a previous comment on the matter[6], you write that "protocol relative links make little sense". What about protocol relative links makes little sense?--Anders Feder (talk) 17:13, 9 September 2015 (UTC)[reply]

The MediaWiki software enables protocol-relative links, which basically means you shall leave Wikipedia on the same protocol (HTTP or HTTPS) that you have entered it. For two reasons, we should not consider this alternative here: (1) Wikipedia has switched to HTTPS-by-default, so everyone is entering on HTTPS anyways (unless you access a mirror website or offline copy of Wikipedia somewhere), and (2) both Google and Internet Archive have made public and clear declarations of HTTPS support and enforcement. For instance, read how IA encourages others to use HTTPS links. --bender235 (talk) 17:20, 9 September 2015 (UTC)[reply]

I'll let others judge whether you are right that "we should not consider this alternative here". But one can easily imagine situations where forcing absolute-HTTPS down people's throat could be a problem. For instance, in countries where the state has a special relationship with HTTPS.[7]--Anders Feder (talk) 17:30, 9 September 2015 (UTC)[reply]

As mentioned in the FAQ, the issue of whether we should bow down to authoritarian regimes' wish to spy on people was considered during Wikipedia's decision to move to HTTPS-by-default. So please do not reopen this debate here. --bender235 (talk) 18:16, 9 September 2015 (UTC)[reply]

This RfC does not concern whether Wikipedia itself should move to HTTPS-by-default, and any considerations made in that debate do not necessarily translate into different considerations in this debate about a different issue being fait accomplis.--Anders Feder (talk) 18:26, 9 September 2015 (UTC)[reply]

Use HTTPS wherever it's supported. The only reasons that ever existed to not use HTTPS were strain on servers and really obsolete clients not supporting it. HTTPS is now optimized enough it adds virtually no strain, and if anyone uses such an old client that they can't use SSL, they also can't read Wikipedia at all anymore, so switching our external links won't affect them anyway. Jackmcbarn (talk) 18:01, 9 September 2015 (UTC)[reply]

Thanks for your support, but let me ask you the follow-up question: does this protection of readers' privacy merit a stand-alone edit of changing HTTP links to HTTPS? --bender235 (talk) 18:27, 9 September 2015 (UTC)[reply]

The latter claim is false. See m:Offline Projects/About Offline.--Anders Feder (talk) 18:30, 9 September 2015 (UTC)[reply]

Well, offline is offline. If you read Wikipedia offline because you don't have internet access, you won't be able to follow any link, regardless of whether it is HTTP or HTTPS. --bender235 (talk) 18:56, 9 September 2015 (UTC)[reply]

No it isn't. There are many people who have intermittent or slow online access.[8] Not least in countries where access to Wikipedia is heavily regulated.--Anders Feder (talk) 19:15, 9 September 2015 (UTC)[reply]

Eh, and what does that matter for http vs https... nothing. HTTPs is actually faster in most usecases these days because then it can also be on HTTP2/SPDY. BTW that data you are linking to is almost 6 years old now. Remember how Europe is overflowing with refugees with smartphones? The first thing people do is buy a prepaid sim, because a phone is their best and most valuable tool. The world is change rapidly on this front, and that's the entire world, not just the western world. —TheDJ (talk • contribs) 19:51, 9 September 2015 (UTC)[reply]

Europe is generally considered to be part of the Western world. It is no surprise a phone is valuable tool there. As for "what it matters", as the example with Russia shows, HTTP vs HTTPS very obviously matters.--Anders Feder (talk) 20:08, 9 September 2015 (UTC)[reply]

@Anders Feder: It seems to me you didn't read the whole story of what you are referring to. Here's the key paragraph from the Russia-vs-Wikipedia+HTTPS story you link above: “This week's example of Wikipedia in Russia is one of the first few test cases of governments forced into an all-or-nothing blocking choice; fortunately, it provides at least anecdotal evidence that the theory works. After just a few hours of blocks, Russia reverted its policy, claiming the material had been taken down. (It hadn't, according to Wikipedia editors, though the title and URL of the page had been changed.)” Something similar had happened to the Internet Archive in June (read Ars Technica). In both of these cases, like in many others, it turns out that the HTTPS-by-default is actually a good thing, because it forces authoritarian governments into a all-or-nothing blocking choice, rather than just subtly blocking whatever they deem "anti-regime." So what you're claiming to be a bug is actually a feature of HTTPS. --bender235 (talk) 19:22, 10 September 2015 (UTC)[reply]

I did read it. The outcome in the case of Russia is hardly a feature, as you phrase it, of HTTPS, but rather of a complex web of specific political circumstances. Whether HTTPS will be a drawback or an advantage in any other given set of circumstances is anybody's guess. My claim was not that it always is a drawback, but rather that it is a factor in how accessible the URL is—one which should be taken into account in the considerations.--Anders Feder (talk) 19:36, 10 September 2015 (UTC)[reply]

I fail to see what the relevance of website blocking is in this situation. If a website is served only over https, any http links will be returned to the user with a 3xx HTTP status code and the browser will attempt to load https, which will be blocked. If that is correct (tell me if it is?), leaving external links as http provides no benefit to people in countries which may block Google or Internet Archive. BethNaught (talk) 19:43, 10 September 2015 (UTC)[reply]

Is it the case that Google and IA are served only over HTTPS? If that is the case, you are clearly right. But I don't know if it is.--Anders Feder (talk) 04:43, 11 September 2015 (UTC)[reply]

Support part 1, question part 2: It seems to me very clear that when websites provide https only, we should provide https links, as doing otherwise is pointless. Hence incidental conversion is definitely appropriate. As to whether solitary edits are appropriate, what risks do users face by visiting an http link which is redirected to https? If they face a privacy risk or outright attack vector a solitary edit would certainly be appropriate. BethNaught (talk) 20:28, 9 September 2015 (UTC)[reply]

Well, the latter depends on the circumstances. Like where they are, and who they are. But in general, no one should have to "depend on the benevolence of network operators." --bender235 (talk) 21:33, 9 September 2015 (UTC)[reply]

Not at VPT. RfCs like this should be at WP:VPR. --Redrose64 (talk) 20:34, 9 September 2015 (UTC)[reply]

Bender235: How about cut-pasting it there?--Anders Feder (talk) 05:37, 10 September 2015 (UTC)[reply]

@Redrose64 and Anders Feder:.

Done. --bender235 (talk) 12:39, 10 September 2015 (UTC)[reply]

I am more than willing to do it and, in fact, I was doing it for long using AutoWikiBrowser. But the AWB people asked me to stop until I established community consensus that those edits are useful. --bender235 (talk) 19:15, 10 September 2015 (UTC)[reply]

Support This is a great endeavour for Wikipedia. In related (but more complex to manage) rules, one day we are going to have some kind of upgrade to .onion to consider in a similar fashion. Wikipedia_talk:External_links#.onion_linking_proposed_standard Deku-shrub (talk) 17:28, 10 September 2015 (UTC)[reply]
Support in full. This should not raise WP:COSMETICBOT issues whatsoever. While the rendering of the pages aren't different, the security of them is, and that's a non-trivial edit. Have you considered submitting a BRFA after gaining consensus to breeze through these all at once in an automatic fashion? ~ Rob^Talk 18:05, 10 September 2015 (UTC)[reply]

@BU Rob13: I did, in fact, file a bot request some weeks ago. --bender235 (talk) 16:49, 11 September 2015 (UTC)[reply]

@Bender235: Did you post the doing tag next to your comment or was it someone else? If it was you, are you working on creating a bot, or are you still looking for someone else to hop in? ~ Rob^Talk 19:29, 11 September 2015 (UTC)[reply]

I added the tag with my initial comment. I am not a programmer, so this was a request for someone to program a bot that was "doing" what I described. --bender235 (talk) 20:55, 11 September 2015 (UTC)[reply]

max-width

My desktop machine has quite a large screen - 1920×1080px but I normally view Wikipedia in a window 960px wide. When I maximise the window the page expands to use the full width which gives text lines impossibly long to read comfortably. There are so many user preferences already, it would not hurt much to allow the user to request the clause max-width: …px; to be sent in the CSS for every page.

Even as I was drafting the above, I remembered that I can set this myself using my custom CSS file. But I leave it as a suggestion of benefit to people who don't speak CSS. — RHaworth (talk · contribs) 15:56, 10 September 2015 (UTC)[reply]

Perhaps this would be a worthwhile gadget? {{Nihiltres |talk |edits}} 17:20, 10 September 2015 (UTC)[reply]

This would be a worthwhile fix in core MediaWiki. Alakzi (talk) 17:24, 10 September 2015 (UTC)[reply]

Change default behaviour of refs on pages without a reflist

When a <ref> tag is placed on a page, the software puts the text inside the ref in a {{reflist}} section, or if there isn't one, it puts the text at the very bottom of the page. At least, this seems to be the behaviour. A problem I've often come across with this is that when refs are placed on non-article pages (mostly talk pages, but I've also seen it at Arbcom and ANI for example) they get detached from the discussion which they're relevant to, and end up stuck awkwardly in whichever discussion is at the bottom of the page. For an example see this revision of WP:RSN, where the two refs at the bottom of the page have nothing to do with the "gun show loophole" thread. It's especially awkward for responding to edit requests, since references are generally a requirement for [semi]protected edits yet few non-confirmed editors know about {{reflist-talk}}, so on long-protected pages there can often be a long list of irrelevant refs inserted below the newest request.

I wonder if it would be possible to change the default behaviour, so that if a page doesn't have a {{reflist}}, the refs float to the bottom of the section they're placed in (above the next lv2 header, for example) rather than floating to the bottom of the page. Thoughts? Ivanvector 🍁 (talk) 19:40, 10 September 2015 (UTC)[reply]

T70324 is open for anyone wanting to work on it (or to read the repeated requests for it in various WP discussion areas). DMacks (talk) 21:19, 10 September 2015 (UTC)[reply]

entity vs template

Minor point for anyone who is interested: The software puts the contents of the ref tags in a <references /> block, rather than in a template. {{reflist}}, with no parameters, does nothing more than display the simple <references /> block, with the additional computing expense of going to look up the template first. Unlike the case in, say, 2008, there are no longer any differences between what <references /> and what {{reflist}} shows on a page, except that the latter is a slower and more expensive method of getting the first to display. WhatamIdoing (talk) 20:46, 10 September 2015 (UTC)[reply]

@WhatamIdoing: then why are {{Reflist}} and <references /> both options on the insert tool below the edit box and above the edit summary window? If {{Reflist}} does nothing different than <references /> yet is more expensive in terms of server power, shouldn't its use be depreciated and it be removed from the tool? ~ ONUnicorn^{(Talk|Contribs)}problem solving 21:11, 10 September 2015 (UTC)[reply]

{{reflist}} has lots of other formatting features if various parameters are used. It's just if used literally as "{{reflist}}" does it give simply result in "<references />". See the template docs for the optional other tricks. DMacks (talk) 21:17, 10 September 2015 (UTC)[reply]

ONUnicorn, I think that part of the reason is that we still have a few old hands who believe that there is still a font-size difference. I believe we have an editor or two who has been systematically substituting the template (via AWB) on all articles, and that adds up over time. I just did a brief review (n=10): one unreferenced; one WP:General reference; two using the templates' features (columns); and six that use the template needlessly.

The (IMO) rational argument in favor of using it universally is that if it's used everywhere, then the fact that the template has other features might be more discoverable for some users. This is probably a minor advantage, because presumably if you wanted to use the advanced features, then you would just find a page that had exactly what you wanted and copy from there. The arguments against are that it's specific to en.wp, so you can't use that knowledge anywhere else (e.g., about 100 Wikipedias, but also in private wikis at work or on other sites), that it's slower/more expensive. I suspect that any given editor would say that both of these are also relatively minor issues. WhatamIdoing (talk) 21:35, 10 September 2015 (UTC)[reply]

The reason I use the template is because it's easier to change later. When you only have a handful of references it's fine to have a single column, as it grows though you'll want to add more to split it up. It's pure laziness, but it's easier to add |2 than it is to change the whole tag. Jerod Lycett (talk) 22:51, 10 September 2015 (UTC)[reply]

column-count is deprecated. Use {{Reflist|colwidth=30em}} instead. Alakzi (talk) 22:55, 10 September 2015 (UTC)[reply]

Enable VisualEditor for Modern and Cologne Blue

VisualEditor should be enabled for Modern and Cologne Blue. Then, Supports only Vector and Monobook skins – of the four skins available in user preferences, VisualEditor works only with the two newest, and most popular. can be removed from Wikipedia:VisualEditor#Limitations. GeoffreyT2000 (talk) 23:15, 11 September 2015 (UTC)[reply]

@GeoffreyT2000: Have you tested these skins and ensured that they work with VisualEditor? Are you committing to keep them fixed promptly and consistently? The reason they aren't enabled for use with VisualEditor is because they're not supported except by the occasional volunteer, but instead of removing them from the cluster they for now still available on the basis that they will be fixed by them. Adding more burdens to volunteers just to make VisualEditor look good seems uncool. :-( Jdforrester (WMF) (talk) 23:19, 11 September 2015 (UTC)[reply]

@@ Line 522: / Line 522: @@
 :::Which step? <span class="vcard"><span class="fn">[[User:Pigsonthewing|Andy Mabbett]]</span> (<span class="nickname">Pigsonthewing</span>); [[User talk:Pigsonthewing|Talk to Andy]]; [[Special:Contributions/Pigsonthewing|Andy's edits]]</span> 21:54, 11 September 2015 (UTC)
 ::::The one in which the non-existent (according to you) templates are removed.  If none exist, then performing that step should be quick, easy, and painless.  [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 02:47, 12 September 2015 (UTC)
+:{{ping|C678}} My proposal is to delete Persondata only if all of its values are found elsewhere in the article.  For example:
+:* Persondata {{para|ALTERNATIVE NAMES}} = Infobox {{para|birth_name}}
+:* Persondata {{para|ALTERNATIVE NAMES}} = Infobox {{para|other_names}}
+:* Persondata {{para|NAME}} = Persondata {{para|ALTERNATIVE NAMES}}
+:* Persondata {{para|SHORT DESCRIPTION}} = Category
+:* Persondata {{para|DATE OF BIRTH}} and/or {{para|DATE OF DEATH}} = birth date and/or death date from lead
+:* Persondata {{para|DATE OF BIRTH}} = Infobox {{para|birth_date}}
+:* Persondata {{para|DATE OF BIRTH}} = Category:#### births
+:* Persondata {{para|PLACE OF BIRTH}} = Infobox {{para|birth_place}}
+:* Persondata {{para|PLACE OF BIRTH}} = Category:People from xxx
+:* Persondata {{para|DATE OF DEATH}} = Infobox {{para|death_date}}
+:* Persondata {{para|DATE OF BIRTH}} = Category:#### deaths
+:* Persondata {{para|PLACE OF DEATH}} = Infobox {{para|death_place}}
+:I created a custom module at [[User:BattyBot/Persondata]] and submitted a [[Wikipedia:Bots/Requests for approval/BattyBot 47|bot request]] for this, but the bot request was only approved to remove those templates that only have {{para|NAME}} populated.  Any suggestions for careful removal of Persondata templates that doesn't prohibit the copying of data to Wikidata would be appreciated.  Thanks!  [[User:GoingBatty|GoingBatty]] ([[User talk:GoingBatty|talk]]) 04:28, 12 September 2015 (UTC)
 == Userpage drafts shown in search engines ==