Jump to content

Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Mnewhous (talk | contribs) at 01:51, 24 September 2015 (→‎consistent style usage on referring to the Catholic Church: new section). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts

New ideas and proposals are discussed here. Before submitting:



Auto archive

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

Enabling VisualEditor for existing accounts which are dormant or inexperienced

Update: Thank you everybody for your feedback. Based on certain points made in the discussion by some community members, we have been re-considering whether some kind of easy opt-in prompt when people use the wikitext editor may be a preferable approach to rolling out wider access to the visual editor for existing editors.
For now, we will not go ahead with the changes we suggested in this proposal, and I'll come back with a different proposal when we are ready.
Yours, Jdforrester (WMF) (talk) 14:10, 21 September 2015 (UTC)[reply]
I'm adding the Archive templates for clarity. --Elitre (WMF) (talk) 19:18, 23 September 2015 (UTC)[reply]

The following discussion 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.

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(TALKCONT) 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
VE WT VE WT VE WT
IP editors 16% 3% N/A 6% 20% 2% Greatly better with the visual editor
1st edit 31% 18% 34% 18% 35% 18% Much better
2nd–5th edit 41% 28% 42% 35% 44% 32% A fair bit better
6th–100th edit 51% 45% 51% 51% 55% 49% A bit better
101st+ 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]
If I'm reading this right, that means that on Wednesday the normal editor was preferred over the Visual Editor by a 3.2 to 1 among new users, and a staggering 33 to 1 among old users ( with anons it's not really a fair comparison, but the number is a ghastly 112 to 1). With that degree of rejection do you seriously, genuinely, and with a straight face say that this is good software with a bright future? Heck, more people liked New Coke than this abysmal flop. Andrew Lenahan - Starblind 00:29, 13 September 2015 (UTC)[reply]
What the old dashboard shows is that VE usage is related to many factors, availability being a main one, and the reason for proposals like the current one (nothing like all existing registered editors have VE enabled; it's the same for new registered editors). This is perhaps clearer when looking at the data for wikis where anonymous editors get the VE tab. Basically, there slightly more people who use VE than those who use wikitext, with variance between different wikis based on lots of reasons (fr - he - ru - sv - it). We also know that VE is even more popular in some communities for which unfortunately we don’t have dashboards available (like the Catalan Wikipedia). Anyway, it only makes sense that there are more edits made with wikitext: the wikitext editor is plumbed into many more things, like the 'undo' button (so those are never VE edits); you can’t do literally everything with VE yet; and even edits started with VE but finished in wikitext mode count as “wikitext” ones. HTH! Elitre (WMF) (talk) 11:42, 17 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. –Davey2010Talk 01:15, 12 September 2015 (UTC)[reply]
  • Support - VE is working pretty well for basic gnoming, and newbies at editathons do much better with it. It was confusing at a recent event when one newbie had VE enabled, but one didn't. For experienced editors, I'm fine with leaving VE in the preference menu for now. VE has some glitches, there are some fancier things I can't get it to do, and once in a while, it's choked up on me, but overall VE is much, much faster than wikitext for basic copyediting and upgrading citations. Copyediting and citations are what new editors need to do, and unless the new people come in with a strong HTML background, VE is working for much better for them than wikicode at the events I've attended. I'm interested in getting the expertise of people who can't be bothered to learn Wikitext-- so I'd like to see VE enabled as a tab, as long as it is still possible to switch to the "edit source" tab. No need to further antagonize expert editors by enabling VE for them.
My overall impression is that there is a big group of nights-and-weekends coders here who feel their hobby coding project is the whole point of this encyclopedia, and that the content and experts contributing the content are an afterthought. It seems doubtful to me that a sustainable Media Wiki with fast response time, high reliability, chat / messaging capability, and full spectrum multimedia support is going to be built by a group of hobbyist coders making volunteer contributions in their spare time-- no matter how experienced, talented, or dedicated they are! Volunteer-driven, "whoever shows up" projects always have some rough edges, where no volunteers showed up, because that piece of the puzzle required way too much work that was no fun for volunteers. I am hopeful that Lila's initiatives to create a working software development organization of full-time professionals will continue to bear fruit, so that we can start to re-focus the organization on what's most important, which is the content and performance of the encyclopedia, and the health of the community which supports it. I wish the technical side of the organization all the best as they attempt to incorporate the input of a passionately opinionated volunteer developer community; and I urge the developer community not to view people unwilling to learn wikicode as unworthy of participation as Wikipedia editors.
For all the people who hate VE, let me give you a challenge: I get more edits done in less time with VE for routine quality control of fixing bare urls and adding cites. Hotshot coder folks, try your own A-B experiment: Pick any WikiProject cleanup list, and try fixing bare URLS and adding citations, with VE and without. Try out the "Automatic" URL feature for adding quick cites from major outlets like BBC and Googoe Books. Could you do this task just as fast both ways, VE and wikicode? Fixing citations and adding citations is not glamorous work, but it needs to be done, and if VE makes this important task quicker, is it really such an awful thing? Yes, it's a waste of skills to ask people with major coding talents to spend their time fixing bare URLs and adding citations, but if the coder folks never try it for themselves, they're unlikely to appreciate the difference VE makes, especially for less skilled typists who are in the 45 WPM range and make errors. --Djembayz (talk) 13:01, 23 September 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.

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

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. ϢereSpielChequers 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]
  • 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.—cyberpowerChat: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!. –Davey2010Talk 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. ϢereSpielChequers 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]
  • 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. ϢereSpielChequers 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. ϢereSpielChequers 11:00, 10 September 2015 (UTC)[reply]
@WereSpielChequers: I now see at least some rationale for opt-in for new users, I guess. I still can't see forcing 120,000 active users to adapt immediately or change prefs immediately; that is, unless we made it extra challenging for the developers and required some kind of pop-up "Do you want this or not?" the first time they edit a talk space after the change. The pop-up would then set the prefs according to the answer given. Without something like that, how are 119,800 of those users going to know about the change and how it affects them? I don't see anything about that in the proposal.
I'd support opt-in for everyone, but this proposal seems pretty much off the rails to me and a new one would be in order (maybe after another round at VPI). I know, it's incredibly messy and frustrating, I've been there. ―Mandruss ☎ 14:28, 12 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]
  • Support awesome idea Datbubblegumdoetalkcontribs 01:03, 15 September 2015 (UTC)[reply]
  • Support This is a good idea for signing talk pages. I recommend thgis be applied across all projects. There could be some editors who forget to sign their comments and other correspondence (I have sometimes as well), but a bot autosigns it. Still, it's an aye from me. Sam.gov (talk) 22:48, 16 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.

@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]
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]
A better looking list is at WP:Requested moves/Old AFC submissions. 103.6.159.77 (talk) 13:11, 20 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.—cyberpowerChat:Limited Access 15:02, 5 September 2015 (UTC)[reply]
 Done Mz7 (talk) 22:34, 5 September 2015 (UTC)[reply]
Moved from WP:VPT upon request.

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]

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.[4]--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]
IMO, yes. Jackmcbarn (talk) 19:45, 15 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.[5] 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]
I believe it is true for Google: searches and Gmail are https only and whenever I try to access Google over http it redirects me to https. BethNaught (talk) 14:00, 12 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]
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]
@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? ~ RobTalk 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]
  • Support in full. We should definitely convert existing Google and Internet Archive links to HTTPS, and this protection of readers' privacy and improvement of security definitely merits a solitary edit. As bender235 has said, no one should have to "depend on the benevolence of network operators", and history has repeatedly shown that network operators cannot be trusted. HTTPS is already enabled by default for everyone on Wikipedia, and it does not make sense to use HTTP links on an HTTPS page unless the target does not support HTTPS. In this case, both the Internet Archive and Google not only support HTTPS, but have also already enabled HTTPS by default. Right now, HTTP links are redirected to HTTPS by Internet Archive and Google from their servers, but the initial unprotected HTTP request presents users with the unnecessary risk that an ISP, government, or someone on the same network can see the links being clicked on and tamper with the subsequent redirection. By changing these links to use HTTPS, we are protecting the Wikipedia readers' privacy and security, without additional drawbacks as Wikipedia itself already uses HTTPS by default. Tony Tan · talk 16:59, 12 September 2015 (UTC)[reply]
  • Strongly Opposed. HTTP and HTTPS are different websites on different ports (80 and 443), changing them would be the equivalent of changing domains. Now due to way citations work, we need the original URL accessed on the cited date. The proposed change will break citation, the link history, and make it harder for tool authors such as myself to find the same URL on previous revision, on different pages, talk pages, and other languages. So unless you're going to check each citations again to update the access date, you are destroying citations.

    Sidenote: Anyone citing Google as a bearer of privacy is delusional. They were instrumental with the NSA in mass surveillance, have dossier on many/most business and individuals in the west, and have been found guilty by the courts for violating privacy. FYI, when you using a Google services, you aren't using the Internet anymore, instead your ISP dumps you into Google's private global network. If you were serious, you'd switch to youtube-nocookie.com, replace Google Books with Internet Archive equivalent (or Wikisource), and use the original AP news sources. — Dispenser 17:00, 15 September 2015 (UTC)[reply]

Most of what you wrote is opinion, but the part that is technical claims is simply wrong. Both Google and IA deliver exactly the same content over HTTP as they do over HTTPS. No citation will be broken. Ever.
As for your "sidenote:" I am not advertising Google as the bearer of privacy. And make no mistake, using HTTPS to connect to Google (or IA for that matter) will not protect you from all government surveillance. But HTTPS can be seen as "some" protection, rather than "none at all" in the HTTP case. In general, any measures of security in computer science should be evaluated against the adversary model. If your adversary is the NSA, then indeed an HTTPS connection to Google will not help you that much. But if your adversary is a rogue ISP, or a public hotspot, or even a foreign (non-US) government agency, then HTTPS will in fact protect not only your privacy, but also the integrity of the data being delivered to you. In essence, HTTPS is like a lock on your door. Will it keep out a government agency that comes with a warrant? Certainly not. But it might keep the ordinary burglars out. --bender235 (talk) 19:34, 15 September 2015 (UTC)[reply]
I've written a link checker and what I've written is not opinion. HTTPS is a different website, just like www1.example.com and www2.example.com are different website serving the same content. For citations, we need the original URL. — Dispenser 21:59, 15 September 2015 (UTC)[reply]
I don't see why this of any concern except for your corner case of a user-written script. Why should this dictate how we deal with this issue that concerns millions of readers and their privacy? I don't even see why this original URL mantra is so important. In the end, we cite a text, not a particular copy of it. That goes for books and websites. Because by your definition, even fixing http://links.jstor.org/sici?sici=0147-7307(198706)11%3A2%3C101%3ADTRDAT%3E2.0.CO%3B2-V to http://www.jstor.org/stable/1393579 would "break the reference," even though it only links to the same article, in the way the website intended. --bender235 (talk) 00:36, 16 September 2015 (UTC)[reply]
Most readers never check at references and the small number left who also care every website is HTTPS can simply install HTTPS Everywhere for this corner case of yours. And are you telling me you've been changing other links without re-verification and updating the accessdate?! — Dispenser 04:07, 16 September 2015 (UTC)[reply]
Oh, so readers never check references? I see...
As for changing URLs: yes, I been doing the fix described above quite frequently although, when a citation template was used, I would just replace |url=http://links.jstor.org/sici?sici=0147-7307(198706)11%3A2%3C101%3ADTRDAT%3E2.0.CO%3B2-V with |jstor=1393579 in that case. Similarly, I replaced links like |url=http://www.sciencedirect.com/science/article/pii/S0264999310000702 with |doi=10.1016/j.econmod.2010.04.008 all over Wikipedia. Do I "re-verify" the source? Well, obviously I had to follow the original link first to get to the JSTOR or DOI identifier. But did I re-read the source to see if it was the same word-for-word? Of course not. And why would anyone? It is exactly the same. (Also, did I update the accessdate? No, because journal articles do not need one. They do not change over time.) --bender235 (talk) 12:18, 16 September 2015 (UTC)[reply]
"HTTP and HTTPS are different websites on different ports (80 and 443), changing them would be the equivalent of changing domains." Not true. It's still served from the same servers ran by the same entity. "Now due to way citations work, we need the original URL accessed on the cited date.". No, you need a URL to the same article. "The proposed change will break citation, the link history, and make it harder for tool authors such as myself to find the same URL on previous revision, on different pages, talk pages, and other languages." How? (And your sidenote is totally irrelevant to the matter at hand. Even if Google is spying on us, using SSL to connect to Google means that nobody else can spy on us.) Jackmcbarn (talk) 19:44, 15 September 2015 (UTC)[reply]
First, same/similar content different server like a mirror. Second, it needs to be the one originally accessed with the timestamp (Got chewed out for a URL updater). Adding an archive_url would be acceptable. Third, it requires more patterns, more SELECT statements, and more processing. It introduces uncertainty into the backdating process. — Dispenser 21:59, 15 September 2015 (UTC)[reply]
It's not the same content on a different server. It's the SAME SERVER. Jackmcbarn (talk) 23:21, 15 September 2015 (UTC)[reply]
Might be the same server (usually not), but changing the Uniform Resource Locator means you need to re-verify that reference and update the accessdate. Simple really. — Dispenser 04:07, 16 September 2015 (UTC)[reply]
Dispenser, can you point me to an actual policy requiring that people fixing dead links re-verify that the contents of the article are supported by the citation. I know: once upon a time, for a situation significantly different from this, someone yelled at you. But I want a policy or guideline, not merely evidence that someone spouted a rule that I've never heard of, despite spending many years at WP:V, WP:RS, and WP:CITE. WhatamIdoing (talk) 20:28, 16 September 2015 (UTC)[reply]
  • Support building this into the standard 'upgrades' to Wikipedia pages that AWB performs, but make AWB not save the pages unless there are significant other changes to the page. It will then slowly migrate. This is at the moment (since both do support still http) a low priority task. Note that the system should check whether the 'old' and 'new' data linked to are really the same (they should be). --Dirk Beetstra T C 06:06, 16 September 2015 (UTC)[reply]
  • Support. The possible downsides seem rather theoretical. In contrast, not having https puts millions of readers at great personal risk. People can and do read Wikipedia from within more authoritarian regimes, where ISPs certainly do monitor individual browsing habits. We have a responsibility to minimize this risk, and changing outgoing links to https is an important ingredient. Sławomir
    Biały     10:24, 17 September 2015 (UTC)[reply]
  • Support. Bazj (talk) 15:40, 18 September 2015 (UTC)[reply]
  • Support. HTTPS means your ISP and your employer and anyone listening in can't (in general) tell what page you are accessing (they just know it is Google or IA). This is an important privacy feature which we should share with our users. filceolaire (talk) 22:58, 22 September 2015 (UTC)[reply]

We Have Created a Timeline for Every English language Wikipedia Article.

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

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

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

http://wikitimelines.net/

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

It is surprisingly simple to do now.

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

OR:

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

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

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

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

Thanks Jeff Roehl

Jroehl (talk) 21:54, 13 September 2015 (UTC)[reply]
Have you considered making this tool work using dumps of the Wikipedia database or other "local copy" of Wikipedia? davidwr/(talk)/(contribs) 23:16, 13 September 2015 (UTC)[reply]
To davidwr
I am not sure what you mean by: "dumps of the Wikipedia database"
Can you be more specific?
Thanks
Jeff Roehl
Jroehl (talk) 23:46, 13 September 2015 (UTC)[reply]
See Wikipedia:Database download. davidwr/(talk)/(contribs) 00:30, 14 September 2015 (UTC)[reply]

David = davidwr,

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

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

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

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


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

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

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

Just my professional assessment, your experience may be different.

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

David = davidwr,

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

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

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

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

I tried it on Timeline of women's basketball for which it would seem to be uniquely well-suited. It was a bust. Did I do something wrong?--S Philbrick(Talk) 19:20, 15 September 2015 (UTC)[reply]
No S Philbrick you did nothing wrong. As of this writing, for the sake of speed and narrative content, we are only placing data on the timeline that is part of a paragraph in any Wikipedia article. That is any content that inside paragraph tags. We will eventually have to write a separate parser for "Wikipedia timelines". One issue is there is no standard format for Wikipedia timeline lists, so it is a trick to parse them. We will be happy to do this, even to the point of writing a program to re-write all Wikipedia timelines into one standard format. Try https://en.wikipedia.org/wiki/Women%27s_basketball which has some paragraph tags with content.
Thanks
Jeff Roehl Jroehl (talk) 18:06, 18 September 2015 (UTC)[reply]
I also recall seeing this a few weeks ago despite the claim that it's new today. I didn't save the link to the discussion and can't seem to find it easily at the moment. Found it Wikipedia:Village_pump_(proposals)/Archive_126#I_would_like_to_put_a_timeline_on_a_wikipedia_page I know there was discussion about getting the Foundation involved so I'd like to hear what is happening on that front.--S Philbrick(Talk) 19:24, 15 September 2015 (UTC)[reply]

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

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

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

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

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

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

Solutions for Chinese versions & their heated warfare on Wikipedia

Problem & Reasons

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

Solution

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

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

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

Needs wider discussion. Can you demonstrate consensus for this task? Because this would affect several articles on a very likely contentious issue. Headbomb {talk / contribs / physics / books} 13:18, 14 September 2015 (UTC)[reply]
Thanks for the quick reply Headbomb. I have opened an RFC below. Hope you're well, —  Cliftonian (talk)  08:48, 15 September 2015 (UTC)[reply]

Request for comment

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

@Cliftonian: yes, I used the word Nation meaning an ethnicity, not a state. I think Arab and Jewish Israelis should be described in the same style, so it's not a separate discussion. Jewish Israelis are the majority, but they should not be considered the default case with Israeli citizens of other ethnicity being an exception. “WarKosign” 15:10, 15 September 2015 (UTC)[reply]
I looked at several articles on African-American actors, as another case of an ethnicity that is a large minority in its country. The articles that I checked describe them as Americans, without wikilink and without referring to their ethnicity in the article unless it's relevant in some section. The only reference to the ethnicity is by category. “WarKosign” 15:29, 15 September 2015 (UTC)[reply]

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

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

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

@Jethro B: apparently made most of the changes, he actually used AutoWikiBrowser. See https://en.wikipedia.org/w/index.php?title=Special:Contributions/Jethro_B&offset=20121031035859 Naraht (talk) 21:36, 15 September 2015 (UTC)[reply]
Thanks for this Naraht. —  Cliftonian (talk)  08:05, 16 September 2015 (UTC)[reply]
  • It's a minor point, but Israeli Jews are not a race. Hence it is not racism. The alleged behavior could perhaps be characterized as discrimination. Praemonitus (talk)

Allow any level of redirection in WhatLinksHere

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

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

Proposal to restrict page moves in the "Module:" namespace to administrators

Simply put, I propose that page moves of pages in the "Module:" namespace be restricted to administrators. In other words, I think that the entire namespace should be move-protected. There is one major reason why I think this is necessary, should have been done long ago, and why I don't believe that even template editors should be allowed to move the pages in that namespace. The reason is: when a page gets moved from a title in the "Module:" namespace, it never leaves a redirect. This situation is problematic since, for one, it is the equivalent of having access to the "delete" function while not being an administrator and, for two, if there are any pages that run the module by its previous name (such as pages in the "Template:" namespace), they all break after the move (and since there are no redirects in the "Module:" namespace, there is no way to avoid the pages that run the modules from temporarily going down after the page move.) Steel1943 (talk) 02:39, 18 September 2015 (UTC)[reply]

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

Undeleting old IP talk pages

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

Propose adding "Social media" or "Verified social media" parameter to relevant infobox templates

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

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

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

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

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

GregKaye 07:57, 20 September 2015 (UTC)[reply]

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

Ahmed Mohamed (student)

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

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

Change "px" to "upright="/"size percentage" for all infoboxes?

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

@George Ho: It's been agreed to scrap the "upright" option for images in the next few months/years, so I'd recommend against that. Jdforrester (WMF) (talk) 08:41, 23 September 2015 (UTC)[reply]
If they decided to scrap out "upright" option, how would this affect WP:IUP? Are we gonna use "px" again for all users? --George Ho (talk) 08:45, 23 September 2015 (UTC)[reply]
@George Ho: I believe the aspiration is also to deprecate pixel-specifying too, and instead move to semantic image types, but that's not agreed yet (and I'm not working on it myself, sorry). There are more details at the RfC to which I linked. Jdforrester (WMF) (talk) 08:46, 23 September 2015 (UTC)[reply]
I don't think scrapping out "px" works well. It would affect very tiny icons, like flags and checkmarks. Reading that link, I wonder whether they were discussing frameless images (with or without |frameless|). --George Ho (talk) 08:57, 23 September 2015 (UTC)[reply]
@George Ho: It's quite a wide-ranging proposal to totally change how media transclusions work, yeah. Needs some serious thought, as you say. Jdforrester (WMF) (talk) 17:33, 23 September 2015 (UTC)[reply]

consistent style usage on referring to the Catholic Church

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

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

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

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

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

Sincerely,

mnewhous

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=682489188"