Wikipedia:Village pump (all)

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search

This is the Village pump (all) page which lists all topics for easy viewing. Go to the village pump to view a list of the Village Pump divisions, or click the edit link above the section you'd like to comment in. To view a list of all recent revisions to this page, click the history link above and follow the on-screen directions.

Click here to purge the server cache of this page (to see recent changes on Village pump subpages)


Village pump sections

Edit-find-replace.svg
Policy
watch
To discuss existing and proposed policies

Preferences-system.svg
Technical
watch
To discuss technical issues. For wiki software bug reports, use Phabricator

Dialog-information on.svg
Proposals
watch
To discuss new proposals that are not policy-related. See also: perennial proposals.

Tools-hammer.svg
Idea lab
watch
To discuss ideas before proposing them to the community and attempt to find solutions to issues

Help-browser.svg
Miscellaneous
watch
To post messages that do not fit into any other category

View all village pump sections at once

Other help and discussion locations
I want... Where to go
...help using or editing Wikipedia Help desk
...to find my way around Wikipedia Department directory
...specific facts (e.g. Who was the first pope?) Reference desk
...constructive criticism from others for a specific article Peer review
...help resolving a specific article edit dispute Requests for comment
...to comment on a specific article Article's talk page
...to view other Wikimedia projects Wikimedia Meta-Wiki
...to learn about citing Wikipedia in a bibliography Citing Wikipedia
...to report sites that copy Wikipedia content Mirrors and forks
...to ask questions or make comments Questions


Contents

Discussions older than 7 days (date of last made comment) are moved to a sub page of each section (called (section name)/Archive).

Policy

Cutting down the excessive length and inconsistency of Wikipedia policy supplementary essays

Closing before this turns into drama. TonyBallioni (talk) 14:18, 16 May 2018 (UTC)
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.

What is being done to reduce Wikipedia's excessively long loose collection of "explanatory supplements" that are inconsistently applied in antagonizing and persecuting ways? Bright☀ 09:52, 13 May 2018 (UTC)

Happening now at WMF HQ
A crack team of WMF secret against are working on it right now. I believe the plan is to parachute into the servers at night and begin asassinating rogue explanatory supplyuments, which, as your question has conclusively proven, are a huge problem in need of immediate drastic measures. Beeblebrox (talk) 17:05, 13 May 2018 (UTC)
Bad tactics Beeblebrox, typical of WMF. They're sure to get tripped up by the flow of bits and bytes created by people trying to build an encyclopedia. John from Idegon (talk) 18:15, 13 May 2018 (UTC)
That's a good start on typing "agents", but the rest needs some work. Supplyuments is beyond help. ―Mandruss  10:41, 14 May 2018 (UTC)
Agree. We don't have to dot the i's and cross the t's. Bus stop (talk) 13:32, 14 May 2018 (UTC)
This dismissive attitude is toxic to the improvement of Wikipedia. Bright☀ 14:16, 16 May 2018 (UTC)

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.

Question

Why was the above section locked? Bright's question seemed sincere, but was followed by some flippant remarks, so then the whole thing was closed by TonyBallioni? Am I missing something here?Egaoblai (talk) 16:52, 16 May 2018 (UTC)

Because the only thing keeping it open would have led to was more hurt feelings and drama. TonyBallioni (talk) 16:57, 16 May 2018 (UTC)
I think the fundamental issue with the question as phrased was its vagueness. There may indeed be a problem about too much rules and instruction on Wikipedia, but it would be more helpful if a specific rule or instruction was identified so that we could discuss it more substantively, as opposed to remaining in generalities. Mz7 (talk) 02:00, 17 May 2018 (UTC)
Alright. How about removing all the supplements to Wikipedia:Disruptive editing or merging them into the guideline itself? There is not a single supplement that covers anything not already covered by the guideline itself. Wikipedia doesn't need many-thousand-word supplements when a few dozens say the same thing more accurately and less vaguely. Bright☀ 09:27, 31 May 2018 (UTC)
  • Proposition (a bit rambling, and a feeler, not a formal proposal to !vote on): If they're not actual guideline/policy material, redundant supplements can simply be retagged and recategorized with {{Essay}}. Supplements really are just essays, but ones that at one time (no longer) allegedly had some kind of formalized consensus buy-in as focused/detailed elaborations on more general guideline or policy material. It's been my experience that very few have actually been through any sort of proposal process to receive that label, and we don't bother with it any longer at all. The wording that used to be at {{Supplement}} indicating that the template was only for pages given this banner via affirmative consensus was removed in September 2017, yet no one has reverted or challenged this change (and the original name of the template was {{Supplemental essay}} anyway). All in all, it appears to me that someone decided a while back that "Supplements" were magically special in comparison to essays, no one paid any attention to that baseless nonsense, so it's been put back the way it was, and we're now here with a clear cleanup path of merging back to {{Essay}}.

    The most practical approach is probably have to have an RfC (here) to deprecate the {{Supplement}} tag and the pretty much imaginary classification it represents, then go TfM the template and CfM any associated category, for merger into the essay versions if the RfC concludes in favor of deprecation.

    The only consequence of this would be that a handful of supplements that the community genuinely might consider more than essays could maybe end up getting "promoted" to guidelines or merged substantively into the guideline/policy pages they supplement. But even this is unlikely: various essays that the community treats like guidelines and which are sometimes treated as rules still remain essays, e.g. WP:BRD and WP:AADD, and proposals to promote them (or "elevate" them or whatever loaded term you like) have failed.

    The {{Essay}} template already supports parameters of various sorts, and one could be added for categorizing essays by nature/role, including whether they're supplementary, if we decide that's a useful categorization at all. (But what's the difference, today, between {{Supplement|interprets=}} and {{Essay|interprets=}}? Both tell the reader that they're additional essay material about some other page). I'm definitely in favor of merging {{Supplement}} out of existence, regardless. If we did add some parameters, we could also merge away all of these: {{Information page}}, {{Wikipedia how-to}}, {{WikiProject style advice}}, {{Wikiproject notability essay}}, and {{WikiProject content advice}}. They're all essays, when it comes to "authority" level; the only difference is the intent of the content (to provide an opinion, a wikiproject's collective opinion, an FYI, an elaboration, or some technical instructions).

    This won't do anything about the original poster's "there are too many pages" complaint, but would address the central "there are too many rules and pages of rules" concern, since these pages really are not rules (even in the guideline sense), and some editors are just confused by the "Supplement" label into thinking they have the force of WP:P&G pages when they're just essays about rather particular best practices (and sometimes alleged best practices that haven't been vetted at all or in a decade+).
     — SMcCandlish ¢ 😼  05:20, 1 June 2018 (UTC)

  • Works for me. Hiding T 17:03, 4 June 2018 (UTC)
Don't add. Just merge {{supplement}} into {{essay}} and start cutting down on verbosity instead of adding to it. Bright☀ 11:00, 6 June 2018 (UTC)

RfC about user page guideline WP:POLEMIC

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

rfcid=C24187C

WP:POLEMIC currently states: ‘’Material that can be viewed as attacking other editors, including the recording of perceived flaws. The compilation of factual evidence (diffs) in user subpages, for purposes such as preparing for a dispute resolution process, is permitted provided it will be used in a timely manner.’’

Please select one of the following choices to keep, remove or modify the phrase “timely manner”:

  1. Keep as is
  2. Replace with: ‘’...is not permitted as it could be misused or misconstrued as a threat or WP:HOUND
  3. within 30 days
  4. within 45 days
  5. within 60 days

Thank you...Atsme📞📧 14:10, 18 May 2018 (UTC)

Survey

  • 2 - history indicates that such compilations have been used (perceived or otherwise) to threaten and/or hound editors who represent “the opposition” in controversial articles. Atsme📞📧 14:10, 18 May 2018 (UTC)
  • 3- although the use of user space to compile a dispute resolution case is legit, leaving it as "in a timely manner" is basically an invitation to let it languish forever. A strict time limit needs to apply. Reyk YO! 14:29, 18 May 2018 (UTC)
  • 3 - Pretty much agree with Reyk, though I would consider more of a 15 days since last substantial edit to the page, 30 days from initial creation. My reasoning is that I think 30 days is a little too long unless you are actively preparing some sort of dispute resolution case. --Kyohyi (talk) 14:38, 18 May 2018 (UTC)
  • 1 - It is better for that drama to just "sit" and die off somewhere in userspace. Do we really want an automatically started incident thread, 30 days after every such thing? wumbolo ^^^ 15:38, 18 May 2018 (UTC)
  • 1 or 60-90 days. These things can take time. Because the target is (in this case) attempting to sabotage the collection of evidence (just as Trump is attempting to dictate the terms of the Mueller investigation), the clock should be restarted and the diff collector given even more time. That should teach the target to not obstruct justice. See my comment below. -- BullRangifer (talk) PingMe 16:11, 18 May 2018 (UTC)
  • 1 "Timely" should not be a hard-and-fast rule. --SarekOfVulcan (talk) 16:14, 18 May 2018 (UTC)
  • 1. What is an appropriate time will vary based on the situation. Natureium (talk) 17:15, 18 May 2018 (UTC)
  • 3 Seems like the best fit, I like the spirit of timely but it is to open to gaming. Perhaps a provision for an extension after 30 days if a good explanation is provided, otherside it festers and creates problems. PackMecEng (talk) 17:40, 18 May 2018 (UTC)
  • 1.5 - I don't like arbitrary time limits, but I also don't see any reason for such material to stay visible outside of when the user is actively working on it. I would add a provision to the current version like A page containing such material should be blanked upon request when not actively in use.. While the user is working on it (in their current session), they can restore it from the edit history of the page, and while they are not working on it, its hidden from view to avoid the polemic nature. -- Netoholic @ 17:52, 18 May 2018 (UTC)
  • 0.5 - remove the "provided..." clause or keep as is. DexDor (talk) 18:53, 18 May 2018 (UTC)
  • 1 or 5+ these things take time. If a case is to go to ArbCom one needs to demonstrate both prior resolution attempts and a long term pattern. There can be months from the time a problem becomes apparent until it can be sufficiently documented for ArbCom to do something about it. Such pages should not be kept on prominent display, e.g. do not collect/post evidence on your user page, but having such a sub-page where others must go looking for it should be OK.
    Beyond that, if there is a long term issue one wishes to document it can take quite a bit of time to dig through various editor and page histories to find diffs and figure out how to properly present the information. Most editors will not want to drop everything simply to research and write up a case but instead will work on it as time permits. Thirty or even sixty days is not very long considering this is a volunteer project and that documenting misbehavior is not why people want to spend their time editing here. Jbh Talk 19:55, 18 May 2018 (UTC)
  • 0.5 per DexDor. Such a list can be a useful thing to have in your back pocket as a way to document and recognize problematic editing patterns, which may or may not lead to dispute resolution etc. It should be kept discreetly on a user subpage without prominent links or polemic commentary.
If such lists are being used problematically, then the problematic behavior should be addressed. In particular they should not be trotted out during talk page discussions unless a formal complaint or accusation is being made. –dlthewave 22:08, 18 May 2018 (UTC)
  • 1 I think such lists can be an element of hounding, but in of themselves they aren't hounding. For example, if you made a list like this and then went around posting links to it on article talk pages or other discussions with the target editor, then that'd be hounding. Not quite the same thing, but some editor took part of a discussion I had with him and featured it prominently on his user page (presumably to make some kind of point) but I only happened to see that by coincidence and we haven't otherwise interacted, so why should I care? Same with a list of diffs like this. If they're just keeping the list on their page, then what harm is it? Just don't go to their user page if you don't like it. Also, there's a very easy solution: if you don't want someone to make a list of diffs of you violating policy, then don't violate policy. Red Rock Canyon (talk) 04:34, 19 May 2018 (UTC)
  • 1 per WP:AINTBROKE and the note at the top of this page about not using this page to settle disputes about implementation of policy. POLEMIC is working just fine. As the discussion bellow is showing, the line between good-faith collection of evidence for dispute resolution versus malicious persecution is not a bright one, and is best decided on a case-by-case basis. Ivanvector (Talk/Edits) 10:53, 19 May 2018 (UTC)
  • 1 It's fine. Dispute resolution can be protracted and subject to changing deadlines/late closures/etc. No need to put a hard deadline on something. As Ivan said, if it ain't broke... ~ Amory (utc) 12:02, 19 May 2018 (UTC)
  • 2 there's no reason for this kind of stuff to be publicly accessible, keep it on your own computer until you're ready to stand behind it. CapitalSasha ~ talk 13:54, 19 May 2018 (UTC)
  • 1 defining hard limits is rarely useful. If it wasn't good on day 31, it also wasn't fine on day 29. 2 would be my second choice. --Jayron32 14:44, 19 May 2018 (UTC)
  • 1 (or 0.5) - There's no need for a strictly-defined time limit. Much wasted time could be avoided if some users would simply refrain from snooping though other user's subpages for whatever drama that they can stir up. We should also stop misusing the word "polemic", which has nothing to do with the compilation of factual evidence (diffs). - MrX 🖋 12:52, 20 May 2018 (UTC)
  • 0.5, remove time constraint completely. Why on earth is this not given as an option? Such apparent bias compromises the credibility of the RFC. The intro says: "Please select one of the following choices to keep, remove or modify the phrase “timely manner”", but there is in fact no remove option. Johnbod (talk) 15:32, 21 May 2018 (UTC)
  • 0.5, remove time constraint completely per Johnbod. I get regularly hounded by people harbouring grudges. Sometimes they turn up on my talk page to complain about something and I tolerate this indefinitely. Maybe they have a point or maybe they don't but it does little good to sweep it under the carpet because it's so easy to repeat or save the details elsewhere. Better to get it all out in the open to understand the grievances and clear the air. Andrew D. (talk) 22:04, 21 May 2018 (UTC)
  • 0.5 per the people above. It's rare I agree with Andrew but he's absolutely right here, sometimes there is a necessity to keep a long string of diffs in your own user area because otherwise it's difficult to prove a persistent problematic issue if it doesn't happen every day. Black Kite (talk) 22:17, 21 May 2018 (UTC)
  • 1 per Ivanvector's WP:AINTBROKE argument. I don't understand the problem that this is intended to fix! Compilation of such info could possibly be construed as Hounding - but I know of no instances where it has been so by the community - in isolation - without other more 'harassing' behaviour. Pincrete (talk) 19:06, 27 May 2018 (UTC)
  • 1 As long as this is in the person's own userspace (preferably with a neutral sub-page name, not the name of the target), and they are not calling attention to it elsewhere, this is a valid and sometimes unfortunately necessary thing to do. We have all seen reports at AN or ANI which were dismissed for lack of diffs, or lack of demonstrating a pattern of disruptive behavior, or whatever. To avoid that kind of result, it may be necessary to collect evidence over a period of time for an eventual complaint - or perhaps no complaint, if the behavior improves or the evidence gathered proves to be insufficient. When I do this kind of thing (and yes, I sometimes do), I do it off-wiki on my own computer, but that is my choice. (BTW I rarely have to use this data, because usually the target gets himself/herself blocked without any help from me.) --MelanieN (talk) 15:19, 31 May 2018 (UTC)
  • Observation: Option 2 doesn't make sense, and would result in a text string of "... is permitted provided it will be used in a is not permitted as it could be misused or misconstrued as a threat or WP:HOUND".  — SMcCandlish ¢ 😼  05:26, 1 June 2018 (UTC)
  • "5+" (e.g. 90 days). I'm vehemently opposed to option 1 and to the "0.5" proposal, having been the victim of someone keeping a "dirt list" on me for something like two years as blatant intimidation tactic, and WP:MFD actually failing to delete it because no one there was sure what "timely manner" meant. I actually stopped editing Wikipedia for several months (other than a few brief visits back in response to direct e-mails) as a result of that person's harassment. The idea of no time limit at all is nuckin' futs; if you want to keep running dirt lists on people for years on end, do it on your own hard drive. But no. 2 (after you parse what it's supposed to mean) is also irrational, since it would make it wiki-illegal to compile and draft any evidence submission on WP at all, even if you intended to use at a noticeboard only 5 minutes from now. Options 3 and 4 are too short, especially for drawn-out processes like WP:RFARB and WP:ARCA, which can take months sometimes. 5 is closer, but even 60 days can be too short.  — SMcCandlish ¢ 😼  05:38, 1 June 2018 (UTC)

Discussion

  • "Hounding" obviously can't apply. That applies to not only aggressively and pointedly following another editor around, but actually disruptively taunting them and/or disturbing edits they have made which were uncontroversial and proper. (Watching disruptive editors, socks, and vandals and fixing their errors is not hounding, even though it involves following them around. That is actually our duty as editors. We must protect the encyclopedia.) An editor's subpage which is not advertised and only known to a few is not a threat or hounding. -- BullRangifer (talk) PingMe 14:21, 18 May 2018 (UTC)
I disagree - I've known instances where one editor starts the diff page, then follows the target editor to collect "add-as-you-go" diffs each time they "believe" the target editor does something they don't like, especially if the diff collector is a seasoned editor who knows how to game the system. I've even seen diffs collected that were not representative of incivility at all - just content disputes, and even legitimate actions were added to the collection, knowing few admins have/take the time to read them all but it looks bad nonetheless - and that is HOUND. Atsme📞📧 15:34, 18 May 2018 (UTC)
Quietly collecting diffs is not hounding. Hounding involves public action negative to their target, which the target immediately knows about, as described above. And it doesn't include what the target "perceives" as simply negative, but what normal others would perceive as "unjustly" negative. The perceptions of paranoid people, or those with a guilty conscience, don't count. You're misusing the term.
It especially doesn't apply to the situation upon which this whole thread is about, a target going to the diff collector's private userpage and loudly and publicly complaining (Streisand effect!!), and then starting an MfD. That's like Trump complaining about the Mueller investigation, and then getting all his staff to complain as well. (He's supposed to ignore it and never talk about it.) That's what's happening. Trump (and the target here) should not talk to the diff collector about it or mention the investigation (or the diff page). Obstruction of justice is a crime (which can be committed by completely innocent people), and interfering with the collection of diffs for a possible noticeboard or AE case is a form of obstruction. It's wrong to do that. The target needs to stay away from the very topic, and the private userpage, since this was done very discreetly. It was the target who publicized it. They exercised bad faith by making it public.
Having some reasonable time limit is another matter. -- BullRangifer (talk) PingMe 16:05, 18 May 2018 (UTC)
  • There is a difference between privately collecting diffs for a complaint and keeping a bunch of diffs or quotes around to shame, harass or poison the well for others dealing with an editor. The later, which includes keeping unattributed quotes and/or quotes stripped of context on one's user page is much, much worse than collecting diffs on a page which no one who is not looking for it will see it. Jbh Talk 20:04, 18 May 2018 (UTC)
  • I tend to use this template for nearly everything in my userspace:
  • {{NOINDEX|visible = yes}}
I suggest it should be used for the type of page under discussion. -- BullRangifer (talk) PingMe 20:14, 18 May 2018 (UTC)
User pages and subpages already have <meta name="robots" content="noindex,follow"/> in their HTML heads.- MrX 🖋 13:02, 20 May 2018 (UTC)
  • @Atsme and Bullrangifer: I take it this is related to an ongoing dispute involving some sort of "target"? –dlthewave 22:09, 18 May 2018 (UTC)
It's a proposed change for a guideline based on a history of disputes for the same/similar issues and it has become clear that the guideline needs clarity. Read the options and cast your iVote - try to imagine yourself in the shoes of the page owner and the targeted editor, and make your decision. Atsme📞📧 22:28, 18 May 2018 (UTC)
That is nonsense. The issue concerns this MfD. Johnuniq (talk) 23:40, 18 May 2018 (UTC)
Are you considering it nonsense based on your personal experiences as a targeted editor, Johuniq? If the latter is the case, please substantiate your "nonsense" position by providing the diffs so others can weigh-in. It would be quite helpful. Atsme📞📧 03:02, 19 May 2018 (UTC)
That's just a CIVIL auto-response that evades the issue. Someone asked if the proposal here was related to a dispute, and I provided the link to show where the dispute can be seen. The close of the MfD specified a date beyond which the diff-collection will be regarded as polemic and deleted so, once again, Wikipedia's model of not trying to specify rules that precisely cover every situation is shown to be working. Johnuniq (talk) 04:12, 19 May 2018 (UTC)
Your preconceived notions are not helpful. My position is still NO, and your naming that MfD for WP:POINT was not only wrong, it was disruptive. Stop reflecting your POV onto me. This RfC is the product of other incidents I recalled with a measure of trepidation, dating back at least 3 years - an accumulation of incidents that have caused disruption. I’m of the mind that waiting and watching one’s opposition for the purpose of collecting diffs-on-the-fly is the same as HOUNDING, and an impediment to an editor’s ability to express free thought for fear it will be misconstrued or taken out of context and wrongfully used against them. It’s one thing to collect diffs that already exist in preparation of filing at AE or ANI which should not take more than 30 days...not to mention the fact that a simple text program off-WP will serve the same pupose without creating a hostile environment in an effort to rid oneself of the opposition. Atsme📞📧 13:37, 19 May 2018 (UTC)
Your opinion about what is and isn't hounding is far from being a reasonable interpretation of the policy. And frankly, someone who has a history of problematic behaviour refraining from said behaviour because they know it will be recorded is a good thing. There should be a hostile environment for them. Oh and lastly: you have no right to express free thought on Wikipedia. Only in death does duty end (talk) 13:49, 19 May 2018 (UTC)
RfCs don't usually come out of the blue, and anyone proposing a change to a guideline should present a compelling reason to do so. @Atsme: If you're aware of a history of issues related to this, or a particular discussion that your concerns arose from, it would be helpful to post links here. This is usually done as part of opening the RfC. –dlthewave 14:24, 19 May 2018 (UTC)
No one said this RfC came out of the blue, but I’m not going to mislead anyone by saying it was the result of one specific MfD. I already explained my reason...and quite frankly, I see some of these polemic pages as nothing more than “opposition research” but I’m just 1 iVote. The community will decide, and it doesn’t require me providing links to deleted pages or past MfDs that once caused some editors grief. I’m trying to avoid disruption and retain editors, which happens to be my main motivation for this RfC - eliminating the ambiguity by setting a time limit or disallowing the practice all together. Based on my years editing here, it is quite obvious that when an editor is truly disruptive, it won’t be difficult to provide 4 or 5 diffs as evidence without any need for explanation, and that’s something that can be kept in a text file off-WP. If it takes months to collect diffs, and you’re doing it on the fly in an effort to provide evidence that isn’t plainly evident, that’s the first 🚩. It’s a poop or get off the pot process. Atsme📞📧 15:15, 19 May 2018 (UTC)

It seems that I am in the minority but I feel pretty strongly that these sorts of pages should not exist. It cannot be a nice feeling to have a page in existence that is accumulating evidence of your supposed misdeeds, when you have no way of challenging this evidence or otherwise defending yourself. Even if the page is not being publicly waved around, if the editor in question knows of its existence then the effect is nearly the same. Editors who want to complain about other editors' behavior should assemble a case in private, take it expediently through the proper channels, and obtain a swift resolution. They shouldn't be allowed to make public lists of others' behavior that they don't like with the threat of someday using it to lodge a complaint. CapitalSasha ~ talk 21:19, 19 May 2018 (UTC)

Anyone concerned about the existence of polemic pages (aka diff collections or shit lists) can relax because they are prohibited and will be deleted. The only point of contention concerns the period of time allowed before such a compilation is used on a noticeboard, whereupon the original compilation should be deleted (and will be deleted if taken to MfD). Clearly six months is too long, and one week is too short. The closing statement for the MfD that led to this discussion has it exactly correct. Another potential problem concerns someone who makes it known that they have a diff collection, for example, by posting a link to it. That would be a sign of battleground behavior that would encourage deletion of the page. Johnuniq (talk) 00:10, 20 May 2018 (UTC)
I don't really understand the difference between what is being discussed here and a diff collection. Even if someone doesn't advertise that they have a collection, it still shows up in recent changes and so may be noticed by others. These lists should be private, i.e. off-wiki. CapitalSasha ~ talk 04:34, 20 May 2018 (UTC)
Lots of sub-optimal things happen at Wikipedia and collecting evidence in public is one of them. However, such activity is accepted as sometimes necessary because it is important to get the wikitext correct and tested before inflicting it on a noticeboard. If anyone knows of a page like that which is more than a couple of months old, please provide a link for assessment in order to have the page deleted per WP:POLEMIC. Johnuniq (talk) 07:20, 20 May 2018 (UTC)
I don't find this argument at all convincing. Checking that the wiki text is correct is what page preview is for. Fixing the formatting definitely doesn't take weeks or months as is being discussed. It seems to me that the benefit of creating these sorts of public diff lists is the psychological feeling that other people are reading the evidence that one is compiling, even if outwardly one says they aren't advertising it. This strikes me as behavior that should be banned. CapitalSasha ~ talk 19:57, 20 May 2018 (UTC)
Getting the wikitext for complex evidence correct is a lot harder than it appears, however my purpose in posting in this section was merely to report current procedure and I wouldn't mind a speedy-delete category for a page with a diff collection older than 7 days. Johnuniq (talk) 22:51, 20 May 2018 (UTC)
  • Johnbod - see #2. It removes the time frame. Also, MfD is used to delete dubious collections and there appears to be some concern for anything longer than 2 wks to a month is obliquely used to HOUND. Atsme📞📧 16:27, 21 May 2018 (UTC)
No!!! "Replace with: ‘’...is not permitted as it could be misused or misconstrued as a threat or WP:HOUND" - it removes the possibility entirely, changing "is permitted" to "is not permitted"! Unbelievable. The !votes so far suggest that "some concern" is restricted to you and one other editor who have between you taken up most of this section. Johnbod (talk) 21:46, 21 May 2018 (UTC)
Yeah...right up until they find their edits being collected on their opposition's user page. Atsme📞📧 15:02, 31 May 2018 (UTC)

The above discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

Suspend page move rights for new editors?

 Administrator note: The account in question below was autoconfirmed, having been registered for 4 days with at least 10 edits, just noting that "new editors" below the confirmation threshold are already prevented from moves. — xaosflux Talk 14:38, 19 May 2018 (UTC)

L_O_M_G_B_O_Y_E registered 3 days ago and was able to do this. While I appreciate that we don't want to make editing too restrictive for new users I can't think of any good reason why we would want a brand new account to start moving around articles. Is it worth considering suspending page move rights for a month or two until the editor beds in? Betty Logan (talk) 05:36, 19 May 2018 (UTC)

It's still the encyclopedia anyone can edit. I doubt this is necessary just because of occasional vandalism from Milly on Mheels. They'll find other things to do if we block this. (those things not listed per WP:BEANS) power~enwiki (π, ν) 05:40, 19 May 2018 (UTC)
It happens far too often with India-related stuff. No idea about other topic areas. - Sitush (talk) 05:44, 19 May 2018 (UTC)
It's just another form of the low level of vandalism that's inherent in being an open encyclopedia. I don't see any reason to block this particular form of it. CapitalSasha ~ talk 05:47, 19 May 2018 (UTC)
It isn't always low level, eg: articles with few watchers being moved to POV titles. - Sitush (talk) 05:50, 19 May 2018 (UTC)
To add to that it is a specific type of vandalism that sometimes causes massive inconvenience. For example, if they had simply vandalised those pages in the conventional sense then any run of the mill editor could have reverted the edits, but sometimes page moves can be a real hassle to get fixed. Betty Logan (talk) 05:51, 19 May 2018 (UTC)
Betty's is a key point. If page moves were always easy to revert, there would be little problem, but too often these moves create a significant mess, one which an average, even experienced user cannot fix with ease. HiLo48 (talk) 05:56, 19 May 2018 (UTC)
A recent example was Mannanars (Thiyya Dynasty), which was one of several pov moves made at that time. - Sitush (talk) 05:58, 19 May 2018 (UTC)

Some functions should be reserved for experienced editors, and that doesn't impinge on the ability of unregistered and new editors to make actual edits. This is one function which should be off-limits to them. -- BullRangifer (talk) PingMe 05:48, 19 May 2018 (UTC)

Agree. L_O_M_G_B_O_Y_E was able to move 20 pages to nonsense names within 5 minutes, and I guess would have continued if he hadn't been caught and blocked at the end of that time. As Betty says, 'ordinary' vandalism is a nuisance, but page-move vandalism can be a real pain; and as BullRangifer says, there's no particular reason for new users to be instantly able to move pages.
L_O_M_G_B_O_Y_E was presumably autoconfirmed. Perhaps page move rights should be delayed until a user reaches extended-confirmed status? — Stanning (talk) 10:13, 19 May 2018 (UTC)
One user moved a couple dozen pages. Not the end of the world. As has been alluded to above, we've faced far worse and managed to stay afloat. AC is a fine limit, and while EC would certainly be harder to get to, it would stop a lot of good, new editors from contributing. Besides, vandals gonna vandal. ~ Amory (utc) 12:05, 19 May 2018 (UTC)
Amory, let's not use the exact same "logic" the NRA uses to keep AR-15s in the hands of those who can use them to cause much damage. Newbies will not suffer from a lack of the ability to move pages. It will not impinge on their ability to edit and improve the encyclopedia at all. If they really feel the need to move an article, they can ask on the talk page and it will be done, if it's a good idea. -- BullRangifer (talk) PingMe 14:17, 19 May 2018 (UTC)
@BullRangifer: Nice sarcasm. NRA does exactly what Amory opposes. Guns only for the experienced, mature, clean and documented civilians. wumbolo ^^^ 14:32, 19 May 2018 (UTC)
Would you kindly rephrase? You seem to be comparing a silly vandal to mass murderers, with me abetting such crimes. That's inflammatory at best, and insulting at worst, and I do not believe it helps your argument. ~ Amory (utc) 14:39, 19 May 2018 (UTC)
I'm only referring to the logic being used. That's all. Change the names and it becomes a combination of NRA talking points, especially the last do-nothingism because vandals/criminals will always do what they're going to do, so let's not do a thing to prevent it. That type of logic isn't useful when we can easily prevent this type of problem without impinging on their ability to do actual editing. BTW, from what's written below about a filter, this may all be a moot point now. -- BullRangifer (talk) PingMe 14:53, 19 May 2018 (UTC)
Except guns kill people, and page moves don't kill people. power~enwiki (π, ν) 22:28, 19 May 2018 (UTC)
Except guns don't kill people, people kill people. wumbolo ^^^ 22:30, 19 May 2018 (UTC)
Way to parrot an NRA talking point. People kill people, but guns broadly and greatly expand the number of people who can kill other people. Seriously, a bit of critical thinking wouldn't hurt.--WaltCip (talk) 11:11, 21 May 2018 (UTC)
@WaltCip: and therefore minimize the number of people killed, by preventing violence. wumbolo ^^^ 12:39, 21 May 2018 (UTC)

Page moves for the last ten years have been well managed by Filter 68. I suspect the feature is currently experiencing a bug, else it would have been picked up, prevented, AND auto-reported to AIV. In any case the filter is the ideal tool for this as opposed to various blunt restrictions; requested adjustments to the filter can be made at WP:EFR, but like I say, I think it's just experiencing a bug. -- zzuuzz (talk) 14:26, 19 May 2018 (UTC)

OK, having looked a bit deeper there may or may not be a bug, but all that's required is a subtle adjustment to the filter. -- zzuuzz (talk) 14:33, 19 May 2018 (UTC)
I see no reason why page moves can't be pushed to EC, as long as article creation is still at AC. Creating a new page doesn't damage anything, while page moves can screw up a lot if the editor is intent to disrupt. If an AC editor needs a non-controversial page move, that should be handled by a edit request. --Masem (t) 15:11, 19 May 2018 (UTC)
  • I will also totally support upping the ability to move pages to Extended Confirmed. There's no urgent need that can make it necessary to allow a 4-day old account and 10 edits to just start moving pages, some of which cannot be reversed by established editor of 10 years who is not an admin and not a pagemover. "It is encyclopedia, everyone can edit" is a banal cliche which is being far and far from the truth evey day, the reality is "you can only edit what you're allowed". And restricting page-move to EC will not leave us with " hundreds of misnamed pages". –Ammarpad (talk) 11:13, 20 May 2018 (UTC)
  • I agree that mainspace-to-mainspace moving should require EC (moving isn't "editing", so Wikipedia would still the encyclopedia anyone can edit), but limiting draftspace-to-mainspace and userspace-to-mainspace moves would essentially be turning ACREQ into ECREQ, as it would force non-EC users to either create ther articles directly in mainspace (and get them speedied), going through AfC, or doing a copy-and-paste move (which is discouraged for copyright reasons). --Ahecht (TALK
    PAGE
    ) 14:37, 21 May 2018 (UTC)
  • Oppose no real reason for this. Page move vandalism is a pain, but the ability to move pages is key to editing: typos, realizing a page you created could be at a better title, actually knowing more about the MOS and title change policy than established editors and doing uncontroversial moves (this is a thing). Restricting a core function of the MediaWiki software to extended confirmed on all pages is too much for me to swallow. TonyBallioni (talk) 14:42, 21 May 2018 (UTC)
  • Oppose yeah, EC is too much for just the ability to move a page. Also, all this appears to be over an issue that is fixed, at-least according to Zzuuzz, per his comment about "it would have been picked up, prevented, AND auto-reported to AIV" Galobtter (pingó mió) 14:50, 21 May 2018 (UTC)
  • Question: Would those editors opposed to the proposal support a confirmed account being allowed to perform an A->B->C move then? If a new account performs a vandalistic page move isn't the ability to revert the move also "key to editing"? It seems to me that if we are going to permit new editors to make such moves then it is equally reasonable to expect the software not to bar reverting these moves. Betty Logan (talk) 14:58, 21 May 2018 (UTC)
    • So long as the auto-created redirects haven't been edited, anyone can just move it back C->B->A. At least half of the page-move requests I see in Category:Candidates for uncontroversial speedy deletion and never, ever touch (due to bad experiences with people complaining at me about the move afterward, instead of the person who requested it) could have been moved by any autoconfirmed user if they hadn't been tagged with {{db-move}} instead. —Cryptic 15:16, 21 May 2018 (UTC)
      • This. I think perhaps folks don't know about overwriting a redirect? At any rate, it's maddening to see. ~ Amory (utc) 20:11, 21 May 2018 (UTC)
  • Seems to me that the solution we're looking for is to throttle page moves - say, to one per minute (+talk page) for autoconfirmed and five or ten per minute for extended-confirmed - rather than bumping the permission up to EC outright. I had vague recollections of this being made configurable back in the bad old days of WoW, but I can't find any evidence of it now in mediawiki source, alas. —Cryptic 15:16, 21 May 2018 (UTC)
  • Making it part of the EC rights package seems sane. There is very little utility in a user moving a page on their first day. After a month and 500 edits, that would filter out 99% of the vandalism while the overwhelming majority of new users wouldn't even know their right was restricted. Moving pages just isn't something new users do a lot of legitimately. Dennis Brown - 18:31, 21 May 2018 (UTC)
  • Oppose Seems like an ad hoc solution to a nonexistent problem to me. I am also not convinced that there is a benefit, and the attitude that new editors' rights have to be restricted more and more ad nauseam with never any good justification is bothering me. Jo-Jo Eumerus (talk, contributions) 18:34, 21 May 2018 (UTC)
  • Oppose - is seems like a properly configured edit filter resolves this. Endorse Jo-Jo Eumerus's bothersome observation. Tazerdadog (talk) 21:06, 21 May 2018 (UTC)
  • Support have seen 3 hijacking moves in last couple of days, all reverted, user blocked but it is an ongoing problem and no bot recognised it, thanks Atlantic306 (talk)
  • Here's another case of an account doing disruptive moves with just autoconfirm. KyrosFan (talk · contribs). --Masem (t) 23:10, 23 May 2018 (UTC)
  • Oppose A common use case for an autoconfirmed user needing to move a page is the cross-namespace move to article space of something they started in draft or user space. If they've worked on it with anyone else, we want the page history preserved, we don't want to drive them to making cut-and-paste moves. --Worldbruce (talk) 01:10, 24 May 2018 (UTC)

Hello, I think that allowing editors with 4 days and 10 edits to rename articles is an excessively low bar. It could be increased to 7 days and 50 edits at the least. — Preceding unsigned comment added by NaBUru38 (talkcontribs)

  • Oppose I have always gone for higher restrictions on recent discussions, but am strongly against this - it is a vastly higher limit that would remove many good edits. It would also seem out of line to have page creation at a lower level. I suppose articles that would fall into the big delete group (50k edits) could have higher restrictions on their move.
NaBUru38 - while that would make perfect sense as an edit/time requirement, Wiki has been rather staunchly against a proliferation of rights boundaries in the past Nosebagbear (talk) 12:53, 29 May 2018 (UTC)
  • Oppose. As pointed out above, AC users moving a lot of pages in short time can and should be caught by an edit filter. That's no reason to ban all AC users from moving. Regards SoWhy 14:18, 29 May 2018 (UTC)
  • Support because page move vandalism (and clueless non-vandalism) can be more problematic than the usual kinds of non-constructive editing, and because WP itself is taking page moves more and more seriously all the time; people have been blocked, topic banned, "move banned", even indeffed for disruptive page moves, and WP:AT which probably would have been fine as a guideline was elevated to policy level years ago. Either the community has decided page moving is a big deal, or it has not. We have get our story straight. PS: WP is not "the encyclopedia anyone can move stuff around it just for the hell of it". This proposal has no practical implications at all for WP being an open-editing encyclopedia, and our naming policy, naming conventions guidelines, style guidelines, RM precedents, category naming conventions, etc., take a while to absorb. Put it this way, if you're a big-corporation CEO and you just hired someone (with not pilot training), you don't say "Hey, why don't you to the roof and try flying the company helicopter around on your lunch break."  — SMcCandlish ¢ 😼  05:46, 1 June 2018 (UTC)
  • Support moving to EC or otherwise throttling the ability to move stuff. In my experience, good-faith new editors don't even know that moves exist - hence all the requests on the help desk to "rename" articles. Only someone with substantial experience and (for whatever reason) a new account is really looking for this right. There are plenty of good-faith editors in that intersection of user experiences, but my guess is that most of them are not. Matt Deres (talk) 00:03, 3 June 2018 (UTC)
  • Suggestion What if we simply allowed AC users to revert moves, which would move the page back to its original title without leaving behind a redirect? To me, this seems like a good compromise between requiring EC to move pages and requiring a page mover to fix this type of vandalism goose121 (talk) 17:34, 4 June 2018 (UTC)

Question about sourcing

I know that the Wikipedia policies declare social media as an unreliable source and I understand why, but what if an original post from the official account of the subject was used as a source, what then? Is it still not reliable?--◂ ‎épine 17:53, 19 May 2018 (UTC)

If this is an officially attributed account of a notable person X, it can reliably source what the opinion of X on the subject is.--Ymblanter (talk) 19:11, 19 May 2018 (UTC)
Note, however, that this would be a primary source for their opinion, which would be less preferred than a secondary source. CapitalSasha ~ talk 21:15, 19 May 2018 (UTC)
@CapitalSasha: it doesn't necessarily have to be an opinion. Let's say for example it's an album release date disclosed on Facebook, it is acceptable to use it, right?--◂ ‎épine 02:08, 20 May 2018 (UTC)
Hello, Épine. Self-published sources (including social media) are generally considered reliable sources about themselves, provided that they are not being used to source controversial or exceptional claims. You can read more about this at WP:ABOUTSELF. NewYorkActuary (talk) 02:48, 20 May 2018 (UTC)
Regarding upcoming release dates... make sure to read WP:CRYSTALBALL, and WP:NOTPROMO... Reliability is not the only question here. While we may be able to use an official Facebook page to reliably source a statement like: "According to the band's official facebook page, they plan to release a new album in June of 2018 <cite facebook page>"... that does not answer the more fundamental question of whether we should mention the new album in the first place. If the only source to mention that a band is planning to release an album is the the band's own self-published facebook page, we should at least question whether it is appropriate to mention that album. Blueboar (talk) 15:15, 20 May 2018 (UTC)

"A primary source may only be used on Wikipedia to make straightforward, descriptive statements of facts that can be verified by any educated person with access to the primary source." That policy surely applies to social media. --NaBUru38 (talk) 22:29, 27 May 2018 (UTC)

Wikipedia's position on disputed grammar of Standard English

I am wondering what exactly is Wikipedia's position on disputed grammar of Standard English, the language in which Wikipedia and other encyclopedias are written, and is the position justified? The MOS page does not address this issue.

The disputed grammar of Standard English includes:

VarunSoon (talk) 06:04, 23 May 2018 (UTC)

If they aren't addressed in the MOS, these constructions are in general probably not discouraged. Split infinitives and stranded prepositions are quite common in modern academic English so I see no reason to ban Wikipedia from using them. CapitalSasha ~ talk 06:16, 23 May 2018 (UTC)
Just a side note, but I see the subjunctive come up in articles reasonably often. I mostly edit math stuff, but I'd guess there are other places where it has its uses too. I've seen people change something in the subjunctive back to the indicative, and I generally revert changes like that. When it's appropriate, I'd argue that the subjunctive sounds more formal, so it's generally good to use for encyclopedia articles. But there's probably some flexibility in a lot of cases. –Deacon Vorbis (carbon • videos) 14:59, 23 May 2018 (UTC)
  • Split infinitives are fine. Nearly every widely used modern style guide does not object to them. There is no dispute among reliable sources on that issue. Similarly, preposition stranding is a non-issue. Style guides and grammars widely agree that there is no issue with such a matter in English. None of these matters are real disputes among academic grammarians or style guides or anything like that. --Jayron32 15:08, 23 May 2018 (UTC)
  • My personal policy: If poor grammar in an article bothers you, feel free to edit the article to fix it. However, if someone else reverts your edit... let it be. The aggravation involved in arguing isn’t worth the effort. Certainly don’t edit war over grammar. Blueboar (talk) 22:20, 29 May 2018 (UTC)
    At least not over optional and subjective and linguistically dismissed points of obsolete prescriptive grammar like those under discussion here. If some dolt continues to want to write "Microsoft sayed Windows 11 not be release until the years 2020", do press the point. >;-)  — SMcCandlish ¢ 😼  06:06, 1 June 2018 (UTC)
  • Generally concur with the above. I would add that from a linguistics point of view, there really is no such thing as "standard English". (Please send me a copy of the standard, and identify what standards body issued it, under what authority. This isn't as flippant a comment as it sounds, as some languages do in fact have standards bodies, e.g. the Académie française.) That Standard English article probably needs a close review for original research and PoV-pushing, and should be rewritten as an article about the concept of "standard English" and what various pundits have put forth about it, rather than suggesting in Wikipedia's voice that it's a real thing.

    What WP is written is in a semi-formal register of English, based primarily on academic style. That's not "standard English" (or, from a Victorianeque prescriptivism perspective, it's one variant of what some might call standard English, though ever prescriptivist would find something to object to in the ways that WP is written, because prescriptivists could never agree on what to prescribe).

    Another point: it's not just that split infinitives and stranded prepositions are accepted by most modern writers (including writers about writing); they've been demonstrably proven to be a natural feature of the language going back to before it was anything like modern English, and have been present the entire time, through Shakespeare and Dickens and so on to the present day. The idea that they were wrong was pulled out of thin air by prescriptive twits in the 1800s, who decided that Latin was a "more perfect" language than English, so anything you can't do in Latin (e.g. infinites are a single word) you mustn't do in English. Few people took this seriously, and despite making it into various low-grade schoolbooks for a few generations and coloring perception of linguistic register a little, it's had little lasting effect. Few people who claim to live by these "rules" actually do so in practice when their writing is analyzed, including various old English writing manual authors who insisted they were rules.
     — SMcCandlish ¢ 😼  06:06, 1 June 2018 (UTC)

Coming to a computer near you tomorrow

Definitely not the place to contact Wikimedia lawyers.
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.

(non-admin closure) Closing thread on GDPR per WP:NLT and because none of the people commenting are lawyers. power~enwiki (π, ν) 17:38, 24 May 2018 (UTC)

The European Commission, in a list of "Examples of personal data" included in its explanation of the General Data Protection Regulation, has the following bullet:

  • an Internet Protocol (IP) address;

Some editors compile lists of IP addresses which they think belong to the same person. On a reading of the GDPR, absent specific consent from the users of these IP addresses the publication of these lists will be illegal. Although up to now specific consent to the publication of the IP address for a particular edit has been given by the act of clicking the "Publish your changes" button the website has not said that by clicking "publish" or in the Terms of Use that by using the site the editors agree to the publication of these lists - they are as illegal on Thursday as they will be on Friday. On Friday, however, huge penalties for non-compliance will come in. What is likely to happen to

(a) the editors who contribute to these lists and

(b) the Foundation

if they are not deleted by midnight? 2A02:C7F:BE3D:8000:84C2:83DA:8FCC:5838 (talk) 12:04, 24 May 2018 (UTC)

Surely the person would have to be identifiable from the IP address, no? Wikipedia already has a policy against outing people. If editors were prohibited from compiling lists of IP addresses shared by a single user then that would severely limit the effectiveness of SPI. Betty Logan (talk) 12:30, 24 May 2018 (UTC)
The Foundation has lawyers whose job it is handle these issues. This is decidedly not the sort of thing that a bunch of rubes like us are supposed to make decisions about one way or the other. If the Foundation's lawyers come to some way to deal with this, they will probably not keep it a secret. Until then, we don't need to change anything. --Jayron32 12:40, 24 May 2018 (UTC)
Reading this Wikipedia may have a problem: "Personal data that has been de-identified, encrypted or pseudonymised but can be used to re-identify a person remains personal data and falls within the scope of the law." I think for dynamic IP addresses you could reasonable argue that the "window" of re-identification is pretty small, but this is definitely a problem for static IP addresses if editors leave a public electronic trail across the internet. Wikipedia cannot guarantee that this information will anonymous elsewhere. This legislation comes into force tomorrow; are we sure that Wikipedia's lawyers have considered this angle? Betty Logan (talk) 12:45, 24 May 2018 (UTC)

(edit conflict) The full list is:

  • a name and surname;
  • a home address;
  • an email address such as name.surname.acompany.com;
  • an identification card number;
  • location data (for example the location data function on a mobile phone)*;
  • an Internet Protocol (IP) address;
  • a cookie ID*;
  • the advertising identifier of your phone;
  • data held by a hospital or doctor, which could be a symbol that uniquely identifies a person.

IP addresses don't identify people, they make them identifiable, same as the other pieces of information on the list. As the Commissioners put it:

Personal data is any information that relates to an identified or identifiable living individual. Different pieces of information, which collected together can lead to the identification of a particular person, also constitute personal data.

IP addresses are the most potent sources of all, because they link to edits going back many years, and each address linked to multiplies the probability of this happening. It doesn’t matter how dynamic the IP addresses are because they are all being linked up. 2A02:C7F:BE3D:8000:84C2:83DA:8FCC:5838 (talk) 12:51, 24 May 2018 (UTC)

Wikipedia doesn't legally have to do a thing at the moment because it is outside the EU. However I agree there is a problem with displaying IPs which needs to be addressed sooner rather than later. The easiest way round I can see is to make them more anonymous by securely encrypting them. This would still mean an IP remained the same but it would be far harder to argue that it identified a particular person except as yet another contributor to Wikipedia. Trusted officers of Wikipedia with special rights should still be able to check actual IPs to aid in identifying trolls and suchlike. Specific edits that give away personal information can be redacted as at present. Dmcq (talk) 13:51, 24 May 2018 (UTC)
The esams server is in Haarlem, Netherlands. 2A02:C7F:BE3D:8000:84C2:83DA:8FCC:5838 (talk) 14:15, 24 May 2018 (UTC)
(edit conflict) If they haven't, they aren't doing the job they are paid for. Regardless, you and I and everyone else here are not lawyers employed by the foundation to advise the Foundation on their legal responsibilities to comply with such laws. There are lawyers whose job it is to do so, they can be found here. Unless and until they tell us to do something, it's not our responsibility or our problem. Let lawyers lawyer. Our job is to write encyclopedia articles. --Jayron32 12:54, 24 May 2018 (UTC)
You and I are users though, and from tomorrow EU users will have a completely new set of rights. If a user asks you to delete their contribution record from a particular article on the basis it includes their personal data (an IP address), how would you respond to such a request? Betty Logan (talk) 13:27, 24 May 2018 (UTC)
(Not legal advice, IANAL) I would decline the request, as (1) there is no way to verify that an IP's contributions were all made by the same person, or by any person in particular, and (2) per the edit window notice which reads: "By publishing changes, you agree to the Terms of Use, and you irrevocably agree to release your contribution under the CC BY-SA 3.0 License and the GFDL." If you edit without logging in there is an additional notice that "Your IP address will be publicly visible if you make any edits." If the requester invoked GPDR or any other law, I would still decline the request but refer them to the instructions to email WMF Legal. It can technically be done, painfully, but would violate the license and thus I suspect you'll never see it done unless as an office action. I think we broke threading here, I don't know where the list below this comment originated. Ivanvector (Talk/Edits) 13:41, 24 May 2018 (UTC)
It would be silly to depend on some lawyers for ideas on how best to deal with this. And I do think we should proactively deal with IPs tending to locate people. I don't think there is any practical problem even with a server in the EU. There are bigger fishb to fry than trying to prove something about Wikipedia's use of IPs and if somehow the worst came to the worst the EU could be told to go jump and it would have big difficulties if it did try to do anything about it. It is a moral problem for us and we should deal with it. Dmcq (talk)
  • I will take the opportunity to point out that the Wikimedia foundation recently sent me an email linking to their blog, where they explain how the privacy policy has been updated. Judging by the date, it's to comply with whatever it is the GDPR means for Wikipedia. The forum for complaining about whether the Wikimedia lawyers have or haven't done it right is at meta:Talk:Privacy policy. Not here. JLJ001 (talk) 18:20, 24 May 2018 (UTC)
  • Thanks for the link and I have expressed my deep concern about IPs there. I believe closing was wrong as the lawyers are there to serve Wikipedia not the other way round. Dmcq (talk) 23:10, 24 May 2018 (UTC)

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.

Specific question about COI

Hi, I have no idea whether this is the right place to ask this, but I have a specific question about application of WP:OWN and WP:COI. A WP:BLP that I watch is edited by the subject to remove the date of birth (which is sourced). I restored the info and added a link on their talk page about editing your own article etc. This morning they removed the information again saying they have a right to control what data is publicly available. Who is right? The Conflict of Interest policies that I've read suggest that no-one can control what information is posted on an article, but does that apply in this case? Jdcooper (talk) 09:43, 28 May 2018 (UTC)

UPDATE sorry, false alarm, I found the relevant guidelines. Jdcooper (talk) 10:44, 28 May 2018 (UTC)
(ec) My understanding is that, in general, a BLP's DOB should be retained in the article unless there is a question of accuracy. They certainly have no "right" to control that information on Wikipedia, although we can take their request into consideration. However, because DOB is something that's very relevant to developing an understanding of the subject,there would have to be pretty unusual circumstances for me to favor removing it. Tazerdadog (talk) 10:47, 28 May 2018 (UTC)
Not only does the COI subject of a BLP not have a right to control the information, they are under greater risk of being blocked for OWN behavior than other editors. They must keep their hands off the article if they can't edit collaboratively. They are always welcome to use the talk page and suggest changes. -- BullRangifer (talk) PingMe 05:55, 1 June 2018 (UTC)
I have no comment about this issue directly, but I will note that an alternative method that article subjects can pursue is to contact the Volunteer Response Team and submit an OTRS ticket requesting the suppression of certain information for privacy reasons. I doubt this would work if the information is already widely available in public sources, but I have seen it work before, such as with the suppression of Vermin Supreme's birth name. See the latter article's talk page (permanent link) for more information on that incident. If it can work with birth names, perhaps it would also work with birth dates, too. —Nøkkenbuer (talkcontribs) 15:53, 8 June 2018 (UTC)

What is a title blacklist and why do we have it?

Please see discussion at Talk:La'aloa Bay. My question is not just in regards to this one article, but to blacklisting in general. I don't understand it. Why would something be blacklisted just because of ʻOkina? I saw a thread like this before, in regards to moving a Hawaiian article. But I don't understand the situation. Please advise. — Maile (talk) 21:05, 29 May 2018 (UTC)

Not sure why the Hawaiian names are on it (several are), but it is usually for abusive page names or spam pages where salting doesn't work. TonyBallioni (talk) 21:08, 29 May 2018 (UTC)
See WP:TITLESPECIALCHARACTERS. I can't find it now, but a (long) while back there was a discussion around the fact that the okina character didn't appear correctly for many readers, which is the usual reason that some special characters appear in the blacklist. Having said that, there are certainly some articles where it is used in the title (i.e. Sol Hoʻopiʻi). Black Kite (talk) 22:38, 29 May 2018 (UTC)
Thank you. I agree that it doesn't always appear as it should, and my computer is an example. It's because of the font I use. Not all fonts support the okina. But that's a small issue, and I think in Hawaiian articles that the okina should be used. — Maile (talk) 23:14, 29 May 2018 (UTC)
One reason which us long-term editors remember only to well concerns the dreaded phrase "...on wheels". doktorb wordsdeeds 23:27, 29 May 2018 (UTC)
I think the blacklist just lumps the okina with other problematic characters and punctuations which prevents non-admin users from moving the articles. It is perfectly fine to create an article with an okina in it but not to move one to it. See MediaWiki talk:Titleblacklist/Archive 3; there are three sections with the Okina topic. Any user used to be able to make the move a few years ago (I was a regular at this) but now the blacklist includes the okina so non-admins can't make these kind of moves. --KAVEBEAR (talk) 03:23, 30 May 2018 (UTC)

ESRB ratings should be on video game pages

I have sometimes wanted to look up ESRB ratings for video games just because I was curious, but I find it annoying that the ESRB's official site is the only place to go to do that, and it is tough to navigate sometimes. So can we add the ESRB ratings of video games to their articles' info table in the top right? — Preceding unsigned comment added by Kylefreed13 (talkcontribs) 20:22, 30 May 2018 (UTC)

We have previously decided against this. This is part to be consistent with the film project which also doesn't include ratings, and also reflects the fact that there are many many ratings systems so if we'd include the ESRB, we'd have to include other ratings systems which would be too much weight. We discuss ESRB ratings (or any others) if they are a subject of note but that's within the body, not in the infobox. --Masem (t) 20:27, 30 May 2018 (UTC)

Wikipedia Policy about Article Neutrality on Other Languages

Hello. I've problems with the Catalonian Wikipedia board, having been blocked for stating that a person born in France territory is French (and therefore a French Painter) and not North Catalonian (a term a Catalonian nationalist invented in the 1930 to reclaim that territory as their own) and Catalonian Painter.

This' the issue:

  • Northern Catalonia was part of Spain up until 1659, due to the Treaty of the Pyrenees. So, people born there up to 1659 are Spaniards (specifically Catalonian) and after that date, they are French.
  • Étienne Terrus was born in 1857 (that is 198 years after being France territory), so he's French and a French Painter.
  • In the Catalonian website, [Esteve Terrús] is a North-Catalonian and a Catalonian Painter.
  • I was blocked for trying to return this article to neutrality, meaning, removing wrong information used only as nationalist indoctrination for Catalonian (North Catalonia), and placing the proper one (born in France, being a French Painter).
  • In the reasons they wrote in my catalonian personal page, they indicated that the administrators voted to allow nationalist indoctrination and banned me for a week.

[Here] you can see other French painters that have been stolen by the Catalonian indoctrinators, like Pere Garcia-Fons, Mercè Diogène Guilera, Lluís Delfau, Jean Capdeville, Sergi Bonacase and Francesc Boher and Auguste Baillayre. And I'm sure if you look for sculptors, or other people you will find more examples of a clear indoctrination use of Wikipedia.

So, as I couldn't find where should be asking if the Wikipedia Project should be paying the hosting for such blatant violation of article neutrality or how to denounce them (as they are the "law" in the Catalonian Wikipedia, I'm helpless there), I'm asking here on how or where should I keep going with this denounce so it can be taken into examination by the Wikipedia Project.

Franzrogar (talk) 23:16, 30 May 2018 (UTC)

Hi Franzrogar, this does not to be an issue you are having on the English Wikipedia, but on other language editions of Wikipedia. If you are having an issue with admins on smaller projects that you believe are behaving inappropriately, you can raise the issue on Meta. TonyBallioni (talk) 23:21, 30 May 2018 (UTC)
Franzrogar, I'm generally not in favor of Wikidata infoboxes on Wikipedia. However more than that, I hate reality-denying nationalistic bullshit. And more than that, I hate administrators using the block button to push nationalistic bullshit. I see that Catalan Wiki has converted their infoboxes to Wikidata. I also notice that the nationality field doesn't seem to be working in infobox person. That makes me sad, chuckle. I suggest you head over to the infobox talk page, and ask about getting the nationality field working. I also note that the place of birth shows as "Elna". I think the infobox would be awesomely-mega-better if it were upgraded to display the birthplace as "Elna, France".
I'll ping Mike Peel and RexxS. They both have excellent Wikidata tech skills, and they both like upgrading Wikipedia with Wikidata-infobox enhancements. Maybe one of them would be interested in helping enhance Catalan's infobox. And as an added bonus they might get some amusement that I'm suggesting a new benefit of Wikidata: rogue communities need to come to terms with living in the same reality as the rest of the planet. Alsee (talk) 22:27, 31 May 2018 (UTC)
Ironically, Alsee, I firmly believe that most of the benefit of using Wikidata as a central repository accrues to the smaller Wikis, far less so for English Wikipedia. In truth, were it not for the benefit to other projects, I'd be tempted to agree with you that the problems raised in trying to import Wikidata to the English Wikipedia would outweigh its benefits. I've met the guy who does most of the work on the Catalan infoboxes and he's not in need of my humble skills, I assure you.
@Franzrogar: I've had the pleasure of working with several Catalan editors, and found them approachable and understanding. Perhaps you got off "on the wrong foot" - I would certainly suggest continuing to talk to the folks on the Catalan site, although the Catalans I know think of Catalonia as a cultural entity as much as a geographic one, so it is possible (I think) for a person to be both French and a North Catalan. In which case it's likely that the Catalan Wikipedia may legitimately choose to emphasise the Catalan identity, while other Wikipedias prefer to make the French citizenship the key point. You may find that in the end you can reach a compromise, or you may find that your arguments are rejected, but it's best to explore all those avenues before escalating. As TonyBallioni advises you, the best place to look for trans-wiki assistance is on Meta, but you will need to demonstrate that you have exhausted all possible courses on the local Wiki first. --RexxS (talk) 23:42, 31 May 2018 (UTC)

Non-consensus icon change on widely-used template

Template:Blocked user has had its icon removed, making it look like just another template at first glance. The templateeditor who performed this cites a talk page thread, but it doesn't contain any consensus; just "I want the icon removed, I agree, I'm gonna remove the icon because I have the necessary user rights". I have restored the classic version here, for comparison. Lojbanist remove cattle from stage 02:29, 31 May 2018 (UTC)

@Lojbanist: this page is to discuss proposed policies and guidelines and changes to existing policies and guidelines. It looks like you have a simple complaint and have already started a discussion at the right place, Template talk:Blocked user. I suggest you specifically invite the person that made the change to the discussion there. — xaosflux Talk 02:50, 31 May 2018 (UTC)

Discussion at Wikipedia talk:Manual of Style/Portals#RfC: Adopt as a MoS guideline

 You are invited to join the discussion at Wikipedia talk:Manual of Style/Portals#RfC: Adopt as a MoS guideline . - Evad37 [talk] 03:00, 31 May 2018 (UTC)

Wikidata linking RFC

I would like to get some more input on if and how we should link to wikidata in the body of articles. The discussion is at Wikipedia talk:Manual of Style#New RFC on linking to Wikidata Thanks.--Rusf10 (talk) 01:36, 1 June 2018 (UTC)

Additional Wiki Content in Different Languages

Maybe this has already been discussed to death elsewhere, if so someone please point me in the right direction to catch up...

I've just published an article in EN.wikipedia.org/wiki concerning events in the Dutch Revolt. Happily it has just been reviewed, so as an infrequent contributor I'm feeling pretty good. (Maybe I'll get hooked and do more, who knows). My sources were from several languages: Dutch, English, French, Spanish, even Latin ! and I've had no end of fun searching for proper names in different languages with old and often varying spellings. I say this because I view different languages as offering different windows through which to view our fascinating world, so maybe we can accept that different language wiki pages will have different content. Question 1: Should different language wiki pages have different content? Or should the facts be presented independent of language? Searching for a French spelling, subsequent to publishing my contribution, caused me to find a page on my topic in FR.wikipedia.org/wiki It had less info than mine, being a stub rather like the previous english page on my topic. That led me to search for the same topic in other language pages ... NL ES Now, one might expect an event in the Dutch Revolt to have more material in NL, but no that was a stub too. Question 2: How will the nl pages get updated with my efforts? However, the NL page did contain facts that I had not previously found, which I will now have to manually add to my page. I could argue, fact are facts, and they should be so useful in any language. Question 3: Should there be a tool to gather (and maybe translate) all other wiki pages on a topic to aid authors like myself, so each new article is as complete as possible? — Preceding unsigned comment added by DanielTrevorShaw (talkcontribs) 02:36, 1 June 2018 (UTC)

Um, not sure this is the right page for this discussion, seems like a help desk topic, but here goes:
  1. Every Wikipedia is functionally a separate project. They have different editors, different administrators, and different policies. There is a degree of overlap in all three of these areas, but it is not complete. You could just wing it, translating as you wish, and hoping that local editors will fix anything that breaks with local policies, or you could go searching an individual project's policies and style guides to see if anything is different.
  2. They will get updated when an editor volunteers to update it. That editor could be you!
  3. All pages on the same topic in different languages are supposed to be connected through interlanguage links, accessible from the language side bar. You can read about those at Help:Interlanguage links. If this is done properly, then while reading the article in any language, you will see links to every available version on the left side of the screen. If that's not the case right now, those links should be added. The help page also describes how to do that. Sometimes this is not done simply because the editors on each project are unaware that another version exists, or they don't know how to update the links.
Hope that helps. Someguy1221 (talk) 03:31, 1 June 2018 (UTC)

Problem behaviours and rudeness

Some editors are distressed by the aggressive behaviour and rudeness of others, and/or believe that many good editors are being driven away by it. I made some observations and proposals on managing the problem at Wikipedia:Village pump (idea lab)#Best practice, several of which affect our policies. I now think it worth exploring them in more detail and widening the conversation. Would it be best to create a new thread here, create it somewhere else, or just ask folks here to follow the above link? — Cheers, Steelpillow (Talk) 16:28, 4 June 2018 (UTC)

I'll post them again here, then. I have some experience of civility codes in both commercial and public organisations, all in the UK. Here are some of my observations about current best practice and how they might be implemented on Wikipedia:
  • It is becoming increasingly accepted that rudeness and disrespect are in the mind of the recipient; if they feel insulted by you then you have insulted them, whether you intended to or not. WP:IUC needs updating accordingly.
  • Rudeness is about more than just words. Aggressive behaviours can be equally rude, not only in active aggression such as reversions but also in passive aggression such as refusal to acknowledge or discuss an issue or to admit any personal failing. WP:IUC could make this clearer.
  • Overly-detailed prescriptive guidelines are the wrong way to implement policy. An enlightened moderator is absolutely essential in dealing with incidents that escalate. As it stands today, WP:IUC is a classic example of how not to do it and does nothing but provide ammunition for logic-chopping excuses and "I have nothing to apologise for" attitudes. If it is simplified and refocused on perceived intent, that should help the moderating Admins to make better decisions.
  • Apologising for unintended harm, such as a perceived insult, is increasingly becoming mandatory. It is in this respect analogous to a fine for a parking offence, where the parking itself is only a civil offence but failing to pay the fine is a criminal one. Such a forced apology may well be mealy-mouthed and insincere, but it has been seen to be made and that is the crucial thing. Once somebody has been forced to cough up several such, they will begin to get the message. WP:CIVIL is grossly behind the times in this respect. It also needs a shortcut such as WP:APOLOGY (which currently redirects to an essay) to help raise awareness of its critical importance.
  • To be effective and deal with expert wrigglers, moderators also need a generic getout clause allowing, "we just find it unacceptably disrespectful overall" judgement even though specifics may be vague. An example would be an unjustified demand for an apology, where the demand is really just a cynical revenge manoeuvre. I don't know to what extent our Admins have this already.
  • Logging and tracking of escalated incidents is the norm. "You have been called here on three separate occasions already this year" type information should be available to moderators at the click of a button. Typically, the data is time-limited to prevent lifelong black marks. I don't know of our Admins have such tools, but they should.

— Cheers, Steelpillow (Talk) 03:17, 6 June 2018 (UTC)

Without addressing the general validity of these principles there are two issues right off the top which I see with applying them: First; we have no baseline of acceptable behavior. Likely the organizations all had either a basic code of conduct against which transgressions could be measured and addressed or a set of common norms based on shared culture. Here the best we can come up with is "fuck off" is generally OK while "fuck you" almost never is. Second; We have no moderators. Rather there is a self selecting and varying population of editors who opine at AN and ANI. There is only a verybasic consensus of what is OK or not and both outcomes and sanctions vary extensively from case to case.
The very concept of rudeness depends on a set of commonly held norms, or at least a recognition of whose norms should be applied to interprete proper behavior. (e.g. 'When in Rome. Do as the Romans) There are many ways our various editors may intend or take offense because our editors each have differing [[Pierre_Bourdieu#Theory of class distinction|cultural] and personal social capital i.e. the knowledge and social graces one gains when growing up e.g. 'ladies first', what one can and can not eat with one's fingers, and all the bits of knowledge and values one equates with being 'proper' or holds as valuable. Without some common ground it is not possible to even identify transgressive behaviors. (Unfortunately there is no Wikipedia equivalent to Emily Post's Book of Etiquette.)
I am tempted to say the solution is to focus on graciousness rather than rudeness. A gracious host neither takes offense nor gives unintended offense. The problem is graciousness is not a common value either. It does, however, have the advantage of being easily described, whereas rudeness is not. Even the gracious host must address the puppy who keeps pissing on the floor though. </pontificate> Jbh Talk 03:58, 6 June 2018 (UTC) Last edited:Added wikilinks for those interested. 15:07, 6 June 2018 (UTC)
"fuck off" is generally OK And here we see the problem... the puppy who keeps pissing on the floor Ah, the ol' WP:CIR defense. The vast majority of rudeness I've witnessed on Wikipedia has nothing to do with competency and everything to do with WP:OWN, an editor who doesn't want anybody to interfere with their preferred version or outright tries to silence another editor through deleting their on-topic comments. Wikipedia really doesn't need any further rules to deal with this behavior; it's purely an enforcement issue where "well-known" editors are hardly ever held up to the rules, allowing them to violate WP:DE with impunity. "The puppy who keeps pissing on the floor" is blocked almost immediately. The "gracious host" who pisses on the rug after the puppy shampooed it and dusted it, that's the problem. Bright☀ 10:56, 6 June 2018 (UTC)
Let me just say I disagree totally with the first point. I oppose making the alleged offended party the sole arbiter of whether something was rude or not. There will be no modifying WP:IUC to this effect. No way. The reason is that there are plenty of people around here who like to feign outrage and insult as a means of "winning" disputes. Reyk YO! 10:57, 6 June 2018 (UTC)
Like many others, the problem is rooted in the way we make decisions. You have five different viewpoints and 20 variations on those viewpoints, and people rarely change their minds as a result of discussion. You also have grudges, axes to grind, and agendas that determine many editors' contributions to decision-making. All of this is human nature and it is not going to change in the time scales that concern us. Thus it's impossible to get anywhere near the clear consensus required to make significant changes for the better.
In the area of editor behavior, self-selected self-governance is a failed social experiment. Such a thing has never succeeded in the history of civilization, to my knowledge, at least not in communities as diverse as this one. To have any hope of addressing these problems, you would have to change the system of government, and that would require WMF to assume control without asking our permission, which would not be without its own problems. ―Mandruss 11:10, 6 June 2018 (UTC)
Not going to happen. Pointless debate, as have been all of its predecessors. If people don't want to be faced with what they perceive as rudeness then they need to adopt the lifestyle of a hermit. It is the way of the world, perceptions differ and all the WMF blarney about "safe spaces" etc will not change that. As was once said, we're not here to sing Kumbaya. - Sitush (talk) 11:20, 6 June 2018 (UTC)

Thank you all for your comments. In response I should perhaps point out that I made a number of suggestions, not all linked directly to each other, so any simplistic "it won't work" type comment begs the question as to which "it" is being criticised and whether any of the others might be worth pursuing. There can never be a "baseline of acceptable behaviour", as what is acceptable in one context may not be in another. That is why it is important for moderators to be free to exercise their discretion. Someone pointed out that we have no formal Moderators but that Admins are frequently called on to perform in this role: yes, that is indeed who I mean when I talk about a moderator with a small "m". For example I already pointed out the example of someone falsely claiming to be offended and admins need discretion to make judgements about that, there can never be the total "one offended party one judgement" rule that someone misread into one bullet point. It is worth repeating that Wikipedia has a problem with so many editors walking away and I am among those who believe that our excessively abrasive environment must hold some responsibility. The suggestion that our current policies and guidelines cannot be improved is frankly ridiculous. Some degree of incremental change is needed and that is what many of my suggestions are aimed at. Somebody also pointed out that the problem is endemic within the Admin community - yes of course it is and that is precisely why I suggested some changes that might help guide such Admins towards a more considerate attitude. These suggestions do not come from nowhere, I have seen them working elsewhere and if Wikipedia will only blindly reject them wholesale then perhaps Wikipedians need to sit back and consider just why they wish to differ from the way the world is moving. Is it really my suggestions that are out of touch with reality, or is it actually the Wikipedians who are driving their ex-colleagues away? This is what I have come here to try and start a reasoned debate about, not just snap soundbites. I would respectfully suggest that, while we are indeed not here to sing Kumbaya, we are not here to piss in each other's pockets for the sake of it, either. — Cheers, Steelpillow (Talk) 21:42, 7 June 2018 (UTC)

Those will all make me glad not to be in the UK! Damn. "Rudeness and disrespect are in the mind of the recipient?" Um, no. We're not mind readers. The standard should be "knew or should have known", and whether offense would be caused to a reasonable person. If you call someone a fucking moron, you should know most reasonable people will be offended by that. If I'm offended by words containing the letter "z", you can't know that would offend me, nor is it reasonable for me to take offense to you discussing The Legend of Zelda. Far as "refusal to admit personal failings", well, if someone says you have a personal failing and you disagree, they can think what they think and you can think what you think. We already consider guidelines descriptive rather than prescriptive, and lawyering doesn't work. If someone finds a way to misbehave that isn't "technically" covered by a policy yet, they can still be sanctioned for being disruptive in general. And reverts happen, it's part of editing. If someone is too thin-skinned to get reverted sometimes, this probably isn't the right place for them to be. I will tell you right now that I will resign the bit before I use it to force someone to apologize. Absolutely not. I want people to apologize if they are actually sorry. If people are routinely forced to apologize, apologies mean nothing at all to the recipient either! If someone right now says to me "I'm sorry, I was having a bad day and I shouldn't have reacted that way", that actually means something to me. But if I knew they were going to be made to say it anyway...do they mean that, or are they just getting it out of the way since they'll have to anyway? As above, we already do have that "wiggle room"—if someone's clearly being disruptive, they can be told they need to knock it off, regardless of exactly what it is they're doing. And with "logging and tracking", blocks and sanctions are logged, and noticeboards are all searchable. But the number of times someone's been to a drama board isn't the crucial bit, you need to go read the context. Did they actually do something wrong and receive a warning for it? Was the complaint generally considered to be baseless? That rather does matter. If someone is drug to ANI ten times, and all ten reports are baseless, we shouldn't sanction them anyway on some kind of "where there's smoke there's fire" stupidity. So a couple of these are already the case, and the rest should absolutely never be. Seraphimblade Talk to me 22:03, 7 June 2018 (UTC)
As Sitush said, we're not here to sing Kumbaya. We're here to build an encyclopedia using certain policies and guidelines. If I tell an editor, "no, you can't factually state that your caste is literally descended from the gods and I'll block you if you continue" I'm aware that I might be insulting them but I'm not going to apologize for upholding Wikipedia policies. Similarly, spammers told to stop spamming have offended me by trying to use Wikipedia for their personal financial gain. I respectfully suggest you need more experience with civility codes in both commercial and public organizations because "if they feel insulted by you then you have insulted them, whether you intended to or not" is certainly not the case when the rubber meets the road (performance reviews, code quality reviews, contractor objective fulfillment reviews, promotion reviews, etc.). I use these specific examples because we are essentially reviewing each other's contributions here. We can do so politely but we will give offense to people not here to build an encyclopedia according to our standards and we shouldn't have to apologize for that. --NeilN talk to me 22:35, 7 June 2018 (UTC)
(edit conflict × 2) Well, I must submit that the belief – "There can never be a "baseline of acceptable behaviour", as what is acceptable in one context may not be in another" is why there is not going to be a solution. If there is no consistent behavioral model to judge and be judged against then anything can be either a transgression or acceptable. Simply saying "what is acceptable in one context may not be in another" is pretty much a throw away statement. Of course that is true but, in this instance, the context is editing Wikipedia. The only contexts that arise are subsets of that one, for instance: interactions at articles, interactions in dispute resolution, interactions with new editors, interactions with the public e.g. BLP subjects, informal interactions among peers, etc. All of those are simply more or less strict application of the baseline. This is no different that how office/professional interactions differ from a baseline.
The issue here is that there is no general agreement on what to model the baseline off of. Some want 'professional' while others feel 'mates hanging out at a pub' is more proper. Add to that the ones who think the world should be wrapped in cotton candy and no offense should ever darken their world and you get conflict and grief from a universe of un-managed expectations.
To create manageable expectations; First define the type on online environment is desired; Then examine the values which must be held dear for such an environment to arise and be sustained; Finally identify the type of behavior which expresses and enforces those values. You talk of processes but what are they meant to achieve? How will they identify who is 'right' an who is 'wrong' if no 'right' or 'wrong' behavior prescribed? Who will administer those processes, if they are to provide coercive relief under what authority can they act?
Simply asking people not to be rude is pointless because it requires knowing not only what one considers polite/rude oneself but what each individual one interacts with does as well. Even if that is known how does one judge which set of mores should be observed? In the 'real world' the senior or dominant individual decides c.f. one's boss, one's elder or one's contextual social superior. On Wikipedia though we have no way of negotiating by whose values an interaction should be judged.
There was a long running and very divisive dispute about whether the severity of an editors transgression by the use of a certain "c-word" should be judged based on the American view of the use of that word (very, very, very bad) or the view of the rest of the English speaking world (meh, its even used on the BBC). In that case the editor, who is British, was sanctioned based on how offended Americans were. There was a bit more to it but the situation is illustrative of what happens when there is no common baseline. Jbh Talk 22:45, 7 June 2018 (UTC)
  • Well, yes, as @NeilN: suggests, I offend people every day, often every hour, of my editing here. A lot of that offence is very severe in nature even on those occasions where I do not name-call nor use words that some people consider to be naughty in some contexts. It frequently invokes serious reactions - legal threats, corresponding attempts at offence, occasionally death threats and in one long-running series of events, things that were so disruptive to my personal life that I had to relocate and get the WMF and police involved. Under the sort of schemes being mooted here, I would have been booted off Wikipedia many years ago and I absolutely guarantee you that the project would have been much worse for it. The same applies to a lot of other people, some of whom have indeed been forced out for Doing The Right Thing. That said, if any sort of snowflake organised monitoring of civility begins, I'll just go anyway: things have to be considered on their own merits and there neither is nor can be any bright line. We are primarily an encyclopaedia, not a social experiment. - Sitush (talk) 03:55, 8 June 2018 (UTC)
  • These pointless discussions founder because they are not based on any practical examples of how being nice would assist the development of a neutral encyclopedia built on reliable sources. People who are offended by assertions that evolution-is-real-get-over-it or similar in many fields need to use another website. People who civil POV push until good editors are provoked to rudeness need to use another website. The aim is to develop a neutral encyclopedia built on reliable sources, not provide a place for every nitwit to have their say. Johnuniq (talk) 23:48, 8 June 2018 (UTC)
  • Yes, being on the wrong end of the civil pov pushing thing earned me one of my blocks. Then, soon after, the person was globally banned or something similar by WMF but the block stays on the record. I still maintain that even my response to them was misinterpreted (deliberately) by their supporters and by an admin (also no gone) who didn't understand the context or the idiom. - Sitush (talk) 01:08, 9 June 2018 (UTC)

Company Pages "Against Policy"

Article userfied. Anything else can be discussed at WP:NCORP. TonyBallioni (talk) 02:47, 6 June 2018 (UTC)
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.

I have a very difficult problem to address: the idea that pages about companies can be "not encyclopedic." I recently wrote an article on the Elk Antennas company, which was nominated for speedy deletion. The Admin who shut it down, @Randykitty:, claimed that it violated Wikipedia's guidelines and that it was more promotional than encyclopedic. The article was only a stub; it stated what the company manufactured and designed, who owned it, and when it was started. I understand that I did not have enough reliable sources. Despite this, other articles have managed to get published and not deleted such as Elecraft. In fact (I'm going to use this article to prove a point, not to be malicious or try to get it deleted too), in the article of Elecraft, there are completely un-encyclopedia phrases such as "The company is most notable for the Elecraft K3 high-performance HF transceiver, a 32-bit DSP based radio covering HF plus the 6-meter VHF band and the 160-meter MF band, introduced in 2008. The reception of the K3 was overwhelmingly positive, with a comprehensive review in QST stating that "The K3, in any of the available configurations, provides a high performance, modular and expandable transceiver that can fill the needs of almost anyone looking for an HF and 6 meter transceiver for home station or portable use"." First of all, "high-performance" is not a fact, that is an opinion. Second of all, a QST review is not a factual source, it's an opinionated article. Third, "overwhelmingly positive" is also an opinion. If this little snipped doesn't say enough, I don't know what will. My article contained nothing promotional, it was only a stub station that the company existed. If an article is going to be deleted, Elecraft should be the one. I am advocating for a change in policy to help promote the inclusion of non-promotional company pages on Wikipedia. Please consider my plead for Justice. BluePankow 01:51, 6 June 2018 (UTC)

Please see the notability criteria for companies and organizations, in particular the sourcing requirements. If Elcraft does not meet Wikipedia's content policies that is a reason to fix it not a reason to allow another article fail those criteria as well. This is brought up so often there is a page, WP:OTHERSTUFF, which goes into detail. Jbh Talk 02:20, 6 June 2018 (UTC)
Okay, okay. I get the jist. How about "there is an article of Elecraft, so there should be an article on Elk Antennas?" BluePankow 02:24, 6 June 2018 (UTC)
I wouldn’t have deleted it as G11, but Elk Antennas was definitely A7 material. TonyBallioni (talk) 02:30, 6 June 2018 (UTC)
Do you think it would be possible to recreate it and keep it? Maybe people just need to give it some help instead of immediately deleting it. BluePankow 02:32, 6 June 2018 (UTC)
BluePankow, see User:BluePankow/Elk Antennas. TonyBallioni (talk) 02:39, 6 June 2018 (UTC)
Thank you, I'll get this back up. Thanks for the help. I think this thread could go on for longer though; the company topic needs more discussion in my opinion. BluePankow 02:41, 6 June 2018 (UTC)
It was deleted because it made no claim at all as to why I should care it exists. I’m closing this because the community has discussed corporate notability ad nasium recently, and this is basically you just appealing a deletion. TonyBallioni (talk) 02:47, 6 June 2018 (UTC)

Real fine. BluePankow 02:49, 6 June 2018 (UTC)


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.

Channel lineups and pricing tiers in articles about Media providers

Question here raised by myself and a COI editor another editor who both were curious to know policy regarding media company providers listing channel lineups and package tier offerings (along with prices) in these articles. I had removed these instances from Sling TV owing to WP:NOTACATALOG and WP:NOTTVGUIDE, but the COI editor the other editor rightly asked why these would be allowed on other media providers' articles and not Sling TV. It's a good question, and I wanted to know what editors thought about this practice. Checking the Pump archives, I found a discussion from 5 years ago at Wikipedia:Village_pump_(policy)/Archive_99#Channel_lineups_in_Wikipedia which touched on the topic, but there did not seem to be a resolution. The talk page discussions around the site regarding pricing in general are numerous, and while I look through many of them, I see a lot of back and forth on what is allowed, although many seem wary of the practice and tread lightly in that area. Would like to get an idea of what current policy/practice is. Currently, Wikipedia:WikiProject Media appears to be a ghost town — which is why I brought my question here. Any input would be appreciated Face-smile.svg spintendo  01:58, 6 June 2018 (UTC)

Channel lineups, pricing tiers and anything which would go on an advert are, well, advertising and not acceptable in an article. See WP:NOTPROMO#5. Much of the Sling TV article should be stripped out. Sections 1-3 are mostly promotionalism and Native advertising. I suggest stubbing. Jbh Talk 02:15, 6 June 2018 (UTC)
I also think it is also an issue with the other streaming providers (Philo (company), PlayStation Vue, YouTube TV and DirecTV Now as well, where packages and prices are listed. So it is not limited to the Sling TV article. Don't think any of the satellite or cable company articles have this issue. Msw1002 (talk) 03:48, 6 June 2018 (UTC)
(Note to Msw1002: I mistakenly referred to you as a COI editor in my post. That has been corrected.) Sorry about that!  spintendo  12:48, 6 June 2018 (UTC)
No problem. :) Msw1002 (talk) 13:27, 6 June 2018 (UTC))
I have removed the worst sections and tagged the articles with {{advert}} but I do not have the stomach to go through and clean them up. Jbh Talk 21:25, 6 June 2018 (UTC)
If independent sources have commentary about pricing this could be there, but it should not be advertising in nature, and not just quoted from the vendor. There is substantial writing on the price of Apple or Samsung products, so that a whole article could exist on that. Graeme Bartlett (talk) 22:49, 6 June 2018 (UTC)
Thank you JBH. And Graeme I agree with you, especially if the price were also a part of the narrative of an item, either because of a price war or some other unique circumstance which made the item's price something that became notable in reporting done upon it. In contrast, the inclusion of the prices in these media services articles seem set on whatever the price is at the moment, and seems to go against the spirit of WP:NOTACATALOG, which focuses on pricing done for the act of comparing prices.  spintendo  23:39, 6 June 2018 (UTC)
There are definitely independent sources out there such as www.suppose.tv . So those should be used instead of direct from providers if pricing is mentioned (if at all). Msw1002 (talk) 13:23, 7 June 2018 (UTC)

Consistent titles for esports athletes

It seems that there may need to be a policy governing the titles of articles about esports (competitive video gaming) competitors. Some of them use the player's legal name, and some their gaming name. My personal take is that it should probably be their gamer handles. Actual names are rarely if ever used in a lot of those communities.TylerRDavis (talk) 20:06, 6 June 2018 (UTC)

I would think this would be settled by applying our existing WP:Article titles policy, especially provisions such as WP:COMMONNAME. No? Blueboar (talk) 20:52, 6 June 2018 (UTC)
Same approach (whichever is taken) should be applied to socalled "Youtube celebrities" like Markiplier and PewDiePie. Right now I think COMMONNAME is the prevailing approach, using their handle over their real name, which in some cases isn't always known. --Masem (t) 21:43, 6 June 2018 (UTC)
No, their handle is not always the common name. --Izno (talk) 01:47, 7 June 2018 (UTC)
This has already been discussed at some length. The applicable guideline is WP:STAGENAME and the applicable policy is WP:COMMONNAME. --Izno (talk) 01:46, 7 June 2018 (UTC)
So, if someone were to go through all of these articles and change the titles to the name these players are commonly known as, meaning their "gamertag," that would be acceptable?TylerRDavis (talk) 18:17, 7 June 2018 (UTC)
Not necessarily... this needs to be determined on a case by case basis. We have to examine the reliable sources that discuss each individual player, and determine which name is favored by those sources. I suspect that the “gamertag” will be favored in most cases... but there may well be exceptions... cases where the sources indicate that a specific player is best known by his/her real name. Blueboar (talk) 22:50, 7 June 2018 (UTC)
Agreed, COMMONNAME already handles this, there’s no need for topic-specific guidelines. Beeblebrox (talk) 03:37, 8 June 2018 (UTC)

RfC Enforcability of logged editing restrictions

An RfC has been opened about whether voluntary editing restrictions logged at WP:Editing restrictions#Voluntary can be enforced in the same was as those logged at WP:Editing restrictions#Placed by the Wikipedia community. Your input would be appriciated.

The RfC is located at WP:Enforceability of logged voluntary editing restrictions Jbh Talk 06:30, 7 June 2018 (UTC)

Technical

RfC: Enabling TemplateStyles

Should Extension:TemplateStyles (help) be enabled on the English Wikipedia as soon as technically possible? Jc86035 (talk) 12:28, 18 May 2018 (UTC)

Background

The TemplateStyles extension will, in brief, allow custom CSS pages to be used to style content without an administrator having to edit sitewide CSS. This will make it more convenient for editors to style templates; for example, those templates for which the sitewide CSS for the mobile skin or another skin (e.g. Timeless) currently negatively affects the display of the template. The extension is already in use on some other Wikipedias, and should not open any avenues for vandalism which are not already possible with existing templates and inline styling. However, it cannot be implemented until HTML Tidy is replaced with RemexHtml, which is scheduled to happen for the English Wikipedia after June 2018.

Currently, TemplateStyles is being enabled for Wikipedias on a case-by-case basis, and if this RfC is successful then a Phabricator task will be made requesting the extension's deployment at the same time as RemexHtml.

Examples

Survey

  • Support. Jc86035 (talk) 12:28, 18 May 2018 (UTC)
  • Yesss Galobtter (pingó mió) 16:00, 18 May 2018 (UTC)
  • Yes please. I have lots of templates that i could fix if only I had these capabilities. —TheDJ (talkcontribs) 17:37, 18 May 2018 (UTC)
  • Support - I can think of excellent use cases for this - making templates responsive with media queries is the first one that comes to mind. Richard0612 17:48, 18 May 2018 (UTC)
  • Support, because it will be much easier for any template editor (not that particular user right, but an editor of template) to request a custom styling for certain templates. I, too, can think of places where custom CSS will be very handy. epicgenius (talk) 21:19, 18 May 2018 (UTC)
  • Maybe? I'd like to use an actual use / example before deciding. Headbomb {t · c · p · b} 22:34, 18 May 2018 (UTC)
    • @Headbomb: A small example can be seen at mw:Template:ResponsiveAmboxExample, the image gets hidden if your browser window is narrow enough. Think of doing something similar with navboxes so the mobile site can stop hiding them. Anomie 07:46, 19 May 2018 (UTC)
      • So basically, this can't (at least straightforwardly) change say an existing string to a different string, but would rather apply things like font changes, width changes, and other CSS type of changes on a per-template basis? I think we still ought to have some restrictions on that (Evad37's restrictions/best practices below seem very reasonable) especially for accessibility reasons, but I don't why what that couldn't be rolled out now (i.e. support), with the understanding that people using this are careful/use WP:COMMONSENSE. Headbomb {t · c · p · b} 11:43, 19 May 2018 (UTC)
  • Conditional support, if we get some sort of guidelines and/or best-practices in place first. Stuff like "only style the template's output", "avoid using !important", "use selectors and class names that are highly likely to be unique to that template (i.e. myTemplate-row rather than row)", "only images which don't require attribution can be used as background images". - Evad37 [talk] 02:01, 19 May 2018 (UTC)
  • Support I've been waiting a long time for this. This will allow us to fix a lot of templates for mobile, and also to reduce the size of the HTML we produce by getting rid of duplicated inline CSS. — Mr. Stradivarius ♪ talk ♪ 07:38, 19 May 2018 (UTC)
  • Sure, seems useful. I'd worry about abuse and keeping track of it all — it seems like the potential for pages could be huge — and would definitely support some level of baseline protection status (probably AC default, elevate to TE if heavily used). Basically, if TheDJ and Stradivarius think it'd be good, it's probably good. ~ Amory (utc) 11:58, 19 May 2018 (UTC)
  • Support This sounds great. I was concerned about mal-use but the measures in place look well thought-out. Cesdeva (talk) 07:23, 22 May 2018 (UTC)
  • Support It looks like it would be useful. Guidance will be developed in the usual way. There may be occasional misuses but they will be reversible. I assume changes will show up on watchlists in the usual way? · · · Peter (Southwood) (talk): 08:29, 22 May 2018 (UTC)
  • Support Not having any useful way to code responsively (or even use CSS correctly) is a real pain, it's like trying to build a car with no wheels and the wrong chassis, and it makes everything on wikipedia look like it's from the early 2000's. Because it is. This would be so helpful. JLJ001 (talk) 17:19, 24 May 2018 (UTC) SOCKSTRIKE. Primefac (talk) 18:37, 31 May 2018 (UTC)
  • Support As long as we have guidelines in place to control how this is used. We don't want editors going wild with this. — AfroThundr (tc) 07:48, 27 May 2018 (UTC)
  • Conditional support, per Evad37. I was going to saying something like this myself (and I think I did in a previous round), but Evad37's got the gist of that minor issue. I fully support going forward with this feature implementation, it just can't be dumped on the community without pre-addressing the potential problem points.  — SMcCandlish ¢ 😼  04:24, 2 June 2018 (UTC)

Discussion (TemplateStyles)

Sounds scary - if I understand correctly, a template in one part of an article would be able to completely or partially mangle the display/styling of a different template in a completely different section of the page. And not just from vandalism, but also good-faith edits if they just happen to result in templates with conflicting rules, which might not be obvious at the time of editing. - Evad37 [talk] 15:41, 18 May 2018 (UTC)

Hmm, people who make use of it should I hope make sure their styling does not affect the rest of the page/other templates but only the target template. People who vandalize can perfectly well cover screen-fuls of page with image vandalism so not going to dramatically up the possibilities of vandalism Galobtter (pingó mió) 16:00, 18 May 2018 (UTC)
Correct, but if that becomes unmanageable, we could elevate edit permissions to templateeditor or something. the benefits will outweigh the negatives. Besides. postion:absolute bothers me on half the user pages and that seems perfectly acceptable to the community. —TheDJ (talkcontribs) 17:37, 18 May 2018 (UTC)
+1 for banning position:absolute and other crimes against design. :P Richard0612 17:50, 18 May 2018 (UTC)
@Richard0612: I think a blanket ban on position:absolute wouldn't be very practical, since there are e.g. 26 Lua modules which use it for largely legitimate purposes such as overlaying images. Jc86035 (talk) 17:57, 18 May 2018 (UTC)
@Jc86035: I was being entirely flippant with my comment - of course it does have sensible uses (image overlays, charts, etc.) and shouldn't be banned. I've just seen a lot of user-space z-order abominations (not that I like CSS much as a technology anyway, but it's the best we have). Richard0612 18:05, 18 May 2018 (UTC)
It seems I left my irony–sarcasm meter off. Jc86035 (talk) 18:07, 18 May 2018 (UTC)
Easily done, no harm! :) Richard0612 18:10, 18 May 2018 (UTC)

So for this custom CSS, which namespace would it be hosted in? Would users be restricted from editing these CSS pages (e.g. limiting these pages to administrators/template-editors only)? epicgenius (talk) 21:19, 18 May 2018 (UTC)

It would be in the Template: namespace, and protection could be applied as needed. High-exposure pages will inevitably be TE-protected. Richard0612 21:30, 18 May 2018 (UTC)
Thanks. epicgenius (talk) 22:30, 18 May 2018 (UTC)

I started a draft guideline page at Wikipedia:TemplateStyles; it could do with some expansion and/or discussion - Evad37 [talk] 02:48, 19 May 2018 (UTC)

  • A usage guideline I'm thinking we should have if going forward is that styles should be easily able to be identified and edited by being associated with a specific template or group of templates. In general, this means it should be a subpage related to the such as: Template:xxxx/styleyyyy.css. Explicitly, for articles styles should never be configured to pull from the User: namespace. — xaosflux Talk 21:51, 19 May 2018 (UTC)
    TemplateStyles CSS pages must have the sanitized-css (Sanitized CSS) content model, which is the default for subpages in the template namespace that end with .css (Template:Foo/bar.css). Only users with changecontentmodel (admins only here) can create them elsewhere. — JJMC89(T·C) 23:02, 19 May 2018 (UTC)
    @JJMC89: perhaps that is a side affect of having that extension installed...currently template subpages ending in .css are in model wikitext (e.g. Template:X1/style.css). — xaosflux Talk 23:37, 19 May 2018 (UTC)
    Yes. You should be able to test on testwiki. — JJMC89(T·C) 00:39, 20 May 2018 (UTC)
    Saw it there, sample for anyone watching at testwiki:Template:-/test.css. — xaosflux Talk 01:10, 20 May 2018 (UTC)

If allowed - default protection?

To touch on some points above, by default any confirmed user would be able to create/edit these type of pages. If we want the default to be something else we can implement controls in a few ways. The title blacklist could be used limit creations to templateeditors similar to the way we do editnotices. We could also do various things with the edit filter. As mentioned in the above section, individual pages could always be dealt with via page protections. If moving forward, do we want to establish any technical controls here? — xaosflux Talk 21:47, 19 May 2018 (UTC)

Is there any reason not to restrict these like editnotices? I'm not sure what a usecase would be where it would be necessary to make these visible and frequently edited. ~ Amory (utc) 01:02, 20 May 2018 (UTC)
Why should the styles of a template be harder to edit that the template itself. {{3x|p}}ery (talk) 01:04, 20 May 2018 (UTC)
They should really have the same protection level as their parent template. Otherwise you just encourage styles to remain inline, or get inline styles added on top of the TemplateStyles CSS since the template was editable but not the css. Perhaps an adminbot could do the protections automatically? - Evad37 [talk] 03:32, 20 May 2018 (UTC)
Or just create a category akin to Category:Templates using under-protected Lua modules. {{3x|p}}ery (talk) 03:47, 20 May 2018 (UTC)
If a template is unprotected, presumably its css page would also be unprotected. What would there be to prevent a rule being maliciously added to that css page? For example, one having a selector that is not specific to the template's code, but perhaps matches some other part of a page - maybe as broad as
body { /* ... */ }
- this could potentially compromise all pages using that template. --Redrose64 🌹 (talk) 09:51, 20 May 2018 (UTC)
The styles are scoped to prevent that kind of thing - basically you can't mess with anything that isn't contained in an element with the class .mw-parser-output. There's still potential for abuse, don't get me wrong, but it's not that bad. Richard0612 10:33, 20 May 2018 (UTC)
It says "Styles included by a template can currently affect content on the page outside of the content generated by that template" which is what I am worried about. --Redrose64 🌹 (talk) 20:06, 20 May 2018 (UTC)
Oh that's true, absolutely. If there's (e.g.) a div on the page that the CSS selects, it'll be affected. But the styles couldn't affect the body or any other elements of the interface. Then again, if a vandal could edit the CSS to cause chaos, they could edit the template itself to cause chaos. Hence the logic that the CSS should have the same level of protection as its parent template. Richard0612 20:20, 20 May 2018 (UTC)

Discussion at Wikipedia talk:TemplateStyles#RFC: Adopt as a guideline

 You are invited to join the discussion at Wikipedia talk:TemplateStyles#RFC: Adopt as a guideline. - Evad37 [talk] 08:26, 22 May 2018 (UTC)

CSD backlog?

CAT:CSD is reporting a backlog even though there are less than 50 items in the cat. — RHaworth (talk · contribs) 12:05, 22 May 2018 (UTC)

I think the template counts sub-categories as well, so the items might be there only. Regards SoWhy 12:30, 22 May 2018 (UTC)
Category:Candidates for speedy deletion has no real subcategories. The listed "Subcategories" are wikitext made by {{CSD/Subcategories}} in the category text. The problem is that {{PAGESINCATEGORY:Candidates for speedy deletion}} produces 152 at the time of writing (557 at the time this page was last rendered) while the category page only displays 13 pages at the time of writing. PrimeHunter (talk) 12:52, 22 May 2018 (UTC)
Assume this is related. Admin dashboard has been reporting an inflated CSD backlog for the last two days. And the problem seems to be getting worse. I first noticed it yesterday when it reported a backlog of 133 when we only had 43. Then it went to a backlog of 176 when the actual figure was 37. Currently, we have 66 backlog, but Dashboard says it's 209. — Maile (talk) 14:43, 22 May 2018 (UTC)
Dashboard now says there are 204 CSD backlog. There are only 27 CSD at the moment. There is one item only in a sub category. — Maile (talk) 18:37, 22 May 2018 (UTC)
Only became noticeable this week: {{PAGESINCATEGORY|Candidates for speedy deletion}} currently showing 557, hugely in excess of the actual number: Noyster (talk), 19:19, 24 May 2018 (UTC)
As of right now, Dashboard says there are 777 items at CSD. In reality, there are only 8 items at CSD. Refer to above task opened at Phabricator. — Maile (talk) 00:22, 29 May 2018 (UTC)
The only comment in that Phabricator link (T195397) is Looks to be an ancient problem related to T18036. However, the problem has only appeared in recent days and seems to be confined to the CSD category, applying even when there are very few members and not applying to other categories with more members: Noyster (talk), 09:59, 29 May 2018 (UTC)
The problem of category counts getting out of sync with reality is ancient. This particular manifestation of that problem is new though. Apparently the only solution is to completely empty the category! Good luck doing that. I did write a script to solve this, which is ready and able to be run on WMF servers (phab:T170737). There is a minor flaw in the output that the script prints to the command line, but that shouldn't get in the way of Reedy potentially running this on enwiki... — This, that and the other (talk) 11:04, 29 May 2018 (UTC)
  •  Done As of right now, Admin dashboard seems to have been corrected, now showing only 22 items at CSD. Whoever did what ... thanks. — Maile (talk) 16:22, 29 May 2018 (UTC)
    That'd be Anomie ~ Amory (utc) 19:32, 29 May 2018 (UTC)
    Gone wild again - now showing 450 - and there are only about 60 Ronhjones  (Talk) 19:37, 5 June 2018 (UTC)
  • Yep, it baaaaccckkkk! Right now, the admin Dashboard says 445 CSD. In reality, there are only 43 CSD. — Maile (talk) 20:20, 5 June 2018 (UTC)

PAGESINCAT miscounting

Category:Candidates for speedy deletion appears to have approximately 110 members, not 557 as {{PAGESINCAT:Candidates for speedy deletion}} claims. What is going on there? Template:CSD summary and other admin backlog templates try to use this number. —Kusma (t·c) 09:02, 29 May 2018 (UTC)

See #CSD backlog?. --Edgars2007 (talk/contribs) 09:11, 29 May 2018 (UTC)

Error tracking category added by translation tool

I have noticed three or four cases where someone created a page using mw:Content translation and where an error tracking category (Category:Age error) was inserted in the translation. Examples: User:OMAR YLIF/Natalie Moszkowska (from fr:Natalie Moszkowska) and User:Dri1com/Jean Dabry (from fr:Jean Dabry). Editing the page shows the wikitext for the category in the middle of the article. This is a trivial issue but it's puzzling—how could that category end up in the translation? Johnuniq (talk) 04:00, 24 May 2018 (UTC)

Here is another: User:Borishermann/Hermann Kamte (from fr:Hermann Kamte). Weird! It's got several error tracking categories including links to help. Possibly some copy/paste confusion using visual editor? Johnuniq (talk) 11:09, 1 June 2018 (UTC)

Collapsible sections of tables?

It there a way to have something like

Table
Date Player Result
2015 [hide]
2015-05-06 Bob Won
2015-08-06 Suzy Lost
2016 [hide]
2016-05-06 Bob Won
2016-05-09 Bob Won

Where the 2015 [hide] would collapse the 2015 rows, but leave the 2016 rows displayed? Thanks. Headbomb {t · c · p · b} 18:57, 24 May 2018 (UTC)

@Headbomb: You could always fake it with separate tables:
Table
Date Player Result
--Ahecht (TALK
PAGE
) 19:22, 24 May 2018 (UTC)
@Ahecht: Was hoping for something that'd still be sortable at the end of the day. And something that would inherit all the properties from the top level, rather than have to specify every width in sub-levels to ensure consistency. Not sure if that's doable. Headbomb {t · c · p · b} 09:52, 25 May 2018 (UTC)
@Headbomb: It should be technically possible with JavaScript, but I cannot read or write JS. I think I might have asked about something like this before, possibly to TheDJ about {{Routemap}}, but the solution in that template, for now, is also to nest tables. How would sorting a collapsible table work? If you were to press "collapse" after reordering the rows, what would happen? Jc86035's alternate account (talk) 09:35, 2 June 2018 (UTC)
That's a good question. Probably only sort the uncollapsed rows? Headbomb {t · c · p · b} 12:04, 2 June 2018 (UTC)
It is bad practice (inaccessible) to have intermediary column-spanning items in a table as this moves tables away from data tables toward layout tables. If you want separate tables, make separate tables. If you want one table, these should be as row-spanning cells, presumably in the first column. --Izno (talk) 19:49, 2 June 2018 (UTC)

webrecorder.io for |archiveurl=

Archive.org, webcitation.org and archive.is are great at recording and playing back static web pages. But dynamic content pages often don't do well, such as Google Books, flash, YouTube, Facebook, Twitter etc...

From Rhizome (organization)#Web archiving:

Funded by the Andrew W. Mellon Foundation, Webrecorder is targeted towards archiving social media, video content, and other dynamic content, rather than static webpages. Webrecorder is an attempt to place web archiving tools in the hands of individual users and communities. It uses a "symmetrical web archiving" approach, meaning the same software is used to record and play back the website. While other web archiving tools run a web crawler to capture sites, Webrecorder takes a different method, actually recording a user browsing the site to capture its interactive features.

The quality and fidelity of webrecorder.io archives on replay are unmatched. It also allows for archiving multiple pages in a single archive. The downside is need to register for an account and a slight learning curve. The upside is the archives are fully open-source meaning the WARC files can be downloaded. If there are sites you want to archive but have not been successful this is a solution. -- GreenC 03:47, 27 May 2018 (UTC)

@GreenC: Should there be a guideline for how to use it in Wikipedia, like the ones for the Internet Archive, archive.is and webcitation.org? It seems to be more complicated than the other web archives, especially since an account is required to archive pages. Jc86035's alternate account (talk) 16:00, 27 May 2018 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Yeah that would be good. There are over 100 thousand YouTube links on enwiki. A sample video:

This is typical. Almost none of the YouTube links are backed up. They last 5-10 years. -- GreenC 15:57, 29 May 2018 (UTC)

I do think that source archival is something that needs to be looked at more closely by the community. Webrecorder could be the best option for interactive sites, which seems to be on the main problems with our current archiving. The other main problem is when a site has died and it has not been archived at all, regardless of interactive or not interactive elements. Emir of Wikipedia (talk) 19:05, 2 June 2018 (UTC)
Another problem: when a page is archived, the underlying HTML code is from that era. As time goes on, the ability to replay that HTML degrades because standards change, browsers change, security changes. So pages from the 1990s don't display well on browsers from 2018. It gets worse with time. Webrecorder uses a virtual machine to emulate old browsers when recording/replaying so it is possible to replay a page as it was intended to be seen no matter the age. It's slick technology and the only archive capable of it. -- GreenC 20:24, 2 June 2018 (UTC)
I have created a page at Help:Archiving a source. Advantages and disadvantages of each service can be listed there. Emir of Wikipedia (talk) 21:46, 2 June 2018 (UTC)
Hmm.. it sort of forks WP:Link rot which I'm (slowly) rewriting in sandbox. There is also WP:WEBARCHIVES. This is a large complex topic when you look into it so many issues. -- GreenC 22:24, 2 June 2018 (UTC)

Issue with editing - End of paragraph and "return"

Hi,

Been noticing the last couple of days that editing does not leave a clear space between paragraphs. In some cases, it also appears to ignore a para break/return and concatenate sections. Most frustrating. Regards, Cinderella157 (talk) 23:53, 28 May 2018 (UTC)

Please give an example and name you browser and your skin at Special:Preferences#mw-prefsection-rendering. Are you referring to the edit area in your browser while editing a page, or to a rendered saved page? If it's the edit area then which editor do you use? Does it happen if you are logged out? PrimeHunter (talk) 00:11, 29 May 2018 (UTC)

See: 1. Would remove “criminal” before Commissar order because it sounds as if that is Wikipedia’s voice, and also duplicates the end of that sentence re contravening laws of war. (btw would be good to clarify what we mean by “laws of war’ – ie what convention or international agreement set these laws in this instance). Alternatively, we would need a specific source for “criminal” as it has a particular meaning beyond violation of a convention – criminal under what national or international law? 4. Do we know what happened to his family after the war?

5. Overall, this is a comprehensive summary of Hoepner’s military career, with some interesting additions and quotes on his views and interpretations of different stages of activity. It would have been good to have a bit more about the nam as an individual (ie not just a soldier), and some further background on his early life. But we’re obviously limited by the soruces we have, which seem fairly comprehensively reviewed.

These have all been typed as seperate paras. Regards, Cinderella157 (talk) 00:29, 29 May 2018 (UTC)

I am using WikiEd in vector. Does this answer all of your questions? Regards, Cinderella157 (talk) 00:37, 29 May 2018 (UTC) See this also, posted by another ed indicating the same problem.

First: Purity of sources. I'm not convinced that looking for sources that deal specifically and only with a given event is helpful in contextualizing the horrors of WWII and German operations in Central/Eastern Europe, particularly in the General Government.
Second: Context is a way of understand the purification of Eastern Europe. Instead, he preferred to rely on one source to document the article, and to limit the article to its barest bones. There is no context of the operation, no sense of how and why it happened in the broader Nazi operation. It sounds to me more like a book report than an article.
Third: Generally, I see this dispute as, first, a sourcing dispute, complicated by personal styles of communication. We have, obviously, a conflict between the kinds of secondary sources acceptable. Second, we also have a dispute over the level of detail appropriate to an article.

Regards, Cinderella157 (talk) 00:37, 29 May 2018 (UTC)

Turned off wikiEd. My first example has rendered appropriately now, so it appears to be a WikiEd problem. Regards, Cinderella157 (talk) 00:41, 29 May 2018 (UTC)

You didn't name your browser. I see no issue with wikEd in Firefox with Vector. wikEd is a script at the English Wikipedia. Problems can be reported at User talk:Cacycle/wikEd. PrimeHunter (talk) 10:07, 29 May 2018 (UTC)
@PrimeHunter, it is Firefox. I will do what you suggest. Regards, Cinderella157 (talk) 04:10, 30 May 2018 (UTC)
I am using Firefox too (on multiple platforms), and I have the same problem. Hawkeye7 (discuss) 05:11, 30 May 2018 (UTC)

Reported per advice. Regards, Cinderella157 (talk) 06:07, 30 May 2018 (UTC)

I'm very glad this has been reported, something indeed has happened in the past few days that makes editing paragraphs with Firefox (and the Monobook skin, if that's relevant) a sorrow: it had worked perfectly for many years before that. An instance happened with this edit; it seems one needs to insert two line-breaks to create, and sometimes to maintain, a paragraph break, and trouble can happen both at the editing point and at the next paragraph break which sometimes also disappears. It's well wrong. Chiswick Chap (talk) 12:02, 30 May 2018 (UTC)

FYI, the maintainer has been so sporadically present and there are currently so many issue open with WikEd, that I consider it unmaintained, which means it will slowely degrade further as time moves on. If you are truly interested in continueing to use it, u should see about learning the code and making your own changes. Im happy to deploy them for you, but i dont have the time to maintain this tool myself. —TheDJ (talkcontribs) 13:37, 30 May 2018 (UTC)

WikEd's code hasn't changed, so there must have been an external change that broke it. It's the only editor we have, so it has to work. Hawkeye7 (discuss) 20:28, 30 May 2018 (UTC)
Looks like a Firefox bug. Working okay in Safari. Hawkeye7 (discuss) 21:11, 30 May 2018 (UTC)
I can report annoying linebreak/paragraph handling here. I use Wikied/Firefox as well. Headbomb {t · c · p · b} 21:21, 30 May 2018 (UTC)

@Hawkeye7: “WikEd's code hasn't changed, so there must have been an external change that broke it.” Correct, a common misconception is that this means the problem is not in WikEd. The eco system changes continuously. Code that isnt maintained is on a slow path towards death. Its the only certainty there is. “It's the only editor we have, so it has to work.” Nah, we have CodeEditor, 2003 editor, 2008 editor, 2010 editor, 2017 editor, VisualEditor and the syntaxhighlight modes for WE2017 and WE2010 (available from Beta) (oh and floweditor, wikidateditor, pagesource editor [wikisource] etc etc etc) —TheDJ (talkcontribs) 22:17, 30 May 2018 (UTC)

Never heard of any of them (except VisualEditor, which cannot edit). Where are they on the gadgets page? Hawkeye7 (discuss) 22:49, 30 May 2018 (UTC)
Your point about the Wikipedia no longer being maintained is well-founded. We have to move away from volunteers. Hawkeye7 (discuss) 02:34, 2 June 2018 (UTC)
I'm having the same problem with wikEd under Firefox. WikEd handles regular expressions, which is why it's especially useful to me. Which replacement editor does the same? My attempts to find out on my own indicates that only a subset of the above, if any, do. Dhtwiki (talk) 22:40, 30 May 2018 (UTC)
The default source editor and toolbar has regex. Click "Advanced" above the edit box and then a magnifying glass icon to the right. PrimeHunter (talk) 22:50, 30 May 2018 (UTC)
Thank you. I'll look into it. Dhtwiki (talk) 23:24, 30 May 2018 (UTC)
VisualEditor (both the wikitext [aka "2017 wikitext editor"] and visual modes) handles regex search/replace as well.
Hawkeye7, they're not gadgets. They're officially maintained software, so they're mostly in Special:Preferences#mw-prefsection-editing instead of the gadgets tab. See mw:Editor for a list (with screenshots and sometimes directions for enabling them). Whatamidoing (WMF) (talk) 00:07, 31 May 2018 (UTC)

I did have a recent large update to windows 10, if that is any help. Regards, Cinderella157 (talk) 23:11, 30 May 2018 (UTC)

@Whatamidoing (WMF), I have used WikiEd mainly for editing, mainly because of its undo function but also, because it has a wider variety/easier access to markup code than the basic editor. What is most likely to be similar in functionallity and a basic point in the right direction please. Regards, Cinderella157 (talk) 02:16, 31 May 2018 (UTC)

I really don't know what to recommend, because personal preferences are personal. But looking at your recent contributions to articles, you seem to make a lot of small edits (instead of one big one) to individual sections, some of the articles use the sfn template family (which the visual editor doesn't support), and you don't seem to be using much markup. With that in mind, you might consider the default (2010) wikitext editor as the next one to try, and seeing whether any extra wikitext markup codes you want are present below the editing window. It should be faster to load than WikEd. You might also want to try the syntax highlighting beta feature for it. Whatamidoing (WMF) (talk) 22:43, 31 May 2018 (UTC)
I've been trying out the default (2010) editor, which I haven't used for years. (I'm using it now.) There is not much evidence that it has been maintained since then. It has two kinds of syntax highlighting; the default one works, although the colour scheme takes a lot of getting used to. The regexp replace works, in the Perl dialect. The find does not work; it does not reset the cursor at the find position, and has no reverse find function. It has the special characters characters menu to add the abominable en dash and em dash characters that the MOS requires, but does not render them so you can detect them. It's by no means unusable, but it isn't very good either. Hawkeye7 (discuss) 02:34, 2 June 2018 (UTC)

There also appears to be a bit of a problem with the generic editor. I am having to add two returns (ie a blank line) to get text to separate otherwise, with one return, text just runs on as if it is part of the same para. Regards, Cinderella157 (talk) 06:31, 31 May 2018 (UTC)

I don't see a problem here. For as long as I've been around (nine years), it's always been the case that a single newline will run text together into a single paragraph, and two newlines (one blank line) will start a new paragraph. See Help:Wikitext#Line breaks. BTW you should not leave blank lines between colon-indented replies, see WP:INDENTGAP. --Redrose64 🌹 (talk) 10:00, 31 May 2018 (UTC)
The blank lines between the colon indented replies are caused by the problem we're complaining about!!! Hawkeye7 (discuss) 10:56, 31 May 2018 (UTC)
I concur with Cinderella157 and Hawkeye7, at least in regard to my use of the classic text editor in Firefox/Windows 7 (desktop): line spacing started misbehaving a couple of weeks ago,.
That is:
(i) Until a couple of weeks ago, return + blank line would always create a new paragraph, but I now have to insert a hard line break (e.g. <br>), to ensure that I don't get one giant paragraph. Even double blank lines vanish in some cases!
(ii) If I use indentation, as I am in this post (i.e. :::), I get an extra, unwanted blank line!
These bugs do not seem to occur with the only other platform that I use to edit articles – classic text editor in Chrome/Android (phone, which is less user-friendly than the desktop, obviously).
Grant | Talk 04:38, 3 June 2018 (UTC)

Jarry's Template transclusion count missing!

On Special:WhatLinksHere there used to be a link to Jarry's template transclusion counter when you searched for a template, but now it's gone! Does anyone know why, or how I can get it back, or who I have to stab in the kidneys for taking it away in the first place? Primefac (talk) 12:25, 30 May 2018 (UTC) (please ping on reply)

@Primefac: Per this, for some reason MediaWiki:Linkshere-2 is used instead of MediaWiki:Linkshere. Copying the code of the latter to the former I think should fix it, though why that change was made I have no idea; doesn't seem to have anything to do with the phab task Galobtter (pingó mió) 13:06, 30 May 2018 (UTC)
(edit conflict) Mediawiki has changed WhatLinksHere from using MediaWiki:Linkshere to using the new MediaWiki:Linkshere-2. The former was customized at the English Wikipedia. The new MediaWiki message is called with the wikilinked page name instead of just the page name. What an annoying and pointless change but we should be able to work around it. I will post to MediaWiki talk:Linkshere#New message name. PrimeHunter (talk) 13:11, 30 May 2018 (UTC)
@PrimeHunter: It's absolutely not pointless; it allows a full-URL link with redirect=no to be passed in when viewing WhatLinksHere for a redirect page. See phab:rMWac187d902f235cd6e523fff30b2bcb4765e3e75b. It is apparently going to go into the next issue of Tech News. — This, that and the other (talk) 16:16, 31 May 2018 (UTC)
Heh, I see you commented at phab:T189860 already. — This, that and the other (talk) 16:18, 31 May 2018 (UTC)
Something else has happened to Special:WhatLinksHere. If you looked at this for a non-existent page, such as Special:WhatLinksHere/Template:WikiProjectBannerShelll, the line "The following pages link to ..." used to have a boldfaced redlink, but now it's a boldfaced bluelink, thus giving the misleading impression that the page exists, when in fact it does not. It means that I'm slowed down when processing Wikipedia:Database reports/Broken WikiProject templates. --Redrose64 🌹 (talk) 16:04, 1 June 2018 (UTC)
Why is the 'what redirects here' functionality removed? Please restore that! Headbomb {t · c · p · b} 19:11, 1 June 2018 (UTC)
Blue instead of red link was reported in phab:T195933. A fix should be on the way. Restoration of "Show redirects only" should also be on the way. We made the link at the English Wikipedia in MediaWiki:Linkshere but it uses a MediaWiki feature which was changed in phab:T189860. PrimeHunter (talk) 19:46, 1 June 2018 (UTC)
Thanks all - I was just about to raise these issues myself. Lugnuts Fire Walk with Me 08:24, 3 June 2018 (UTC)

Missing functionality

The last time I used the "what links here" tool, a link was present atop the list to "show redirects only". That link is currently, for me, no longer displayed. What happened? Is there a work around for this formerly useful feature? Thank you.--John Cline (talk) 22:45, 3 June 2018 (UTC)

@John Cline: I moved your post to the existing section. PrimeHunter (talk) 23:23, 3 June 2018 (UTC)

What links here redirects

The last few days, when I click on “what links here”, there is no option to list redirects only. What happened to that? Its absence is seriously hindering some of the work I do. NotARabbit (talk) 17:54, 4 June 2018 (UTC)

Change coming to MonoBook skin for mobile users

Hi,

(Unfortunately, my note missed Tech News by a few hours, so I'm posting a special notice here as a heads up, in addition to my wikitech-ambassadors email, and the post here a month ago.)

Thanks to Isarra's awesome work, the MonoBook skin is now responsive, meaning it will have a mobile-optimized view for smaller devices (similar to the new Timeless skin). You can try it out on the beta cluster by shrinking your browser window to see what the new layout looks like. This change only affects people who use the MonoBook skin on their mobile devices (and potentially other smaller screens like tablets). Feedback/bugs/suggestions can be reported here or on the Phabricator task.

If you don't like the new layout, it should be possible for you to opt out by using your mobile browser's "request desktop site" option (Firefox for Android documentation). This will be deployed as part of this week's wmf.6 deployment (today or tomorrow depending on your timezone).

Thanks! Legoktm (talk) 06:08, 31 May 2018 (UTC)

Cool deal :-) ~Oshwah~(talk) (contribs) 06:13, 31 May 2018 (UTC)
  • Well the usual question, how does one get the previous layout back as the default on the "Desktop version" without having to set the desktop setting every time in the mobile browser? —Mr. Matté (Talk/Contrib) 20:36, 31 May 2018 (UTC)
  • This is horrible. And it's impossible to get the good layout on an iPad. In Safari, "Request Desktop Site" takes me to the mobile site. I then either request it again or scroll down and select "Desktop", and I'm back where I started. It doesn't work in Chrome either. The ability to permanently opt out of this is desperately needed. MANdARAX  XAЯAbИAM 21:51, 31 May 2018 (UTC)
  • I would have to agree. If I wanted nesting menus, I would just use a desktop program. I'm trained on using Monobook on all of my devices, no matter how kludgy it might be on an iPhone screen. The icons are too random and so tiny as to be useless to contextualize the menu option beneath it; if I'm keeping this I'd like the option to use text titles. I'm annoyed enough with the WP app wanting to grab anything I surf to, and this doesn't help mobile browsing/editing. Nate (chatter) 22:18, 31 May 2018 (UTC)
  • Is this what's screwed up the screen when I request the desktop site on mobile? I now get some horrible and meaningless icons at the top of the screen. Please stop "improving" things by making them worse. DuncanHill (talk) 22:51, 31 May 2018 (UTC)
Chiming in as the developer who approved the relevant patchsets and who has been working closely with Isarra on this...
First of all, thank you for providing feedback! Given that a lot of volunteer time and effort has been put into testing this change and ironing out bugs, it's surprising to see that some persistent bugs are still present — and I'm hoping you can help us squash those bugs for once and for all!
Can you tell us the following things:
  • The name of your device (e.g. Lenovo ThinkPad X230 laptop, iPad Pro 2nd generation, 12.9" screen, etc.)
    • This is important because while there are, for example, many tablets released by Apple sold as "iPad", there are many significant differences between the different "generations" of devices — sometimes these differences are so major, in fact, that you could legitimately call them entirely different things! (Of course "iPad" is a well-estabilished brand and Apple will want to hold onto it and its good reputation, hence why it's more than likely they'll continue using the iPad brand even in the future.) Providing as accurate data as possible about the devices helps us in — hopefully — finding a device similar to that or a someone who owns a similar device and is able to assist in the development process.
  • The operating system (OS) of the device
  • The screen resolution of the device
    • E.g. 1920x1080px/full HD, etc.; you can find out sites which can help you in finding out your screen resolution by searching Google for "what is my screen resolution", for example, since on mobile devices it can be trickier to find out the screen resolution than on desktop or laptop computers
  • The browser you were using at the time, and if possible, its version
    • Internet Explorer, Firefox, Google Chrome, Safari, Firefox for Android (also known as Fennec) and Chromium are some examples of popular web browsers.
    • Finding out the browser version can be trickier, again. If you search Google for "what is my user agent", Google will display your browser's user agent which usually includes the browser name and version. Most browsers should have a menu labeled "Settings" (or something similar) under which you can find an item like "About <browser name>" or such, which allows you to find the browser version number without resorting to Google. On Firefox for Android (Fennec) 47.0, this menu can be accessed by tapping the three dots (on the same row as the address bar, choosing "Settings", then "Mozilla Firefox" and finally "About Firefox".
  • Name or URL of the page where the problem is occurring
    • Is the problem present only on the Main Page? Or on a certain article? All articles? All Wikipedia: pages? etc.
  • Ideally, a screenshot or even a video of the issue actually taking place!
To elaborate a bit more on what is being done and why...mobile devices are ubiquitous these days. The MonoBook skin was written originally in 2004, back when almost nobody had heard the words "responsive web design"; if MonoBook were written today, it would naturally feature responsiveness since in 2018 — and, frankly, for many years before, responsiveness has been a de facto standard for most web sites out there; MediaWiki has and still is lagging behind, partially because Wikipedia and other Wikimedia sites (Wiktionary, Wikivoyage, etc.) use the MobileFrontend extension to serve a rather different view to users of mobile devices. --Jack Phoenix (Contact) 00:49, 1 June 2018 (UTC)
Samsung Galaxy J3 SM-J320FN, Android 5.1.1, Chrome 66.0.3359.158 (32 bit), screen 360x640. I have lost the talk/edit/history etc tabs at the top of the page, they have been replaced by illegible and meaningless icons. I can't see an option on the upload wizard for Wikipedia screenshots. DuncanHill (talk) 01:26, 1 June 2018 (UTC)
I think I managed to work out the upload. DuncanHill (talk) 01:40, 1 June 2018 (UTC)
Horrible icons instead of words
Hi DuncanHill. Icons in a user interface are very common. For example, the wrench and hammer to mean "tools" seems straightforward to me. If the meaning of the icons is not immediately obvious, when you click on the icon, it shows a "Tools" box. I'm not sure I understand what the objection here is. In the screenshot you provided, the icons are legible and meaningful. The user icon is the same guy who's been sitting next to the user tools all these years. The pencil icon means edit. The speech bubbles are for the talk page. And so on. --MZMcBride (talk) 02:50, 1 June 2018 (UTC)
They take up more space than the text, and are not by any means as readily understandable. One of the reasons I like monobook is because the tabs are so much clearer to me than on the other skins. They also make me have to click twice for some functions that I only had to click once for before. Also, PLEASE DO NOT PING OR @ ME. Getting rid of the notification on the new display is a pig. And more, it makes the desktop display on a mobile much more like the mobile site display, which is exactly what I'm trying to avoid. It makes articles take more scrolling to get through, contents lists take up the whole damn width of the screen, pictures take up the whole width. It's nasty. DuncanHill (talk) 02:59, 1 June 2018 (UTC)
Yes, exactly this. I would imagine that if someone is deliberately using the desktop view on mobile devices, he or she probably is used to the desktop view and wants it to look exactly the same on all devices. Responsive web design is exactly the opposite of what such users want. They like one view and don't want it to change, and they would like to keep using it everywhere. And at least my personal opinion places no weight on "lagging behind" when the desktop view has already been very optimised for editing; if we change it, it should be because something actually is broken, not to keep up with the Joneses. It strikes me that these efforts would be better spent on the mobile view, where they would be aimed at a public that actually wants this. A pertinent question might be if anyone on WP actually asked for this, or if it was simply imposed because some higher-ups from the WMF decided we had to keep up with the Joneses (never mind that the Joneses are doing something completely different and have completely different needs). An even more pertinent question might be if anyone actually realised the counterproductiveness of applying responsive web design to the desktop view on mobile devices. Double sharp (talk) 03:32, 1 June 2018 (UTC)
Something I've forgotten to add is that editing on the desktop view even on a mobile device allows you to do layout fixes even when not on a desktop, with the desktop view as the showcase one as it ought to be (there you have the biggest screen and the most complete experience, after all; it's quite difficult to research and edit on a smartphone simultaneously due to the amount of tab-swapping needed, so while it could be done, I do most of my large edits on the desktop). On the mobile view and this responsive quasi-mobile view, this can't be checked because pictures take up the whole width and override any chosen settings (never mind the mistakes that sometimes result when this is done, like unscrollable images that spill off the screen). Double sharp (talk) 06:13, 1 June 2018 (UTC)
I see, from Isarra's comment further down, that (to quote her) "the WMF was actually against this, as they feared pretty much precisely this reaction, which just goes to show that they have learned from previous incidents". I find this quite heartening and agree with her that it shows they've learned. I also see the link below showing where this was previously discussed, albeit without much publicity. Nevertheless, I still wonder if anybody along the lines realised the counterproductiveness of this, because the only people who are likely to see this are the people who are likely not to want it. Double sharp (talk) 10:37, 2 June 2018 (UTC)
@Jack Phoenix and Isarra: Please provide a way to permanently revert/disable this feature; as a screen reader user, I have no interest in it and never will (not to mention that it disables the access keys). I receive it in desktop view on my 15.6-inch laptop (!), a 2012 HP Pavilion dv6 Notebook PC running Windows 10 with a screen resolution of 1366×768 (the maximum) in IE11 when the window is restored (but not when it is maximised, and not at all in FF57). IE11 is easiest to use here for various screen-reader-related reasons, and Edge is not an option. Graham87 01:37, 1 June 2018 (UTC)
Also, how do I disable the jump-to-navigation/search links now? Putting .mw-jump-link{display: none;} in my monobook.css doesn't do it. Graham87 02:01, 1 June 2018 (UTC)
Hi Graham87. What do you mean the access keys are disabled? When I press, for example, option+control+e, it works fine for me. What are you trying that isn't working?
Your CSS also looks fine to me. --MZMcBride (talk) 02:56, 1 June 2018 (UTC)
@MZMcBride: It turns out that the "Edit this page" shortcut is the only one that works here when the new mode is active; I was trying the talk shortcut, which in my case is alt-t. They all still work with the normal Monobook.
Re: CSS ... that's really weird; the navigation/search links still display for me in all combinations of JAWS and NVDA (the two primary Windows screen readers) with Firefox and IE. Graham87 03:36, 1 June 2018 (UTC)
There was a separate change to the jump links this week: phab:T195256. I haven't investigated yet whether that could be related, but just mentioning it for completeness. Legoktm (talk) 05:49, 1 June 2018 (UTC)
@Graham To disable the jump-to links, use .mw-jump-link{display: none;}. Notice the class name containing "link". The explicit disabling of accessibility links (in addition to being visually hidden by default) is not something MonoBook offered officially before, but I hope this snippet helps you to keep disabling it. Krinkle (talk) 20:42, 1 June 2018 (UTC)
@Krinkle: Thanks, but I already have that code in my monobook.css and it doesn't work. Graham87 03:30, 2 June 2018 (UTC)
@Graham: That's unfortunate. Which browser and operating system are you experiencing this on? I have tried myself with MonoBook in IE 11 on Windows 8, and also in Chrome and Firefox on macOS. Without the change to monobook.css it is visually hidden but becomes visible when tabbed to. With the change to monobook.css it is always hidden and not part of the accessibility tree and tab sequence. I have also tried adding the rest of your monobook.css customisations and are still not able to reproduce the issue. --Krinkle (talk) 21:05, 2 June 2018 (UTC)
@Krinkle: Hmmm, that's really weird! I get it in all combinations of JAWS/NVDA, the two most popular Windows screen readers, with IE11/FF60 unnder Windows 10. Could be a screen reader thing. After a couple of days of having it like this, I find it doesn't bother me anywhere near as much as the (now-reverted) responsive skin changes, however. Graham87 02:13, 3 June 2018 (UTC)
I now have to have my zoom size at 150% (instead of 175%) to maintain my previous layout. TBH, I wish ya'll would leave things alone. GoodDay (talk) 01:59, 1 June 2018 (UTC)
Here we go again. Did anyone actually ask for this? Selecting "Desktop view" on my phone does absolutely nothing to get rid of this. I'd like a way to have all the main functions (main/talk/edit/watch/history/move) back in their tabs in one click. If I want any of them on my smartphone, I just zoom in on them and then tap the screen, not try to interpret tiny icons. Double sharp (talk) 02:40, 1 June 2018 (UTC)
Don't know if this is related, but it seems to have just started together with this: the multiple images at my talk page won't fit on my mobile screen anymore and won't allow me to scroll to see the parts cut off. Samsung Galaxy Core Prime (SM-G360G), Android 5.1.1, 534×320 (landscape, although the same problem occurs in portrait), Samsung Browser 3.3 on Android (Lollipop). Double sharp (talk) 03:32, 1 June 2018 (UTC)
I logged in this evening and found myself looking at whatever this mobile skin is. Except I am definitely not using a mobile device. Please fix immediately. Thank you.
Lenovo ThinkCentre 700 desktop PC
Linux Mint 18.1 Cinnamon
1600x900 (zoom at 150%)
Firefox 60.0.1
The problem is on every page.
Sephiroth9611 (talk) 02:42, 1 June 2018 (UTC)
  • My devices are an iPhone 7+ and the iPad Pro 10.5" running the most current Safari version (under a beta; I'm on 11.4 public beta 2). 1920x1080 on the iPhone, 2224x1668 on the iPad. It isn't as bad on the iPhone (though again I'd love a text labels icon over the pinpoint-sized icons), but I use the iPad because it renders a page how it should on a desktop. I don't need it to render the 'mobile version' on that device. Nate (chatter) 03:19, 1 June 2018 (UTC)
  • How do we get the hell rid of this? I don't use Monobook for "responsive design", I use it for a familiar workflow that's now entirely broken. Please either revert this change, Isarra and MZMcBride, or at very least provide an opt out (that isn't "fiddle with your phone settings.") This is the same kind of tone deaf "You'll love it once it's rammed down your throat hard enough!" that WMF likes to pull every so often. Seraphimblade Talk to me 04:57, 1 June 2018 (UTC)
    • What has this got to do with WMF? By the sounds of it, this was an initiative entirely of volunteer developers. — This, that and the other (talk) 09:20, 1 June 2018 (UTC)
  • What the flying fuck, please get rid of this abomination on mobile NOW. If I ask for the desktop version while I'm on my phone, that's because I want the goddamn desktop version, not a crapfest of unusability buried 20,000 leagues deep under barely legible icons that convey little to no information.Headbomb {t · c · p · b} 08:48, 1 June 2018 (UTC)
Oh god, this affects the desktop view on desktops as well if you aren't in full screen mode. Revert this abomination ASAP please! Headbomb {t · c · p · b} 08:55, 1 June 2018 (UTC)
  • As so many others have said: How the hell do I get rid of this? The icons are invisible because I work with images off, and the useful text links are at the bottom of the page, which can be a long way down. If you wanted to create a new 'responsive' skin, that's what you should have done, not broken Monobook. BlackcurrantTea (talk) 09:55, 1 June 2018 (UTC)
    @BlackcurrantTea: how are you disabling images in your browser? When I tested with images disabled in Firefox, the icons still showed up. Legoktm (talk) 07:49, 2 June 2018 (UTC)
  • Legoktm, I was using a version of Firefox old enough to have a convenient prefs checkbox to disable them. (On a laptop, by the way, not a mobile device.) When I saw your mention here I tried to test it on the computer I'm using now, but you'd reverted the change, for which I heartily thank you. Please, please leave it reverted. BlackcurrantTea (talk) 08:37, 2 June 2018 (UTC)
Would it be all right if I sorted the responses here into... general buckets of what they are/are discussing? It would make it much easier for me to respond to stuff, pull out actionable items, etc. Also maybe help figure out what we should do with this moving forward, and such. -— Isarra 11:02, 1 June 2018 (UTC)
  • (ec) I'm sorry, but I am another person who thinks this change was very much for the worse, and it is impossible to get the old look back for me (iPhone 6s, Safari). Apart from the fact that the new design is considerably less useful for me than the old one which worked really well for me personally (so yes, why not create a new skin for people who do not like the old version, and allow those of us who to like it to keep using it?), I now can't see e.g. the full "Open for discussion" table at Wikipedia:Requests for adminship without flipping the phone into landscape mode, which I usually prefer not to do. This is certainly not intended behaviour. (By "can't see" I mean that it is too wide for the screen and the leftmost part of the table is cut off, so on my screen it starts with the "Support" column.) And that's in the desktop version on the mobile, not the mobile version, so I can't in fact "return" to the desktop version and fix it in that manner. --bonadea contributions talk 11:07, 1 June 2018 (UTC)

Issues/problems/questions

I'll try to address specific concerns here. If I've missed something, please feel free to add an item, or comment on anything here already. (Responses to specific things above also coming shortly, but I'd prefer if further issues etc are added below, as this will make them much easier to keep track of and address.) -— Isarra 12:12, 1 June 2018 (UTC)

On second thought, I can't follow the source of the above at all. I've tried to add all issues below. -— Isarra 13:56, 1 June 2018 (UTC)

Who asked for this?

Third-party MediaWiki sites, primarily. There is a serious lack of mobile support in the skins currently shipped with MediaWiki, and MobileFrontend often does not entirely meet their needs either. Making more of the available skins themselves responsive is a good step toward supporting their need for a mobile-friendly site for visitors.
I did enquire what people thought of this change here in april once I had the basic prototype, but no issues were raised and nobody objected at the time. -— Isarra 12:12, 1 June 2018 (UTC)

Opt-out methods not working

Mobile browsers have a browser option to request the desktop site - this works in firefox, but due to bugs in the browsers themselves, apparently not so much in safari and chrome.
There is a link in the page footer for 'Mobile view' or 'Desktop view' - this is a part of MobileFrontend, and has nothing to do with this change.
No way to opt-out on desktop - there may be browser extensions for this? I'm not sure. This is, frankly, a very unusual request. (If all else fails it might be doable to add a user preference, though? But that's apt to be very messy source-side, as mw isn't exactly built for these kinds of options either.) -— Isarra 12:12, 1 June 2018 (UTC)
Is this a response to me? If you thought I wanted the ability to opt out of seeing the Mobile/Desktop view links, then you've misunderstood me. (If not, then I guess I've misunderstood you, but that's the only thing I can think of that would qualify as a "very unusual request".) I mentioned the Desktop link because Legoktm said that one could opt out of the new layout by requesting the desktop site, and I wanted to point out that it didn't work no matter how I attempted to get the desktop view. What I wanted the ability to opt out of is the same thing everybody else here is talking about. MANdARAX  XAЯAbИAM 06:16, 2 June 2018 (UTC)
If a change is known not to work on common browsers, maybe don't introduce it? Or only introduce it on a new skin that people can choose to use if they want to. DuncanHill (talk) 12:29, 1 June 2018 (UTC)
But the new look is what is visible on the mobile after requesting the desktop site (Safari). It's the mobile version of the desktop site that has changed; the en.m.wikipedia version is the same from what I can tell (I always scroll down and click "Desktop" whenever I am redirected to the mobile site so don't have that much experience with what it is supposed to look like, exactly). --bonadea contributions talk 12:42, 1 June 2018 (UTC)
A bit clearer of an explanation for people: The new design doesn't actually switch on "desktop" versus "mobile", it switches on the effective viewport width being greater than or less than 850 pixels. On (some) mobile browsers, the browser's "Request Desktop Site" option forces the minimum viewport width to a value larger than 850px which is why it functions to bypass the new responsiveness in Monobook. Anomie 13:18, 1 June 2018 (UTC)
And the toggle on the bottom of the page is for MobileFrontend, which turns MF specifically on/off, regardless of viewport. We really need to make this less confusing, but for now that's how it is. -— Isarra 13:27, 1 June 2018 (UTC)

Issues with screen readers etc

This is definitely a bug. Could you please specify exactly which things aren't working? Which access keys, which labels, links etc. -— Isarra 12:12, 1 June 2018 (UTC)
@Isarra: The article/talk access keys don't work; the "edit this page" link (and it turns out all the others!) work fine. Graham87 16:50, 1 June 2018 (UTC)
@Graham87: Okay, thanks - can you try a hard refresh and let me know if that fixes it? -— Isarra 20:12, 1 June 2018 (UTC)
@Isarra: Nope, it doesn't. Graham87 03:34, 2 June 2018 (UTC)
Also, this is probably obvious but I'll say it anyway ... the access keys for the hidden elements don't work when they're hidden (by design). Having to unhide them first kinda defeats the purpose of the access keys as a quick navigation tool. Graham87 03:47, 2 June 2018 (UTC)
@Graham87: The problem here is I can't replicate this elsewhere, and if the mobile hiding is the problem, then none of them should be working, including talk, history, etc. Based on what this change actually does, the page-related access keys should either all work or none, so if some still work and others don't, this suggests that this may indeed be caused by something else entirely. (The other change? What was the other change?)
We're reverting this for now, but... agh. (Also, in general, are you saying that display: none on a parent disables accesskeys in general in screen readers? Because if so I may have a few other skins that definitely need fixing... )
Also thank you, seriously, for your specific feedback and bearing with us on this. Very helpful. -— Isarra 08:52, 2 June 2018 (UTC)
@Isarra: I can't replicate this problem here anymore (obviously), but I can replicate it on your prototype with the latest stable versions of both JAWS and NVDA, the two most popular Windows screen readers, in both IE and Firefox (again with the latest stable versions ... I had to hugely increase the zoom for the elements to be hidden there). Not sure if this was clear enough before (perhaps it wasn't!), but this is only a problem for me when the elements are hidden; they work fine otherwise. Maybe it's a display:none thing ... who knows? Graham87 09:50, 2 June 2018 (UTC)
@Graham87: Ah, thanks! That actually helps clarify a lot. Now I get what you're saying, and... yeah, this will definitely be fixed. -— Isarra 21:49, 2 June 2018 (UTC)

Uses icons instead of text for tab labels

Filed as phab:T196190. Legoktm (talk) 19:29, 1 June 2018 (UTC)
This is necessary because there are an arbitrary number of tabs with fairly arbitrary content across languages. The only way to make them fit on a set size is to set their size as well, and the only way to do that is to remove the text and replace it. The reason why they would now appear bigger is because they also have extra padding so they're easier to hit with random body parts that do not have the precision of a mouse pointer.
  • We cannot simply have them as text that wraps and moves the rest of the page content down because they are technically after the page content in the DOM.
  • A fallback for something to appear when the icons are disabled should be added. The problem is I'm not sure how to do that. Any ideas? This is important for a lot of things, frankly, not just (mobile) MonoBook. -— Isarra 12:12, 1 June 2018 (UTC)
The icons are not necessary, the tabs worked perfectly well before. Just bin this change. DuncanHill (talk) 12:29, 1 June 2018 (UTC)

Hides navigation and requires extra steps to find/use it

General workflow changes are to be expected when using different kinds of devices. However they should not be so significant, so if anyone running into issues here can describe exactly what you would do before, and then compare to after, that would be quite useful to improve the situation. -— Isarra 12:12, 1 June 2018 (UTC)
Well, before I would just do what I would do on my pc, all the tabs etc were in exactly the same place and looked exactly the same. I can't give you any screenshots because my Tardis is broken. Now, I have to work out what the icons mean, work out where some of them are hiding as they don't all show at once (see screenshot above), and I can't dismiss notifications without navigating away from the page I am on. DuncanHill (talk) 12:29, 1 June 2018 (UTC)
I know this is a long shot, but could I ask you to please try to bear with it for few of days, see what you think after you've had a chance to get more used to it, and then let me know what problems/things are still being specifically annoying at that point? I know this kind of came out of the blue, and I'm sorry about that, but Wikimedia's update deployments are a little... strange compared to how the sites I usually work with are (third-party mw sites tend to have actual versioning, as opposed to rolling-release updates), and I'm apparently still not very good at handling it appropriately. -— Isarra 13:27, 1 June 2018 (UTC)
I don't want to use it at all, certainly not get used to it. It's grim for reading, and awful for editing. Telling people to "get used to it" is not helpful. DuncanHill (talk) 15:01, 1 June 2018 (UTC)

WMF shoving things down users' throats

The WMF was actually against this, as they feared pretty much precisely this reaction, which just goes to show that they have learned from previous incidents. This, on the other hand, is a volunteer-driven initiative targeted more toward the needs of third-party MediaWiki users, with the understanding that nobody objected when I asked about it here earlier, so it was probably fine. -— Isarra 12:12, 1 June 2018 (UTC)
This might not have been the best place to ask. Next time try somewhere a little more public. DuncanHill (talk) 12:23, 1 June 2018 (UTC)
What's more public than VPT? -— Isarra 13:27, 1 June 2018 (UTC)
I'd expect suggested changes that are expected to affect a large majority of the Wikipedia community to be at least publicised by a watchlist notice and/or a link at Wikipedia:Centralised discussion. I'm not so tech-savvy that VPT is somewhere I go often; I mostly go here if something's not showing up right, whether because of recent changes or because the stuff on my .js and .css pages (all written by others) are not working properly. I'd expect this to be true of quite a few other Wikipedians. Double sharp (talk) 14:48, 1 June 2018 (UTC)
Quite so, I only come here when things don't work as expected, or I am baffled by something. DuncanHill (talk) 14:55, 1 June 2018 (UTC)
And if I was unclear in what I said, I didn't mean that this was WMF's idea. I said it was like the time WMF has pulled similar things, generally with very little notice (most people don't follow VPT, and even fewer read every discussion). For the vast majority of Monobook users, me included, this was just a sudden change with no explanation. I actually originally thought it was some kind of weird bug, and came here to see if anyone else had reported experiencing the same thing. I certainly did not expect to find that it was done intentionally. A proposed change like this, especially if it will not have an opt-out, should have first gone through a well-publicized RfC to see if the community wants the change to begin with. Seraphimblade Talk to me 17:23, 1 June 2018 (UTC)
What's more public than VPT? – I also do not think VPT is sufficiently "public". I'm a frequent editor but don't read VPT unless I'm following a discussion about a problem after it occurs. I'm only here now because I noticed the change to the skin and saw the watchlist notification. Mitch Ames (talk) 14:03, 8 June 2018 (UTC)
The WMF was actually against this apparently not against it enough to block promoting it to production... — xaosflux Talk 01:34, 4 June 2018 (UTC)

'Notifications' is just a link to Special:Notifications instead of a flyout with the actual notifications displayed

I have noooo idea what to do about this. Apparently Special:Notifications just doesn't entirely work, but we also can't use the usual echo flyouts on mobile because OOUI doesn't support mobile either. Um. -— Isarra 13:27, 1 June 2018 (UTC)

Previewing/fixing formatting problems for desktop/mobile from either device

This is a longstanding issue that's been brought up time and again - that mobile and desktop render differently, and people need to be able to preview changes on either regardless of which they're actually editing from. Having skins that responsively support both should improve the situation in that you can focus on the content itself more than the formatting, but... hmm, not sure if this helps, since indeed it does seem to kill the ability to zoom out and crap on a phone. -— Isarra 13:56, 1 June 2018 (UTC)
Wait, nevermind, that's what the 'Request desktop site' thing is for. Actual problem is that it only seems to entirely work in firefox. -— Isarra 13:58, 1 June 2018 (UTC)

Should have a tablet/small-desktop view

I think a tablet/small-desktop view, which hides the sidebar but still shows labels for the tabs, would be a good idea. I find this works quite well in Timeless. Why give users a phone experience if they're on a mid-to-large sized device or small desktop screen? - Evad37 [talk] 14:43, 1 June 2018 (UTC)
@Evad37: Main reason was because I didn't want to figure out how to make collapsible tabs because vector's implementation scares me and just making the cutoff wider sort of avoided the problem, but since people seem to feel a lot more strongly about this than expected, yeah. This seems definitely in order. -— Isarra 20:18, 1 June 2018 (UTC)

Not a problem, just an observation

I saw something about this on the Help Desk, and wanted to comment that when I start a new talk page topic, the line for the heading turns blue.— Vchimpanzee • talk • contributions • 20:59, 6 June 2018 (UTC)

I don't like it

Everyone who doesn't like this change please sign here.

  1. It is kind of dumb. -— Isarra 12:12, 1 June 2018 (UTC)
  2. It makes Wikipedia much harder to use on mobile, it forces people to have what is essentially a mobile view despite them asking for desktop. If people want a different skin for mobiles then make one, don't impose it on people. Kind of dumb is an understatement. I do appreciate that a lot of hard work went into it, and it was well-intentioned, but you know what they say about good intentions. Please get rid of it. DuncanHill (talk) 12:22, 1 June 2018 (UTC)
  3. Please get rid of it, or move it to a separate skin, or something. It really impairs functionality on the mobile. --bonadea contributions talk 12:45, 1 June 2018 (UTC)
  4. I was wondering why the Mediawiki skin wasn't rendering properly. Now I know why. Please revert, it's causing major problems. Cesdeva (talk) 14:01, 1 June 2018 (UTC)
  5. No one addressed my issue above about this change affecting an actual desktop user. So whatever you're doing, please revert until this is addressed. Sephiroth9611 (talk) 14:12, 1 June 2018 (UTC)
  6. Basically what DuncanHill said. Double sharp (talk) 14:43, 1 June 2018 (UTC)
  7. Get rid of it NOW. Either create a new skin, or don't enable 'responsiveness' without providing an opt-out/opt-in mechanism via preferences or something. Headbomb {t · c · p · b} 16:10, 1 June 2018 (UTC)
  8. Get rid of it for now, until there's an opt-out feature, for screen reader users. I also get this new view on a non-mobile device. Graham87 16:50, 1 June 2018 (UTC)
  9. Revert, or restore the original version and have them separate. Preferably immediately. —Xezbeth (talk) 20:50, 1 June 2018 (UTC)
  10. The mere fact that Graham87 (talk · contribs) is being denied their normal experience is a killer for this enhancement, and so on grounds of accessibility alone, must be reverted forthwith. We cannot assume that all our users can use a mouse - or even that they can see. --Redrose64 🌹 (talk) 21:49, 1 June 2018 (UTC)
  11. Change things back to the way they were. GoodDay (talk) 22:15, 1 June 2018 (UTC)
  12. This hasn't affected me, yet, and i don't want it to. Make it opt-in only. DES (talk)DESiegel Contribs 22:45, 1 June 2018 (UTC)
  13. This hasn't affected me either, as I use vector, but when you are making editing and even reading difficult for power users and blind people, it's time to revert and rethink. – Jonesey95 (talk) 03:12, 2 June 2018 (UTC)
  14. Ugg why oh why is this on by default for desktop?! pull this change back. — xaosflux Talk 03:49, 2 June 2018 (UTC)
  15. I agree with pretty much everything everybody above said. MANdARAX  XAЯAbИAM 06:20, 2 June 2018 (UTC)
  16. People keep talking about mobile, but I'm seeing it on desktop. With no warning, I suddenly can't find anything anymore. So I go looking, and I find some things and not others. Then on another computer, it shows up the way it used to. Huh? Eventually I figure out that it's determined by the zoom level, so as long as I don't need to make anything too big, I can have the controls where I know how to find them. There seems to be no relationship between the two control layouts, and it just toggles back and forth depending on the zoom. In what universe is this supposed to be an intuitive UI? --Trovatore (talk) 07:05, 2 June 2018 (UTC)
  17. I saw it on a laptop, and it made editing close to impossible until I switched to another skin. Any change of this magnitude should be opt-in, and the accessibility problems Graham87 mentioned are a dealbreaker. As I said above, if you want a 'responsive' skin, then create one. Don't break Monobook to do it. BlackcurrantTea (talk) 08:55, 2 June 2018 (UTC)
  18. Yesterday, when I went to Wikipedia on my laptop (I do not own a 'phone, so I don't know anything about or have any connection to mobile), I saw the new UI. I had no idea how to do anything on it other than search. I thought I was going to have to quit editing on the English Wikipedia. Kdammers (talk) 09:55, 2 June 2018 (UTC)
  19. I'm not fundamentally against a responsive skin, or icons, or anything to make the system more usable on mobile in general. For large parts of the world, mobile is the only way people access the internet, and they need to be supported. That said, there also needs to be a way for people to get the plain-old desktop version if they want it. I'm a power-user, and I've learned my way around the desktop U/I. When I'm on mobile, I generally find the mobile version to be annoying, because I no longer know where things are. -- RoySmith (talk) 16:32, 2 June 2018 (UTC)
  20. There's no need to dick around with Monobook for this. Make it a new skin. Seraphimblade Talk to me 07:04, 3 June 2018 (UTC)
  21. I use the desktop view on my mobile devices because the mobile view is shit and always has been. I prefer to have a page that won't fit on the screen to a view that is a complete pain to navigate. As an admin I see a constant procession of IPs and new users who think they have had to jump through hoops to get to the talk page (or get to talk to anybody). It is completely couterproductive for my mobile devices to default to the mobile view. If I wanted that I would set it, or use a different skin. Having said that, making the skin responsive on desktops might be useful to me. The only time I look at mobile view is to check what mobile users are seeing. Being able to do that just by shrinking the screen would be cool, but I definitely do not want this on mobile devices. SpinningSpark 15:36, 8 June 2018 (UTC)
  22. I also use desktop view on mobile devices. Having it (or worse, my desktop, as some point out above) essentially revert to mobile view with a "mobile view" link at the bottom for irony, would go against my stated preference, not to mention be a waste of JavaScript, with which the WP editing window is already bloated to the max. I'm tired enough of websites making the letters 5 cm tall when I'm browsing on a 720p computer screen (and also of having to switch off JS on my phone because WP won't go to desktop view if I don't enable cookies, which I'd then have to enable for all websites). WP doesn't need to join the club for the sake of satisfying the web design keyword of the week. DaßWölf 15:51, 8 June 2018 (UTC)

A different suggestion for implementation

Isarra has said above that a user preference to toggle on or off the "responsive" nature would be difficult. How about a different solution, then? Revert the "classic" Monobook to work as it did, and put the new version as a skin option in Preferences. It could be called "Monobook for Mobile" or something. That way, those who do like the changes can continue using them, those who don't get their Monobook as they already like it, third party Mediawiki users still get their "mobile Monobook", and...don't really see any downside? Seraphimblade Talk to me 17:19, 1 June 2018 (UTC)

See also this XKCD comic. This is 2018, responsive web design should be the standard, not an opt-in. If we do end up forking monobook, the old (non-responsive) version should be called something else (perhaps "throwback") and responsive monobook shipped along with MediaWiki to third parties. For folks that want to opt-out of responsive design, they would then be free to switch the skin to the forked version in their preferences. It is going to be impossible to please everyone, but we must be forward thinking in terms of the MediaWiki software design, and a small but vocal minority of those who would rather be stuck in 1999 cannot hamper progress. This is not to say the current iteration of responsive monobook is perfect, and if you have found issues which hamper your experience with the skin beyond "I don't like it because it's different", then please let us know about it. These are the things that need to be discovered and addressed in order to make the skin work great in mobile as well as desktop. Unfortunately, it's difficult to uncover all of these issues beforehand given the various workflows that people have, so if you bear with us during this teething process and offer constructive feedback and criticism, the skin will come out better for it :). Unfortunately, forking monobook into a throwback version is not free; it adds maintenance burden to the WMF as they now have one additional skin to test against and ensure it remains up-to-date and secure. Ideally, those who detest responsive monobook can figure out what real issues they have with it (versus feelings or knee-jerk reactions against change) and report them so they can be looked into and resolved, and we end up with responsive monobook as the only monobook at the end of the process. --Skizzerz (talk) 20:16, 1 June 2018 (UTC)
There have been plenty of valid issues given. Your response is patronising and dismissive of the real problems listed above. It makes Wikipedia harder to use. It's not a "knee jerk reaction" to object to a degradation of service and function. DuncanHill (talk) 20:31, 1 June 2018 (UTC) More - To dismiss the complaints as a case of "I don't like it because it's different" shews that you either haven't read the problems above, or you simply do not care about user experience. I am appalled at your comment. You should not be involved in dealing with volunteers if that is your attitude to us. DuncanHill (talk) 20:34, 1 June 2018 (UTC)
I am a professional software developer. If I responded to client complaints about a UI change as Skizzerz did above, I would be promptly out of a job, and rightly so. (Hint.) I fully agree with DuncanHill here. This sort of major UI change should never be imposed with little or now warning except oin an opt-in basis, particualry when doing it instead as a new varient skin would apparently have been simple. DES (talk)DESiegel Contribs 22:44, 1 June 2018 (UTC)
@Skizzerz: Here's the issue with the "responsive" skin: it's responsive. This is a negative-value feature and no amount of "fixes" and "improvements" will ever change that. People who use monobook, as opposed to say vector, use monobook because it's the power editor skin. All the features we want are exposed there, directly. Not buried in 482 layers of unrecognizable icons spread over 47 submenus. Headbomb {t · c · p · b} 22:58, 1 June 2018 (UTC)
@Skizzerz: I will echo DESiegel's comment that if I treated the users of my software in the dismissive and sarcastic way that you've done here, I would swiftly be out of a job (and yes, I do it professionally too, and have for over a decade now). Rather, I treat those users as valued partners, since at the end of the day, the software I write means nothing at all if the people who use it cannot get done with it what they want to get done. I do understand that you feel attached to what you've written, but your dismissive citation of an xkcd cartoon (and by the way, I have read xkcd every Monday, Wednesday, and Friday morning for years now, and yes I saw that one) as some kind of justification doesn't say much for you. Yes, all changes break something, but that doesn't mean all changes that break something are by definition good ones. I would challenge you to specifically refute what I've asked here, to put "Monobook" and "Monobook Mobile" as separate skins. I can see no downside to that, aside from perhaps as you said some additional maintenance costs, but well, you made these changes, so if the additional maintenance isn't worth it, revert them back. When a substantial proportion of your users wants the "classic" or "legacy" functionality, you do need to maintain that until and unless you convince them that what's newer really is better. Seraphimblade Talk to me 00:23, 2 June 2018 (UTC)
@Skizzerz: Question: is there any argument at all for responsive web design for WP besides "it's 2018 and all the cool kids are doing it?" Surely we should at least ask ourselves why the cool kids are doing it and if their situation is applicable to ours. I rather find that no, it really isn't. The simple fact of the matter is that contributing seriously to Wikipedia is quite different from contributing seriously to a lot of other sites: you can't just write what you think, because that is going be non-neutral original research. Being a serious WP editor is not that easy and you will end up using pretty much all the sidebar and header tools all the time, and I do not think that any change that hides them is an improvement. If anything I think it would make it more difficult for readers to become editors (and that is already difficult enough as it stands). Double sharp (talk) 03:27, 2 June 2018 (UTC)
Going to try to respond to all of the above in one go (if you couldn't tell, I don't visit here much).
@DuncanHill: I am not trying to be dismissive of any of the issues already raised which are actually issues, of which there are quite a few in the sections above. This kind of feedback is very valuable and I encourage people to keep raising these sorts of issues. For example, from the feedback above it's pretty clear that the iconography could probably use more work to be clearer, the breakpoints could be re-evaluated so that it breaks only on lower resolutions (perhaps with the introduction of a tablet-friendly view so it doesn't go straight from desktop to phone), the thing with screen readers and access keys not working is a major issue, the orange is odd/confusing, and so on. All of these are valid issues, and if people see more things like that, they should by all means report them. The types of feedback that is not useful or at all helpful is neatly encapsulated in Headbomb's comment above. That type of feedback is entirely useless and pointless, and would be promptly ignored if I was in charge of the project (I'm not; I just happen to be friends with Isarra -- I haven't contributed anything to the project itself as of yet). You don't like it because it's different? Keep it to yourself, we don't need to hear it. You don't like it because there are actual issues that impact its usability or aesthetics? Let us know so we can work with you to address them.
@Double sharp: The applicability of responsive design stems from the increasingly larger percentage of users who browse Wikipedia with their mobile devices as days go by. The existing mobile site (MobileFrontend) largely goes about solving the issue in the wrong manner. By having an entirely separate mobile skin, features which editors or power users may need are simply nonexistent, whereas if we made a desktop skin responsive those features would still be present (albeit perhaps behind a menu in order to ensure the content is given top priority for screen real estate). As an example, the MobileFrontend skin makes it impossible to view the diffs between non-adjacent revisions, so if one user makes 5 edits in a row you cannot easily see the full diff combining those 5 edits. However, in a responsive skin, those features would still be present in some fashion as the same skin is serving both mobile devices and desktop users. For things such as checking up on vandalism on the go, these sorts of features are invaluable even though they don't impact the vast majority of users (hence why MobileFrontend doesn't support them).
@Seraphimblade: It is not my decision to introduce this as a second variant of the skin. Should that discussion come up, I will fight as hard as I can to make responsive monobook the default one, and have the non-responsive one introduced as a separate skin that people can switch to if they absolutely hate the new monobook. Your "substantial proportion" is less than a fraction of a percent of all users of monobook across all wikis, and English Wikipedia's community does not and should not have any say over what MediaWiki as a whole serves to 3rd party users. We ship monobook along with the tarball, so forcing those 3rd party users who have been asking for responsive skins for years to go out and download one separately instead of bundling it and automatically upgrading their wikis to use it once we do ship it is only doing them a massive disservice. The English Wikipedia's community does and should have absolute say over what happens to English Wikipedia itself, so if the community really wants the skin to be forked, that will be a decision the WMF will need to weigh and perhaps implement. I think that decision is premature, however. Once the bulk of issues mentioned in the above sections are ironed out, that is the time to evaluate what the community really thinks about it. Causing riots due to an alpha-quality responsive skin is incredibly short-sighted. Now, you may have questions as to why an alpha-quality skin was deployed to English Wikipedia, and well, so do I. This probably should have been deployed to the test Wikipedia for a month or two to gather this sort of feedback rather than abruptly and without much advance warning deploying it to a production wiki.
@Lots of people: I'm a professional developer too. I'm not posting in a professional capacity. You are not my clients, I am not representing anyone but myself with my comment, and I am not being paid to sit here and type these words. I'm a volunteer who happens to have opinions on software design, and saw a colleague (who is also a volunteer) being raked over the coals by negative responses which had no business being that negative. So, I jumped in with a somewhat snarky comment asking for people to state the actual issues they have (for the actual issues which exist, of which there are many), and for people who just want everything to stay the same for 20 years without any attempts at improvement to either go away or stop being curmudgeons and offer constructive feedback instead so that we can move forwards as a platform and as a community. If you want my respect, start respecting the efforts of other volunteers, and work with them instead of attacking them. --Skizzerz (talk) 18:26, 2 June 2018 (UTC)
@Skizzerz: In order to work on the layout of WP articles, and ensure that they look good on desktop as well as on mobile, we need a mobile view that matches the desktop view in this respect, instead of one that (like the current one) makes all images take the entire screen width. We also really don't have enough room on mobile to have all the tabs, sidebar links, and top links without making the text a lot smaller, but these need to be directly accessible to be really useful. But once we keep those the same as the desktop view, don't we essentially have the desktop view already? Even just adding references on a smartphone is time-consuming and pretty painful already, and we don't need to make things even more painful by requiring more clicks and possible loading time at each step along the way to doing small edits that are still practical on smartphone. Double sharp (talk) 16:02, 5 June 2018 (UTC)

Oddly enough, one gets the previous display restored via reducing 'font size' to 150%. But, I'm used to having my fonts at 175% GoodDay (talk) 11:55, 2 June 2018 (UTC)

@Skizzerz: Re:"Keep it to yourself, we don't need to hear it." This change was forced upon on me/us, with no way to opt out, so yes, you/the devs do need to hear it. More importantly, this change needs to be reverted, and promptly so. Which apparently it was.Headbomb {t · c · p · b} 18:32, 2 June 2018 (UTC)

Skizzerz (talk · contribs · deleted contribs · logs · edit filter log · block user · block log) "You don't like it because it's different? Keep it to yourself, we don't need to hear it. You don't like it because there are actual issues that impact its usability or aesthetics? Let us know so we can work with you to address them." I have been telling you actual issues that affect its usability and its aesthetics. I am a vastly more active editor on Wikipedia than you are, so I think I have rather more right than you, who hadn't edited here in over 6 years before your patronising post above, to say that something degrades usability, and I think you would do well to defer to people who actually edit this Wikipedia on such issues. If you want our respect Skizzerz try being a productive editor rather than someone who just turns up to be snide and ignore genuine issues. DuncanHill (talk) 18:48, 2 June 2018 (UTC)
(edit conflict) @Headbomb: There was a way to opt out: it was the "request desktop site" feature of your mobile browser. This apparently didn't work on iOS (and also impacted actual desktop users who didn't fullscreen their browsers), so reverting seems a sensible course of action while those issues as well as the other issues raised above are addressed. As I mentioned in my reply above, I don't think this should have been deployed here as-is, rather it should have been on test Wikipedia for a couple of months to gather this sort of feedback in a non-production environment. The skin will continue to be worked on and these issues addressed, and hopefully the deployment process for it next time will be more sensible and with more advanced notice. To come back to what you were actually responding to, a good feedback would be "The opt out isn't working" or "I don't see a way to opt out" or "It's showing the phone version when I'm on my desktop with the browser window still large but not full-screen" rather than peppering it with swears, calling it an abomination, and other inflammatory remarks. @Duncan: Wikipedia is not the world, and is not the only wiki running the MediaWiki software. We are both volunteers, you have exactly zero more and zero less rights than I do. I honestly do not care one whit about Wikipedia, as my focus areas are more towards supporting 3rd party MediaWiki instances, and I have made numerous contributions in that area, just as you have made numerous contributions here because presumably you care about Wikipedia and this is one of your focus areas. The size of my e-penis edit count compared to yours here has absolutely no bearing on the validity of all of the above statements I made. I was not accusing you of not pointing out issues in a constructive manner; my initial comment did not name any names or call anyone out. My follow-up to you specifically in fact noted that a lot of the issues that you and others raised were in fact "valid issues" according to my original comment, to make it clear that I was not flippantly discarding everything said in the above sections. I am not "ignoring" genuine issues. I was asking everyone to have less grar and derogatory comments so that the genuine issues could stand out so they can be addressed. --Skizzerz (talk) 18:58, 2 June 2018 (UTC)
No, "request desktop site" was not a way to opt out of this. This affected the desktop versions as well, both when seen from a phone, or from a desktop. Headbomb {t · c · p · b} 19:00, 2 June 2018 (UTC)
Holy hell, this guy doesn't even have 25 edits on Wikipedia this is how he talks to power users? Headbomb {t · c · p · b} 18:54, 2 June 2018 (UTC)
@Skizzerz:You certainly shouldn't dismiss the concerns of people who do a lot of editing and who have told you that these changes make editing harder when you do not have any real experience to base your dismissal on. If you are telling the truth when you say you don't care about Wikipedia then you really shouldn't be diving into discussions like this, especially when you mischaracterise the contributions of others and fail to respond to genuine concerns. DuncanHill (talk) 19:08, 2 June 2018 (UTC)
I’d appreciate if we could stick to the problems instead of discussing the people. —TheDJ (talkcontribs) 19:57, 2 June 2018 (UTC)
We were doing that until Skizzerz turned up with his dismissive and patronising posts. DuncanHill (talk) 22:07, 2 June 2018 (UTC)

I am finding it difficult to understand why this has been a problem for third party users. If they don't like the non-responsiveness of monobook then they don't have to install it on their system. After all, monobook has not been the default skin here for many years; it is not essential for third parties. If they are asking for a monobook-like skin that is responsive, then as several editors have already suggested, develop a new skin that does that for them. Don't mess with the skin the grognards are using. By definition, they won't like it. SpinningSpark 15:44, 8 June 2018 (UTC)

Revert this

T196212 I've created a request to revert this change in phab:T196212. Feel free to subscribe and continue to comment on it. — xaosflux Talk 03:55, 2 June 2018 (UTC)

I wrote a much more elaborate post on Phabricator, but I've temporarily reverted this for now due to some of the accessibility problems mentioned above. Legoktm (talk) 07:44, 2 June 2018 (UTC)
Thank you thank you thank you. Please do not revert back - please. --bonadea contributions talk 07:50, 2 June 2018 (UTC)
Please do revert back, and then implement this properly: As an opt-in change for those who want it, not a forced change for those who do not. Seraphimblade Talk to me 10:00, 2 June 2018 (UTC)
Right, as an opt-in change it would be excellent. Just not this forced change for those who are hindered rather than helped by it. --bonadea contributions talk 10:17, 2 June 2018 (UTC)
So, Legoktm, note that the revert ticket included "and consensus". You have indicated neither on the Phabricator ticket nor here why it would be somehow impractical to keep in place the Monobook functionality which has been working for over a decade along with whatever shiny new toy is supposed to replace it. But let's be clear: If there's really a choice between the venerable, well-loved, widely used Monobook and the shiny new toy, it is the toy, not the well-loved and well-used version, that must be discarded. Seraphimblade Talk to me 10:42, 2 June 2018 (UTC)
At that time I hadn't tried to see how much work it would be to support both. It turned out to be reasonably possible to add in a user preference to control the responsiveness. In general we try and avoid adding in new preferences/conditionals like this, but I think we'll be able to deal with the extra maintenance burden in the future. Legoktm (talk) 08:51, 7 June 2018 (UTC)
And apparently phab contributors think they don't need any community consensus to push this on us (having removed a community consensus project tag)? It is bad enough when staff push an unwanted change, now we have to fight with volunteers too? — xaosflux Talk 17:38, 2 June 2018 (UTC)
Well that's correct...ish. Generally, individual technical changes don't go through any form of community consensus review, and on the scale of things, this was only supposed to affect people who use the MonoBook skin on mobile devices, which is a pretty small set of people. But that didn't work out as planned due to the mobile breakpoint triggering for people with high zoom levels on laptop/desktop devices, and that we only started announcing and socializing the change a bit too late. Legoktm (talk) 08:42, 7 June 2018 (UTC)
What does "socializing the change" mean? DuncanHill (talk) 20:04, 7 June 2018 (UTC)
Because of my background I could understand this to mean: developing/documenting a capability, providing tech support, and publicizing the 'how to do it' to a community. --Ancheta Wis   (talk | contribs) 20:07, 7 June 2018 (UTC)

Wikipedia's font size.

Wikipedia's page display appear to go out of wack, when one has it set at above 150% font size. GoodDay (talk) 22:13, 31 May 2018 (UTC)

GoodDay, I think we're going to need more information. Which page? What web browser and operating system? How big is your screen? What does it look like when it's out of whack? Whatamidoing (WMF) (talk) 23:01, 31 May 2018 (UTC)
(edit conflict) "out of wack" is very vague for something depending on your skin, browser, window size, the specific page and other factors. Above 150% is a lot and it does not surprise me if something displays poorly. PrimeHunter (talk) 23:01, 31 May 2018 (UTC)
It just doesn't display the same, anymore. I can't explain it without showing what it looks like, which I can't do. An example: the 'Search' box, should be on the left of the screen, but instead is at the top. GoodDay (talk) 23:27, 31 May 2018 (UTC)
If your search box is usually on the left then you don't have the default Vector skin at Special:Preferences#mw-prefsection-rendering. I guess you have MonoBook and are seeing an effect of the new responsive MonoBook feature in the previous section. It will vary when it happens for different users. You can maybe also get it to happen at 100% or less by narrowing the browser window. PrimeHunter (talk) 00:41, 1 June 2018 (UTC)
Vector default, seems to be the closet to what I previous had. GoodDay (talk) 01:23, 1 June 2018 (UTC)
Would you consider trying to upload Wikipedia:Screenshots of Wikipedia? Or turn on an e-mail address for a few minutes and send me a note? I can reply, and then you could e-mail the screenshot to me. Whatamidoing (WMF) (talk) 18:25, 1 June 2018 (UTC)
This is connected to what's being discussed in the preceding discussion. GoodDay (talk) 22:12, 1 June 2018 (UTC)
I've had the same problem, with the same solution. Reducing the font size restores normalcy. Bus stop (talk) 07:00, 2 June 2018 (UTC)

Update, and opt-out details

Hi, here's an update. This is going to be redeployed today, as part of the weekly MediaWiki deployment train, with two important changes. First, as soon as it's deployed, you can go to Special:Preferences Appearance tab, uncheck "use responsive MonoBook design", and it'll revert to the normal desktop styles. Secondly, the threshold for devices being considered mobile has been lowered, so people with high zoom levels are less likely to even see it in the first place.

I hope that this resolves most people's immediate concerns (please let me know if it doesn't). There's a list of other bugs/proposed improvements listed as subtasks on Phabricator, as well as additional discussion behind these changes on that task. Legoktm (talk) 08:22, 7 June 2018 (UTC)

Why it opt-out instead of opt-in? DuncanHill (talk) 10:29, 7 June 2018 (UTC)
And, as noted above, this is not a widely-read noticeboard. Will there be wider publicity for this? DuncanHill (talk) 10:34, 7 June 2018 (UTC)
Do you have suggestions on where else this should be announced? Relatively speaking, this change should not affect that many users... Legoktm (talk) 19:05, 7 June 2018 (UTC)
MediaWiki:Watchlist-messages and MediaWiki:Sitenotice spring immediately to mind. WP:AN is also a good place to announce changes which are likely to confuse editors. VP:T isn't quite a disused lavatory with a sign on the door saying "Beware of the Leopard", but it's not Trafalgar Square either. Why is it opt-out instead of opt-in? DuncanHill (talk) 19:47, 7 June 2018 (UTC)
@DuncanHill: we are usually much more liberal with watchlist messaging then sitenotices, drop an edit request at MediaWiki talk:Watchlist-messages for discussion, if it gets support (or lacks opposition) we can spin it up pretty easily. — xaosflux Talk 19:50, 7 June 2018 (UTC)
Done. Why is it opt-out instead of opt-in? DuncanHill (talk) 20:02, 7 June 2018 (UTC)
Yes, why is it opt-out instead of opt-in? Since this is for Monobook rather than Vector, the people who are going to see it are mostly power editors, who will largely have no use for it. Double sharp (talk) 23:20, 7 June 2018 (UTC)
I suppose a more flexible question here would be, is the opting default something that can be configured per project? — xaosflux Talk 00:00, 8 June 2018 (UTC)
Opt-out or opt-in makes very little difference to individual users in the end, save that if it's opt-in, very few people will choose to opt-in since they won't even know it's an option (how often to you check your preferences to see if something new is out there). I don't care which of the two is chosen by whomever, for whatever reason, as long as those who don't want it don't have it forced on them. Headbomb {t · c · p · b} 01:25, 8 June 2018 (UTC)
Yes, but if it's opt-out, I imagine people will also not know for the most part how to opt out in the absence of a wider announcement than VPT, for exactly the same reason. DuncanHill's edit request at Mediawiki talk:Watchlist-messages will of course lead to a wide announcement, so this is likely to be less of a problem now. I nevertheless wonder how strong the correlation will be between high mainspace activity and opting out. Double sharp (talk) 05:03, 8 June 2018 (UTC)

"Watch this page" and "This is a Minor edit" tickboxes in Safari

Can anyone tell me why the "Watch this page" and "This is a Minor edit" tickboxes in the edit view no longer work in Safari. When I click on them they fill in (blue) but aren't ticked. So, for instance, when I finish an edit and click the "Watch this page" box, the page is not added to my watchlist (evidenced by the star in the top right not being filled in). Shhhnotsoloud (talk) 09:33, 1 June 2018 (UTC)

its a Safari bug, there is a ticket in phabricator and a bugreport on webkit/safari too. Ppl are looking vot solutions. Luckily, they still work, its just the checkmark that is missing —TheDJ (talkcontribs) 10:56, 1 June 2018 (UTC)
Seems like a workaround (removing the animation for all browsers) was implemented and it should arrive next week. —TheDJ (talkcontribs) 12:45, 1 June 2018 (UTC)

@TheDJ: Thanks! Shhhnotsoloud (talk) 06:14, 2 June 2018 (UTC)

Anti-vandalism bots and the bot flag

From User:ClueBot NG/FAQ#Edits:

Anti-vandal bots do not perform precise, exact work like most other bots do. They act more like humans, with most edits correct and good, but a small percentage of mistakes. Bot edits show up as (unflagged) human edits so they can be reviewed for possible mistakes if necessary, like other human edits.

And yet I still don't want to see them when I filter my watchlist. ¯\_(ツ)_/¯ What then was the point of all the effort spent on improving watchlist filtering?  — Scott talk 11:24, 1 June 2018 (UTC)

If you don't want to see ClueBot, you can follow WP:HIDEBOTS. Headbomb {t · c · p · b} 16:13, 1 June 2018 (UTC)
Respectfully, that's both a non-solution and is terrible. Firstly, it doesn't appear (I haven't tried it) to provide a visibility toggle, but a permanent hiding, which makes it technically inferior to the watch list's built-in functionality. It's a kludge. Secondly, it relies on the user being a technical type, along the lines of you and I, who's capable and willing to implement it on our own behalf. That's exactly the kind of hostility to general users that the gradual overhauling of MediaWiki's interface is supposed to be doing away with. I'm perfectly capable of installing yet another technical doodad myself, but I'm not raising this purely on my own behalf. The lack of bot flag on these bots affects anyone who uses their watch list, and it's not proportionate or contemporary to impose this addition technical burden on them to cope with a deliberate exclusion of the bots from an improved part of MediaWiki's capabilities.  — Scott talk 15:21, 3 June 2018 (UTC)
So far the community has deemed ClueBot edits to be something that should not use the botflag to be hidden from editors, per the rationale you've pasted above. WP:CCC, of course, and you're welcomed to create an RFC on the issue, but if you want a solution to your problem, you have one. Headbomb {t · c · p · b} 22:40, 3 June 2018 (UTC)

Can't disambiguate a link

Resolved

In Portal:British Army/Selected unit/8 there is a link at the bottom which says "Read more..." and which links to the disambiguation page Intelligence Corps. It should link to Intelligence Corps (United Kingdom). I cannot see how to fix this. Could anyone help please? DuncanHill (talk) 12:05, 1 June 2018 (UTC)

Scrub that, worked it out. DuncanHill (talk) 12:07, 1 June 2018 (UTC)

Potential replacement for Template:Rp

FYI: Pointer to relevant discussion elsewhere.

The new improvement to <ref>...</ref> proposed at meta:WMDE Technical Wishes/Book referencing/Call for feedback (May 2018) would obviate the need for the {{Rp}} template, as well as provide various other enhancements. The discussion is presently swamped by people who just don't like fully-inline citations and only want to use {{sfn}} and page-bottom referencing, but this is a false dichotomy. The discussion isn't about which citation style is better (the answer to that is "it depends on the article"); the question is whether this feature would be good to have for referencing that is fully inline, and the answer is clearly "yes". I would be delighted if my old {{Rp}} template was finally superseded by an actual (and more tidy) feature of MediaWiki itself.  — SMcCandlish ¢ 😼  22:04, 1 June 2018 (UTC)

This won't replace {{Rp}}, it will just produce yet another citation style. {{3x|p}}ery (talk) 22:09, 1 June 2018 (UTC)
Nah, I would WP:TFD {{Rp}} myself as redundant after it's implemented.  — SMcCandlish ¢ 😼  04:22, 2 June 2018 (UTC)

Hundreds of broken talk archives

Resolved: Fixed by Cobi. Bradv 01:06, 3 June 2018 (UTC)

I came across several hundred talk pages that use the User:ClueBot III/ArchiveThis without the required "archiveprefix" parameter. According to the documentation this is supposed be okay, but yet the archive boxes on these talk pages are filled with links to unrelated pages, and the actual archives are nowhere to be found.

I made a list of all the affected talk pages User:Bradv/ArchiveFix. I'm not sure if my proposed fix actually works, as I tried one and it appeared to have no effect.

Could someone familiar with the inner workings of ClueBot please weigh in? I posted a message at User_talk:ClueBot_Commons#Hundreds_of_broken_talk_archives but I'm not sure how active that page is.

Please note this is also happening to user talk pages, although I have not attempted to index those. Here's a diff from a few minutes ago where ClueBot wiped out the archive index and replaced it with bogus data. Bradv 04:34, 2 June 2018 (UTC)

Regardless of whether there is a configuration issue at play, ClueBot is clearly misfiring. Bradv 05:36, 2 June 2018 (UTC)

Search Index

Hi all,

So I made a page about 2 months ago. The page was reviewed by a patroller on May 29, as you can see here. [[1]] For some reason it still doesn't appear on Google searches. Does anybody know why? I'm a bit concerned because other pages I created that were reviewed didn't have this long of a lag time before appearing. Thanks in advance. Wikiman5676 (talk) 20:03, 2 June 2018 (UTC)

Dharma Bum Temple is the third Google hit for me on Dharma Bum Temple. I'm in Denmark. Google's cache says their current snapshot is from 2 Jun 2018 20:12:20 GMT. That's nine minutes after your post and may have been triggered by an edit [2] at 20:08. I don't know whether they had it indexed before. PrimeHunter (talk) 20:46, 2 June 2018 (UTC)
Wow so all i had to do was edit it once after it was reviewed? haha thats so funny. I'll remember this for future pages. Thank you for pointing that out, i appreciate it. Wikiman5676 (talk) 21:02, 2 June 2018 (UTC)

Introducing Toolhub

What does your participation on the Wikimedia projects look like? Do you edit articles? Upload files? Patrol vandalism? Translate articles? Translate interface messages? Do you organize people, online or offline? Do you train new editors, or new trainers? Do you write code?

There are many different ways to contribute to Wikimedia – more than you would expect just from reading Wikipedia articles. Over the past several years, volunteers have developed technical tools that help Wikimedians improve content, patrol vandalism, and perform many other tasks. They make it possible to do what the wiki software alone cannot accomplish. Without these tools, many of our projects would slow down to a crawl.

I am very happy to announce a new project called Toolhub which seeks to create a searchable index of these tools in all languages. We are building this tool catalog based on what our communities need. If you would like to help, please take a look at m:Toolhub and review the question at the top of the page. You can also leave feedback in any language on the talkpage. You can also email me private feedback. Harej (WMF) (talk) 23:23, 2 June 2018 (UTC)

Thanks, Harej (WMF). This looks good and needed. -- GreenC 23:17, 3 June 2018 (UTC)

Searching logs

I wanted to find versions of an article that have been deleted, and went to the deletion log and put in the first word ("Novotech") that all the pages had. This pulls up Novotech which is fine, but I know there was also Novotech (Australia) Pty Limited and if I put that in, it finds that. There were two other ones, I think. I tried the typical wild card searches, adding a * or ~ at the end, but these searches came up null. Is there any kind of fuzzy search for logs? Jytdog (talk) 17:03, 3 June 2018 (UTC)

Special:Log needs an exact page name. Administrators can search a string in the title of deleted pages at Special:Undelete. I see: Liquid Glass Nanotech (not an exact match but shows up), Novotech, Novotech (Australia) Pty Limited, Novotech Australia Pty Limited, Novotech Clinical Research, Novotechip. PrimeHunter (talk) 22:31, 3 June 2018 (UTC)
Thanks User:PrimeHunter. For me it would be useful to have fuzzy search capability in logs. Do you (or anybody else) see downside to that? Would it be worth asking the software people if this can be done? Jytdog (talk) 23:06, 3 June 2018 (UTC)
A search of Special:Log search at phab: finds many similar requests, e.g. phab:T120764 which lists some of the others. PrimeHunter (talk) 23:20, 3 June 2018 (UTC)
I see. Thanks. Jytdog (talk) 23:27, 3 June 2018 (UTC)
This can be done through Quarry, e.g. quarry:query/27387. It's relatively slow - that query took about two minutes. If you run your own (terse instructions here), be aware that log_title uses underscores instead of spaces, and doesn't include the page's namespace. —Cryptic 23:34, 3 June 2018 (UTC)

{{DEFAULTSORT:}} and the default sort key

Currently, when {{DEFAULTSORT:<sort key>}} is used, the page is no longer found, in a category, at the default sort location but instead is found as sorted by the sort key used. How was it decided that it should be removed from one location to be listed at another? It seems intuitive to me that it should instead be listed in categories at both locations. Does anyone agree, or disagree, and how much of a technical challenge would it be to modify {{DEFAULTSORT:}}'s behavior to achieve the dual placement in categories such as I am suggesting here? Thank you.--John Cline (talk) 21:51, 3 June 2018 (UTC)

In a category, any given page will only be listed once. This has always been the case. If a page seems to be listed more than once, a maximum of one of them will be the page itself, all the rest will be redirects. See for example the first seven entries at Dodds - the spellings differ by one or two letters, they are different pages. --Redrose64 🌹 (talk) 22:15, 3 June 2018 (UTC)
I understand. The problem, as I see it, is that no redirect can be created form the default location because, of course, the page already exists. It just seems counter intuitive that using {{DEFAULTSORT:}} effectively means the one place a page will never be listed at is the default location of its common name title; the one place, above all, where it probably should appear. A work around would be to not use {{DEFAULTSORT:<sort key>}} on the page so it appears at its default sort location, and create an {{R from sort name}} redirect, ensuring to add the categorization used on the target page (since redirects do not inherit the categorization of the target page which they probably should) so it also appears in the category at the sort key location. I'd prefer, instead, to see the behavior of {{DEFAULTSORT:}} changed than to depreciate its use.--John Cline (talk) 23:21, 3 June 2018 (UTC)
Considering it's called "DEFAULTSORT" and not "ALTERNATIVESORT", the existing behavior makes complete sense to me. MediaWiki currently does not allow a page to appear more than once in a category. Anomie 23:31, 3 June 2018 (UTC)
I don't want many categories to list twice as many titles with half of them duplicates. And placing redirects with similar names in the same category as the target should very rarely be done. We have a search box if people are looking for a specific article. PrimeHunter (talk) 23:35, 3 June 2018 (UTC)
According to Wikipedia:Categorization, the central goal of the category system is to provide navigational links to Wikipedia pages .... Why would anyone prefer processes that undermine that central goal? In effect, you are saying: go somewhere else if you are desirous of navigational links to Wikipedia pages.--John Cline (talk) 00:04, 4 June 2018 (UTC)
I think few people would prefer your system as default but you could make a phab: request for a user preference. I don't think it would be implemented though. To reduce confusion it would require a way to distinguish the two listings. Italics are used to indicate redirects so something else would be needed. PrimeHunter (talk) 00:16, 4 June 2018 (UTC)
@John Cline: Please give examples of pages that would benefit by being listed twice in the same category. --Redrose64 🌹 (talk) 07:14, 4 June 2018 (UTC)
I am literally on my way out the door; almost late, as it is. Off the cuff, John F. Kennedy and Bruno Mars, I'd say. Cheers.--John Cline (talk) 11:42, 4 June 2018 (UTC)
Which category should list these people twice? --Redrose64 🌹 (talk) 22:38, 4 June 2018 (UTC)

Deformed pie chart

pie chart at the top of Irreligion in the United Kingdom

Does the pie chart at the top of Irreligion in the United Kingdom look deformed to anyone else, or is it just me? DuncanHill (talk) 02:12, 4 June 2018 (UTC)

Deformed how? It looks correct to me. Chris857 (talk) 03:23, 4 June 2018 (UTC)
Me too. {{pie chart}} looks like it invokes some serious black magic, though. What browser/version/os/etc? Do the examples at {{pie chart}} and/or {{Graph:PieChart}} look ok? —Cryptic 03:29, 4 June 2018 (UTC)
Looks very slightly egg-shaped to me. I'm using chrome version 67.0.3396.68 on Android 7.0. It's perhaps an optical illusion though, as it is very slight. Cesdeva (talk) 08:27, 4 June 2018 (UTC)
Yeah, it looks slightly taller than wider. Mainly though it is horrifyingly rasterized.. Galobtter (pingó mió) 08:40, 4 June 2018 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── I've uploaded a screenshot. The ones on {{pie chart}} that Cryptic linked above also display badly. Edge on Win 10. Same problem with Chrome on Android on my phone. It appears to be an issue with the blackscreen gadget, as when I switch that off they display ok. DuncanHill (talk) 11:01, 4 June 2018 (UTC)

Yes, that is caused by "Use a black background with green text" (example) at Special:Preferences#mw-prefsection-gadgets. {{Pie chart}} uses background-color and the gadget changes background colors. Many things will work poorly with the gadget but you can try posting to MediaWiki talk:Gadget-Blackskin.css. PrimeHunter (talk) 12:32, 4 June 2018 (UTC)
Interestingly, the example at {{Graph:PieChart}} shews the pie chart correctly, but the text in the key is black, so invisible on a black background. DuncanHill (talk) 13:07, 4 June 2018 (UTC)
{{Graph:PieChart}} doesn't use background-color. It uses mw:Extension:Graph to produce a transparent png image with black text and a colored graph. It's assumed the image will be shown with a light background but the gadget makes a black background. The produced image gets class="mw-graph-img" so maybe the gadget could be tweaked to consider this. PrimeHunter (talk) 13:47, 4 June 2018 (UTC)
So there's been a known problem with thumbnails, galleries, and more, because the original blackskin just clobbers all styles. Fixing it requires me to dig into Monobook and Vector styles. When done, I can order and receive packages from Amazon before an admin copies the changes. That frankly zaps motivation to work on it. — Dispenser 04:14, 5 June 2018 (UTC)

Beginning of text too close to the top of the page

This must have been a recent change, but wow, it looks strange. I recall even just a week or so ago, there was more space between the "From Wikipedia, the free encyclopedia" at the top of every page and the next line of text below it. Where/why was this change made? And, if I can, I'd like to propose the change be reverted. Steel1943 (talk) 17:48, 4 June 2018 (UTC)

I agree! It looks crowded and confusing. NotARabbit (talk) 17:55, 4 June 2018 (UTC)
Yeah, there is a small problem there. I left a comment at the ticket that I suspect introduced the problem. —TheDJ (talkcontribs) 20:15, 4 June 2018 (UTC)
See also MediaWiki talk:Gadget-metadata.js#spacing. --Redrose64 🌹 (talk) 22:42, 4 June 2018 (UTC)

Mobile view

Is there any particular reason why mobile view is the default view for tablets? 78.16.209.113 (talk) 19:30, 4 June 2018 (UTC)

Is the beta wikitext editor abandoned?

I am using the beta source editor.

The editor often doesn't load, and I click the "reload the page" link to get it to work. When creating a new page, though, it does load, and is not very useful: it has no toolbar buttons except the "switch to visual editing" button, which is broken. Is this getting fixed, or has it been abandoned and I should give up on using it? Thanks. —{{u|Goldenshimmer}}|✝️|they/their|😹|T/C|☮️|John 15:12|🍂 21:52, 4 June 2018 (UTC)

Also, when I click Edit link, it shows a loading indicator *in* the page, but the browser stop button is not available, so the page is only loading inside it. This prevents stopping loading editing, which loading can take a good half minute, and renders the page unreadable while it loads, as well. How can I get this to be a normal link, instead of whatever JavaScript abomination it is? (I use the MinervaNeue theme.) Thanks. —{{u|Goldenshimmer}}|✝️|they/their|😹|T/C|☮️|John 15:12|🍂 22:07, 4 June 2018 (UTC)
@Goldenshimmer: What web browser and operating system do you use? --Izno (talk) 22:23, 4 June 2018 (UTC)
Izno Mozilla Firefox 60 in Gentoo GNU/Linux. —{{u|Goldenshimmer}}|✝️|they/their|😹|T/C|☮️|John 15:12|🍂 22:29, 4 June 2018 (UTC)
I took a picture of it
Screenshot 2018.06.03 14.59.00 cropped
. —{{u|Goldenshimmer}}|✝️|they/their|😹|T/C|☮️|John 15:12|🍂 22:52, 4 June 2018 (UTC)
Can you give me the URL that's in that screenshot? It appears to begin https://en.wikipedia.org/w/index.php?title=Tods_shoes#/e but I'm not sure what follows. Whatamidoing (WMF) (talk) 00:44, 5 June 2018 (UTC)
Whatamidoing_(WMF): I think it was https://en.wikipedia.org/w/index.php?title=Tods_shoes#/editor/0. I just made a similar page, which exhibited a similar button deficit in the editor while creating, and the URL for that was https://en.wikipedia.org/w/index.php?title=Tods_Shoes#/editor/0. —{{u|Goldenshimmer}}|✝️|they/their|😹|T/C|☮️|John 15:12|🍂 00:55, 5 June 2018 (UTC)
Thanks. What you're seeing is the regular mobile editor. File:Switching edit modes on Mobile Web 2014-11-04.png is a little out of date (the menu shown in this screenshot has changed since 2014), but that's the editing environment you're getting.
Can you please confirm that Special:Preferences#mw-prefsection-betafeatures says that you have the "New wikitext mode" enabled, and tell me what Special:Preferences#mw-prefsection-editing says about the visual editor and its "Editing mode" (e.g., one tab or two)? Also, have you tried this in a different web browser or kind of computer? Whatamidoing (WMF) (talk) 02:03, 5 June 2018 (UTC)
Whatamidoing_(WMF), I have "New wikitext mode" checked, and "Editing mode" is set to "Show me both editor tabs". The current equivalent to the menu shown in the "Switching edit modes" doesn't seem to work for me (clicking on "Visual editing" does nothing). The only other browser I have installed is Links, which I don't think uses JavaScript and probably wouldn't show this issue. I'll install and test in Falkon, and let you know once I have the result. —{{u|Goldenshimmer}}|✝️|they/their|😹|T/C|☮️|John 15:12|🍂 18:59, 5 June 2018 (UTC)
I tried with Vector skin, and this resolves both these issues. I certainly won't switch to that skin, though. —{{u|Goldenshimmer}}|✝️|they/their|😹|T/C|☮️|John 15:12|🍂 19:30, 5 June 2018 (UTC)
Oops, it only fixed the missing-buttons issue. The loading issue is still there. Sorry. (Also, after saving an edit, the Edit link goes to https://en.wikipedia.org/w/index.php?title=Special:Badtitle/dummy_title_for_API_calls_set_in_api.php&action=edit&section=40 which shows an error.) —{{u|Goldenshimmer}}|✝️|they/their|😹|T/C|☮️|John 15:12|🍂 19:32, 5 June 2018 (UTC)
I'm not sure what's going on, so I filed a bug report so the VisualEditor devs can look at it. Whatamidoing (WMF) (talk) 03:51, 6 June 2018 (UTC)
Some more information that might be useful in the issue tracker ticket: I think the slowness is fairly reasonable, since I'm using a slow Internet connection (when my computer is uploading files, which is a lot of the time, the connection gets around 2 to 6 KB/s download rate). The problem is that I can't keep reading the article while I wait for the edit page to load, and can't cancel loading the editor if I click on it by accident. I think that is because MediaWiki uses JavaScript to load the edit page instead of it being a separate page. I don't really mind it being slow, I just don't want it to be impossible to stop, and I want to still be able to read while it's loading. —{{u|Goldenshimmer}}|✝️|they/their|😹|T/C|☮️|John 15:12|🍂 07:06, 6 June 2018 (UTC)

Tech News: 2018-23

21:54, 4 June 2018 (UTC)

Note that the Monobook skin changes appear to be described inaccurately above. The skin changes were implemented for devices that the Mediawiki software perceives to be mobile devices, even if the Desktop view is requested. Discussion is in a section above, and at the phab link at the end of the sentence in this tech news. – Jonesey95 (talk) 22:01, 4 June 2018 (UTC)

Incomplete lines underneath headings

Screenshot of the issue on a Wikipedia article, using iOS 10 on an iPad 4. Notice that the line below the header disappears underneath the infobox for whatever reason, even though the infobox doesn't interfere at all with the header. In my view it would be aesthetically more appropriate if the line were to continue underneath the infobox, sadly this isn't the case for whatever reason and I'd like to know why. AlbanGeller (talk) 22:53, 4 June 2018 (UTC)

Does it help to edit the page and put {{clear}} just before the header? I don’t know how other screens and browsers would be affected by that, though. NotARabbit (talk) 03:27, 5 June 2018 (UTC)
”even though the infobox doesn't interfere at all with the header” from the screenshot it looks to me that the bottom (and bottom margin) of the infobox is lower than the top (and top margin) of the header. It therefore IS interfering with the header, this is expected behavior. —TheDJ (talkcontribs) 03:48, 5 June 2018 (UTC)
User:TheDJ, it might be technically interfering with it, though for most readers I doubt they'd be able to tell the difference. My point is, there's plenty of space for the line to continue underneath the infobox. That it doesn't just looks tacky and strange, in my opinion. AlbanGeller (talk) 18:31, 5 June 2018 (UTC)
@AlbanGellar: So what do you propose to do ? Reduce the margin on infoboxes in all situations? Reduce the margin on headers in all situations? Or do you want to write a proposal to W3C to change how webpages work ? —TheDJ (talkcontribs) 18:36, 5 June 2018 (UTC)
@TheDJ: I think we should reduce the margin on headers in all situations, though I'm not exactly sure where is the best venue to propose that. AlbanGeller (talk) 21:51, 5 June 2018 (UTC)
That won't do a thing to fix this (though it might obscure the problem (if you accept that it's a problem) in some cases). What would fix it would be to change the line from a bottom-border on the h2 etc elements to a separate hr or similar following them. That's a bad idea for numerous reasons, but I suppose it could be kludged in with javascript. —Cryptic 22:24, 5 June 2018 (UTC)
@AlbanGeller, NotARabbit, and TheDJ: The word "Corruption", with an "[edit]" link to its right, is a heading, not a header.
@AlbanGeller: Headings should be considered to be bounded by invisible boxes, similar to how a table is normally bounded by a visible box. In the case of a level 2 heading (like "Corruption"), the bottom edge of the bounding box is made visible by having a border drawn along it. Outside that box is a transparent no-go area known as the margin, and margins cannot overlap except in special circumstances - they push each other to one side in order to stay out of each others way. There are two margins at work here: the heading's right margin and the infobox's left margin. So the right-hand edge of the heading, and thus the right-hand end of the heading's bottom border, is constrained in how far it can extend to the right. --Redrose64 🌹 (talk) 22:50, 5 June 2018 (UTC)

How to export the deletion log?

Is there a way to export a portion of a given log? I'm specifically interested in the deletion log for the last couple of months. I don't see any obvious way of doing that from Special:Export. – Uanfala (talk) 09:16, 5 June 2018 (UTC)

You can do that with the API example in sandbox. You might have to do some batching if you want to fetch that many entries though. —TheDJ (talkcontribs) 09:39, 5 June 2018 (UTC)

Broken IPA templates

{{IPAc-it}} seems to be broken, see here. This came to my attention through an edit request on Talk:Benito Mussolini. It's making a whole bunch of links to MfD, but I'm not sure what that has to do with it since it seems to be in active discussion and nothing has come of it yet. In looking at Template:Usage of IPA templates, it seems that {{IPAc-mi}} is broken in the same fashion. I don't see any recent changes to either template that would explain this, so I wanted to raise it here and get someone more knowledgeable than I to take a look. Thanks much! ‑‑ElHef (Meep?) 16:04, 5 June 2018 (UTC)

 Fixed with this edit. Galobtter (talk · contribs) had put the {{Template for discussion/dated}} outside the <noinclude>...</noinclude>. --Redrose64 🌹 (talk) 16:15, 5 June 2018 (UTC)

Plans to graduate the New Filters on Watchlist out of beta

Collaboration team is announcing plans to graduate the New Filters for Edit Review out of beta on Watchlist by late June or early July. After launch, this suite of improved edit-search tools will be standard on all wikis. Individuals who prefer the existing Watchlist interface will be able to opt out by means of a new preference.

The New Filters introduce an easier yet more powerful user interface to Watchlist as well as a whole list of filters and other tools that make reviewing edits more efficient, including live page updating, user-defined highlighting,the ability to create special-purpose filter sets and save them for re-use and (on wikis with ORES enabled) predictive filters powered by machine learning. If you’re not familiar with the New Filters, please give them a try on Watchlist by activating the New Filters beta feature. In particular, it would be very helpful if you can test the new functionality with your local gadgets and configurations. The documentation pages provide guidance on how to use the many new tools you’ll discover.

Over 70,000 people have activated the New Filters beta, which has been in testing on Watchlist for more than eight months. We feel confident that the features are stable and effective, but if you have thoughts about these tools or the beta graduation, please let us know on the project talk page. In particular, tell us if you know of a special incompatibility or other issue that makes the New Filters problematic on your wiki. We’ll examine the blocker and may delay release on your wiki until the issue can be addressed. - - Kaartic correct me, if i'm wrong 16:23, 5 June 2018 (UTC)

Weird behaviour at Afd

FR30799386's screenshot

There seems to be something wrong with the newly inserted( and rather irriating) box at Afd, which gives links to three essays as primers before commenting on a deletion discussion. The box has moved to the left, has been stripped of all background and borders, partially cut away and is pushing content downward on Minivera Skin. I am using a Moto G with a Chrome browser. (I will be able to upload a screenshot tomorrow) — FR+ 17:20, 5 June 2018 (UTC)

@FR30799386: Which Afd page? The main one, WP:AFD; one of the daily lists; or a specific discussion? Which box is it - which section is it in, what text dies it contain? --Redrose64 🌹 (talk) 17:59, 5 June 2018 (UTC)
It's on every discussion page. Natureium (talk) 19:51, 5 June 2018 (UTC)
They're likely talking about {{AFD Help}}. Which I've transcluded on this page. Looks fine here, so I'm not really sure what's wrong with it. Is the issue only with the Minivera skin? Headbomb {t · c · p · b} 19:55, 5 June 2018 (UTC)
I'm using vector and have no issues with it. Is it really necessary to have this template on every AfD page? When someone's article is nominated, they should get a notice on their talk page anyway.Natureium (talk) 19:59, 5 June 2018 (UTC)
Only if they are notified via scripts or by someone who manually posts a notice (neither are a guarantee), and that notice doesn't give much help. That notice is also only given to one editor, which may have created a redirect ages ago, and isn't involved with 'creating the article' proper, or help people stumbling upon the deletion. But that's for Template talk:AFD Help if anything. Consensus was in favour of the notice though, and it's gotten much praise (e.g. User_talk:Headbomb#AFD_help_template, but elsewhere as well), so it certainly serves a use. Headbomb {t · c · p · b} 20:15, 5 June 2018 (UTC)
Fair enough. Natureium (talk) 23:18, 5 June 2018 (UTC)
I tried MinervaNeue (if that's the skin in question) on desktop and mobile (FF and Chrome) and I don't see any issue either here, or at Wikipedia:Articles_for_deletion/Daniel_Carver_(3rd_nomination). @FR30799386: would you have a specific page where the issue shows up? Headbomb {t · c · p · b} 20:08, 5 June 2018 (UTC)
Headbomb-Here is a screenshot...Parts of the text have been chopped off etc. Hope you can help out — FR+ 04:34, 6 June 2018 (UTC)
Informative screenshot. What does the "previous AFDs" box look like? Their style coding is pretty similar, so I'm curious. Someguy1221 (talk) 04:39, 6 June 2018 (UTC)
I use Opera 36, I sometimes get blank rectangles like that when a page loads. Scrolling the page - even by just one line - usually fills in the missing content. --Redrose64 🌹 (talk) 07:05, 6 June 2018 (UTC)
Someguy1221-The "previous Afd" box does appear squashed to the left...stripped of any styling (like this one)....but text wrapping remains fine (on Minvera Neue). Headbomb- I can confirm that this weird stuff occurs only in MiniveraNeue on mobile (Trying it out on MiniveraNeue on desktop gives okay results). Redrose64-I tried scrolling but the problem did not go away. — FR+ 07:24, 6 June 2018 (UTC)
Headbomb, Redrose64:Repinging — FR+ 07:32, 6 June 2018 (UTC)
What happens if you look at say, Quark. Is the infobox all messed up? Headbomb {t · c · p · b} 08:00, 6 June 2018 (UTC)
Nope. It is perfectly okay. — FR+ 08:38, 6 June 2018 (UTC)
The problem seems to be in MinervaNeue's handling of a specified width inside a div, or some issue with the infobox class when a width is specified on that specific phone/OS. I can't offer much help here, we'll likely need an HTML specialist. Headbomb {t · c · p · b} 08:43, 6 June 2018 (UTC)
Headbomb-I added the following hack to my Minivera.css and now the template works okay on AFD pages.The one which you trascluded on top of this thread is still having the same problem..afd-help-box{width:100% ! important;} — FR+ 09:25, 6 June 2018 (UTC)
"Infobox class" This triggered me to look at this. DONT use functional, semantic classes for purely visual effects. If you tell something is an infobox, the system will start making all kinds of assumptions and problems as described above are EXACTLY what you should be expecting (same with using navbox for anything that is not a navbox). Additionally, using things like 30% is really unpractical most of the time, as 30% also means 30% on a small screen. This can all be improved once we have TemplateStyles, but this is the best I can do for nowTheDJ (talkcontribs) 05:16, 7 June 2018 (UTC)
Sadly, the infobox class is used inside {{Afd2}}, which substs the 'old AFD nominations' "infobox" thing as well. And it seems things don't line up when infobox classes aren't used, or a width of 33% isn't used. I suppose AFD2 could be fixed, and pages updated, but whatever's done here should produce a consistent, well-lined up output, and fixed retroactively to June 1st or so. Headbomb {t · c · p · b} 11:12, 7 June 2018 (UTC)
I cannot help here then. If someone has too much time on their hands they can write a bot and figure it out. —TheDJ (talkcontribs) 19:59, 7 June 2018 (UTC)

Template transclusions that generate a <strong class="error">

I need help regarding template transclusions whose functionality is derived from calls to invoke modules written in Lua; in particular, calls that return a <strong class="error"> message </strong> I'd like to track these by causing any return that includes <strong class="error"> to also return [[Category:Wikipedia page transclusions with strong class errors]] so that the affected pages will begin sorting through the tracking category mentioned afore. Is this possible? If so, will someone accomplish this on my behalf, please? Thank you in advance.--John Cline (talk) 01:02, 6 June 2018 (UTC)

They're already in Category:Pages with script errors. Is there any reason to put them in a less-specific category? Anomie 01:24, 6 June 2018 (UTC)
No Anomie, there would be no reason for that. It turns out that the pages in Category:Pages with script errors are the antithesis of pages meant for populating the Wikipedia category. Thank you for your response.--John Cline (talk) 09:46, 6 June 2018 (UTC)

Copyvio tool broken

The copyvio tool appears to be broken. When I use the Page > Tools > Copyright vio detector as usual, I get the message

"The URI you have requested, /copyvios?lang=en&project=wikipedia&title=Leucospermum_gueinzii&oldid=&action=search&use_engine=1&use_links=1, doesn't seem to actually exist."

I tried it on another article as well, and got the same error. Natureium (talk) 15:29, 6 June 2018 (UTC)

I noticed this too, when I went to work at around 14:30 UTC, but it's back up now. The best place to post for this tool is at the maintainer's talk page (User talk:The Earwig). — Ninja Diannaa (Talk) 16:56, 6 June 2018 (UTC)
Thanks. Natureium (talk) 17:54, 6 June 2018 (UTC)
All of Toolforge and VPS was rebooted yesterday around this time. Everything should be back up now MusikAnimal talk 15:22, 7 June 2018 (UTC)

502 Bad gateway for GUC

I'm getting error 502 "Bad gateway" for wmflabs Global User Contributions. Mathglot (talk) 20:26, 6 June 2018 (UTC)

It's about https://lists.wikimedia.org/pipermail/cloud-announce/2018-June/000054.html, reported at least on phab:T196568. Stryn (talk) 20:54, 6 June 2018 (UTC)
Okay, temp, scheduled downtime is reasonable and necessary. But couldn't they do a temp DNS adjustment and route everything for that server to another which puts up a rational advice message instead of leaving us in the dark? The Wikipedia-editing public didn't get the internal email. Mathglot (talk) 01:49, 8 June 2018 (UTC)

Module:EditAtWikidata needs a small tweak

If you use {{EditAtWikidata|qid=Q1}}, you get Edit this at Wikidata. If you inspect the link, you see that it links to https://www.wikidata.org/wiki/Q1# rather than https://www.wikidata.org/wiki/Q1 . That should be fixed if possible. Headbomb {t · c · p · b} 00:46, 7 June 2018 (UTC)

Why is this a problem? {{3x|p}}ery (talk) 01:05, 7 June 2018 (UTC)
It's unnecessary and users may waste time wondering why it's there or whether an anchor is missing. Module:EditAtWikidata by RexxS already tries to omit # when there is no anchor pid. But the code if propertyID assumes an empty string is considered as false. In Lua it's considered as true.[10] PrimeHunter (talk) 06:43, 7 June 2018 (UTC)
I edited the module as requested. It should be ok but please check! Johnuniq (talk) 07:46, 7 June 2018 (UTC)
Thanks John! Your logic looks sound to me. I actually thought I'd set propertyID to be nil if it was empty, as I had done for qid. Thanks for catching it. --RexxS (talk) 17:19, 7 June 2018 (UTC)

Messaging users of a particular skin

Is it possible for Wikipedia to target messages at users of a particular skin? DuncanHill (talk) 11:06, 7 June 2018 (UTC)

@DuncanHill: No. User preferences, including skin, are considered private data, so are not exposed. Jdforrester (WMF) (talk) 18:28, 7 June 2018 (UTC)
While we can't "message" them - we could make messages that APPEAR only for people in certain skins with skin specific css, such as a site notice. If you are wondering about the opt-out monobook stuff a general watchlist notice might be a good idea. — xaosflux Talk 19:42, 7 June 2018 (UTC)

Re: "Forgot password" emails

Not sure if this is the right place for this, but I've been getting a lot more than usual emails regarding password resets (Someone (probably you, from IP address xx.xx.xx.xx) requested a reset of your password...), and perhaps this has to do with the increase in failed login attempts. All of these temporary passwords have 10 characters: would it be possible to increase the number of characters in those (temp passwords would have 20 or so characters), or randomize the lengths of the temp passwords? SpencerT•C 17:20, 7 June 2018 (UTC)

I am not sure that this will make sense. 6210 is a very large number of possible passwords. Ruslik_Zero 17:31, 7 June 2018 (UTC)

Unexpected behaviour of search/go

Until recently, if I typed a non-existent article title into the search box and clicked go I got taken to the non-existent page and given the oppoertunity to create it, see what linked there, etc. Now I just get a list of search results. I noticed this just now. What is causing this unexpected and unhelpful behaviour, and how can it be fixed? Thanks, DuncanHill (talk) 22:31, 7 June 2018 (UTC)

It's been this way for me for a long while. What skin are you using?
You still have the option to create the page, you just have to click the red link that's the first result. Search for something like "hflegicljic," for example. The option to create the page has just one more click involved.
Showing search results (as a search bar would imply) allows one to find articles for which one can remember likely keywords or partial title but not the exact title. For example, I could find Magical Treatise of Solomon by searching "magical of solomon" or "Loutzipher". It would be less helpful to not have this feature. Ian.thomson (talk) 22:37, 7 June 2018 (UTC)
There is no redlink. DuncanHill (talk) 22:43, 7 June 2018 (UTC)
When I search "hflegicljic", I see:
Search Results
[Search bar]
Content pages: [Multimedia] [Everything] [Advanced]
You may create the page "Hflegicljic".
There were no results matching the query.
When I search "magical of solomon," it's the same deal, except there's results. Ian.thomson (talk) 23:21, 7 June 2018 (UTC)
Ah now I think I've worked it out. I was searching for "Roland Baines", which is a salted title. When I search for unsalted titles I do get the redlink. It's rather annoying as I was trying to find socks adding links to the page. DuncanHill (talk) 23:27, 7 June 2018 (UTC)
@DuncanHill: With default settings you should still get a red link for salted titles like Roland Baines without quotation marks. What is your skin at Special:Preferences#mw-prefsection-rendering and what is your language at Special:Preferences#mw-prefsection-personal? If you have set the language to British English or Canadian English then you don't get a red link for salted titles but the top of Special:Preferences should give a general warning with MediaWiki:Preferences-summary/en-gb or MediaWiki:Preferences-summary/en-ca, linking to Help:Preferences#Internationalisation. I have tried to suggest a stronger warning in the MediaWiki messages but some users object to indicating that British or Canadian English is a bad choice for interface language. If you have it and decide to keep it then please always mention it when you report issues with interface messages. You should also have mentioned your search term from the start. PrimeHunter (talk) 07:51, 8 June 2018 (UTC)
Also, what is your setting at Preferences → Search? There are four options here; I use "Classic prefix search". --Redrose64 🌹 (talk) 13:40, 8 June 2018 (UTC)
Monobook, British EnglishHas anyone ever thought that rather than warning users of British or Canadian users that we'll get a sub-standard experience it might be worth improving the experience?, default on the search preference (which I was not aware of before). DuncanHill (talk) 15:30, 8 June 2018 (UTC)

Templates hidden by default?

In WISE J2000+3629, there's two templates at the bottom of the page:

{{Nearest star systems|4}}
{{Stars of Cygnus}}

The first one displays in the hidden state, the second one in the open state. My template fu is pretty weak. How is that controlled? It seems to me it would be better if they both showed in the hidden state by default; the latter one in particular is a huge display which overshadows many of the articles it's part of. -- RoySmith (talk) 13:44, 8 June 2018 (UTC)

 Done @RoySmith: that second template has a 'state' parameter that can be used to control the "collapse" (not really "hidden") initial display. I set it for you on that article, is that what you wanted? — xaosflux Talk 13:47, 8 June 2018 (UTC)
If you want to change it for all instances, the | state = {{{state|<noinclude>uncollapsed</noinclude>}}} line in Template:Stars of Cygnus is what controls the default there, you could add a <includeonly>collapsed</includeonly> right after the noinclude section and before the closing curly braces. — xaosflux Talk 13:51, 8 June 2018 (UTC)
Ah, that's what I was looking for. Yeah, my intent was to fix it for all instances, not just for this one example. Thanks for your help. -- RoySmith (talk) 13:56, 8 June 2018 (UTC)

Job queue

Just for curiosity, does someone know what happened to job queue management from March 5, 2018? See Graphana Job Queue Health last graph. From that day job queue is always very very low. Check for example the API link: it will report "jobs": 0, I am in Wikipedia from many years and I don't remember that value less than ~1000. I am interested in some technical detail. Thanks in advance. --Rotpunkt (talk) 14:57, 8 June 2018 (UTC)

@AKlapper (WMF): Did the job queue die? :D --Izno (talk) 15:27, 8 June 2018 (UTC)
@Izno: It's not that I run the job queue or can travel back three months in time, sorry. :) You could ask in #wikimedia-tech connect or on wikitech-l@ (or maybe meta:Tech but that looks pretty dead)? Thanks! --AKlapper (WMF) (talk) 16:27, 8 June 2018 (UTC)
It probably has to do with the transition to a new job queue backend, it seems they didn't implement the reporting yet so the existing interfaces don't report jobs that are in the new queue. Anomie 21:42, 8 June 2018 (UTC)

Animated gif not animating

In the Brownian motion article, the first animated gif (File:2d_random_walk_ag_adatom_ag111.gif) appears static both when viewing the page and when I click on the image to view in the media viewer (or when just clicked on from the above link). However, when I click on the image once more so that Chrome is simply displaying the plain image file, it does display correctly as an animation. The next two images in the article are also animated gifs, and they both appear correctly however I view them. I have no idea where the problem lies here, so I thought I'd post about it to see if anyone else had any ideas. –Deacon Vorbis (carbon • videos) 17:46, 8 June 2018 (UTC)

The file description page states "Note: Due to technical limitations, thumbnails of high resolution GIF images such as this one will not be animated." --Redrose64 🌹 (talk) 17:56, 8 June 2018 (UTC)
Ugh, missed that of course. Thanks for the pointer. –Deacon Vorbis (carbon • videos) 18:13, 8 June 2018 (UTC)

#ifeq around template:shortcut???

In Wikipedia:Deletion review/Purpose, we've got the following blob of template gunk:

{{#ifeq:{{{shortcut|yes}}}|no||{{shortcut|WP:DRVPURPOSE}}}}

What's the purpose of the #ifeq conditional here? What does this do that plain old:

{{shortcut|WP:DRVPURPOSE}}

wouldn't do with less obfuscation? -- RoySmith (talk) 20:47, 8 June 2018 (UTC)

@RoySmith: The page is also transcluded at Wikipedia:Closing discussions#Challenging a deletion, where the shortcut is not needed. -- John of Reading (talk) 20:52, 8 June 2018 (UTC)
Hmmm, I'm still not getting how this is parsed. Looking at Help:Conditional expressions#Using #ifeq, I get as far as:
  • string 1 is "{{{shortcut|yes}}}"
  • string 2 is "no"
  • value if identical is the empty string
  • value if different is "{{shortcut|WP:DRVPURPOSE}}"
I'm not grokking what the triple-brace notation does. I'm just a poor C++/Java/Python guy. All this template magic makes my brain hurt. -- RoySmith (talk) 21:11, 8 June 2018 (UTC)
It's the shortcut parameter if there is one, or "yes" if there isn't. Help:Template#Handling parameters. So if there's a shortcut parameter and it's equal to "no", then evaluate to nothing; else evaluate to {{shortcut|WP:DRVPURPOSE}}. —Cryptic 21:21, 8 June 2018 (UTC)
(edit conflict) shortcut is the name of an optional parameter when Wikipedia:Deletion review/Purpose is transcluded. Wikipedia:Closing discussions#Challenging a deletion transcludes it with {{Wikipedia:Deletion review/Purpose|shortcut=no}}. A template (or any other transcluded page) references parameters with triple curly braces like {{{shortcut}}}, or {{{shortcut|X}}} to specify the value X if the shortcut parameter is missing or empty. But if you want to learn template code then please try Help:Template before asking further questions. See e.g. Help:Template#Handling parameters. Wikipedia:Help desk or Wikipedia:Teahouse are better places to ask questions about template coding. PrimeHunter (talk) 21:29, 8 June 2018 (UTC)
Not quite, PrimeHunter: the form {{{shortcut|X}}} only reduces to X if |shortcut= is absent - or of course if explicitly set to |shortcut=X. If this parameter is present but empty, {{{shortcut|X}}} reduces to an empty string. --Redrose64 🌹 (talk) 22:18, 8 June 2018 (UTC)
Ah, I got it. It's set to "no" in Wikipedia:Closing discussions#Challenging a deletion: {{Wikipedia:Deletion review/Purpose|shortcut=no}}. And (I think this is the part that really made my brain hurt) the parameter name "shortcut" in "shortcut=no", is in a different namespace from the template named "shortcut" in {{shortcut|WP:DRVPURPOSE}}. -- RoySmith (talk) 22:55, 8 June 2018 (UTC)

Proposals

Proposal: A US-only CentralNotice in support of Net Neutrality

After two weeks of discussion, and multiple comments from both the support and oppose sides, regardless of any good intentions made in this discussion, with a near-even split in !votes (55 supports and 56 opposes as of this closure), it's clear that there is no clear consensus to post this at this point. I'm aware that I participated in this discussion, but given that discussion has slowed down and the !vote count, keeping this open longer would likely not have affect the final outcome regardless. Any further discussion is welcomed in the subsequent sections, which remain open. (non-admin closure). Narutolovehinata5 tccsdnew 13:16, 20 May 2018 (UTC)
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.

Proposal: A US-only CentralNotice in support of Net Neutrality.

Net Neutrality is the principle that service providers should treat all Internet traffic as equal, and not discriminate on the basis of origin, destination, or type of data. Net Neutrality protects people's access to knowledge by prohibiting internet service providers from blocking, slowing, or prioritizing data traffic for a fee.

The Wikimedia Foundation and several US Wikimedia affiliates have come out in support of Net Neutrality in the United States, as well as the efforts in Congress to keep the Open Internet rules in place. Just as the Foundation considers Net Neutrality as essential for access to knowledge, the Wikimedia community should realize that equal access to knowledge is important to our mission and knowledge equity and act accordingly. The concern is that if access to Wikipedia and/or its sources is slowed, or allowed only as part of a paid premium, this could gravely harm our fundamental mission to provide free access to knowledge for all. Any restricted access could reduce the quality of articles and reduce the diversity of contributors who create and maintain Wikipedia’s content. If access is limited in a way that restricts access to sources we use to create Wikipedia articles, that hinders our mission of delivering free knowledge.

This proposal is to gauge the community's interest in presenting a banner to US-based viewers of the English Wikipedia, which would show the importance of Net Neutrality to Wikipedia's mission and encourage further reading and action. A landing page with more details has been produced here. A proposed banner with expandable information is previewable here, with a preview of its unexpanded form as follows:


Free knowledge depends on net neutrality.
We are asking for your support.

LEARN WHY AND TAKE ACTION

The reason this proposal is being brought up now is that on May 9, a petition will be filed in the U.S. Senate to force a vote on a bill to block the FCC's December repeal of net neutrality rules. The bill currently has bipartisan support from half the Senators, and only one more vote is needed for the bill to pass in the Senate.

In general, Wikipedia should remain non-partisan and non-political; however, Wikipedia's own mission of free and open knowledge for all is a political one, and the community must support public policy when that policy is vital to protecting its mission. Just this week the German Wikipedia ran a banner to support European Union copyright reform; in the past, banners were run in South Africa in support of freedom of panorama, and banners were run in Australia to support fair use. This proposed Net Neutrality geo-targeted banner would be in line with previous community efforts to support policies in the best interest of Wikimedia.

Some may remember SOPA and PIPA, two other laws that would have radically altered how the internet is used in the United States in a way that negatively impacted our mission. A Wikipedia blackout and banner was instrumental in turning public and legislative opinion against these detrimental bills. We're not going for a blackout this time, but hope that a US-focused banner can direct attention to the issue and preserve Net Neutrality by promoting a grassroots effort to convince Congress to act.

Thank you.

Further reading:

— Preceding unsigned comment added by Gamaliel (talkcontribs) 19:00, 6 May 2018 (UTC)

Survey: A US-only CentralNotice in support of Net Neutrality

  • Support Gamaliel (talk) 19:00, 6 May 2018 (UTC)
  • Support Blervis (talk) 19:10, 6 May 2018 (UTC)
  • Support as co-writer. ~SuperHamster Talk Contribs 19:10, 6 May 2018 (UTC)
  • Support Granato31415 (talk) 21:07, 6 May 2018 (UTC)
  • Oppose net neutrality is not in the interest of the global Wikimedia movement (see Wikipedia Zero, which is bring wound down, but is the exact opposite of net neutrality.) Even with Wikipedia Zero being done away with, the Foundation will likely gave future projects that would benefit from net neutrality not existing, and that would serve our readership in the US and around the world. We should not be promoting political concepts that hurt the global movement. TonyBallioni (talk) 19:15, 6 May 2018 (UTC)
  • I'm puzzled by the assertion that "net neutrality is not in the interest of the global Wikimedia movement". Wikipedia Zero was a necessary step in countries where the situation is not ideal and net neutrality is not in place, but I doubt anyone participating in that would trade real net neutrality for a workaround like WZ. The Foundation (was in charge of WZ) has publicly come out strongly in favor of NN, so they seem to think it *is* in the best interest of our global movement, as do many in the Wikimedia volunteer community. Gamaliel (talk) 19:21, 6 May 2018 (UTC)
  • As a political reality in the states, the Foundation has to support net neutrality , but as a large player in the online marketplace, we are much more likely to benefit from Net Neutrality not existing than be hurt by it. We are the website run by a large organization that people complain about getting preferential treatment. The simple fact is that by our size and reputation, the ability to get preferential treatment from ISPs could actually help our mission of spreading free knowledge. We aren't the small startup website that someone is running from their home. We're an international organization that is the 5th most visited website in the world. People could use us as the reason to oppose Net Neutrality if they were trying to set up rival projects. TonyBallioni (talk) 20:34, 6 May 2018 (UTC)
  • We should look beyond the end of our own noses and support what is right. The possibility that Wikimedia may not benefit from net neutrality should not prevent us from supporting it. Surely an open Internet is more important. Richard Nevell (talk) 22:44, 6 May 2018 (UTC)
  • You don't get an open internet by giving government censors more power. As Reuters points out, "The FCC ... has introduced a so-called 'general conduct' provision in the latest version of the rules ... In the general conduct provision, the FCC will say that Internet providers’ actions cannot be harmful to consumers or content providers ... "A 'general conduct rule,' applied on a case-by-case basis with the only touchstone being whether a given practice 'harms' consumers or edge providers, may lead to years of expensive litigation to determine the meaning of 'harm' (for those who can afford to engage in it)," the Electronic Frontier Foundation, a net neutrality advocate, said in a filing submitted on Thursday."' --Guy Macon (talk) 14:45, 7 May 2018 (UTC)
  • Net neutrality is key to the interest of the global free knowledge movement of which we're a part - Wikipedia's birth would never have been possible without it, and we'd be foolish to forget that.--Pharos (talk) 21:04, 6 May 2018 (UTC)
  • No, Wikipedie grew in an environment in which large-scale net neutrality was so much a given that the concept was not explicitly discussed - it just was. --Stephan Schulz (talk) 22:36, 7 May 2018 (UTC)
  • With that statement made—which is exactly the opposite of what existed—I don't think the US Net Neutrality law is what you think it is. The free market has driven the internet in America since the inception of the net. Why would you want to give the government more control now when nothing is broken? GenQuest "Talk to Me" 19:18, 8 May 2018 (UTC)
  • Then start a PAC or other advocacy group and lobby for it that way. Using an organization that has in the past benefited from the lack of Net Neutrality around the world to lobby for Net Neutrality in the United States is a bad idea. TonyBallioni (talk) 21:19, 6 May 2018 (UTC)
  • Whether it's the problematic grammar or the confusing line of thought, I don't understand your point. I'm not trying to be argumentative – I honestly don't understand it. Care to clarify? -- Fuzheado | Talk 19:24, 6 May 2018 (UTC)
  • For whatever it's worth, former WMF General Counsel Mike Godwin has in the past defended zero-rating alongside net neutrality. For lack of a better summary, it's an important nuance. I haven't asked him lately, but at any rate, even if you do think W0 and net neutrality are at odds, W0 is done with, so this shouldn't be a concern. ~ Amory (utc) 21:38, 6 May 2018 (UTC)
  • Support - This is an important enough issue not just in the US, but globally, and one where the community should have a voice of conscience. The modest proposal is not an extreme one like the SOPA blackout – it is a nondisruptive awareness campaign to highlight a troubling trend that could affect more than just daily traffic to Wikimedia projects but everything from multimedia uploads to bulk data contributions to GLAM collaboration – all the types of things have gotten Wikimedia to where we are today. -- Fuzheado | Talk 19:20, 6 May 2018 (UTC)
  • Support Richard0612 19:24, 6 May 2018 (UTC)
  • Support. Also show to users with IPs from Canada and Mexico, as some ISPs near the borders serve both sides. Lojbanist remove cattle from stage 19:27, 6 May 2018 (UTC)
  • Support. --Rosiestep (talk) 19:39, 6 May 2018 (UTC)
  • Support. Megs (talk) 19:57, 6 May 2018 (UTC)
  • Extremely strong oppose. Wikipedia should not take stands on political issues. SOPA was arguably an existential threat; this is not. --Trovatore (talk) 20:03, 6 May 2018 (UTC)
    All existential threats were once non-existential. Should we fold our arms until when we are aimed directly then we start running non-dismmisable banners across all WMF projects indefinitely?... –Ammarpad (talk) 20:33, 6 May 2018 (UTC)
    We should not be involved in politics, period. Even the SOPA thing I have come to see, in retrospect, as a mistake. --Trovatore (talk) 20:35, 6 May 2018 (UTC)
  • Support as coauthor. I've been researching this one and may have lots of further comment. -- econterms (talk) 20:05, 6 May 2018 (UTC)
  • Support - Free knowledge depends on an environment that does not privilege large commercial websites.--Pharos (talk) 20:14, 6 May 2018 (UTC)
  • Oppose. We can't keep running political ads so frequently. The primary objective of this website is to provide a free encyclopedia, and the frequency of CentralNotice use is becoming very disruptive. (Also, the summary above re the US Senate vote is misleading. Passing the Senate alone will not determine the repeal, and the bill does nothing without the approval of the House and the President.) --Yair rand (talk) 20:29, 6 May 2018 (UTC)
  • The last time we took a comparable action was over 6 years ago. True, it does not feel very long ago to those who were heavily involved at the time, but this is hardly a frequent occurrence.--Pharos (talk) 20:38, 6 May 2018 (UTC)
    It has been 56 days since we had a CentralNotice pushing political action on the Turkish Wikipedia block. --Yair rand (talk) 20:56, 6 May 2018 (UTC)
  • Oppose: The Internet is not broken, and does not need to be "fixed" by giving the US government more control over the internet. The recently repealed Obama-era net neutrality rules adopted a vague but sweeping "general conduct" standard that gave the FCC the power to crack down on perceived bad behavior by internet providers without providing clear guidance about what would trigger enforcement. Wikipedia was built on internet freedom, not government regulations. Please at least try to read and understand the reasons who so many people oppose this: [11][12][13][14] --Guy Macon (talk) 20:34, 6 May 2018 (UTC)
    • @Guy Macon: I actually wrote a large comment below that explains that the net neutrality rules were not just enacted in 2015. The FCC simply codified what they had been doing for twenty plus years. The Trump FCC's repeal was not simply a rollback of the Obama FCC's rules; it also took away other things as well, such as the FCC's ability to enforce anything. epicgenius (talk) 16:52, 8 May 2018 (UTC)
      • You are wrong. From our article on Net neutrality; "U.S In April 2015, the FCC issued its Open Internet Order, which reclassified Internet access - previously classified as an information service - as a common carrier telecommunications service; i.e. a public utility. But on December 14, 2017, the Commission, which was led by Chairman Ajit Pai, voted to partially repeal the 2015 Open Internet Order, classifying Internet access once again as an information service." At no time in the previous twenty plus years did the FCC classify ISPs as common carrier telecommunications services / public utilities. Prior to 2015 the FCC always classified ISPs as information services, and all regulation was done according to the rules for regulating information services. --Guy Macon (talk) 17:12, 8 May 2018 (UTC)
        • Look, I'm not going to argue with you, because obviously we have different opinions. However, your rebuttal is a straw man argument, because Title II wasn't my argument; the FCC's net neutrality enforcement was. Look at Net neutrality in the United States#FCC attempts at enforcing net neutrality (2005–2010). The FCC did try to enforce net neutrality (anti-throttling) against Comcast, and this is where it got them. Title II was a result of Verizon's similar suit against the FCC, which ended up in a dispute over whether the FCC had the power to keep enforcing its regulations. Title II only reclassified the ISPs so the FCC could continue to enforce these laws. Nothing happened to the enforcement process itself until Ajit Pai stepped in. The 2017 rollback took away the FCC's ability altogether to enforce these statutes; whereas before 2015, the FCC could still enforce the statutes against ISPs. All of this is according to the Net Neutrality in the US article. epicgenius (talk) 18:19, 8 May 2018 (UTC)
  • Support: The Internet is not broken, and we should state that we are in favor of keeping it that way. And this proposal is not similar to the previous one at Wikipedia:Village_pump_(proposals)/Archive_147#Net_neutrality that asked people for overt political action; this one just encourages support for the principal. Dicklyon (talk) 20:38, 6 May 2018 (UTC)
    @Dicklyon: There's a huge red button saying "Take action" linking to a page asking for "your support" and "your voice" to preserve Net Neutrality, as well as linking to a tool for contacting members of congress by phone, email, and Twitter. I think that counts as "asking for overt political action". --Yair rand (talk) 21:10, 6 May 2018 (UTC)
  • Support --denny vrandečić (talk) 20:52, 6 May 2018 (UTC)
  • Oppose - net neutrality regulation is a partisan issue, with the left arguing that regulation is necessary and the right arguing that the same state of affairs can be achieved without regulation and that unnecessary regulation in this area is more harmful than good. I personally think that regulation is good here, but we aren't the internet wing of the Democratic party and I don't think we should be taking a side on this American political issue. -- Ajraddatz (talk) 21:07, 6 May 2018 (UTC)
  • No partisan issue is supported by all of one side and opposed by all of the other. My point is that this is a political issue and we shouldn't be involved. -- Ajraddatz (talk) 21:36, 6 May 2018 (UTC)
  • Except it is; the existing rule was removed by a vote along party lines. And none of this refutes my key point that this is a political issue and we shouldn't be involved. -- Ajraddatz (talk) 22:37, 6 May 2018 (UTC)
  • @Ajraddatz: It actually isn't as clear cut as "the left supports net neutrality and the right opposes it". Some Democrats have voted against net neutrality legislation in the past. Conversely many Republican citizens support such an action. I elaborated on this point in a comment below. epicgenius (talk) 16:52, 8 May 2018 (UTC)
  • Of course. As I said, partisan issues are rarely support entirely by one side and opposed entirely by the other, especially in the American political system which is characterized by weak party discipline compared with parliamentary systems. But from what I can see, there is a clear Democratic position and a clear Republican position here, and I don't think we should be involved. Political matters are for the politicians. -- Ajraddatz (talk) 17:05, 8 May 2018 (UTC)
  • Oppose Is there an actual problem here that needs to be fixed. I don't support extending governmental power over the private sector (citizenry) without some clear specific justification based upon a serious detrimental problem (not theoretical musing) and a clear specific belief that regulation will bring improvements. This is really fear of monopolistic control that must be "regulated" by the government, when monopolies really inspire competition which brings about more choices and better results than regulation. This is a political issue and WP should take no position. MB 21:10, 6 May 2018 (UTC)
  • I would agree with you generally, but this is clearly a special situation. Scrapping net neutrality wouldn't encourage new ISP's to start up because the costs of starting a new network are simply too high. Removing it wouldn't have any affect on potential new competitors, just allow the existing duopoly to charge more for the same service. I doubt that anyone is sitting around wanting to start a new internet service but just can't because of net neutrality. It is a political issue, but we have a duty to do what we can to ensure Wikipedia continues to be a valuable resource into the future. --Blervis (talk) 21:58, 6 May 2018 (UTC)
  • Oppose Support If we are going to take a historic stand for something which is likely to get media coverage then at least we need to assess what we have and what we are doing. I appreciate this RfC and I want to support this project but I think we should plan this a little better. Here are some things which I would want to see done:
    • Develop the right external partnerships
      • Someone needs to initiate on-wiki conversation with partners and get them to post to Wiki. A prerequisite for a Wikimedia partnership is that organizations should either have an on-wiki presence or a wiki community project here which is capable of two way communication. If they want a wiki call out then maybe someone can ask them if they can bring expert review and community engagement to wiki.
      • The proposal promotes Battle for the Net and Public Knowledge, a non-notable organization and an organization with a wiki page which probably would not pass AfD. It is not helpful to the Wikipedia community to associate with fringe organizations for which readers cannot get information on Wikipedia.
      • Wikipedia is the single most single most consulted source of information about net neutrality. These organizations have a communication strategy which does not include bringing expertise to Wikipedia, and they are making a mistake by not directing their staff to promote the development of the Wikipedia articles. I know these are small organizations but they are still funded, and there is nothing that they could do to better achieve their communication goals than give attention to wiki. If they develop wiki articles then they should claim wiki's audience to their funders, who almost certainly already require them to report impact and reach. Someone needs to tell them and they need to respond.
      • Battle for the Net organizes community events which they do not document. They should catalog their images and photos and get them into Wikimedia Commons. Unfortunately the many dozens of public demonstrations which they organize typically are not leaving behind a media record.
    • Develop the Wikipedia articles:
      • "Net neutrality" is in poor shape. For the amount of attention this article gets (it is high traffic by Wikipedia standards) I am a little embarrassed that so many people read it without it being well developed. Can we confirm that the wiki community wants this article to get media attention? It is intimidating for many editing to review high traffic complicated topics like this and I have doubts that we should showcase it without a cleanup effort.
      • We need to sort out {{Net neutrality}} and the articles in it. These are not good articles to promote on the world stage when we are asking for scrutiny and engagement
    • Have a community discussion about the circumstances under which we will endorse other organizations' work
I want to support this proposal. I would change my "oppose" to "support" if asked, but I wish that we could be thoughtful about the problems with this and plan to collect whatever resources we can to make this work. I do not want to set a high standard for what we need to begin an awareness campaign. However, I think that Wikipedia should have a minimal standard, however we define it, and I think that what I am proposing above about making an effort to improve wiki content and to consider our relationship to and the notability of partners when calling their names is reasonable.
Blue Rasberry (talk) 21:32, 6 May 2018 (UTC)
I'm on board for improving Net neutrality and related articles. Will work on this soon. I do not think people in other orgs have an obligation to participate on our platform, but your arguments are significant and I'm processing them. -- econterms (talk) 21:40, 6 May 2018 (UTC)
I agree with most of what you are saying, but the time to act on this issue is limited. We can work towards improving what you mentioned, but if we don't act on the current situation now, any future efforts may be in vain. I also don't think this is a partnership with any of the above mentioned groups, we simply share the same goal. --Blervis (talk) 21:58, 6 May 2018 (UTC)
@Blervis and Econterms: How would you feel about removing mention of or links to other organizations? I would support this without the inactive partners, and if the wiki community came up with a few people to spend a few hours to revise the articles. Blue Rasberry (talk) 02:00, 7 May 2018 (UTC)
Hi @Bluerasberry: Re. the links to Fight for the Future and Public Knowledge, those can be removed - they're there simply as supplemental readings and are minor points in the proposal. ~SuperHamster Talk Contribs 02:29, 7 May 2018 (UTC)
@SuperHamster: I changed to support if the non-wiki partner organizations are removed. Blue Rasberry (talk) 02:40, 7 May 2018 (UTC)
@SuperHamster, Econterms, and Blervis: I did a little article cleanup this morning as described at Talk:Net_neutrality#Split_of_content_to_Net_neutrality_by_country. I hope that what I did improves the article's readability, advances its development, and prepares it for any future education effort. Blue Rasberry (talk) 13:52, 9 May 2018 (UTC)
  • Oppose: Last month, I noted that this was political, and shouldn't be broadcast through the entire encyclopedia. I like this pared-down version: it's significantly clearer, even if the technical issues involved are somewhat murky to this layman. However, the Wikimedia Foundation has already spoken about this, and no matter how much I agree with net neutrality, I cannot, in good conscience, support this proposal. Quite simply, it's a political issue, and there are other fora for issues of a political nature, including message boards, Twitter, Reddit, Facebook, calling your Senators and leaving polite messages with the aides and staff, &c., &c., ad infinitum. So, the long and the short of it: again, no, it's too political. — Javert2113 (talk) 21:38, 6 May 2018 (UTC)
Addendum: I agree with Blue Rasberry; I'd love to support this, but it seems slightly unorganized. If we do go about this (that is, if this proposal passes), we cannot do so haphazardly, and that means planning (dun dun dun); and while I have some minor quibbles with Blue's notes, by and large, he's not wrong, though I do balk at the mention of a Wikipedia community endorsement (at least, that's how this editor understood it). One thing I'd like to emphasize, if I may, is his final point: community and collaboration. At all times, we must strive for consensus, even if we don't all agree. — Javert2113 (talk) 21:47, 6 May 2018 (UTC)
Erratum: Not "last month", but, rather, in late March. See the below challenge to validity from Guy Macon. — Javert2113 (talk; please {{ping}} me in replies) 22:58, 6 May 2018 (UTC)
  • Support I think it's okay for us to occasionally take targeted action against particularly egregious threats to the site. SOPA/PIPA were good examples. Process-wise, this is a significantly different proposal, so I am okay with it, although admittedly this is a bit soon after that one (and a bit down to the wire). More substantively, and I can say this at meta as well, but "We are asking for your support" in a banner looks awful similar to asking for a donation. I would worry many folks would dismiss it without clicking, even though it's not December. ~ Amory (utc) 21:44, 6 May 2018 (UTC)
  • Support Ian.thomson (talk) 21:51, 6 May 2018 (UTC)
  • Oppose - I didn't join Wikipedia to be a party to politics, and not every Wikipedia editor is either for/against Net neutrality. Adding this disenfranchises many people for that reason. For me personally, I have no interest in participating here if Wikipedia gets involved in ANY political issue. We are supposed to be here to build an encyclopedia, not champion a political cause, any political cause. This constant RFC after RFC is akin to shaking the magic 8 ball until it gives you the answer you want, and frankly, seems to be a form of bludgeoning the point. Dennis Brown - 22:01, 6 May 2018 (UTC)
  • Oppose per Javert2113 and Dennis Brown and this is a political issue and feel there other fora are better for this.Pharaoh of the Wizards (talk) 22:19, 6 May 2018 (UTC)
  • Strong oppose. Wikipedia should not meddle in political issues, not only because many editors are not here for this but also because of the unwanted attention this kind of stance is likely to generate. Building an encyclopedia has nothing to do with that. José Luiz talk 22:25, 6 May 2018 (UTC)
  • Oppose – It is tempting to use Wikipedia as a means to promote public policy. However, I would advise extreme caution whenever we consider doing it. There is a very good reason why we don't normally get involved in politics, and that is because it is also part of our mission to provide a neutral resource where readers can find out more about a topic without getting the feeling that someone is trying to sway their views in a particular direction. It is our goal to create a place where readers can decide for themselves what they should believe based on a neutral description of what reliable sources have said. The moment our editorial community forms a consensus to take a stance on a political topic, we are betraying that mission by admitting that we have a conflict of interest with respect to some political topics, so we better be certain that if we don't take the stance, Wikipedia's ability to function will be fatally compromised. That, in my view, is the cost of taking political stances for Wikipedia, and I'm not sure enough evidence has been presented thus far to justify that cost for this issue. Mz7 (talk) 22:33, 6 May 2018 (UTC)
  • Support If we're not prepared to lend exposure to issues that threaten it, we can't claim to be working for free knowledge available to all. — OwenBlacker (talk; please {{ping}} me in replies) 22:39, 6 May 2018 (UTC)
    • @OwenBlacker: On what basis do you assume that giving the US Government increased control over the Internet in some vague way "working for free knowledge available to all"? And why the US government? Why not the EU? The Internet is not broken and does not need fixing, and Wikipedia was built on internet freedom, not government regulations. The recently repealed Obama-era net neutrality rules adopted a vague but sweeping "general conduct" standard that gave the FCC the power to crack down on perceived bad behavior by internet providers and web site owners without providing any real details about what would trigger enforcement. How is this good for Wikipedia? --Guy Macon (talk) 22:57, 6 May 2018 (UTC)
      • Net neutrality does not give "increased control over the Internet", no matter how many times you repeat it. If you oppose any law whatsoever that might help the weak, that's fine, but let's not get ridiculous. --Nemo 20:01, 15 May 2018 (UTC)
  • Fuck yeah. Net neutrality is 100% in alignment with Wikipedia's core mission. The only reason not to do this would be if the Foundation say it jeopardises 501(c)(3) status. Guy (Help!) 22:47, 6 May 2018 (UTC)
  • Comment on the false dichotomy underlying statements like "Wikipedia shouldn't get involved with politics" or "Wikipedia shouldn't be political" - The question should be whether this is something that furthers the mission of Wikipedia or is otherwise in the best interests of the people involved with writing/reading Wikipedia. Wikipedia is political, and not just because of this kind of initiative. An encyclopedia that anyone can edit is political, the way we use sources and define which sources are reliable is political, how we understand neutrality is political, the decision to cover a subject one way rather than another is political, not running ads on the site is political, having as part of our mission being accessible to everyone is political, not privileging academic credentials is political, our consensus-building processes are political... it's just that these politics are not, for parts of the world most participants here live in, nicely split along partisan lines in contemporary discourse. For many other parts of the world, however, these things we take for granted are explicitly political in a similar sense. Climate change has been politicized in the United States, too, and we have dealt with that in a way that really bugs one side because we determined that doing so is in accordance with Wikipedia's principles/mission/purpose, not because we decided to get political. This is likewise not a decision of whether to "get political." We are already political. The question isn't whether this is relevant to American politics, but whether this is or is not something that matters for Wikipedia's principles/purpose. Oppose if you decide that it is not, oppose if you think net neutrality isn't all that meaningful or if you think this particular aspect of net neutrality isn't something that matters for Wikipedia, oppose if you don't think we should have messages outside of articles that don't themselves follow Wikipedia content policies, oppose if you think our article needs to improve first, but don't oppose "because politics." It's just more nuanced than that. — Rhododendrites talk \\ 22:40, 6 May 2018 (UTC)
  • Exactly! "Everything is political", and that's fine. Not posting this banner is a political decision. Thus, I agree that !opposing this because "it's political" is invalid. Davey2116 (talk) 18:34, 12 May 2018 (UTC)
    • No, it really really isn't. We shouldn't be taking political stands as an encyclopedia. Period. --Trovatore (talk) 23:08, 6 May 2018 (UTC)
      • I'm fine with disagreement but this doesn't address at all any of Rhododendrites' thoughtful remarks, it just says "uh-uh". In many parts of the world, the encyclopedia's very existence is a political stand. We are a neutral encyclopedia but we don't exist in a neutral world, unfortunately. Gamaliel (talk) 23:25, 6 May 2018 (UTC)
        • Rhododentrites instructed me not to oppose the initiative because it's political, but I do oppose it because it's political. It really is just that simple. We should not be taking political stands as an encyclopedia. As for the existence being a political stand, I'm sorry, I think that's nonsense. --Trovatore (talk) 23:49, 6 May 2018 (UTC)
          • Agreed. In fact, the attitude expressed above "... Wikipedia is political..." is part of the problem, because such bias constantly and consistently finds it's way into articles, and must be regularly fought against. Wikipedia can't even keep it's own entries neutral, why then should it try to take on the internet? GenQuest "Talk to Me" 14:15, 7 May 2018 (UTC)
            • such bias - what bias are you talking about? The idea that Wikipedia is political is a bias? It's naive/simplistic to think there's some "politics" bogeyman that has infested our encyclopedia that can/should be contained before it dashes some objectivist fantasy about platonic apolitical truths. My point wasn't just about articles, but articles as part of the larger Wikipedian enterprise -- its own qualities and the world it exists in. You have extracted the words "Wikipedia is political" from what I wrote, but responded to those words as though I used them in the way I was arguing against. — Rhododendrites talk \\ 14:51, 7 May 2018 (UTC)
  • Oppose I read the first of the four articles linked above by Guy Macon — the debate between Yoo and Wu. While I personally think the Yoo's arguments were more compelling, This discussion is not (or should not be) a simple vote on whether, on balance, regulation and supportive net neutrality is a good idea. In my opinion, there are some decent arguments on both sides, and as is almost always the case when considering a regulatory proposal the devil is in the details. Delivering a banner in support of net neutrality is not simply a statement that a majority of Wikipedia editors support the concept, but that the support is so overwhelming that we feel it is appropriate to make that statement in the voice of Wikipedia (as was the case with SOPA). I don't think that's remotely the case. On page 577 of the linked article, Yoo makes a similar point:

At this point, it is impossible to foresee which architecture will ultimately represent the best approach. When it is impossible to tell whether a practice would promote or hinder competition, the accepted policy response is to permit the practice to go forward until actual harm to consumers can be proven. This restraint provides the room for experimentation upon which normal competitive processes depend. It also shows appropriate humility about our ability to predict the technological future

--S Philbrick(Talk) 22:55, 6 May 2018 (UTC)
  • Oppose I don't think that Wikipedia should be involved in any kind of activism, period. It isn't clear that Net Neutrality is going to have any detriment on Wikipedia's goals or functionality, and we should not get involved. This RfC is also too soon after the last one. The proposal is in violation of Wikipedia's core concept of conveying information from a neutral pint of view; picture the proposed banner at the top of the Net neutrality page. Does anyone accept that as being NPOV? — Insertcleverphrasehere (or here) 23:41, 6 May 2018 (UTC)
  • Strongest oppose possible as a US citizen without resorting to armed rebellion Not that I dont support net neutrality, and I am taking steps to protect it, its the 2018 mid terms and I have plans to vote against my current representatives due to their ambivalence regarding the issue. Keep politics off Wikipedia. cinco de L3X1 ◊distænt write◊ 00:20, 7 May 2018 (UTC)
I would like to clarify that unlike GM I support Net Neutrality as the only way to save us from the whims of for-profit ISPs, but this is the en.wiki not the US.wiki, something our Tommy editor friends love to remind us. cinco de L3X1 ◊distænt write◊ 01:42, 7 May 2018 (UTC)
@L3X1: To clarify, the proposal is for a banner that will only be shown to US viewers, unless I'm misunderstanding your point. ~SuperHamster Talk Contribs 01:48, 7 May 2018 (UTC)
...which is yet another reason for opposing the idea. The resulting increased US government control over the Internet will affect pretty much all English-speaking countries. --Guy Macon (talk) 14:12, 7 May 2018 (UTC)
  • Support Wintonc7 (talk) 00:44, 7 May 2018 (UTC)
  • Oppose Stop trying to involve wikipedia in politics. Natureium (talk) 00:51, 7 May 2018 (UTC)
  • Oppose - Wikipedia should remain non-partisan and non-political. — Godsy (TALKCONT) 01:00, 7 May 2018 (UTC)
  • Strong support. I'm baffled by the folks above saying that net neutrality wouldn't affect Wikipedia. As for involving Wikipedia in politics, the existence of Wikipedia itself is political. GorillaWarfare (talk) 01:02, 7 May 2018 (UTC)
    • I'm going to flat contradict you on that. The existence of Wikipedia is not political. --Trovatore (talk) 01:40, 7 May 2018 (UTC)
      • And you likewise. Everything is political. We aren't above that. Our licensing, our mission, our assessment of sources, protection of individuals by our BLP policies, the concept of neutrality itself, where we are hosted, where we can't be hosted. All of it is political. We're kidding ourselves by denying that. Seddon talk 03:04, 7 May 2018 (UTC)
        • This is rapidly becoming a very silly argument about definitions. Perhaps we could say that Wikipedia is not about advocating, implementing, or influencing government policy, hm? These things can be tangentially related to our goals under certain circumstances, but participating in activism related to these topics can be problematic. Our differing definitions of "political" do not change that. --Yair rand (talk) 04:10, 7 May 2018 (UTC)
            • In my view there is only a single political question: How, if at all, should the state's monopoly on the use of force be used? Net neutrality is a position on that question. It says that the state should use its monopoly on the use of force to prevent certain economic transactions, by players deemed to have market power, to prevent certain results deemed undesirable.
              The existence of Wikipedia, per se, takes no position on how the state's monopoly should be used.
              Now, it is true that some people have a more expansive notion of "political" than I do. They're entitled to that view. As Yair rand says, we can still formulate the view that Wikipedia should not take political positions in a narrower sense. --Trovatore (talk) 04:22, 7 May 2018 (UTC)
        • Freedom of speech and open access licensing are political in a sense, but they are far from partisan politics. Net neutrality is similar. I believe this is the kind of policy that is directly tied to Wikipedia's core values, and that we should feel proud to share our views on in a public way once every few years.--Pharos (talk) 04:26, 7 May 2018 (UTC)
  • Oppose Just as I opposed the SOPA/PIPA blackout years ago, Wikipedia must remain above the politics of any one (or group of) country. Courcelles (talk) 01:10, 7 May 2018 (UTC)
  • Oppose per Guy Macon. ​—DoRD (talk)​ 01:12, 7 May 2018 (UTC)
  • Oppose: We are here to build an encyclopedia, and nothing else. That mission is better served by maintaining our impartial image than picking fights. – Finnusertop (talkcontribs) 02:20, 7 May 2018 (UTC)
  • Support Mozucat (talk) 02:49, 7 May 2018 (UTC)
  • Oppose while it's tempting to say that Wikipedia shouldn't take political positions, I feel that's largely unrealistic. However, I don't support this proposal, which seems to be unilaterally encouraging people to contact their senators about a bill that is unlikely to be signed by Trump. It is too low-impact to justify a promo of this sort, which must remain rare. power~enwiki (π, ν) 04:37, 7 May 2018 (UTC)
  • I would disagree, it is only a few votes away in the senate, and if it were to pass there, attitudes throughout Washington would be changed. It already has significant popular support, and a "Yes" vote in the senate could signal that. Ultimately our support or lack thereof may prove the deciding factor. -Blervis (talk) 14:17, 7 May 2018 (UTC)
  • Support. I share the same view as Fuzheado, above. Rehman 05:21, 7 May 2018 (UTC)
  • Support. - Jmabel | Talk 05:49, 7 May 2018 (UTC)
  • Oppose per Power~enwiki Galobtter (pingó mió) 07:28, 7 May 2018 (UTC)
  • Oppose per Javert2113 MT TrainTalk 09:13, 7 May 2018 (UTC)
  • Oppose Wikipeda should not be promoting political causes or legislation. —Farix (t | c) 10:41, 7 May 2018 (UTC)
  • Support. Kellyjeanne9 (talk) 11:33, 7 May 2018 (UTC)
  • Support. The cat's out of the bag re: politics (see above about WMF response), and this is an important issue that could affect the internet in a significant way. I see this as like the SOPA blackout, but less disruptive. — pythoncoder  (talk | contribs) 12:24, 7 May 2018 (UTC) on semi-wikibreak
We are not the WMF. We are the English Wikipedia community. We can, and sometimes do, disagree with the Foundation with regards to what best serves our shared mission. – Finnusertop (talkcontribs) 00:08, 8 May 2018 (UTC)
  • Support -- the Australia Fair Use campaign demonstrates that these targeted communications activities, act as a way to communicate to a very focused audience the importance of an open public forum/environment for making Wikipedia work. Wikipedia is political, in that it radically challenges a number of assumptions about knowledge: one of them, "what is the purpose of the internet". Like SOPA/PIPA, net neutrality is an important pre-requisite for our mission -- and its appropriate for our communities in the United States to support it, when it becomes a political issue. Sadads (talk) 12:33, 7 May 2018 (UTC)
So let me get this straight. The Stop Online Piracy Act (SOPA) was a controversial effort to increase the power of the United States government to control and censor the Internet (including the Internet in Australia), so you opposed it, and Net Nuetrality is a controversial effort to increase the power of the United States government to control and censor the Internet (including the Internet in Australia), so you... support it?
  • Support - while I'm generally adverse to slippery slope arguments, it certainly is easier to ensure net neutrality now rather than risk something being problematic in the future (whether related to usage speeds or an alternate area of governmental action regarding net usage). Regarding certain discussion points arguing a futile action due to X & Y, a campaign can influence people other than US senators, so there is benefit to be gained in more than one frontline.
Purely out of interest, does the WMF have an opinion on individual wikis campaigning in this fashion? Nosebagbear (talk) 14:11, 8 May 2018 (UTC)
From The Fear-Based Campaign to Control the Net:
"Unfortunately, as the internet has taken on an ever more central role in our personal and economic lives, the temptation to seize control apparently became too much for the FCC. The political left is invested in the narrative of internet service providers as privacy-violating boogeymen—and the FCC as a heroic digital guardian—not because there is any evidence to support the position but as a means to exercise more control."
From Here’s why the Obama FCC Internet regulations don’t protect net neutrality:
"The FCC staff did their best with what they were given but the resulting Order was aimed at political symbolism and acquiring jurisdiction to regulate the Internet, not meaningful 'net neutrality' protections. [...] Aside from some religious ISPs, ISPs don’t want to filter Internet content. But the Obama FCC, via the 'net neutrality' rules, gives them a new incentive: the Order deregulates ISPs that filter."
--Guy Macon (talk) 14:08, 7 May 2018 (UTC)
  • Strongly Oppose per what is becoming a perennial request, that is a call to a political-ized action by Wikipedia. Most of us are here to make an encyclopedia. As the proposer/supporter, what is YOUR agenda? GenQuest "Talk to Me" 13:37, 7 May 2018 (UTC)
To ensure we can keep writing this encyclopedia and to ensure people can keep reading it. Seddon talk 13:51, 7 May 2018 (UTC)
And giving the US government more power and control over the Internet accomplishes this ... how? --Guy Macon (talk) 14:08, 7 May 2018 (UTC)
Wikipedia was getting along just fine before the net neutrality law went into effect, and seems to be getting along just fine since the expiration of it. I don't understand where this nebulous 'ensurance' of which you speak comes from. GenQuest "Talk to Me" 14:29, 7 May 2018 (UTC)
The only reason net neutrality even had to become a law was because of Verizon Communications Inc. v. Federal Communications Commission (2014). Beforehand, the FCC could enforce net neutrality statutes without it specifically being a law, but the lawsuit made it so the FCC might not be able to enforce the statutes anymore. The law just formalized this enforcement. The repeal of the net neutrality law does not allow the FCC to enforce the statutes anymore, not even informally. Therefore, your comparison of pre-2015 and now is incorrect. epicgenius (talk) 18:31, 8 May 2018 (UTC)
What statutes? There were no statutes. Lumbering, idiotic bureaucracy maybe, but no statutes. And the free market is working/will work just fine without further US government or FCC control of the internet. GenQuest "Talk to Me" 19:31, 8 May 2018 (UTC)
OK, let's say there were no net neutrality statutes that restricted ISPs prior to 2015. I'd expect that if I were an ISP and I had no regulations, I'd be pretty happy. Yet that's clearly not the case: the ISPs kept suing the FCC up through 2015 (e.g. Comcast Corp. v. FCC, 2010), so there's gotta be something must have had pissed off these ISPs. Anyhow, it's not as if the FCC sat back while the big ISPs were all well behaved companies who voluntarily enforced net neutrality. Case in point, in 2005, Madison River had to pay the FCC a fine because it blocked VOIP communications through certain providers - clearly a violation of net neutrality standards. Therefore, it's incorrect that the FCC didn't have net neutrality before 2015, or that it never enforced net neutrality prior to that date.
As for the free market in action, the internet is not like the healthcare or energy sectors where you have a wide range to choose from. The market of ISPs right now, is composed of a half dozen huge ISPs and a smattering of comparatively tiny ISPs. There are smaller ISPs in TN and NC who were prohibited from expanding their services because they would have competed against bigger ISPs. As far as I'm aware, these bans are still in place. If these small ISPs can't compete, then obviously the market is not "free".
TL;DR - Obviously this isn't relevant to the original discussion about whether the banner about net neutrality is appropriate. But if you're going to argue in favor of deregulation, at least get the facts in order. I'm not trying to convince you that the FCC regulation is going to be the cure-all to net neutrality, or that it's even the correct step. I'm simply refuting the misconceptions. epicgenius (talk) 21:00, 8 May 2018 (UTC)
You've made my point. Because there are very few examples of ISPs behaving badly in the past. But, with business being business, sometimes lawsuits ensue and sometimes government has to get involved. Let's take your Verizon example. When Verizon started their throttling shenanigans, the free market actually worked as it was supposed to. That behavior drove subscribers to their (often) much smaller competitors, and actually strengthened the marketplace. Saying ISPs won't be able to compete is simple fear-mongering which can be found on any progressive website out there. Doesn't make it so. News Flash: the internet isn't broken. It's working just fine. No need to man the life boats.
Back when I had my small business, if the big guys did something stupid, I capitalized on that and gained business. It's how competition works. The same thing happened to Verizon. They lost customers and eventually reversed their badly thought-out decisions. Things worked out, in a free market. I for one really, really don't want the US government to have any more bureaucratic control over our internet.
There is also no need for an unnecessary, non-neutral, devisive, controversial-at-best banner placed anywhere around an encyclopedia which touts its neutral voice. GenQuest "Talk to Me" 16:57, 9 May 2018 (UTC)
I concede that you are correct that the free market worked in the particular case of Verizon. I myself am a supporter of small business: my family are small business owners, and we don't want to get crushed by the big businesses. The concept of net neutrality is the same thing. Net neutrality forces ISPs to treat small businesses' traffic the same way as big businesses', regardless of whether the ISP is a multinational corporation or a small outlet like the local public library.
When you say I for one really, really don't want the US government to have any more bureaucratic control over our internet, that is a laissez-faire approach, not necessarily a free market. A free market allows companies to thrive, even with some regulation, while the laissez-faire approach is a lack of any meaningful intervention by the government.
Now the problem here is that, with the laissez-faire approach, larger companies can snuff out smaller competitors, which is the opposite of a free market. There are still state laws that prohibit small ISPs or municipal ISPs from expanding, which actually prevents a free market from happening. Even if a small outlet like Greenlight wanted to expand, they couldn't, because it would be illegal. The larger ISPs are usually the only choices available to most of the population in these states, as I mentioned. Net neutrality makes the playing field easy for everyone from the start; you still have a free market, but the big ISPs aren't just going to be allowed to bully smaller ISPs. Net neutrality includes the concept that if you wanted to create your own ISP, the big ISPs would not be able to block your traffic - which is good for free market competition.
TL;DR: Wikimedia is not being non-neutral by advocating for a neutral position. A laissez-faire approach is not necessarily the same as a free market; the free market will still exist with net neutrality. epicgenius (talk) 14:14, 10 May 2018 (UTC)
  • Strong oppose. There seems to be too much focus among respondents on the goals of net neutrality and not the specific effects. I did research over the net neutrality debate for a speech class not particularly long ago, and I confess not being impressed by what I read. The ban on paid prioritization is pointless, as its effects already exist and are implemented without a paywall; instead it depends on the ability to purchase the relevant hardware. For example, it is relatively common for major websites to purchase dedicated servers at ISPs to expedite the speed at which they are processed. This website does a good job of explaining the details. Proposed net neutrality regulations fail to address this aspect of prioritization. The second issue raised, content blocking, is also not particularly important; I have only found one instance when an ISP used its status as an ISP to disrupt access to a website, and that's with Comcast throttling BitTorrent because the latter is extensively used to host copyright violations of movies. Wikipedia does a satisfactory job of policing copyright problems, and its popularity and humanitarian mission would make any attempt to throttle it deeply unpopular.
Consequently, I don't believe that Wikipedia is threatened by the issues purported by net neutrality supporters, and agree with TonyBallioni's statements that it could feasibly benefit from the regulations not existing. I will also argue that US regulatory agencies have histories of issuing absurd, impossible orders to enforce regulations, and that in this regard Wikipedia may actually be threatened by regulatory creep. I will also echo the sentiments expressed by numerous editors above: using Wikipedia to host a banner gives the impression that net neutrality is supposed by the Wikipedia community as a whole, and the controversy of this and previous RfCs clearly indicates that this is not the case. Furthermore, wading into activism for political issues undermines the project's appearance of being a neutral, independent source of information. Between the sacrifice of perceived neutrality and the lack of tangible benefits to the project, I must consider the promotion of net neutrality to be a net malus. Compassionate727 (T·C) 14:11, 7 May 2018 (UTC)
  • Strong oppose: The entire discussion is turning into a political soapbox. While the Wikimedia Foundation can make political statements on behalf of itself, Wikipedia is a community project, and all of its decisions should reflect the consensus of its users and our core policies. In fact, a proliferation of support for net neutrality would actually place undue weight on the corresponding POV, as it will not equally promote counterarguments. Unlike SOPA, which was a much more clear-cut issue, Net neutrality is a more contentious issue, and in fact, the WMF had previously been involved in initiatives that blatantly violate its principles. ViperSnake151  Talk  17:12, 7 May 2018 (UTC)
  • Strong oppose for all the reasons mentioned above. Contact me for further information. Brian Everlasting (talk) 15:30, 7 May 2018 (UTC)
  • Strong support There are plenty of times when one would be right to worry about "expansion of government power", but this is not one of them. Regulating industry for the purpose of protecting the citizens is a good thing for a government to do. (And, no, we can't trust the Free Market(TM) to save us when consumers have no choice among providers; nor is it all hypothetical: Comcast throttling BitTorrent — which blocked legitimate content as well as piracy — is only one example of ISP bad behavior [15].) I'm here to build an encyclopedia, but I'd like for people to be able to read that encyclopedia without Wikimedia having to slide cash under the table to Comcast and Verizon. And, frankly, in the current climate of the United States, wanting to build an encyclopedia — that is, holding education to be worthy and facts to be important — is itself a political act. XOR'easter (talk) 16:17, 7 May 2018 (UTC)
I assume your reference to Comcast-BitTorrent is partially directed at me, as I'm the one who mentioned it, so I should take the time to reply. I'm aware of the ACLU page, and in fact relied extensively on it in my research. But the other examples provided there aren't relevant, and I'll explain why:
  • AT&T's censoring of portions of the Eddie Vedder concert utilized the fact that AT&T was the official sponsor and sole provider of that concert. Their censoring actually made sense and was in my view justified, as the fact that they were a sponsor would have made it appear as though they were endorsing that political message when they weren't.
  • Verizon's discrimination against NARAL Pro-Choice America affected their text-messaging service, meaning that it involved their status as a cellular provider, not an ISP. Cell services are already regulated for this, and fall outside the scope of net neutrality anyway.
  • Telus is a Canadian ISP, so any regulations passed here don't seriously affect them.
The other claims you make have already been addressed elsewhere. Compassionate727 (T·C) 20:57, 7 May 2018 (UTC)
Expanding a little. tl:dr; The personal is political. "free knowledge is inherently radical"
Here's my reasoning. I'm a socially left (US left) leaning person living out the outskirts of a moderately sized urban center. Grew up rural. I'm more central (US central) when it comes to government, regulation, capitalism, etc.
I have two choices for my ISP. Both are large companies. Most folks, across the United States where this proposal will be most impactful, have an ISP like mine. ISPs, the large ones especially, can be considered government approved monopolies. Decades ago, taxpayers funded the initial cable to wire up the country. In exchange these companies are given exclusive status to prevent other companies from laying down their own wire. AT&T, as one of the oldest telecom companies in the country, just rents use of their wires to other ISPs, big and small.
I don't like the government sanctioning monopolies. That's a little libertarian sounding, I realize. If the government is going to do it though? They better regulate them. A government-sanctioned monopoly should follow the same restriction the government itself does for it's own utilities. That includes this kind of neutrality. I want companies like Comcast to have less power to coerce and distort the market. This is a complex, nuanced matter. While you might be against regulation in other areas, such as energy, or financial markets, or whatever - accepting this one actually works in our favor as a community, project, and movement. Ckoerner (talk) 18:08, 7 May 2018 (UTC)
  • Question - Maybe I'm missing it, but what is the timeline for this discussion? If the event people would "take action" about is on the 9th, today is the 7th. Is there a plan for a specific point to stop discussion ans assess consensus about this? — Rhododendrites talk \\ 16:47, 7 May 2018 (UTC)
  • Answer It doesn't have the votes here, desn't have the votes in congress[16], would likely be vetoed if it did have the votes, and would not accomplish what this RfC claims that it would accomplish.[17] --Guy Macon (talk) 20:24, 7 May 2018 (UTC)
  • The question was not "Would someone be willing to restate their opinion, but with the word 'answer' in front of it?" Alternatively, someone quoted Inigo Montoya elsewhere in this thread in a way that seems relevant re: "answer". — Rhododendrites talk \\ 20:42, 7 May 2018 (UTC)
  • I think these things normally run for 30 days or so? It would take a truly extraordinary consensus to justify accelerating the timeline to two or three days, just because of the timing of the vote in the Senate. I don't see that here; it's not clear there will be a consensus at all, but certainly there is no evidence of the sort of overwhelming consensus that could justify such a radical departure from our normal procedures. --Trovatore (talk) 20:55, 7 May 2018 (UTC)
  • An RfC typically runs for 30 days, yes. This is not technically an RfC, and I imagine that's intentional, given the time constraints. It would not be the first time we have had a discussion on a shorter timescale, but I do tend to agree that there should be a pretty clear consensus in such cases. — Rhododendrites talk \\ 21:05, 7 May 2018 (UTC)
  • Strong oppose - Wikipedia is an encyclopedia, not a platform for political statements supported by a majority of the few editors who happen to show up in a discussion on this page. That's regardless of the merits of the issues or how Wikipedia might be affected by them. We are Wikipedia editors, not political activists (although each of us is free to be a political activist off-wiki). In my view, this proposal should go the way of the proposal to show an anti-Trump statement before the U.S. presidential election. Furthermore, I think we should consider an explicit policy against using the encyclopedia as a platform for political statements. ―Mandruss  19:18, 7 May 2018 (UTC)
  • Support as critical to Wikipedia's mission. Headbomb {t · c · p · b} 19:48, 7 May 2018 (UTC)
    • So it is your position that a US government regulation that did not exist until 26 February 2015 and was repealed on 14 December 2017 (and pretty much not enforced during most of the 2 years, 9 months and 19 days it was on the books) is somehow "critical to Wikipedia's mission"? Critical?' In the words of Inigo Montoya, "You keep using that word, I do not think it means what you think it means."[18] --Guy Macon (talk) 20:13, 7 May 2018 (UTC)
    • Net neutrality has de facto existed since the beginning of the internet. Net neutrality law is a more recent response to threats to the status quo that made a crazy project like Wikipedia possible, and you can disagree about any specific regulation, but the principle indeed remains critical to an open internet.--Pharos (talk) 20:28, 7 May 2018 (UTC)
      • My position is that net neutrality was in effect for pretty much the entire existence of the internet, until corporate interests decided to attack it, and now it needs defending. The principle was first enshrined into law/regulation in 2015, but it existed before. The issue is that the regulation/law has been since overturned to allow for violations of the principle. And yes, critical. Because otherwise a carrier may very well decide to have a surcharge for Wikipedia traffic, so they can send their subscribers to a Wikipedia mirror full of ads instead. Headbomb {t · c · p · b} 19:36, 16 May 2018 (UTC)
  • Support: This issue affects Wikipedia and its users directly. It also has significant impacts for users who access the internet via smaller ISPs who are not affiliated with the major telecom companies. While in general WP needs to remain NPOV, it does not need to be silent on matters that relate to its core mission. Montanabw(talk) 20:26, 7 May 2018 (UTC)
  • Support shoy (reactions) 20:45, 7 May 2018 (UTC)
  • Oppose One of the pillars Wikipedia is built on is having a neutral POV. There are many other outlets that can voice opinions on Net Neutrality, however I do not feel that Wikipedia should be one of them with this message front and center as this proposal would be. RickinBaltimore (talk) 20:50, 7 May 2018 (UTC)
  • Oppose - let twitter and facebook do things like this. This feels too close to an ad or as Rick above says, a POV statement. I like WP because it is above politics or conflicts - it is a font of knowledge, nothing more. There ARE exceptions, mainly during the donation drive. But, this should not be an exception, imo. ‡ Єl Cid of ᐺalencia ᐐT₳LKᐬ 20:54, 7 May 2018 (UTC)
  • Support   - Mark D Worthen PsyD (talk) 20:58, 7 May 2018 (UTC)
  • Oppose this is an apolitical project, as much sympathy as I might have for this. The SOPA/PIPA blackout set a bad precedent that shouldn't be repeated. Mélencron (talk) 21:04, 7 May 2018 (UTC)
  • Strongly Oppose Net Neutrality is just a means to allow big content providers to dictate what gets distributed. Indyguy (talk) 21:09, 7 May 2018 (UTC)
  • Oppose Am agnostic about NN, but I find the apocalyptic scenarios unpersuasive and often tinged by hysteria. Wikipedia's neutrality shouldn't be thrown away for such a hobby-horse. NPalgan2 (talk) 21:16, 7 May 2018 (UTC)
  • Oppose It's best for the WMF not to get involved in matters that can be perceived as being political issues. BillHPike (talk, contribs) 21:17, 7 May 2018 (UTC)
  • support--Ozzie10aaaa (talk) 21:19, 7 May 2018 (UTC)
  • Strong support - In the interest of being accessible to all, it would be remiss for Wikipedia to not get involved in issues of accessibility to the Internet. You can't be neutral on a moving train. Etzedek24 (Would it kill ya to leave an edit summary?) 21:23, 7 May 2018 (UTC)
  • Oppose. Wikipedia isn't everything. It doesn't have to take a stance on a question external to Wikipedia. We shouldn't speak as a united voice because essential to our nature is objectivity. Bus stop (talk) 21:48, 7 May 2018 (UTC)
  • Support Napplicable (talk) 21:54, 7 May 2018 (UTC)
  • Strong Support Accessibility is extremely important. Megalibrarygirl (talk) 00:47, 8 May 2018 (UTC)
  • Strong Support per User:Fuzheado. OhKayeSierra (talk) 00:53, 8 May 2018 (UTC)
  • Oppose While I am sympathetic to net neutrality, the debate about it is a partisan matter, and with extreme exceptions, Wikipedia should remain neutral and not involve itself in political affairs. Narutolovehinata5 tccsdnew 01:50, 8 May 2018 (UTC)
  • Support, while I'm opposed to the idea of Wiki(p|m)edia being involved in politics or activism in general, the exception is when something is a direct threat to our mission. A lack of net neutrality threatens efforts like Wikipedia, for not-for-profit entities to make information and knowledge freely available. In this case, then, we should speak in favor of net neutrality and against any type of preferred traffic being permissible. Seraphimblade Talk to me 02:02, 8 May 2018 (UTC)
  • Oppose: per NPalgan2. --MZMcBride (talk) 02:31, 8 May 2018 (UTC)
  • Support - making knowledge freely accessible to everybody is the most political, the most power changing, act that anybody can do. And it is our mission. Making all internet content equally accessible is the only way we can accomplish our mission - otherwise we can be censored for "economic reasons", i.e we may not be profitable to ISPs. Smallbones(smalltalk) 02:51, 8 May 2018 (UTC)
  • Oppose per above, I don't think it is appropriate for Wikipedia to be making political statements. And for the record, I do strongly support net neutrality. -FASTILY 03:05, 8 May 2018 (UTC)
  • Complete and utter Oppose this is an encyclopaedia, not a political party, an activist group nor a debating society. Let us concentrate on the task of making the sum of human knowledge available and leave the politics out of it. No matter how much some of us feel that some political issue is important, it does not belong here. -Nick Thorne talk 07:40, 8 May 2018 (UTC)
  • Very, Very Strong Support. Wikimedia's mission depends in part to net neutrality, so if they support it, this banner is fine. I don't get what all of the opposes are about. Are people being bought out by ISPs and big businesses? This is sarcastic, just so people don't take this last comment at face value.
    But in all seriousness, this isn't a political question. It's a question about whether ISPs can throttle access to sites like Wikipedia, thereby compromising its mission. And it's not really even a political question with that much opposition from the general public. Polls have shown that more than 80% of Americans do support net neutrality. epicgenius (talk) 11:12, 8 May 2018 (UTC)
This is certainly a political question because it boils down to an issue of free enterprise vs government regulation. ISPs provide services people want and if people want access to Wikimedia or anything else they will get it. As far as your 80% poll, I suggest that if that is true, it can be attributed to the benevolent-sounding name and ignorance. The US has supported spending on reducing poverty for over 50 years, but if you asked people if they would support "Spending $22 trillion with no improvement" [19] would they support that? How you ask the question is important. MB 12:37, 8 May 2018 (UTC)
Yes, the wording is definitely important. But it doesn't change the concept of net neutrality which is to protect against unethical practices such as some content being prioritized over others. Here are some more surveys with different wording that support the idea that the vast majority of those who know about net neutrality support it. Net neutrality opponents argue that ISPs can self-police, but that's obviously not true. The truth is that without net neutrality, there is theoretically nothing to stop ISPs from burying Wikipedia links in favor of sponsored content, or even fake news stories. That really is against Wikipedia's mission.
In regards to being a political question, normally I'd agree that this would be a political dispute that should be kept off Wikipedia. However, net neutrality is an issue that directly affects this project. A banner is not even asking much. If net neutrality is such a politically charged situation, by that reasoning we shouldn't have had that huge anti-SOPA and anti-PIPA blackout six years ago. That was basically the same thing, except the entire project was inaccessible for 24 hours. A banner is not as obtrusive, it's simply asking to consider how Wikimedia projects would be like without net neutrality. epicgenius (talk) 13:03, 8 May 2018 (UTC)
I do not need the Federal government to protect me from unethical practices by ISPs. Government regulation really means transferring more power from the citizenry to the government. Since the government is far more corrupt than businesses which have to provide services people are willing to pay for in order to survive, it should be kept to a minimum as envisioned in the US Constitution. You have no idea what the would happen without "net neutrality" - your fears are purely theoretical. I happen to believe it will continue to get better at a faster rate with less regulation. MB 15:34, 8 May 2018 (UTC)
@MB: I don't agree with these points or think they make total sense, and I'm not trying to change your mind on this, but I'll just say my piece so others can understand my position: epicgenius (talk) 16:35, 8 May 2018 (UTC)
The rules reclassifying internet traffic under Title II of the Communications Act of 1934 were codified in 2015; but before that, it had been a de facto assumption that the ISP would act ethically. The FCC did not need to explicitly say that the ISP had to act ethically; it simply enforced ethical standards. But in 2015 the FCC enacted the rules due to lawsuits from Verizon (Verizon Communications Inc. v. FCC, 2014) and other ISPs that claimed the FCC was overreaching. Title II was the recourse because all the other methods of enforcement failed. The "net neutrality repeal" was not just a counteraction to the Title II classification; it also made it so that the FTC, not the FCC, was in charge of enforcing net neutrality standards. It just transfers enforcement from one government agency to another, but the FTC also doesn't have as much resources to enforce such rules.
As to your other points, they are political arguments so they are subjective. However, I will address them with factual evidence. To be fair, I may be a little biased because I did all of this research while writing the article on Net Neutrality (Last Week Tonight).
  • Regarding government is far more corrupt than businesses which have to provide services people are willing to pay for in order to survive - you are allowed to your opinion that the government is corrupt. But let's look at the facts: in large parts of the US, there is very limited choice in broadband providers. A 2010 study by broadband.gov showed that 96% of Americans have, at most, 2 providers to choose from. Here's another article from June 2017 which states that many people only have one high speed provider, or none at all.
  • You have no idea what the would happen without "net neutrality" - your fears are purely theoretical. - This is factually wrong. ISPs have blocked or slowed down access to competitors, promoted their own items, and even forced companies to paid for higher speeds. There are many examples of this. I think the most prominent is when Comcast slowed down Netflix speeds back in 2014 until Netflix agreed to pay a fee to Comcast.
  • I happen to believe it will continue to get better at a faster rate with less regulation. - Again, you are entitled to your opinion. Under normal circumstances, I would agree that if you leave the companies be, then they will be allowed to grow. But you are also missing an important point: the larger ISPs have successfully lobbied for laws that effectively shut out competition. In Wilson, NC, Greenlight tried to expand but they were blocked by a statewide restriction against municipal broadband - sponsored by private ISPs like Time Warner. And mind you, this restriction had bipartisan support. Same thing happened in Chattanooga, TN.
TL;DR - There are a lot of factors in play here. While the FCC's actions should technically be growth-inspiring and innovation-supporting, other actions at the state and federal level have made it so that this is essentially a monopolistic competition between a few large ISPs. I think everyone would agree that it would be better if a greater competition among ISPs was allowed, but this is unfortunately not the case right now. I would like to repeat that you are entitled to your opinion, MB. I'm not trying to change your mind, but I think there are many things to take into account here. epicgenius (talk) 16:35, 8 May 2018 (UTC)
Addendum to previous comment: A lot of the political controversy boils down to "Obama/Democrats/liberals/the left likes net neutrality so therefore I hate it". This shouldn't be one side versus the other. In reality, there is nothing not neutral about something that literally has the word "neutrality" in its name. Some of the strong opposers are arguing that this Central Notice is not a neutral message. This is true to some extent, but for political reasons, not because the concept of net neutrality itself is wrong. However, as I have personally observed, this is based on a lot of mistaken thoughts or suppositions about what should be the case (i.e. political views about laissez faire market), and not a lot of what's actually the case (i.e. the difficulties that smaller competitors face in a non-neutral internet). This issue is more complex than what is being presented as face value. epicgenius (talk) 15:26, 10 May 2018 (UTC)
  • Oppose - Admittingly I'm divided between the 2 - On one hand Net Neutrality is important, On the other we're not a platform for political statements ..... Whilst I did support the whole SOPA/PIPA thing compared to 2012 social media is used a hell of a lot more now (and SOPA/PIPA was different) and as noted above we should remain neutral on this (Not everyone's going to agree with Net Neutrality),
In short if anyone agrees or disagrees with it then they're more than welcome to sign petitions and use social medias - I know the project is American and all that but in my eyes as I said we should remain neutral on this and this project should not be used for political things. –Davey2010Talk 13:48, 8 May 2018 (UTC)
Hi Davey2010, I don't believe we've interacted before, but I have a curious question I hope you can help me with. You, and others in this conversation, have said, we're not a platform for political statements. I've always understood that the content of the Wikipedia project should be neutral, well cited, from reliable sources. Free from politics as it were. I think we all agree on that. :)
The confusion, and why I'm asking this question, is about the movement of people behind the projects. The work we do as a community is a political statement. We say, "Free knowledge for all". That is a rather radical statement to make (much less actually do) when you look at how, and by whom, knowledge was created and shared in the past. I think it's this last part we seem to have the most disagreement on as a community and particularly in this conversation. I would love to understand more why that is. From yourself and others if they're willing to humor me here or on my talk page. Yours, Ckoerner (talk) 20:40, 8 May 2018 (UTC)
  • Oppose - I support Net Neutrality, but we are not a political platform. - Knowledgekid87 (talk) 14:32, 8 May 2018 (UTC)
  • Strong Support Net neutrality is crucial to our goals in WP. SusunW (talk) 14:44, 8 May 2018 (UTC)
  • Oppose - Wikipedia should only take a political position in response to an existential threat. A very credible argument can be made that SOPA/PIPA rose to these levels, but I don't see the severity here. I'm happy to flip if the argument that net neutrality is an existential threat to WP can be made, but I haven't seen it made yet. Tazerdadog (talk) 22:55, 8 May 2018 (UTC)
  • Strong oppose Direct advocacy on a political matter is about the farthest you can get from maintaining neutrality. "Please do not add commentary, your own point of view, or your own personal analysis to Wikipedia articles", to quote {{uw-npov2}}. Go start a blog if you want to publicize your opinions about political matters, whether in your own country or another. Nyttend (talk) 22:58, 8 May 2018 (UTC)
  • Strongly oppose Let's not get Wikipedia in the habit of advocating the progressive cause du jour. It's not going to convince anyone who isn't already sympathetic to the viewpoint, but it will alienate those who oppose it.—Chowbok 06:36, 9 May 2018 (UTC)
  • Support I'm on this project to reduce walls between people and knowledge. Quiddity (talk) 06:37, 9 May 2018 (UTC)
  • Oppose, mostly per Ajraddatz's remark. --Vogone (talk) 10:25, 9 May 2018 (UTC)
  • Strong oppose The Wikimedia Foundation should be less hypocritical. They spearheaded the anti-netneutrality Wikipedia Zero program knowing full well Facebook and Google would use it to justify their own Zero-rated programs. Refusing to entertain arguments that parts of the US have as much need for WP0 as existing deployments. Their actions speak louder than words and if this run it should rewritten to reflect their past actions ("Rules for thee, not me"). — Dispenser 11:24, 9 May 2018 (UTC)
  • Support I've shown my support in the past for this, and still support it now. Esp. with something as low key as a geofenced banner. —TheDJ (talkcontribs) 12:01, 9 May 2018 (UTC)
  • Oppose I appreciate that editors feel strongly about this issue and share many of their concerns. But on Wikipedia the impartial credibility and integrity of this project should be our primary concern - advocacy activities should be a very rare exception reserved for imminent direct threats to Wikipedia's core mission. Also, some of the outlined speculative scenarios seem exaggerated or are still under discussion among experts. The net neutrality dispute, while serious and concerning, is not a direct imminent threat to Wikipedia. GermanJoe (talk) 12:25, 9 May 2018 (UTC)
  • strong support It is important that we speak up for this, as one of the only non-profits and public spaces on the internet that is *not* beholden to corporate interests, and thus as a project that can speak with authority on behalf of *users* of the internet -- not on behalf of companies trying to make a buck. -- phoebe / (talk to me) 12:46, 9 May 2018 (UTC)
  • Support This project is made possible by the free and open internet. 10Eleventeen 13:01, 9 May 2018 (UTC)
  • Support, while Wikipedia should stay neutral on almost all everyday political topics, Internet regulation (or lack thereof) directly affects us, so we should take a stand and defend our position so we can continue to be neutral in the future. —Kusma (t·c) 14:16, 9 May 2018 (UTC)
  • Oppose we are not a political platform. Ealdgyth - Talk 14:22, 9 May 2018 (UTC)
  • Oppose - is not in accord with the WP:Five pillars, specifically Wikipedia is not a platform for advocacy. -- Netoholic @ 20:07, 9 May 2018 (UTC)
  • Oppose Although I have rarely edited recently, I still frequently read articles, and I find CentralNotice and other banners to be very distracting. I also believe that this would constitute using Wikipedia as a soapbox, which I disagree with. Finally, the rules change is not nearly as disastrous as some people have indicated, as it is only restoring similar regulations to 2013, and Wikipedia had no difficulty existing then. Gluons12 | 17:30, 9 May 2018 (UTC).
  • Oppose Per Guy Macon and WP:NOT. Mr Ernie (talk) 00:29, 10 May 2018 (UTC)
  • Support, and especially support identifying now, gradually over time (and not in response to any particular campaign), the areas of policy around copyright, the Internet, and other topics which are core to wikimedia's work and not generic advocacy. – SJ + 03:18, 10 May 2018 (UTC)
  • Support. xplicit 04:06, 10 May 2018 (UTC)
  • Support This proposal links readers to a relevant page where they can learn about an important ongoing political topic. I think that is by itself a benefit to our readers, and one that in my mind outweighs the nuisance of a banner (at least this one's somewhat unintrusive with the coloring). An additional benefit is that the Wikimedia Foundation has come out in favor of this position, meaning it would help inform readers about something the WMF thinks will be good for the encyclopedia (and the readers by extension). Wugapodes [thɔk] [ˈkan.ˌʧɻɪbz] 06:57, 10 May 2018 (UTC)
  • Support. Andrevan@ 06:54, 11 May 2018 (UTC)
  • Oppose. While I favor net neutrality and dislike many of Ajit Pai's opinions (and his lame videos), WP is not the place for politics. Glrx (talk) 17:15, 11 May 2018 (UTC
  • Oppose Per Dennis Brown, TonyBallioni, Guy Macon, Ajraddatz, ICPH, Mandruss, Nyttend, and others, without prejudice to Net Neutrality. Granted, the WMF and most of its servers are based in the US, but all the encyclopedia users and contributors are in the clouds - and not only above the US but also throughout the whole world. Wikipedia encyclopedias should not be dominated by American politics - who or whatever the WMF is, Wikipedia is already a global thing. The only way political action of this kind would be tolerable would be if the WMF owned server farm and its connectivity were physically threatened by any US policy, in which case, along with the WMF corporate identity and staff, it would then have to relocate to a more traditionally neutral territory. Kudpung กุดผึ้ง (talk) 07:30, 12 May 2018 (UTC)
  • Oppose. While I support net neutrality in terms of government policy, Wikipedia should stay out of partisan politics in view of our own policy of WP:NPOV. Sandstein 07:40, 12 May 2018 (UTC)
  • <Troll/sock comment removed and troll/sock blocked.> Boing! said Zebedee (talk) 09:56, 12 May 2018 (UTC)
    • Why don't you log into your real account instead of using sockpuppetry to avoid scrutiny. Had I not already opined, I would remove this as trolling. Dennis Brown - 09:52, 12 May 2018 (UTC)
  • Very Strong Support Important issue not just to the U.S. but to Wikipedia as well. There are many benefits to doing this, and virtually no drawbacks. Davey2116 (talk) 18:15, 12 May 2018 (UTC)
Commment there are very big drawbacks - offending volunteer editors who do not support increased government regulation of private activity. If you want to lobby for this policy, by all means go do so in any way to want to personally. But don't do so under WP's name which implicitly makes me a supporter. MB 19:17, 12 May 2018 (UTC)
  • Your argument would be more convincing if the subject were something like tax or healthcare policy. But we're talking about net neutrality, which directly affects Wikipedia, so I think this banner is justified, as it was for SOPA/PIPA in 2012. Davey2116 (talk) 19:28, 12 May 2018 (UTC)
I agree net neutrality directly affects Wikipedia. However you think it is positive while I think the effect would negative - there will be unintended consequences and it will slow the rate of technological progress. I don't believe "Free knowledge depends on net neutrality" and don't want to forced to be part of the "we" that is asking for support. WP should not take any position.MB 19:45, 12 May 2018 (UTC)
  • I'm not sure what "unintended consequences" you are referring to. Net neutrality has been the status-quo since the beginning of the Internet, and it has not been a hindrance to technological progress. If anything, covert 'bandwidth throttling' by ISPs (as has already been done by Comcast to BitTorrent, by AT&T to Apple, by Verizon to Netflix, etc.) would slow technological progress, and this is exactly the type of activity that net neutrality laws were formalized to prevent. Wikipedia would like to ensure that it does not become the next victim of such oligopolistic tactics; the reader should interpret "we" as the Wikipedia, not its entire base of editors. Davey2116 (talk) 22:40, 12 May 2018 (UTC)
The status-quo since the beginning of the internet has been Laissez-faire which allowed great technological progress. Net-neutrality is the opposite of that, putting the industry under the regulatory purview of the FCC which will have negative consequences as explained here. I have no fear that WP will become a "victim" of free-market capitalism but rather a benefactor. MB 22:59, 12 May 2018 (UTC)
  • How is that? Where would Wikipedia procure the funds necessary to gain access to the "speedy service" lane? I am 100% sure that Wikipedia will be hurt by the repeal of net neutrality; how many more $3 donations per year do you think there can be? Also, net neutrality has been the status quo (you can't argue with that fact) and the laws passed in 2015 only formalized those principles. Net neutrality and laissez-faire are not completely incompatible; net neutrality is not the abolition of the free market. On the contrary, net neutrality ensures a fair market, so that not too much power is concentrated at the hands of a few large ISPs. Your talking point is that the whole purpose of laissez-faire is competition, which drives innovation and efficiency; I completely agree with that, and I think repealing net neutrality hurts those goals by stifling such competition and allowing unfair business practices. (Further reading.) Davey2116 (talk) 01:38, 13 May 2018 (UTC)
  • @Davey2116: I agree with the gist of your argument. However, I don't think you should try to convince opponents to switch to "support". Most of the editors who post here with an opinion on net neutrality are set in their beliefs, and trying to convince them will result in the backfire effect. Regarding Also, net neutrality has been the status quo [...] net neutrality is not the abolition of the free market. I had actually mentioned a very similar thing in my comments above.
    (Side note: MB's comment about the pre-2015 Internet being laissez-faire is totally wrong. The FCC enforced net neutrality by filing lawsuits against violators such as Verizon. This is the opposite of what laissez-faire means, which is "leave things be and don't intervene".) epicgenius (talk) 23:54, 13 May 2018 (UTC)
Even if the notice were implemented, it would have to include a prominent disclaimer similar to: This message is supported by 59% of 0.8% of the active editors of English Wikipedia.Mandruss  21:44, 12 May 2018 (UTC)
  • I don't think this disclaimer is necessary. The message is made on behalf of Wikipedia and the Wikimedia Foundation, not its entire base of editors. Davey2116 (talk) 22:40, 12 May 2018 (UTC)
I don't know how many causal readers are able to discern this. Any such banner should have a disclaimer.MB 22:59, 12 May 2018 (UTC)
1. WMF can advocate any position it wishes to advocate without using the encyclopedia as a delivery vehicle. 2. Wikipedia is its entire base of editors. Not the self-selected few. We will not make any statement on any political issue without making it crystal clear that it is the opinion of a minuscule fraction of the editing population, period. ―Mandruss  23:20, 12 May 2018 (UTC)
  • I'm not completely opposed to such a disclaimer; I was just going on the SOPA precedent, where the banner had no such disclaimer (so your claim that we always put a "crystal clear" disclaimer is categorically false). Also, as the Wikimedia Foundation owns Wikipedia, it can advocate any position using Wikipedia as the vehicle as it wishes (though doing so for any position other than those that directly concern Wikipedia (i.e., other than Internet law) would obviously damage its reputation). Davey2116 (talk) 01:38, 13 May 2018 (UTC)
Thanks for the correction. What I meant, which I thought was obvious enough, is that I will vigorously oppose any such use of the encyclopedia on the say-so of the self-selected few. It's patently wrong, but I can't force anybody to see that. Thankfully, it looks like I'll have plenty of self-selected company. ―Mandruss  01:50, 13 May 2018 (UTC)
  • Okay. Don't get me wrong, I'm also annoyed that a (relatively) small group of people are 'deciding' for the whole of Wikipedia in this survey (especially since newcomers may find the village-pump very obscure). But this is the system we have, and we'd have to move mountains to change it. Davey2116 (talk) 03:51, 13 May 2018 (UTC)
  • Oppose Wikipedia has been built by volunteers from all walks of life and political alignments, and it never should be hijacked for a political campaign. --Pudeo (talk) 01:31, 13 May 2018 (UTC)
  • Oppose Wikipedia and politics should not mix. We have editors who support the governmental initiative, we have editors who oppose it, and we have editors who are neutral. We should--in this forum--be neutral. Editors should feel free to express their views any way they choose outside of Wikipedia. For Wikipedia to take a position would imply to the outside world that there is a voting system and a majority polling took place when really it could be just whatever a passing closing admin (or user) decided a conversation built as consensus from those who participate. We should avoid taking a position on issues like this as a matter of policy.--Paul McDonald (talk) 04:15, 13 May 2018 (UTC)
    • Paul McDonald, are you aware that Overwhelming Bipartisan Public Opposition to Repealing Net Neutrality Persists («Eighty-six percent oppose the repeal of net neutrality, including 82% of Republicans and 90% of Democrats)»? There is only one fringe extremist political position here, and it's the idea to repeal net neutrality. Not speaking against the repeal of net neutrality means, in fact, to acritically adopt a party line. To be neutral, Wikimedia needs to support net neutrality. Then, of course, one can say that there are different degrees at which we can support the bipartisan view. --Nemo 04:18, 17 May 2018 (UTC)
      • I disagree that "to be neutral, Wikimedia needs to support net neutr4ality." That's the opposite of "neutral" -- that's taking a position. And we shouldn't do that as a community.--Paul McDonald (talk) 12:57, 17 May 2018 (UTC)
  • Oppose This seems very against the policy of being Here to build an encyclopedia, bordering even on WP:SOAP. Wikipedia is here to build an encyclopedia, not as a platform for points of view. [Username Needed] 08:43, 15 May 2018 (UTC)
  • Comment Saying that if one USA party adamantly opposes something then an issue automatically becomes partisan and all sides must be considered equal is bothsidesism. --Nemo 19:58, 15 May 2018 (UTC)
  • Support, because even if Wikipedia was created at a time when the rules were dodgier, I believe that allowing ISPs to throttle back on certain services is laying the groundwork for future trouble for us. Also, the comments about us being apolitical are completely off the mark. Yes, we're a non-partisan resource, and we should continue to be. But we're not "neutral" in some abstract sense of the term; we have our definition of neutrality, based on presenting what reliable third-party sources say. The sources are literally all that matters; the views of political parties anywhere really don't matter a damn. So we write about climate change and Darwinian evolution as facts, we write most of our articles within a human rights framework (because that's what most scholars use), we're critical of the anti-GMO movement, critical of eugenics, etc, etc. A political party taking a stand on an issue is not a reason for us not to do so. Politicians can say what they like; this could threaten our mission, and that's all that matters. Vanamonde (talk) 06:26, 16 May 2018 (UTC)
  • Support. We weren't always one of the top 5 websites in the world, and the only way we became that is because of effective net neutrality, because we would not have had the money to pay providers for speedy treatment. Same for most every other nonprofit, or startup, and especially nonprofit startup. --GRuban (talk) 20:38, 16 May 2018 (UTC)
  • Oppose - What the proposer is actually asking is whether he can use Wikipedia to promote his own political viewpoint, and the answer to that ought to be a resounding NO! --Ykraps (talk) 05:18, 17 May 2018 (UTC)
    • I agree. Even if a full audit was taken of all registered editors and active users that are not registered, and it could be validated, and exactly 100% of everyone supported the issue--if it were truly unanimous--Wikipedia should still remain neutral on all topics.--Paul McDonald (talk) 15:17, 17 May 2018 (UTC)
  • Comment I have already !voted above, but I urge an immediate close as 1) there is clearly no consensus, and 2) the vote in the Senate has already happened, making this proposal as stated moot. Gluons12 | 14:04, 17 May 2018 (UTC).
The senate is not the only governing body that has to approve this. It still has to pass in the House and be signed by the president. --Ahecht (TALK
PAGE
) 16:03, 17 May 2018 (UTC)
  • Oppose This has no interest with Wikipedia. – TheGridExe (talk) 02:32, 18 May 2018 (UTC)
  • Support I've read every comment, and after deliberating I strongly support this. This is beyond a political statement, it is about freedom and equal rights to access knowledge. If this is allowed to stay it is purely to maintain a manufactured social divide based on wealth and that is not why we are here. Mramoeba (talk) 13:02, 18 May 2018 (UTC)
  • Strongly Support Wikipedia depends on Net Neutrality. Allowing ISPs to pick and choose winners online is dangerous and should never happen. The Wikimedia Foundation clearly supports Net Neutrality. So why doesn't Wikipedia? Retroity (talk) 19:42, 18 May 2018 (UTC)
  • Oppose -- I have personal feelings about the issue, but, this issue doesn't matter in the slightest to my work here as a Wikipedian. We are here to build an encyclopedia. -- Dolotta (talk) 01:17, 20 May 2018 (UTC)

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.
Discussion appears to have died down here too: time to close this. (non-admin closure) Narutolovehinata5 tccsdnew 04:50, 30 May 2018 (UTC)
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.

I challenge the validity of this too-soon RfC

It has only been a month since the last time this proposal was rejected. See Wikipedia:Village pump (proposals)/Archive 147#Net neutrality. Editors should not be allowed to ask the same question over and over, hoping for a different result. This RfC should be closed and the proponent should be asked to wait at least a few months before asking again. --Guy Macon (talk) 20:34, 6 May 2018 (UTC)

I am having trouble finding any meaningful difference between
Could we perhaps link to www.businessesfornetneutrality.com in a banner at the top of all pages?
...and...
Proposal: A US-only CentralNotice in support of Net Neutrality.
What makes them different? Is it the added US-only provision, or the slightly different wording in support on Net Neutrality? I didn't see any responses to the previous RfC that said "I would support it if the notice was US only" or "I would support it if you dropped the businessesfornetneutrality.com link". Generally, for a new RfC to be posted after a month, one would expect the new RfC to address some issue identified in the previous RfC. In my considered opinion, this is substantively the same proposal. --Guy Macon (talk) 14:30, 7 May 2018 (UTC)
I would support the banner which states: "Wikipedians are opposed to the advancement of government control over our internet!". Wikipedia, however, does not speak with one voice here. Let's get over it, and get back to writing an encyclopedia. Can someone close this waste of editor time and energy which will NEVER REACH CONSENSUS and is beating a dead horse? GenQuest "Talk to Me" 16:40, 7 May 2018 (UTC)
Wikipedia, however, does not speak with one voice here. Can someone close this waste of editor time? Pot, meet kettle. Just let the discussion play out first. Maybe there will be consensus for one side or the other, but no one will know unless the discussion runs its course. epicgenius (talk) 13:13, 8 May 2018 (UTC)
  • Comment No matter what issue exists, on any topic at all, it is likely unwise for Wikipedia to take any stance on any issues based on "consensus of editors" on any Wikipedia page. The potential morass is vast. The gain is de minimis. And where iterated versions of such things get placed here on a monthly basis, the value of any "consensus" is Wertlos. Guy Macon is correct. Collect (talk) 19:45, 7 May 2018 (UTC)
    • This proposal is substantially different, and the discussion should continue. Megs (talk) 19:59, 7 May 2018 (UTC)
  • Of course it is too soon. Saying "Plenty of editors above disagree." is either disingenuous because you want your side to "win at any cost", or moronic. Bludgeoning the community until it grows weary of these discussions is not how you form a consensus. In the past it has been clear that a majority do not want to get involved in ANY politics. Saying the slightly different wording changes everything is bunk. Dennis Brown - 20:06, 7 May 2018 (UTC)
  • While not technically against the rules, There is a strong appearance of a conflict of interest when the person who posted an RfC reverts a (at that time uninvolved) editor hatting it.[20][21]. --Guy Macon (talk) 17:20, 8 May 2018 (UTC)
You opposed the previous proposal so you weren't uninvolved Galobtter (pingó mió) 17:24, 8 May 2018 (UTC)
You are saying that the proposals are in fact the same thing? Natureium (talk) 17:35, 8 May 2018 (UTC)
I didn't say they were different anyhow; but presuming the proposals aren't the same, the proposals would still be on a similar enough topic that it'd be hard to call Guy Macon uninvolved Galobtter (pingó mió) 02:47, 9 May 2018 (UTC)
But whether or not I am involved because of my participation in another RfC, you do agree that the person who posted this RfC is involved, right? --Guy Macon (talk) 06:07, 10 May 2018 (UTC)
(...Sound of Crickets...) --Guy Macon (talk) 12:40, 12 May 2018 (UTC)

This would not accomplish what this RfC claims that it would accomplish

According to this legal analyses,
"The CRA would not undo the FCC’s decision to classify broadband internet access service as an information service. That classification decision was the result of an adjudication and is embodied in an order, not a 'rule' subject to the CRA. Nor would the CRA permit Congress to restore the net neutrality rules that the FCC eliminated in the Restoring Internet Freedom Order.
Thus, the CRA joint resolutions of disapproval recently introduced in the Senate (S.J.Res.52) and House (H.J.Res.129) can neither return broadband Internet access service providers to Title II regulation nor restore prohibitions on blocking, throttling, and paid prioritization. In fact, the result of an enacted CRA resolution in this case would be to disapprove the FCC’s transparency rule — the only substantive rule adopted in the Restoring Internet Freedom Order — and prevent the FCC from adopting substantially similar transparency requirements in the future. In short, the CRA resolution exercise represents nothing more than empty political theater rather than a serious legislative effort to preserve Internet openness."
Related: The Process for Using the Congressional Review Act to Protect Net Neutrality, Explained. --Guy Macon (talk) 20:35, 7 May 2018 (UTC)
So, a blog post written on a law firm's website, by a lawyer that represents communications companies against the FCC. Always nice to grab extra attention with a new subsection for such things.. — Rhododendrites talk \\ 21:10, 7 May 2018 (UTC)
(Snark ignored.) Actually, it was published on Law360. As a convenience to the reader I searched out a non-paywall version.
Do you have a source that disputes the sourced claim that the CRA allows review and possible overruling of new federal regulations issued by government agencies and does not allow the overruling of a repeal of an old regulation as a result of an adjudication?
Do you have a single example of the CRA being used to force an agency to adopt a rule as opposed to disapproving a rule? See Congressional Review Act. --Guy Macon (talk) 23:14, 7 May 2018 (UTC)
(Psst...saying something is ignored is the opposite of ignoring it.) ―Mandruss  23:27, 7 May 2018 (UTC)

Watchlist Geonotice

A watchlist geo-notice targeted to the US is now in effect advertising this discussion, saying "Please participate in a discussion about whether to temporarily display a banner in support of Net Neutrality to U.S. readers only." As there is a very tight timeframe here and the notice is neutrally worded, this seems acceptable to me, though I assume some of the other participants here will disagree. power~enwiki (π, ν) 20:57, 7 May 2018 (UTC)

  • I've asked this this be removed from watchlists ASAP. I view this as an attempt to get around the obvious no consensus here as it all but adevrtises this banner despite the fact that there is no consensus for it. This is already advertised on CENT. There is no need to further advertise it, and IMO, doing so undermines the discussion. TonyBallioni (talk) 21:10, 7 May 2018 (UTC)

Discussion update

IntelligenceSquared Debate on Net Neutrality

https://www.youtube.com/watch?v=aAJabAjoK08

The Federal Communications Commission’s recent decision to end Obama-era net neutrality regulations has sparked contentious national debate about the future of the web. Is net neutrality necessary to preserve a free, open internet for all?

For the Motion:

  • Mitchell Baker Chairwoman, Mozilla Foundation & Mozilla Corporation
  • Tom Wheeler Fellow, Harvard Kennedy School and Former Chairman, FCC

Against the Motion:

  • Nick Gillespie Editor at Large, Reason
  • Michael Katz Professor, Berkeley & Former Chief Economist, FCC

--Guy Macon (talk) 15:01, 12 May 2018 (UTC)


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.

RfC: Deletion of drafts

The deletion of drafts via MfD was previously discussed over two years ago in this RfC that concluded that drafts should not be subject to the notability criteria, but that there may be other valid reasons for the deletions of drafts. Reading the comments of the RfC and the close, there also seemed to be agreement that drafts should be works in progress, eventually expected to meet mainspace standards. Currently, it is possible to continually resubmit a declined draft to AfC with no changes while not meeting any of the CSD criteria or failing WP:NOTWEBHOST and effectively stay in draft space forever. This has caused some back and forth at MfD as what to do with these articles. To help provide clarity for this situation, I am proposing WP:NMFD be modified to read the following (updated text in red):

Drafts are not subject to article deletion criteria like "no context" or no indication of notability so creators may have time to establish notability. Drafts may be nominated for deletion at Wikipedia:Miscellany for deletion, but not solely based upon a concern about notability. A draft that has been repeatedly resubmitted and declined at AfC without any substantial improvement may be deleted at Wikipedia:Miscellany for deletion if consensus determines that it is unlikely to ever meet the requirements for mainspace and it otherwise meets one of the reasons for deletion outlined in Wikipedia:Deletion policy.

TonyBallioni (talk) 18:39, 11 May 2018 (UTC)

Drafts RfC Survey

  • Support as proposer as it will clarify what has de facto become a delete reason at MfD, deal with cases that will never be G13 or G11 eligible but also have no chance of ever becoming an article, and also provides protection to drafts so that they are still not eligible solely because of notability and requires that they be given more time to develop. This also has the potential to lighten the load on MfD because it would set the standard as repeated resubmissions (read 3 or more times) and would leave the others alone to develop or meet G13. I think this wording is a good way of splitting the baby of protecting drafts from overeager while remembering that at the end of the day, we are ultimately an encyclopedia first and foremost, and that the end goal of the draft space is to build that encyclopedia. Content that doesn't have a chance of meeting that goal shouldn't be kept. TonyBallioni (talk) 18:39, 11 May 2018 (UTC)
  • Support. Drafts that are tendentiously resubmitted without improvement are an unnecessary waste of volunteer time and should be deleted. Some submitters evidently have difficulty in understanding the word "no" (let alone "encyclopedia"). Deletion makes that message clear. I'd like to see some article CSDs (A11 in particular) apply to submitted drafts, as the act of submission indicates that the submitter believes their draft should be treated as an article. MER-C 18:54, 11 May 2018 (UTC)
    • User:MER-C, the resubmitters are never told “no”. Have a look at some. —SmokeyJoe (talk) 22:04, 11 May 2018 (UTC)
      • In some sense, yes -- I strongly agree with you that we waste far too much time sending the wrong message to and accommodating those who aren't here to improve Wikipedia. But having a draft declined stating that further improvement is necessary and not doing that before resubmitting is still failing to understand a very simple concept. MER-C 11:57, 12 May 2018 (UTC)
  • Support per Mer-C & Tony but is not strong enough. I like Robert's idea of A7 for draft articles.-- Dlohcierekim (talk) 19:00, 11 May 2018 (UTC)
  • Oppose As I noted at AN before the thread was closed, resubmitting a draft multiple times is a conduct issue not a content issue and should be handled by sactioning the user in question instead. Once the user has been banned/blocked, the problem posed by the RFC is solved. This proposal would allow a single editor to decline a draft three times and then nominate it for MFD for being declined three times, effectively circumventing the whole reason why we have Draft-space in the first place (which is also why I strongly oppose any attempts to expand A7 to drafts). Regards SoWhy 19:02, 11 May 2018 (UTC)
    SoWhy I would be in complete agreement, except Tony has inserted the phrase "without any substantial improvement". If there is question about what "substantial improvement" here constitutes, an per-case discussion happens at MfD. This is not a "Speedy" process, although I also think there should be such a process for egregious cases. 78.26 (spin me / revolutions) 19:07, 11 May 2018 (UTC)
    I just don't see it as solely a conduct issue. The reason why a draft may be repeatedly declined is because the subject simply isn't suitable for an encyclopedia and has no foreseeable chance at becoming suitable in the future (WP:OVERCOME); that's a valid content issue, if I did hear one. Although it might work, the problem I see with treating it as a behavioral problem is WP:BITE. Threatening to block should be a last resort, and I see deletion as the neatest solution that saves the most time and doesn't unnecessarily personalize the issue for new editors. Mz7 (talk) 00:30, 12 May 2018 (UTC)
    How does deletion stop a user from recreating the same page? BITE problems are a big reason why I don't favor deletion of drafts at all (I see it as a fool's errand to devote energy to pages whose existence does not pose an actual problem in terms of outside visibility) but even BITE has its limits. We block users who don't get the message after being warned multiple times in other areas as well, so how is AFC different? Deleting a page someone has worked hard on is usually as BITEy as blocking them because both send the message that they are not welcome. But only sanctioning the user will actually address the problem posed by Tony. If we agree to sanction users, we could easily create an edit filter that prevents those users from resubmitting drafts (which would be less BITEy than blocking them without being less effective). Regards SoWhy 09:11, 12 May 2018 (UTC)
    Off topic uninformed oppose Vote! on a clarification of policy to match existing practice at MfD from a user with 17 visits to MfD in their last 50,000 edits over a decade. Sanctioning new throwaway accounts is a fools errand and does nothing to remove the bad Draft from the system. Legacypac (talk) 05:18, 12 May 2018 (UTC)
    @Legacypac: An ad hominem argument obscures the points you are trying to make. You should stop attempting to discredit users by who they are or what they've done and instead discredit their points by answering their points directly. --Izno (talk) 12:11, 13 May 2018 (UTC)
  • Support - I appreciate the nuance given here to those editors who make good-faith efforts to improve their draft, even if it takes 3 or more or many more attempts. Tendentious resubmissions with no effort to address the concerns of the declining editor, however, should be cause for deletion. Even speedy per Dlohcierekim. 78.26 (spin me / revolutions) 19:03, 11 May 2018 (UTC)
  • Support as redundant addition. I don't see the slightest effect that this will have on what we currently have. Also agree with SoWhy. Changed to support. As I already made it clear, I am not against the substance of this proposal but the amount of difference it can make to what currently exists. After TonyBallioni's response, I am convinced supporting this will surely be a one step forward and the impact will (hopefully) be seen in the long-term. –Ammarpad (talk) 19:11, 11 May 2018 (UTC)
    • It makes “repeatedly resubmitted with no improvements, has no chance of being in mainspace, and has no sourcing for uninvolved editors to show notability.” an unambiguously valid reason for deletion at MfD. I think it should be already per NOTWEBHOST. This makes that clear. TonyBallioni (talk) 19:33, 11 May 2018 (UTC)
    @TonyBallioni: I generally agree with the principle of any proposal that will hasten deletion of non-notable drafts that otherwise didn't meet any of our extant WP:GCSD. But I would like to support something that will make impact. Many proposals nowadays are just collection of random support without short term or long term effect. Even now, that this proposal is not in effect, one can nominate non-notable, hopeless and repeatedly submitted draft and it will surely be deleted. But considering your points;
    1. repeatedly resubmitted
    2. with no improvements,
    3. has no chance of being in mainspace, and
    4. has no sourcing for uninvolved editors to show notability
    Shouldn't this be clear need for speedy deletion criterion? If a draft meet all these criteria what else people will discuss? How many people participate in MfD these days? –Ammarpad (talk) 08:18, 12 May 2018 (UTC)
    Hi, Ammarpad, thanks for pinging me. The reason I didn't propose those here is because those would be a lot bigger changes than this, I don't think they have consensus at this time, and I hadn't done any work into looking at what a process there might look like.
    My general approach to policy reform is that policy is meant to be descriptive of practice, not prescriptive. That means I typically only propose RfCs where I think there is a pre-existing consensus. Here, I'd heard enough complaints about how we deal with drafts through MfD, I was aware that previous attempts to get a CSD criterion approved had not been successful, and that draft PROD would be more controversial than this and would probably have a 50/50 chance of passing. I think this proposal addresses a concern that people have, already has consensus, and will improve the encyclopedia as a whole.
    There may be other reform ideas in this area that could be successful, such as Kudpung's suggestion for DfD or yours for Draft PROD. I'd likely support those. That's not the intent of this proposal though. This is an attempt to be a first step in making the process easier by documenting what people already bring up at MfD pretty frequently in policy. If you support the idea generally, like Mz7 below, I hope you'll consider supporting. This doesn't pretend to be the perfect solution, just a viable step forward. TonyBallioni (talk) 12:45, 12 May 2018 (UTC)
    Thanks, TonyBallioni, I now understand you better. Hopefully, although this doesn't mean much now (my concern), it is a stepping stop to something more impactful in the future, instead of ignoring/opposing it now and end up discussing it again at the time we ought to be discussing measures beyond it. –Ammarpad (talk) 07:01, 13 May 2018 (UTC)
    MfD receives reasonably high participation actually; for a CSD you'd need an A7-esque standard, as what counts as "no sourcing" for notability and not suitable for mainspace is contentious Galobtter (pingó mió) 12:52, 12 May 2018 (UTC)
    • Indeed, I think if you look at Wikipedia talk:Miscellany for deletion and its archives, you'll see that the current wording of this section has resulted in a lot of confusion and debate. For that reason, I do not see this clarification as redundant, and if you think it is descriptive of current practice, I think you should consider supporting. Mz7 (talk) 20:15, 11 May 2018 (UTC)
    Yes, I see it as that. That means it will have no solid impact. It merely repeats what already exists. Any draft that meet what was described above will surely be deleted at MfD. See my reply to TonyBallioni above. The current problem as described requires only speedy criterion to make sense and for us to know we're moving forward. Or to a lesser extant, to establish special "sticky prod" for drafts. I will shortly describe it in General comment section. comments below. –Ammarpad (talk) 08:53, 12 May 2018 (UTC)
  • Support see User:JJMC89_bot/report/AfC_decline_counts where drafts are declined as many as 11 times! It is a serious waste of effort and gums up AfC. This can help the actually notable draft stuck in AfC as well because it will expose the page to a discussion where someone can make a case for promotion, but mostly it will provide an exit path for the hopeless repeated reviewer free spin of the wheel style resubmissions. I also support applying A style CSDs to submitted drafts. The act of submission is a request to apply mainspace criteria to the page so treat the page as such. Legacypac (talk) 19:10, 11 May 2018 (UTC)
  • Support Why should notability not be considered for drafts? The point of drafts is to develop into articles, and articles require notability. What then is the purpose of allowing drafts on non-notable subjects? Natureium (talk) 19:23, 11 May 2018 (UTC)
  • Oppose - We should not be spending time in deletion discussions about drafts. These discussions and administrative actions take unnecessary resources, are WP:BITEY, and feed trolls. Please let these submissions wait their turn in the queue for a few weeks before rejecting them. Authors will get the message and the drafts will eventually be deleted under G13. ~Kvng (talk) 19:37, 11 May 2018 (UTC)
  • Oppose, per Kvng. This proposal comes across as a punitive measure, too. --Doncram (talk) 19:52, 11 May 2018 (UTC)
    • The other working proposal to deal with this is to block them and let G13 take hold. I consider that much more bitey and puntative. TonyBallioni (talk) 19:56, 11 May 2018 (UTC)
    • @TonyBallioni: I proposed above that we basically put these drafts in timeout. Can we put that on the table too? No change to process is required, just a change to reviewer behavior. ~Kvng (talk) 00:41, 12 May 2018 (UTC)
      • I'm not really sure if there is a way to prevent them from submitting the AfC draft. I'm also not sure what good it does to keep them for 6 extra months if we've already made the determination we don't want them. If the main reason is BITE, I'll somewhat echo Seraphimblade below in noting that most of these are not actually good faith users who are trying to contribute something encyclopedic that they find interesting to Wikipedia. Most of these are people who have a financial incentive to keep resubmitting and take advantage of our good faith. I'm not sure BITE is really a good argument in dealing with people we don't want contributing anyway. TonyBallioni (talk) 01:12, 12 May 2018 (UTC)
  • Support Oppose arguments such Kvng's are admirable in their assumption of good faith, but practical AfC data shows that there are far too many bad-faith article creators. This reality is the reason that we have made ACTRIAL permanent, after all. The proposed language is a common-sense way to address bad-faith resubmitters. The difference between good-faith and bad-faith article creators is often disclosed by their response to AfC rejection. The former will at least query the rejection and its feedback, while the latter will just send the exact same article back into the queue. This proposal only targets the latter behavior, something that should be dissuaded in any event. Eggishorn (talk) (contrib) 19:57, 11 May 2018 (UTC)
    • @Eggishorn: Can you provide some details about this "practical AfC data"? ~Kvng (talk) 00:41, 12 May 2018 (UTC)
@Kvng:, I suggest starting with the meta:Research:Autoconfirmed_article_creation_trial and wp:Autoconfirmed article creation trial/Post-trial Research Report. Eggishorn (talk) (contrib) 04:29, 12 May 2018 (UTC)
@Eggishorn: I've read those and they don't support what you're saying here. There is nothing in the report about draft author behavior. Also the WMF is only now gaining an understanding of how AfC works. The AfC-related conclusions in the report are disputed. There were more submissions to AfC but there is no evidence there was a "struggle" to keep up with it. See Wikipedia_talk:Autoconfirmed_article_creation_trial/Post-trial_Research_Report#AfC_backlog_"struggle". ~Kvng (talk) 14:38, 12 May 2018 (UTC)
  • (edit conflict) Support – It is true that in the wide majority of cases, the notability guidelines that justify the deletion of articles do not automatically justify the deletion of drafts. This is because one of the purposes of the draft space is to serve as an incubator for drafts about non-notable subjects that have a high likelihood of becoming notable in the near future (e.g. film actors who are about to star in a significant role, upcoming films from major studios, athletes who are about to debut in the top tier of their sport). The draft space is the successor to Wikipedia:Article Incubator in this respect. Articles that were in the incubator did not stay there forever, however; they either were moved back to mainspace or were nominated to MFD or userfied (see WP:GRADUATE).
    I've long held the view that there are two general cases where notability should and does factor in as a part of a decision to delete a draft (see this July 2017 discussion). The first is repeatedly submitted AfC drafts with no foreseeable chance at acceptance due to lack of notability, and the second is long-abandoned non-AFC drafts about non-notable subjects with no foreseeable chance at becoming notable in the future. The second case has largely been mitigated with the expansion of CAT:G13 to all drafts, but I see MfD as the natural place where repeatedly submitted AfC drafts should be sent. I don't see blocking or other conduct sanctions as the best solution because the issue is indeed fundamentally with the subject of the article: no amount of editing can overcome a lack of notability. Mz7 (talk) 20:06, 11 May 2018 (UTC)
  • Oppose for a few reasons, although mostly this is just echoing SoWhy. First, AfC doesn't own the entire Draft namespace, so constant submission is a project problem. In that case, I think SoWhy's response (i.e., it becomes a behavior/cluefulness issue) is appropriate. Second, the purpose of draftspace is for folks to work on pages that are inappropriate for mainspace; this would defeat the whole purpose of treating something as a "draft" rather than an article. I've said elsewhere that I am unconvinced of the damage or harm a large draftspace would supposedly cause, and that remains true. Finally, I think the proposed text weakens WP:NMFD to a degree that it will cease to be a barrier. ~ Amory (utc) 20:34, 11 May 2018 (UTC)
Sure, AfC doesn't own the draft namespace, Amorymeltzer, but it was created with them in mind and with the hope that ACTRIAL would take place one of the days. Well, ACTRIAL took place, and has since become ACREQ and there has been the anticipated (but slightly lower than feared) increase in the number of drafts. Nevertheless, SoWhy's argument (i.e., it becomes a behavior/cluefulness issue) is indeed also appropriate, because the reviewing needs to be much improved so that even if they have clue, they will be singing from the same page of the same hymn book, and at the moment they do not appear to be doing either. And that's a much longer story. Kudpung กุดผึ้ง (talk) 20:48, 11 May 2018 (UTC)
I would qualify your description of the purpose of the draft space in this way: the purpose of the draft space is for folks to work on pages that are inappropriate for mainspace but will soon be appropriate for mainspace. The draft space is not a dumping ground for articles about just any topic that doesn't meet mainspace standards to remain indefinitely – that would be using Wikipedia as a web host. We expect drafts to be actively worked on and improved so that they will eventually be a part of the encyclopedia. If a draft is about a topic that is inherently non-notable and has no foreseeable chance at becoming notable in the future, then more community time is wasted when we allow it to be repeatedly submitted at AfC than if we allow it to be deleted at MFD. Fundamentally, it is not just a conduct issue, but an issue with the subject of the draft. If the real solution is to threaten to block a user if they don't stop submitting, and let it be deleted after waiting out 6 months via G13, then isn't that WP:BITEy and perhaps even more time wasting than if we just waited out 7 days at MfD? Mz7 (talk) 23:59, 11 May 2018 (UTC)
  • (edit conflict)(edit conflict) Support strongly - in fact I would go one further and suggest the creation of DfD - Drafts for Deletion. Since ACREQ was rolled out, there are going to be a lot more drafts for deletion. As one of the editors who works a lot in these areas I prefer pragmatic solutions rather than philosophical ones. Being BITEY is not part of the equation , telling a troll his trash is not wanted is not being bitey, nor is telling an obvious paid editor that Wikipedia was not conceived as a platform for blatently making a career from making money out of our volunteer-created encyclopedia; Wikipedia is not a business directory either or a register for rappers. What is really needed are a better set of instructions (without TL:DR, but more than just a quick click-through of four four-line pages) at the Article Wizard, and more consistent reviewing at AfC; and above all, more truly active AfC reviewers Kudpung กุดผึ้ง (talk) 20:35, 11 May 2018 (UTC)
@Kudpung: I would say, personally, I would like a DfD system, but I've heard arguments that it won't have nearly enough traffic to work properly. Jjjjjjdddddd (talk) 03:45, 12 May 2018 (UTC)
  • User:Kudpung, User:Jjjjjjdddddd - I am genuinely puzzled by the idea of Drafts for Deletion. My question is why drafts need a separate deletion process from MFD, especially since MFD is primarily used for drafts anyway. Why do drafts require their own deletion process? Why not do at MFD whatever would be done at DFD? I hope that this isn't considered a stupid question, but I really don't understand why a new process would solve the known problems with cruddy drafts. Robert McClenon (talk) 23:12, 12 May 2018 (UTC)
  • Support In my experience, G13 is just not good enough to deal with this issue. Drafts that are truely not notable, which are just cruft should be able to be deleted rather than going after x months of no edits and instantly undeletable. Additionally, at MfD/DfD/whatever it is called, there will be the chance for more people to look over nominations than one reviewer every few weeks. While I'm an advocate for a more engagement-based approach on paid editing, in cases where companies are non-notable, we do need to be less wishy-washy on the message we send out. Mdann52 (talk) 20:54, 11 May 2018 (UTC)
  • Support but I like Kudpungs idea a lot - Having "DFD" would be a much better place for all of these as IMHO Drafts are unrelated to MFD, Anyway support this proposal. –Davey2010Talk 21:05, 11 May 2018 (UTC)
  • Support (edit conflict) - I understand SoWhy's concern but I think that if the article is undergoing substantial improvements there is no concern with this affecting the draft. -- Dane talk 21:07, 11 May 2018 (UTC)
  • Support - this is a step in the right direction, although it is still insufficient. Blatantly non-notable drafts (one where no reasonable editor can make a case for notability) should be eligible for deletion either as a speedy or through a XfD process without the need to show anything else. Endorse Kudpung's DfD process. Tazerdadog (talk) 21:18, 11 May 2018 (UTC)
  • In-the-end Support but not yet, not when the resubmissions followed a face reading of the saccharine decline template that encourages the author to edit improve and, with a big blue box, “resubmit”. The template confuses the newcomers who think this is how to communicate. The root fault lies with the AfC template and this deletion process does nothing to address it. Support for resubmissions that follow removal of the saccharine resubmit template only. —SmokeyJoe (talk) 21:34, 11 May 2018 (UTC)
The prerequisites to precede are (1) Wikipedia_talk:Criteria_for_speedy_deletion#Applying_A*_criteria_to_submitted_drafts and (2) fixing the AfC practice of the confusing rejection template. —SmokeyJoe (talk) 21:39, 11 May 2018 (UTC)
  • Support. I also wouldn't mind having a Drafts-for-Deletion notice board, but would prefer to save DFD for a Disambiguations for Discussions notice board. Also, if we are going to separate drafts from MfD, we should create a master deletion noticeboard where editors can see all discussions going on at AfD, MfD, CfD, RfD, and any others that are made. bd2412 T 21:42, 11 May 2018 (UTC)
DAB pages are dealt with at MfD. They may need to be deleted occasionally, but rarely for the reasons that junk that is received at AfC needs to specially treated. Kudpung กุดผึ้ง (talk) 22:06, 11 May 2018 (UTC)
Actually, DAB pages are usually dealt with at AfD - if the issue is deletion. More importantly, however, there are a number of non-deletion issues for which disambiguation pages require a central noticeboard, including move requests, and proposals to change an existing article or redirect to a disambiguation page (or to turn an existing disambiguation page into an article). bd2412 T 22:19, 11 May 2018 (UTC)
DAB pages are never dealt with at MfD but are immediately referred to AfD. DAB discussions would be better as RM discussions on the DAB talk page, except if an outcome is deletion the discussion would be deleted. —SmokeyJoe (talk) 22:25, 11 May 2018 (UTC)
In that case you'd better send this to RfD ;) Kudpung กุดผึ้ง (talk) 22:53, 11 May 2018 (UTC)
With four incoming links, and before today an average of less than one view per ten days, rfding it would be busywork. —SmokeyJoe (talk) 03:39, 12 May 2018 (UTC)
  • Oppose per Kvng and SoWhy. I don't agree with deleting drafts that are declined multiple times after many resubmissions since it may come off as WP:BITEY and completely unnecessary. Just undo/revert the submitter to solve the issue easily instead of MFD-ing which is a waste of time or reviewers should just leave them alone for a few weeks before declining since no one outside the community cares about the draft space and keeping the drafts around will not be detrimental to WP. What is already written is sufficient and the proposed addition could actually make it more confusing rather than give clarity. KingAndGod 22:02, 11 May 2018 (UTC)
    You are free to vote bow you like but basing your vote on the reasoning of an editor with no AfC and extremely limited MfD experience is less convincing. Legacypac (talk) 08:01, 13 May 2018 (UTC)
    @Legacypac: See above your comment to SoWhy re ad hominem. --Izno (talk) 12:13, 13 May 2018 (UTC)
  • Support, absolutely, per Tony. Volunteer time is our most precious resource; we should not be forcing wasting it on reviewing and declining drafts that are tendentiously resubmitted by people not acting in good faith. ♠PMC(talk) 23:37, 11 May 2018 (UTC)
  • Oppose - Resubmitting the same draft over and over is a behavioral issue. Deal with the user. If it's a recurring problem, disallow it via AfC processes. If AfC allows resubmitting the same draft over and over again, don't defer to another process to fix it by deletion. — Rhododendrites talk \\ 23:53, 11 May 2018 (UTC)
Sanctioning new throwaway SPA accounts does not solve much. MfD is no more a seperate process from Draft space than AfD is a seperate process for Mainspace. I am unaware of any way to prevent someone from adding the AfC submit code to any page other than to block them. Legacypac (talk) 05:18, 12 May 2018 (UTC)
  • Support, draft space should be used for things for which there's a reasonable likelihood that they can one day be an article. It should not be a dumping ground for people to write about their pet dog, nor (and I've seen this tried on multiple occasions) for an undisclosed spammer to see just how much promotional language they can get away with by making small changes and resubmitting. We either need this, or a "______ strikes, you're out" speedy criterion. At some point, repeated failed resubmissions indicate that either the author is not acting in good faith, or lacks the competence to write an article. In either case, there comes a point at which we need to say we've spent enough time on it. Seraphimblade Talk to me 00:02, 12 May 2018 (UTC)
  • Support – this is a no-brainer: this is an encyclopedia devoted to articles on notable subjects – if a draft has been determined to insufficently notable at something like AfC multiple times, and is unlikely to ever be notable, it does not belong as part of this project, even in Draftspace. WP:NOTAWEBHOST. --IJBall (contribstalk) 01:16, 12 May 2018 (UTC)
  • Support - While I understand the good faith aspect here, and indeed whenever possible, if a draft has potential to become an article, they should be kept as long as they're being worked on. But unfortunately, there are many drafts on subjects that simply would be deleted quickly if they were an article. It would be better to put them out of their misery quickly as opposed to keeping them in the limbo of waiting for them to become G13 eligible. This is especially with ACTRIAL becoming permanent after all. With that said, perhaps MfD would be a better compromise as opposed to extending certain CSD criteria to drafts, since many drafts are still potential articles, and it's necessary to see which is workable and which needs to go. Narutolovehinata5 tccsdnew 01:48, 12 May 2018 (UTC)
  • Support Most people that repeatedly submit the same bad submission are either not acting in good faith, or are ignoring the decline reason. AfC is already heavily backlogged as it is, and besides, the MfD discussion will either have the bad-faith trash deleted, or give the (presumably somewhat good-faith) submitter a push to improve their draft. Jjjjjjdddddd (talk) 03:58, 12 May 2018 (UTC)
  • Support. We are WP:NOTWEBHOST for material unsuited to our project. Sandstein 07:46, 12 May 2018 (UTC)
  • Support this seems reasonable, it allows for people to try to bring a draft up to acceptable standards without turning draftspace into a webhost for pages which will never become articles. Hut 8.5 10:05, 12 May 2018 (UTC)
  • Support per Hut 8.5. This doesn't stop people from using user space for longer term storage, but it does give us the appropriate tool to deal with the few drafts that need to be cleaned up. Dennis Brown - 10:08, 12 May 2018 (UTC)
  • Oppose This proposal makes a very bold assumption: that AFC reviewers are infallible and that if a draft has been rejected by them three times then "obviously" the draft must be worthless. the problems with AFC's lack of accountability have been discussed many times on Wikipedia and I fail to see how this does anything bu increase the lack of accountability.

    AFC reviewers are declining articles for incredibly petty reasons like not formatting a reference correctly, or "this looks notable, but can you make the article perfect", or the most obnoxious, which is the dreaded copy-pasted boilerplates that say the draft is not good, but do nothing to advise the draftee on how to improve it.

    Something many older reviewers don't realise is that new users are corralled into AFC. AFC is not mandatory for creating a page, but if you are a new user, the instructions you receive to everything to convince you that the only way to create a new page is to make a draft and submit it for review. This has given the reviewers of AFC an incredible amount of power, in a way that goes against the entire spirit of the Wiki (Collaboration). Many AFC reviewers instead of looking to improve articles, have appointed themselves unilateral quality editors and continually reject drafts that AFD would never delete. This proposal seeks to increase the power of AFC editors, but I suggest that this is a solution to a problem that doesn't exist. Egaoblai (talk) 10:23, 12 May 2018 (UTC)

Egaoblai this isn't a CSD so they aren't automatically deemed worthless. Having an MfD for those drafts declined spuriously means that they'll get attention from multiple editors and more accountability and an accept in those cases where the declines are spurious Galobtter (pingó mió) 12:13, 12 May 2018 (UTC)
At MfD we can discuss and save if the AfC reviewers are wrong Legacypac (talk) 08:01, 13 May 2018 (UTC)
I agree with your concerns Egaoblai but a timely MfD is likely to be an improvement on the draft ageing out and being quietly deleted G13 after 6 months. Espresso Addict (talk) 00:26, 15 May 2018 (UTC)
  • Support. I see this as a genuine problem and this seems like a practical way to solve it. WP:MFD will get extra eyes on them in case there's a consensus that the AFC reviewers have erred, and there's always WP:DRV as a backup as with other deletion processes. Boing! said Zebedee (talk) 10:26, 12 May 2018 (UTC)
  • Support per Tony and Mer-C; blocking the accounts is hard to do when they are likely in good faith etc; you'd need first need to leave specific warnings rather than encouraging AfC messages and it is basically much more effort overall. Galobtter (pingó mió) 12:52, 12 May 2018 (UTC)
  • Support - this seems like a measured solution to the problem. Richard0612 13:47, 12 May 2018 (UTC)
  • Oppose Per WP:NOTPAPER, there is no physical limit requiring deletion. If resubmission is an issue, it is better to retain drafts as a record of previous versions. If you start deleting versions, then further submissions will seem to be starting afresh, so causing the process to loop indefinitely. So, just as we keep our discussions and archives indefinitely, we should keep draft versions too. If they don't seem to be going anywhere, then use a category or other tag to mark their status. Andrew D. (talk) 21:23, 12 May 2018 (UTC)
  • Measured oppose "Repeatedly" is an interesting word, and the criterion should not be "repeatedly" but "repeatedly without prospective changes in notability" - that is, we ought to avoid burning up a draft where the notability of the topic or person has a decent chance of being altered substantially. Collect (talk) 21:29, 12 May 2018 (UTC)
if that is true for a draft that can be discussed at MfD. Legacypac (talk) 08:01, 13 May 2018 (UTC)
  • Support - a measured proposal that doesn't try to go too far. — Insertcleverphrasehere (or here) 23:04, 12 May 2018 (UTC)
  • Support - Something needs to be done about tendentious resubmission. Either the drafts can be deleted, or the resubmitters can be blocked, or both. Something needs to be done. I don't see a practical way to request that the fools and flacks be blocked, because WP:ANI isn't worth the drama and will probably wind up with a warning anyway, and they aren't vandals. I don't think it goes far enough, but it is better than nothing. I would like to be able to speedy drafts that have no credible claim of significance, but I know that I am in the minority there. Robert McClenon (talk) 23:28, 12 May 2018 (UTC)
  • Oppose - The issue of a draft being submitted too many times would be better addressed at Wikipedia:Articles for creation/Wikipedia:WikiProject Articles for creation. For example, a process of barring a draft from resubmission for a certain period of time or barring a user from submitting draft(s) to be considered for a certain period of time could be established. Let the AfC process govern itself; the problem should not be thrust directly on MfD. If AfC establishes a guideline that such drafts should be deleted (as opposed to my examples above which I believe are better options), they can cite it at MfD. WP:NMFD is not the place for such guidance to reside. All drafts inducted into the AfC process become eligible for speedy deletion per G13 after 6 months of inactivity anyhow, so I fail to see the necessity of early deletion. — Godsy (TALKCONT) 00:21, 13 May 2018 (UTC)
If they get repeatedly resubmitted they never get to G13 Galobtter (pingó mió) 06:35, 13 May 2018 (UTC)
  • Support - per User:Robert McClenon Smallbones(smalltalk) 15:09, 13 May 2018 (UTC)
  • Support a separate "drafts for discussion" page, as well as a CSD for drafts that have been declined more than 3 times without any plausible improvement. Lojbanist remove cattle from stage 19:07, 13 May 2018 (UTC)
  • Support a working solution to a real problem of NOTWEBHOST content that otherwise falls between the cracks. – Finnusertop (talkcontribs) 22:42, 13 May 2018 (UTC)
  • Support just formalizing my own personal view. If the same submission gets repeatedly submitted without correcting the problem I go from friendly to not-so-friendly in my comments with the last comment being to the effect of Do not resubmit this without correcting the issues already raised otherwise I will nominate this for deletion at MFD. It doesn't threaten the user directly, it simply explains what the consequence of them failing to read/understand/correct will be. Hasteur (talk) 01:38, 14 May 2018 (UTC)
  • Oppose per SoWhy and Amory. Besides, draftspace is exactly the place to put not-article-worthy-yet drafts. This would defeat the whole purpose of it. Besides, there are some AfC reviewers that will acept draft with lower standards, while others will wait for them to be GA-class to accept them. L293D ( • ) 02:24, 14 May 2018 (UTC)
  • Support, but only under a specific set of criteria. I agree that drafts that aren't likely to go anywhere need to be shown the door, but I'm not sure just doing it by MfD'ing everything that gets power-submitted is the way. I'd actually think a valid case could be made for drafts that fit all of the following criteria:
    1. The draft has been rejected at least five times, or has been resubmitted and rejected with no substantial edits to it three times. If someone is working on a draft and at least trying to make it work out, the likelihood of it getting rejected five times is slim to nil. On the other hand, someone who's just spamming the submit button is likely doing it for Google exposure, not to build an encyclopaedia.
    2. The draft's sources are unacceptable, and no acceptable sources are available online or off. Oftentimes the biggest hurdle to a draft is finding usable third-party sources, and newer users are less likely to understand what we deem acceptable. I would also suggest amending the decline message for lack of notability to include a link to a plain explanation of acceptable sources (which I'll probably dope up soon, since this is almost universally THE main sticking point as far as helpees in -en-help go).
    3. The draft, in addition to the above, has not been (substantially) edited for at least three months since the last decline or edit. Given that the usual backlog for AfC at present is in the neighbourhood of months (as an acknowledged consequence of ACTRIAL and ACPERM) this gives time for sources to come into existence and thus subvert the second bullet above. This is also why a WP:BEFORE check must be done before a draft gets taken to MfD. While I suggest three months (as a fair chunk of drafts are made in anticipation of a topic) this should be considered a suggestion and not a hard-and-fast rule, but it should be no less than ten weeks and no more than 6 months (when G13 kicks in anyways). —Jeremy v^_^v Bori! 03:30, 14 May 2018 (UTC)
  • Support - This is not an area where I have a great deal of experience, but it seems to me that the "support" !votes present better arguments than do the "oppose" !votes. Having no strong personal reason to oppose, and trusting in TonyB's judgment, I support. Beyond My Ken (talk) 03:54, 14 May 2018 (UTC)
  • Support – Regardless of whether resubmitting a draft repeatedly is a behavioural issue as some argue it should be treated as, this will make it easier to get rid of problem drafts via MfD. If it is a substantive draft that is actually worth keeping, MfD will see it as such. Draftspace has been a mess for a while, and the problem isn't with the potentially publishable drafts; it's with the repeatedly resubmitted corporate spam and self-published non-notable bios. I don't see the issue here. Kb.au (talk) 14:39, 14 May 2018 (UTC)
  • Support - I will ask a going further, for those where consensus is at MFD that there is no clear case at mainspace WP:SNOW - then admins should be able to SALT the page. I have been seeing people recreating their useless drafts and then repeatedly recreating. Banning individual users may be in need, but we need warnings, final warnings and etc. And the user maybe able to contribute in other areas, so sometime can't ban also. Therefore, to solve the content issue, SALT the page. --Quek157 (talk) 21:16, 14 May 2018 (UTC)
  • G4 is applicable if they blindly re-create it after an XfD debate without fixing any of its issues. We shouldn't salt the earth unless and until they prove themselves unwilling or incapable of listening to criticism of their article by repeatedly growing a new one from the ashes. —Jeremy v^_^v Bori! 19:18, 15 May 2018 (UTC)
  • @Jéské Couriano:, I declined a draft with 2 - 3 can't remember previous deletion, CSD G11 (Advertising) with G4 (SALT). The admin who process initially did G4, but then said "unnecessary for draft" so then reallow creation for G4. G4 can only be used for mainspace, not draftspace, I am thinking to extend it to here. --Quek157 (talk) 21:20, 15 May 2018 (UTC)
"It excludes pages that are not substantially identical to the deleted version, pages to which the reason for the deletion no longer applies, and content that has been moved to user space or converted to a draft for explicit improvement (but not simply to circumvent Wikipedia's deletion policy). This criterion also does not cover content undeleted via a deletion review, or that was only deleted via proposed deletion (including deletion discussions closed as "soft delete") or speedy deletion."(emphasis in italics). This is the big problem NOW at the draftspace which is this entire RfC is for. It is quite protected and is not like others. I just came back after a long hiatus and apparently it is now like that, FYI too =) --Quek157 (talk) 21:25, 15 May 2018 (UTC)
  • Support- I'd personally go further, in terms of Notability as a criterion, but the proposal would certainly be an improvement on the current position. KJP1 (talk) 05:39, 15 May 2018 (UTC)
  • Support. I do think that this would address a need. What makes it work for me is that it is directed at drafts that keep getting resubmitted without "getting the message", and that it makes it possible to decide that a draft should be deleted, as opposed to saying that a draft must be deleted. In other words, it still leaves discussion and editorial judgment in place. --Tryptofish (talk) 19:25, 15 May 2018 (UTC)
  • Support. This is already how discussions at MfD are turning out: the community (or, at least, the portion of the community that regularly votes at MfD) feels that it is appropriate to delete tendentious resubmissions that utterly fail to address the reasons for their rejection as a way of communicating to the user that their disruption won't be tolerated without going to the extreme of bans or blocks. Compassionate727 (T·C) 21:18, 15 May 2018 (UTC)
  • Support. Anything not in one of the "normal" namespaces can already be nominated for MFD, and any such page will be deleted if consensus favor deletion. This isn't adding any new ideas or procedures to policy; it's simply saying what's already happening. WP:PPP. Nyttend (talk) 11:29, 16 May 2018 (UTC)
  • Support, also support Drafts for Deletion. Having drafts with no hope of becoming articles is helpful to no one; having a dedicated drafts for deletion space will allow people specializing in drafts to watch it, as shepherding a draft into an article is a skill. --GRuban (talk) 20:30, 16 May 2018 (UTC)
  • Support per Kudpung. Amorymeltzer is exactly wrong; draft space only exists as the location for AfC's backlog. SoWhy is correct insofar as problem editors are behind the repeated submissions. Because these drafts are of interest to businesses or fan collectives where meatpuppetry or sockpuppetry is likely, deleting the draft is a more efficient practice. Chris Troutman (talk) 16:44, 20 May 2018 (UTC)
  • Support: no chance of ever becoming an article & tendentious resubmissions which take up volunteer time. This is a suitable approach to addressing the issue. K.e.coffman (talk) 01:30, 22 May 2018 (UTC)
  • Support: well, a decision should be taken based on a statistic (in available). I agree that if a draft gets declined 3 times (ofthen for the same reason) further resubmissions for AfC is just time wasting. I believe that if a WP:RENOM style policy would be implemented for drafts would be a good step forward. We all know that a new editor, not familiarised with all the policies needs some time to know that there are some fair rules. So a time frame to improve an entry between two resubmissions would be a viable solution as well. However, if the draft keeps getting declined by different reviewes several times during, let's say, 6 months or a year... we all know what that means. As a NPP reviewer and page mover - sometimes, when I felt like an article has potential - I draftified those articles and some of then giving advice to its creator how to improve the draft. Robertgombos (talk) 23:07, 24 May 2018 (UTC)
  • Oppose This feels like we are trying to make a crystal ball to predict if a subject will become notable or not. I do not agree with the wording and what it can imply. I could get on board for an "abandoned" guideline, that any draft that has not been improved in X amount of days is deleted or userfied.--Paul McDonald (talk) 23:17, 24 May 2018 (UTC)
  • Support per Tony and K.e.coffman. Could not have said it better myself. JTP (talkcontribs) 15:41, 31 May 2018 (UTC)
  • Support IF ANSWERED - it is codified how much and how frequently is going to trip the tendentious resubmissions bit. I'd like just being able to userfy etc, but if those who endlessly resubmit would presumably do the same in AfC.
TonyBallioni the latter part of your proposal "otherwise meets one of the reasons for deletion". AfC pass requirements are stricter than those for an article to remain. Most notably on issues such as verification (AfD can be stopped by sheer possibility of finding sources) and promo levels (AfD articles have to be completely promo). Would a strict following of this proposal not risk us having a group of articles that would continually fail AfC but not be deleted under WP:DEL-REASON? Nosebagbear (talk) 14:54, 6 June 2018 (UTC)
I'm obviously not Tony, but I would imagine that in such a case if an MfD is closed as keep, then the article fails AfC again or just sits there for a while, then that very fact can be used as an argument to delete at a second MfD. And, of course, if the draft is left unedited for 6 months then it'll get G13'd. ƒirefly ( t · c · who? ) 09:34, 7 June 2018 (UTC)
Nosebagbear, sorry for the late response. AfC's acceptance criteria is "is likely to survive AfD", which means they are substantially lower than the mainspace requirements. Also, if the reviewer has made mistakes, MfD will likely suggest booting it to mainspace with no prejudice against sending to AfD. TonyBallioni (talk) 14:21, 7 June 2018 (UTC)
  • Support per above. Seems sensible, and already appears to be the case at MfD anyways. -FASTILY 23:05, 7 June 2018 (UTC)

Drafts Discussion

TBD, the whole Draft system itself, should be abolished. IMHO, it's best to let an editor create an article as a stub, then let the community gradually evolve that article. Meanwhile, individual editors can use their own sandbox to construct what they want to put into an article created by themselves or somebody else. The Draft system is just an extra layer, for editors to fight over. GoodDay (talk) 19:17, 11 May 2018 (UTC)

I do not think that is an appropriate suggestion at all. Coming from a user who has a very high count of minor edits and not in the areas under discussion here, I wonder on what experience you actually base your comment. Kudpung กุดผึ้ง (talk) 20:59, 11 May 2018 (UTC)
Up until a few weeks ago, there were quite a few Draft-related disputes concerning behavior being brought to ANI. This wouldn't have occurred, if there were no Draft system. GoodDay (talk) 21:20, 11 May 2018 (UTC)
'Quite a few' is quantitively subjective. I'm no friend of statistics where concrete empirical evidence exists, but I would like to see that claim supported by some numbers. Are you an admin? Do you frequent ANI regularly? I do. Those issues would probably have been brought to ANI under some other reason. — Preceding unsigned comment added by Kudpung (talkcontribs)
Abolish the Draft system & the community just might be happier for it. GoodDay (talk) 22:17, 11 May 2018 (UTC)
Heh, I remember the days when AfC drafts were stored in the "Wikipedia talk" namespace because the draft namespace just did not exist. Let us not return to those days. Mz7 (talk) 09:56, 12 May 2018 (UTC)
Re: "Up until a few weeks ago, there were quite a few Draft-related disputes concerning behavior being brought to ANI. This wouldn't have occurred, if there were no Draft system." On those grounds, if we abolish article space we'll have no article concerns brought to ANI, and if we abolish User space we'll have no User space concerns... perhaps we should just abolish Wikipedia? Boing! said Zebedee (talk) 10:35, 12 May 2018 (UTC)
  • Comment - the interpretation of the RfC that "notability criteria don't apply to draft space" continues to be tone-deaf, overly simplistic, and harmful. Of course drafts should be on notable topics; anything else fails WP:NOTWEBHOST. Deciding which is which is a task for MfD (or perhaps drafts should be handled at AfD since they're supposed to be articles) but just setting another completely arbitrary draft working limit (like "six months") is not going to do anything to address the problems identified by this proposal (which are real problems which should be addressed). It's just inviting fights about what constitutes meaningful improvement. Ivanvector (Talk/Edits) 19:20, 11 May 2018 (UTC)
(edit conflict) I also endorse GoodDay's comment. Ivanvector (Talk/Edits) 19:20, 11 May 2018 (UTC)
I agree but 1) I never propose RfCs that I don’t think have pre-existing consensus, and I think making N apply to all drafts at the beginning doesn’t have a chance of passing. 2) This actually expands the force of N to drafts more than it is now, while still shielding them from the brunt of it initially. It can’t be the sole reason for deletion, but a repeatedly deleted draft that fails the notability criteria and doesn’t have a chance of being in mainspace. TonyBallioni (talk) 19:30, 11 May 2018 (UTC)
I just think the implementation of the RfC has been very poorly done; I get the intent, but, ugh. The notion that the draft space should be an incubating space for content intended to form part of an article, and not a junk space to hold whatever bits of writing anyone wants to drop there, seems to be a minority opinion. It's absurd to me that we allow editors to post basically anything they want in draft space, like the thousands of drafts that are nothing more than SEO listings for entirely non-notable businesses. We keep telling the authors of these articles that they "don't demonstrate notability" but our AfC messages encourage them to try again by adding more references, as though we'll decide to accept their article that's just a list of directors of their tech startup if they just pay for enough copies of their own press release, and so of course they resubmit over and over again with no meaningful improvement. There's no meaningful improvement to be made, the topic is not notable. We should empower our AfC reviewers to just come out with it and say, "this isn't notable" and punt the drafts to MfD immediately. And we can word that response as gently as we need to, we've been rejecting and deleting articles on non-notable topics for, oh, 17 years now? But if everyone who's been here a month can see that a draft on a non-notable topic is going to end up being deleted, is it more bitey to string an editor along for months and possibly years with messages telling them they just need to improve the draft a bit more before it can be an article when it never will be, or just delete it outright and say "thanks, but no"? I realize I'm ranting here and I'm probably not even really addressing the proposal at this point, but if anyone wants to really consider this, my talk page is probably a good place to respond.
Tony, to reply to your comment more briefly, a draft that doesn't have a chance of being in mainspace shouldn't need to be repeatedly [declined] before we pull the plug and delete it. In my opinion we should be able to make that determination much earlier in the process. To GoodDay's point, when a draft is reviewed we should be able to determine its article-worthiness on the first go-round, and either promote it or delete it. If it's notable but poor quality, promote it and let the usual community improvement process proceed. If it's not notable, delete it. Somehow AfC has evolved into a highly arbitrary quality pre-screening process, and I'm pretty sure that was never the intent. Ivanvector (Talk/Edits) 20:39, 11 May 2018 (UTC)
Ivanvector, The notion that the draft space should be an incubating space for content intended to form part of an article, and not a junk space to hold whatever bits of writing anyone wants to drop there, seems to be a minority opinion, is in fact very much a majority opinion. Our CSD criteria are very strict and narrow but there is no catchall for cases that don't completely match a criterion. I agree entirely that when a draft is reviewed we should be able to determine its article-worthiness on the first go-round, and either promote it or delete it. But we don't even do that in the harsh reality of the front-line trenches at at NPP where there are borderline cases that have to be sent to AfD, or inappropriate CSDs that admins have to decline and send to AfD. Contrary to GoodDay's point, it's not the Draft namespace that should be deprecated - it's more likely that AfC should be abolished or merged into NPP - but we're trying to come up with a compromise that will prevent that happening). Kudpung กุดผึ้ง (talk) 21:38, 11 May 2018 (UTC) Kudpung กุดผึ้ง (talk) 21:38, 11 May 2018 (UTC)
User:Kudpung, User:Ivanvector - I honestly didn't know that the common sense stated above was a majority opinion. It often seems that I am in the minority in thinking that draft space should be kept free of crud that will never be ready for mainspace. I don't mean to be sarcastic, but it does appear that Ivanvector and Kudpung and I are in the minority in wanting to apply common sense to what can be in drafts. Perhaps the problem is that AGF and BITE are carried to such extremes that they are allowed to override judgment about drafts. As User:Legacypac said today at my talk page, there is a culture of busybodies who have no practical experience at AFC or MFD but show up to express opinions. This is unfortunately part of a larger Wikipedia culture that it is a good idea to dump on the reviewers for not being sufficiently welcoming to new editors (even if they are fools or flacks). I honestly didn't know that Ivanvector and Kudpung and I were in a majority, when there is a culture of editors who preach platitudes about AGF and BITE without seeing the fools and flacks. (Of course new editors who have clues should be welcomed. Some do, many don't.) Robert McClenon (talk) 23:24, 12 May 2018 (UTC)
  • I disagree. When reviewing pages at NPP, there are a lot of articles that could potentially be articles with a lot of work, but aren't good enough for article space. For example, an "article" of thoughts in bullet form with a list of references. Without the option to move this to draft space, are you suggesting that this be kept in article space or be deleted? Natureium (talk) 19:26, 11 May 2018 (UTC)
Userspace. —SmokeyJoe (talk) 21:44, 11 May 2018 (UTC)
  • Support, or at least extending ACTRIAL to DraftSpace. On the whole it is a big negative, mostly due to the silent cold reception given to the newcomers. They should edit mainspace before starting new topics. —SmokeyJoe (talk) 21:42, 11 May 2018 (UTC)
Of course it would be better extend it to all users. We could do away with AfC altogether then, but that would defeat 50% of the object of having ACTRIAL - allowing IPs and non-confirmed user to create drafts was part of the plea bargain in order to get ACTRIAL approved at all. Kudpung กุดผึ้ง (talk) 04:32, 12 May 2018 (UTC)
  • Wouldn't it be a possible idea to have a ClueBot NG style bot monitoring drafts and reverting resubmissions without substantial changes? I guess an edit filter won't work because it probably can't detect resubmissions but a bot could and that would be a potential time saver if human editors weren't forced to check those pages manually. Regards SoWhy 10:27, 12 May 2018 (UTC)
    Hmm, this is beyond AI at this time. SoWhy. "What is substantial changes"? Lot of text? Lot of references?. Number of sections?. –Ammarpad (talk) 10:37, 12 May 2018 (UTC)
      • Well, ClueBot NG is pretty good at spotting vandalism. But that's why I asked. A bot could at least handle cases where no changes were made, couldn't it? Regards SoWhy 11:55, 12 May 2018 (UTC)
        • Actually, this isn't a bad idea. There's one draft currently being debated at MfD, where it was rejected for the seventh time for notability with the note that the Daily Mail isn't a reliable source, so the person removed the Daily Mail and then re-submitted. I've also seen drafts where it was re-submitted immediately after the rejection with literally no changes. It would very easy for a bot to detect and reject these submissions. Compassionate727 (T·C) 21:33, 15 May 2018 (UTC)
  • I don't really have any idea what this is all about. But from a purely technical viewpoint I could quite easily train an AI program to scan for substantial changes to an article, measured by a weighted quality score rather than using any one measure. Such a program could be programed to automatically detect whether sources have been added or just slightly altered. And it would be feasible for it to detect and warn reviewers of policy violations in the text. The only reservations I have is that since no program is perfect I would not recommend you have an AI editing articles all on it's own. JLJ001 (talk) 11:10, 17 May 2018 (UTC)
  • The more I read these debates, the more I feel the ability to ban/block users from any form of article creation process is inevitable. Junkcops, aka FMecha (mail box|what I did) 05:41, 23 May 2018 (UTC)

Regarding MfD of drafts and G13

I've heard that G13 is supposed to delete the junk from draftspace, but there's a better way. I propose that we repeal G13 and expand *some* CSD to draftspace, possibly write up new draft-specific CSD and PRODs, without actually expanding the normal PROD to draftspace (because it wouldn't be patrolled enough). Why? First off, G13 is simultaneously too fast and too slow. Too slow to delete the obvious garbage (and does nothing for repeat, unchanged, AfC submissions), and too fast to accommodate an abandoned-but-workable draft. Second, G13 is arbitrary. 6 months means nothing (see also WP:NODEADLINE). In a nutshell, more specific deletion criteria, less G13 dragnet. Thoughts? Jjjjjjdddddd (talk) 03:58, 12 May 2018 (UTC)

Keep G13 and extend PROD to drafts. After all, it's no worse than PRODing a new article at NPP. Again, however, I come back to what I've been saying several times: Improve the Wizard so that it provides some useful instructions for new users. Kudpung กุดผึ้ง (talk) 04:27, 12 May 2018 (UTC)
G13 actually sorks in favor of good drafts. A non-AfC Draft gets the attention of an experienced user working the G13 elegable list and, if tagged for deletion, an Admin's attention. I've sent many pages to mainspace from the G13 list (but 99% that reach G13 need to go in the dust bin). Rejected AfC Drafts may be bot nominated.
MfD can function as an advertised PROD for Draftspace. If no one objects a week after nomination an Admin deletes. Legacypac (talk) 04:55, 12 May 2018 (UTC)
How would some sort of PROD be helpful for drafts if they're being resubmitted? That just sounds like you want to take G13 down from 6 months to 1 week. Nobody but the occasional AfC participant looks at any given draft, so any PROD-like system is just an attempt to mass-delete drafts. I don't think we have a rash of people who take a week or two off from their draft but come back and "ruin" G13 five months later. Either these pages are resubmitted to the point of disruption or they're not. ~ Amory (utc) 13:17, 12 May 2018 (UTC)
G13 is one of the most bizarre rules on Wikipedia. I still don't know the reason it was instituted. These arguments about "clogging" the wiki are bizarre when you consider that it's all online. Also many of the deleting admins at g13 don't even look at what they are deleting, which to me is ludicrous for a wiki that claims to be a repository of the world's knowledge. Again, what exactly is the problem here and why are people looking for ever more unilateral ways to delete potential content?Egaoblai (talk) 10:43, 12 May 2018 (UTC)
I agree with you on G13, but I think it should be easier to delete drafts without potential, and other junk, so there are less junk drafts to get in the way of viable drafts. Jjjjjjdddddd (talk) 23:41, 12 May 2018 (UTC)
Egaoblai, Also many of the deleting admins at g13 don't even look at what they are deleting, which to me is ludicrous, that's a strong claim. Please state on what experience you base your assumption. Provide concrete examples. Kudpung กุดผึ้ง (talk) 02:37, 13 May 2018 (UTC)
I was looking through the G13 pages in December and saw one that I thought might be worth looking at, or at the very least not deleted without a conversation. The next day I went back to find it, but it had gone. I posted on deleting user's talkpage and asked them what the reason for deletion was, they said that it was because it hadn't been edited in 6 months and that was the only reason needed to delete an article.
I posted on the admin board about this as I believed that this was not the spirit of the rule and that deleting admins at g13 were supposed to check the articles before deleting them. The incident was closed and I messaged the closing admin about it, which actually led to this discussion: https://en.wikipedia.org/wiki/User_talk:Primefac/Archive_14#Closing_the_Incident whereI was told that deleting admins can and do delete articles at g13 without looking at them. Winged Blades of Godric even stated that "even a GA-standard article, that for some reason has been lingering for over 6 months in draft space, could be G13-ed." Not that they neccesarily agreed with that, but that is the system that is happening right now. Do we really want the same lack of oversight to be applied to PROD too? Egaoblai (talk) 16:16, 13 May 2018 (UTC)


This is commonly known, Kudpung. It may be that most admins who patrol G13 are diligent, but – as often happens – the vast majority of G13 deletions are carried out by the minority of admins who aren't. – Uanfala (talk) 14:47, 13 May 2018 (UTC)
On the contrary when I nominate G13 I save the occasional useful page and the Deleting Admins occasionally save a page I nominated so they are looking at them. We have a G13 postponed category too. We definately need G13 or the rejected and abandoned would pile up. G13 sweeps up all kinds of problematic pages, including link spam. Legacypac (talk) 04:06, 13 May 2018 (UTC)
Wow... just wow... Time for a history lesson. G13 was originally created when we had One hundred and thirty thousand pages in the space Wikipedia talk:Articles for Creation/ that had been created by 15-minutes-of-fame editors that had zero interest in coming back and correcting the issues raised with their submission. G13 was originally written to address AfC pages that had been 100% unedited for 6 months. Editors went through and did bulk nominations causing admins to be upset with the amount of pages G13 nomination category and with the overall size of the CSD nominations set. I developed a bot script that would procedurally go through all the pages and warn the author that the page was in danger of being deleted under G13, how they could prevent the deletion, how they could get the page back with a very low effort, and if they were a user the option of WP:USERFICATION. The bot limited the number of pages in the G13 sub-category to 50 pages at once so as to not overflow the admins. Over time the backlog was addressed, AfC moved to Draft space, Incubator moved to draft space, the G13 rule got finessed to be "unedited for 6 months (barring bot edits or trivial changes)" (which I think opens it up to discretion and uphold the more strict interpertation of the rule), and finally G13 got expanded to encompass all of Draft space. G13 was written to be a binary question Has this page been unedited for at least 6 months? If so, you may nominate for CSD:G13. The amount of Good will that is expended towards the authors whose pages get swept up by G13 is far more than any other area in Wikipedia for the simple reason that these authors are supposedly the newbies and shouldn't be bitten by not knowing all the esoteric rules of mainspace. Abolishing G13 will only create more MFD nominations. Hasteur (talk) 01:56, 14 May 2018 (UTC)
  • G13 was logically required, and still is. G13 cannot be repealed for as long as newcomers are encouraged to start drafts. --SmokeyJoe (talk) 07:58, 14 May 2018 (UTC)
  • G13 is certainly required but I've found ~5% of G13-ed abandoned drafts are on notable topics which might be salvageable with work but aren't ready for mainspace. I wish there were some way of dealing with these and bringing them to the attention of a wider editor base. Robotically deleting G13s because they are eligible feels wasteful to me. Espresso Addict (talk) 12:00, 15 May 2018 (UTC)

Sticky PROD for drafts (idea)

TonyBallioni expressed these 4-points in the above proposal.

  1. repeatedly resubmitted
  2. with no improvements,
  3. has no chance of being in mainspace, and
  4. has no sourcing for uninvolved editors to show notability

There are many, many drafts that currently possess the above characteristic squarely. However, I (previously) largely opposed because, it just repeats what exists, and will not make any solid difference to how MfD is run now. Because any draft that clearly possess these characteristics, it will surely be deleted at MfD. Now we are looking for way to move forward. To agree on more process that will hasten deletion of utterly non notable drafts that otherwise didn't met any of our CSD criterion and at the same time be courteous to these new users. One of the option can be clear need for Speedy criterion for them, which has been repeatedly discussed but lacked support. So I think why should we not try special PROD for that kind of drafts?. I know something like this was discussed before, but I am outlining it more explicitly below for more thought.

  1. A draft meet all the above four characteristics.
  2. A special sticky Draft Proposed Deletion tag (DPROD) is placed by user.
  3. Once draft is tagged with DPROD tag, then it cannot be removed unless if the person wishing to remove it has thoroughly rewrote the article and moved it to mainspace. (This will serve two purposes: It will be an incentive to save salvageable drafts and at the same time any non-notable draft moved to mainspace without development will now be subjected to both WP:ACSD and AfD.)
  4. If the tag, remains in the draft after say 1 week, 2 weeks or 1 month at most; then it will be summarily deleted as expired DPROD. Any recreation is subject to rule of G4 since it is determined not notable at all and no one is willing to explain why it should stay here.

Through this method, a large number of these hopeless draft will be easily shown the way out without exhausting editors' time at MfD and at the same time ample chance is given for anybody to prove why they should stay here.

Of course, this can be tweaked and refined. –Ammarpad (talk) 10:24, 12 May 2018 (UTC)

  • Strongly Oppose Every single time someone makes a proposal to increase deleting things, the argument is always "but we'll only do it for the ones that are really non notable, we swear", and every single time, the dragnet is increased and increased until you have uninvolved editors, who have zero knowledge or interest in the subject of an article or draft declaring "this will never be notable". At least with the jury system of AFD these decisions have a fighting chance, but increasing the scope of what are basically unilateral deletions is not helping the Wiki with collaborative editing. Just the other week I dePRODded an article, which the nominator then sent to AFD instead, to which the community decided that the article was notable. How many articles that the community would have seen as notable have been wiped from the Wiki because of PROD? It's undemocratic and goes against the spirit of consensus, which is supposedly how this Wiki is run.Egaoblai (talk) 10:49, 12 May 2018 (UTC)
Again Egaoblai you are making some very strong assumptions. The way Wikipedia is run, some examples would be needed to give weight to your opinions. Our PROD systems were introduced on very strong consensus - are you suggesting PROD is 'undemocratic' just because you found one that was kept at AfD? Kudpung กุดผึ้ง (talk) 02:47, 13 May 2018 (UTC)
So, I have looked at your editing history and your user page and checked out the articles. I admit that more 'BEFORE' should have been done prior to listing them for deletion. But this is not a fault of the system, it's a problem of educating the users who tag them. In the case of the school article on which your arguments were excellent, your adversary has a clear pattern of singling out schools for deletion. They generally lose the school AfDs they nominate or vote on. Kudpung กุดผึ้ง (talk) 03:11, 13 May 2018 (UTC)
A system should be evaluated by how it works in practice, not in theory. Furthermore, just because a system is established by consensus does not mean the system itself is democratic. — Godsy (TALKCONT) 04:57, 14 May 2018 (UTC)
  • Support in principle, but perhaps a normal PROD would suffice. I am reminded of recent discussions somewhere about a 3-Strike rule, but I don't recall the outcome. Perhaps a PROD following the 3rd rejection? Kudpung กุดผึ้ง (talk) 02:51, 13 May 2018 (UTC)
  • Support Prod for drafts but I prefer simply sending them to MfD as a form of advertised Prod If no one votes keep and adopts the page in a week it gets deleted without fanfare. Legacypac (talk) 07:49, 13 May 2018 (UTC)
  • Support I am surprised there is not already some guideline providing for the deletion of drafts resubmitted after being rejected for non-notability, and where the draft has been changed little if at all since the last rejection. I certainly think this would be helpful in helping the community delete some of these drafts that clearly have no chance of becoming actual articles. But I wonder: the proposal uses the word "repeatedly"--does that mean that a draft that was rejected once, resubmitted, and then rejected again would immediately become eligible for deletion? Does "repeatedly" mean "2 times or more" here? (BTW what the answer to this question is doesn't really matter as far as my support for this proposal is concerned.) Incidentally, I might even support the use of a new CSD criterion for drafts repeatedly rejected as non-notable, where the lack of notability is obvious. Every morning (there's a halo...) 21:08, 13 May 2018 (UTC)
  • Comment Do you realise how BITEY this sounds? "Hey your draft sucks and we've put a label on that means if you don't improve it in one week it's getting deleted!" If you wish to frustrate new users or people that can't afford to spend hours a day on Wikipedia, then this is the proposal for doing that. AFC reviewers are not gods and their opinion on what is notable should not supercede the community at large. Currently drafts can be deleted through MFD, which at least puts things to a public discussion. There is also G13 which is mostly hidden and allows drafts to be deleted without discussion after 6 months. Now you want to increase that power and allow drafts to be deleted after a week? based on the opinion of one person at AFC? What is with this paranoia and hand wringing about drafts. What problems are there that this is a solution to that G13 or MFD don't already solve? Please consider that for many many users here, writing a draft is a learning process and so is submitting it for review. Not every draftee is out to try and scam the wiki, many are good faith contributers, often with English as a second language who need guidance and help and community. What ever happened to that on this wiki? As far as I can tell this proposal does not allow any chance for the community to help the draftee improve the page, nor does it offer any space for the community to discuss the merits of the draft. According to the proposal one or two AFC editors could effectively blackball a topic from wikipedia and this would go unnoticed by the majority of editors, unless they were also AFC editors who happened to look in, or people who browsed Prod. This is really unacceptable for anyone who sees this as a community project. Egaoblai (talk) 00:06, 14 May 2018 (UTC)
  • Oppose So you'd rather take the consensus discussion that happens at MFD to individual draft pages and put a arbitrary stickey prod on it? PROD is "I propose a uncontraversial deletion". The only exception is BLPPROD, and that is foundation policy. Hasteur (talk) 01:58, 14 May 2018 (UTC)
    That is not true. BLPPROD was not created by fiat because of "foundation policy" as you're wrongly implying. It was created after community consensus was found for it. Your first point doesn't make sense either. It is still uncontroversial PROD, if you object to any DPRODDED draft, then simply develop the draft to become meaningful article, move it to mainspace and remove the tag, the same way it is done for sources in BLPROD. –Ammarpad (talk) 07:06, 14 May 2018 (UTC)
  • Oppose for drafts that, if they were articles, would not fall under BLPPROD; support ONLY for drafts on living people that would otherwise fail BLPPROD. There's absolutely no reason to apply a sticky PROD to all drafts, and as noted above it's fairly BITEy to users for whom English may not be a language they can communicate well in. (There have been a few instances in -en-help where users seeking help have "keyworded", missing most of what was being said and responding only to certain words in the message.) That said, biographical drafts do still fall under WP:BLP, and so those can and probably should be allowed to be sticky PRODded if they have absolutely no sources (or ELs that can be made into sources) whatsoever. —Jeremy v^_^v Bori! 03:11, 14 May 2018 (UTC)
    @Jéské Couriano: You missed the requisite points raised above. This is not meant to apply to all drafts. It is meant only for draft that:
    • is repeatedly resubmitted
    • with no improvements,
    • has no chance of being in mainspace, and appears to
    • has no sourcing for uninvolved editors to show notability. –Ammarpad (talk) 07:16, 14 May 2018 (UTC)
    To which I'm saying that those limitations are bullshit. In essence, I'm saying "apply BLPPROD standards to biographical drafts instead of making a sticky PROD standard for all drafts". Note that my argument in favour of MfD'ing unacceptable drafts above comes with caveats more along the line of those suggestions you just threw at me. I agree with the other Opposes in that this is something that seems too half-baked and, as pointed out below, the time period the grace period provides is ludicrously short, considering most drafts tend to get abandoned due to real-life concerns. The only sticky PROD debate we should be having is whether to apply BLPPROD to drafts, not whether to BITE newcomers who may not speak very good English or who (almost invariably) have real-world commitments that make this sort of PROD so bitey. —Jeremy v^_^v Bori! 08:48, 14 May 2018 (UTC)
  • Oppose - 3.Once [a] draft is tagged with DPROD tag, then it cannot be removed unless if the person wishing to remove it has thoroughly rewrote the article and moved it to mainspace. is fairly self-evidently ridiculous, but I'll explain the fundamental flaw (among the many flaws): Deletion bar improvement should not be turned into a unilateral decision by a single editor but should remain a community decision that is made through a discussion to determine consensus. — Godsy (TALKCONT) 04:47, 14 May 2018 (UTC)
  • Oppose - Sticky and PROD don't belong together, especially not in draft which is supposed to be a safe space for article development. ~Kvng (talk) 12:57, 14 May 2018 (UTC)
Draft is for article development - you got that part right. Deletion procedure is for junk/promo that is not going to be an acceptable article. Legacypac (talk) 15:12, 14 May 2018 (UTC)
  • Oppose for this to work it would have to have objective criteria, things like "no chance of being in mainspace" and no evidence of notability are very subjective. The process doesn't make any sense at all. If I take a draft which has been sticky PRODed and add two sources which demonstrate that the subject is notable then I can't remove the tag. Not unless I'm also prepared to completely rewrite the article and get it ready to move it to mainspace before the clock expires. Having recreations subject to G4 doesn't make any sense either, and we don't apply it to other types of PROD. MfD is not being inundated with deletions of hopeless drafts and if it was then something closer to normal PROD would make more sense. Hut 8.5 18:22, 14 May 2018 (UTC)
  • Oppose. I appreciate the good intent of this idea, but I think it has the problem of setting a deadline for something that doesn't need a deadline. The main proposal above is in large part about the problem of drafts that keep getting resubmitted, but the proposal here is about drafts that are just sitting there. --Tryptofish (talk) 19:18, 15 May 2018 (UTC)
  • Oppose draft means draft.--Paul McDonald (talk) 23:22, 24 May 2018 (UTC)

American English Wikipedia

No. TonyBallioni (talk) 16:47, 18 May 2018 (UTC)
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.

Split American English Wikipedia (let's say american.wikipedia.org) and use British English on English Wikipedia as British English is the original dialect of English. That would solve all debates on which dialect of English should be used on which article. Erkinalp9035 (talk) 16:36, 18 May 2018 (UTC)

Articles currently in American dialect would be moved to American English Wikipedia. Articles written Australian, NZ and Indian varieties would be converted to British English. Erkinalp9035 (talk) 16:38, 18 May 2018 (UTC)

Extremely bad idea. Lots of work without any gain whatsoever. Also, Australian and New Zealand Englishes are perfectly legitimate and separate varieties of English. Mr KEBAB (talk) 16:40, 18 May 2018 (UTC)
@Erkinalp9035:, you may want to see this. The wild impracticality also applies equally to this. I also suggest reading the Manual of Style on English varieties. Good luck. Eggishorn (talk) (contrib) 16:43, 18 May 2018 (UTC)
WP:ENGVAR is already quite adequate to deal with it. Splitting projects would be a massively excessive "solution" to an already solved problem. Seraphimblade Talk to me 16:45, 18 May 2018 (UTC)

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.
Sorry for necroposting, but MediaWiki already has a separate "en-gb" language option, so we could theoretically have a "en-gb.wikipedia.org". Lojbanist remove cattle from stage 23:29, 29 May 2018 (UTC)
It'd be better to have someway to convert articles between the two (actually all) English dialects within the same Wikipedia. I think that was originally planned for the Serbian Wikipedia (for ekavski and ijekavski dialects) using lookup tables or something.Details on that plan here. I'm pretty sure that part wasn't implemented and they only got the Latin/Cyrillic script converter. Anyway, the ekavski/ijekavski problem is a headache (go read about it) but doing English "dialects" should be really simple. Brightgalrs (/braɪtˈɡæl.ərˌɛs/)[ᴛ] 15:38, 6 June 2018 (UTC)

WP:NOTMEMORIAL Victim lists in mass tragedy articles - Round 2

The issue of victim lists in mass tragedy articles was adressed before and the consensus was that these scenarios should be handled on a case-by-case basis. I believe the issue needs to be addressed again to finally reach global consensus due to the fact that each mass tragedy articles become a constant struggle amongst editors supporting or opposing the inclusion of a victim list. There is also another issue where outcomes of a consensus on a specific article does not count as consensus for later articles, so the back and forth edits and fights never end. Current RfC

Current language of WP:NOTMEMORIAL: Memorials. Subjects of encyclopedia articles must satisfy Wikipedia's notability requirements. Wikipedia is not the place to memorialize deceased friends, relatives, acquaintances, or others who do not meet such requirements.

I propose that we add a line to WP:NOTMEMORIAL that would either allow or prohibit listing individual victims of mass tragedies if they do not meet our notability guidelines and/or WP:BLP and they are covered in the media as part of the story of the mass tragedy event. This proposal, if approved, would also override any local consensus and precedents. Long lists containing more than 20 names should be contained in a collapsed section.

   Support = Will allow inclusion
   Oppose = Will prohibit inclusion

Cheers, --Bohbye (talk) 21:52, 23 May 2018 (UTC)

Memorial:Support

  • Support as nominator. --Bohbye (talk) 21:53, 23 May 2018 (UTC)
  • Support - I continue to say that the victims are notable in the context of the given event. This isn't just someone creating an article in order to remember their deceased loved one or friend. - Knowledgekid87 (talk) 04:04, 24 May 2018 (UTC)
  • Support — I'm reading this proposal as "allow" not "require," since that's what it says. I don't expect adding a line to WP:MEMORIAL stating this will end all disputes over victim lists. However, right now these disputes often boil down to
Proponent: I think we should have a victim list due to X, Y, and Z.
Opponent: I don't think we should have victim lists because of WP:MEMORIAL
Proponent: That's not my reading of WP:MEMORIAL.
Admin closer: No consensus.
This is simply not a helpful pattern. If WP:MEMORIAL included something like the following it would help: "This policy does not prohibit the inclusion of lists of victims of tragic events, if they serve an encyclopedic purpose, appear in reliable sources, and are compliant with other Wikipedia policies. These lists should be written to provide relevant information, rather than memorialize the lives of the victims."--Carwil (talk) 18:46, 24 May 2018 (UTC)

Support as 2nd choice. A mandatory rule that overrides local consensus and past precedent is a horrible idea that will require absurd and illogical outcomes. However, if the community decides to create a mandatory rule, I’d prefer for it to be inclusion for two reasons. First, this is more in-line with common practice on Wikipedia (particularly with school shootings) and will require less clean-up. Second, many tragedies are notable because of the specific victims (such as the 1943 Gibraltar B-24 crash, which killed many leaders of the Polish Government in Exile). In these cases, it is incredibly important to know the names of at least some of the victims. Further, many notable people (particular those from non-English speaking countries) do not have articles, so we’d have to hold a pre-emptive AfD for many entries into the victim list. Spirit of Eagle (talk) 19:40, 2 June 2018 (UTC)

I realized that a mandatory inclusion rule would require victim lists for pandemics such as the 1918 flu pandemic (50 million deaths, minimum), natural disasters such as the 2004 Indian Ocean earthquake and tsunami (230,000 deaths, minimum), and genocides such as the Rwandan Genocide (500,000 deaths, minimum). Most commenters in this RFC agree that victim lists are appropriate in some articles but not others; the main dispute here is over the proportion of articles in which victim lists are appropriate, not whether they are appropriate period. I think this RFC would have been more helpful if it proposed a default rule that could be overruled with local consensus instead of a mandatory rule that must be obeyed even in illogical situations. Spirit of Eagle (talk) 20:47, 2 June 2018 (UTC)

Memorial:Oppose

  • Oppose, policy is meant to be descriptive, not prescriptive. As it stands, this type of information gains consensus to be included in some articles and fails to in others, so there is clearly no consensus that this should always or never be added. Therefore, case by case discussion, as is current practice, is the proper way to settle it. Seraphimblade Talk to me 22:17, 23 May 2018 (UTC)
    • Seraphimblade, I'm not sure that your response matches the description above for what "oppose" is supposed to mean. WhatamIdoing (talk) 02:55, 24 May 2018 (UTC)
  • Oppose, the victims of mass tragedies are (generally) not notable, they are simply the people who happen to be in the area when the event occurs. Even in the case of mass shootings (where this debate keeps popping up), most of the perpetrators are not targeting specific people, they are simply killing anyone in the way. Obviously there are some minor exceptions. The vulcanologist who was killed by the eruption of Mount St. Helens while collecting data, a newscaster who is blown away by a tornado while on air, a passenger on a jet who attempts to stop hijackers, a shooting victim who was called out by name in the perpetrator's manifesto. But notice that these are highly specific things. For most victims of these tragedies the story would have been exactly the same if anyone else had been there and their names give us no real extra data. --Khajidha (talk) 11:58, 24 May 2018 (UTC)
  • Oppose but with appropriate exceptions. We should encourage editors to avoid these, unless there are reasonable circumstances, notably that if discussing the event that it is impossible to do so without mention some of these people. --Masem (t) 02:30, 25 May 2018 (UTC)
  • @Masem: My understanding is that this is about complete lists of names and ages, not prose about selected notable victims. They are separate issues and I think most opponents of the former do not oppose the latter outright, although we might disagree on the meaning of "notable". In my opinion your !vote is the same as mine in the following subsection. ―Mandruss  02:36, 25 May 2018 (UTC)
  • Oppose, lack of notability. — Preceding unsigned comment added by Edibobb (talkcontribs) 02:08, 27 May 2018 (UTC)
  • Oppose, with appropriate exceptions per Masem and Khajidha. The status quo, however attractive it may seem to !vote for, has not served as well, and provides a justification for battleground that is really unnecessary. The wording should at least strongly discourage the practice of inclusion. No such user (talk) 13:35, 31 May 2018 (UTC)
  • Oppose. For the normal reader it is an utterly meaningless and worthless list of names randomly pulled out of the phonebook (with my apologies to the family and friends of the deceased). For the normal reader, it serves absolutely no encyclopedic purpose. Name(s) should only be included where it provides some identifiable and distinctive purpose for a generic reader. If it's a relative of the perpetrator, or a celebrity who gets individualized news coverage, or one of Khajidha's examples, it makes sense to have a textual-discussion of those individuals. To make the point reducio ad absurdum, there's no reason we should treat the victims of a mass shooting any differently than the victims of 9/11. A list of 20 random names is just as useless as a list of 2,996 random names. Alsee (talk) 00:53, 1 June 2018 (UTC)
  • Oppose - 2nd choice because there should be explicit provision for exceptions. Superior to status quo, however, per my comments elsewhere in this proposal. ―Mandruss  01:25, 1 June 2018 (UTC)
  • Oppose a list of the names of non-notable people who were killed in an event has no point other than to memorialize the victims in question. While I feel for the people involved, that is not the point of an encyclopedia. Cataloging the victims of various of events is a noble pursuit, but is more suited to another venue. My conclusion would be to prohibit victim lists unless the victim meets general notability requirements. It is either that or we have to decide where to draw the line. Does every soldier who died during a battle get listed in an article about the battle? How about everyone killed by the Nazis at Auschwitz in it's article? The list could do on. {{u|zchrykng}} {T|C} 05:39, 5 June 2018 (UTC)
  • Oppose, If for no other reason then who gets to decide what is deserving of such memorials? Victims of Terror, Mass shootings, collateral damage? Too much room for edit warring and POV pushing.Slatersteven (talk) 15:41, 6 June 2018 (UTC)

Memorial:Alternatives

  • Status quo Continue deciding ona case-by-case basis. Beeblebrox (talk) 01:38, 24 May 2018 (UTC)
  • Status quo One-size-fits-all policies are rarely useful at Wikipedia. --Jayron32 02:28, 24 May 2018 (UTC)
  • Status quo, since apparently "oppose" doesn't actually mean, well, "oppose", but I oppose making such a change. Policy is meant to be descriptive, not prescriptive. As it stands, this type of information gains consensus to be included in some articles and fails to in others, so there is clearly no consensus that this should always or never be added. Therefore, case by case discussion, as is current practice, is the proper way to settle it. Seraphimblade Talk to me 22:17, 23 May 2018 (UTC)
  • Status quo - 2nd choice. - Knowledgekid87 (talk) 04:04, 24 May 2018 (UTC)
  • Default to omit, exceptions by local consensus - There was a minor but distracting outcry of "Not this again!" when the list was disputed at Santa Fe High School shooting, and the RfC for that case is underway. If "Status quo" or "no consensus" is the result here, it must be stressed that "Not this again!" is inconsistent with that result and thus an invalid complaint. If the community kicks this decision down to article level, despite the fact that the relevant factors and circumstances are essentially the same in each successive case, then the community is saying it must be re-litigated at each successive case. I oppose that as a waste of editor time, and I support omission as default with provision for exceptions by local consensus. The difference between that and the simple "decide case-by-case" is that any arguments for exception would be required to show what is unusual about the case that justifies exception to the default. My rationale for supporting omission rather than inclusion as default is found here (first !vote). ―Mandruss  04:09, 24 May 2018 (UTC)
  • Status quo. Continue deciding on a case-by-case basis. One-size-fits-all policies are rarely useful at Wikipedia. Case by case basis with no default rule. Some take WP:NOTAMEMORIAL way out of context. It is meant to shut down stand alone bios on deceased friends and family. It is not meant to exclude the mention of a murder victim name within the context of a page about a notable crime. Bus stop (talk) 05:38, 24 May 2018 (UTC)
  • Omit excepting strong local consensus I'm not entirely sure what adding a comprehensive list of victims adds to an article, and as some users commented at the last RfC, it may be seen as disrespectful to mention people purely for how they died (WP:BLP1E). If some victims are notable for other reasons, sure it may make sense to list them. However, there may well be cases where listing all victims makes encyclopedic sense, and local consensus should be sovereign where it exists. Richard0612 12:46, 24 May 2018 (UTC)
  • Generally Support Inclusion I think generally murder victims names and often ages (which helps distinguish the victum from other people with the same name) are an important part of every murder story that are almost always covered by reliable sources repeatedly. We have almost always covered the victim names for other notable murders like Golden_State_Killer#Original_Night_Stalker There is a trend in the media to even deemphasize the killer's name and emphasize the victims for notoriety reasons. Some take WP:NOTAMEMORIAL way out of context. It is meant to shut down stand alone bios on deceased friends and family. It is not meant to exclude the mention of a murder victim name within the context of a page about a notable crime. Do to privacy and accuracy reasons I do not support releasing victim names before they are released by law enforcement and published in RS or the listing of all wounded victims, which needs to be considered on a case by case basis. If child Mary Jones is shoot in the leg and survives she does not need to be named on wikipedia but if Jane Smith gets shot and earns an award for heroism we may well name her. Legacypac (talk) 12:48, 24 May 2018 (UTC)
  • Status quo. The current wording, which in general would appear to prohibit the mass listing of names, but would allow for it if there were a good reason (mainly notability), seems fine.  — Amakuru (talk) 12:59, 24 May 2018 (UTC)
  • Status quo - Case by case basis with no default rule. I have supported inclusion on the two most recent mass shooting pages I have participated in, but I see examples where it was decided to exclude the names, and if there is another situation where that is what the consensus is decided to be I have no problem with it. WikiVirusC(talk) 13:22, 24 May 2018 (UTC)
  • Status quo - Should be done on a case-by-case basis, Seems the logical answer..... –Davey2010Talk 14:10, 24 May 2018 (UTC)
  • Status quo - There are some cases where setting notability as a threshold would be a good idea. But, there are other cases, like where there are seven or so victims, and one notable person among them, when including the names of all killed would be a fine idea. Overall, having a guideline to cite isn't very good when that guideline has lots of good exceptions. RileyBugz私に叫ぼう私の編集 20:13, 24 May 2018 (UTC)
  • Status quo I'd suggest that it mostly depends on the number of names, if there are only a handful then it makes some sense to include them, if there are hundreds then it probably isn't a good idea. There are other factors that could affect the decision though. Hut 8.5 20:30, 24 May 2018 (UTC)
  • Default to include, allow exclusion per local consensus After every major shooting, we seem to have the exact same debate about whether to include a list of victims. The debatealmost always centers around the same general arguments rather than the details of the specific shooting. Having to debate the same point again and again is a waste of time and is starting to ware on the nerves of many editors. Establishing a default rule instead of continuously debating the same point would be in the best interest of Wikipedia. I would prefer for the default rule to be inclusion of the lists for the reasons I explain here. Spirit of Eagle (talk) 01:51, 25 May 2018 (UTC)
  • Status quo These are the type of articles where the need for editorial judgement is the greatest. Drawing lines in the stand is rarely useful. Cullen328 Let's discuss it 07:32, 25 May 2018 (UTC)
  • These local discussions are never about the characteristics of the case. They are regurgitations of the same general arguments about victim lists, over and over. The result depends merely on the mix of the editors involved in the local decision. And there are always many editors who !vote based largely on precedent, as if that showed a community consensus, when in fact it does not. If there were such a community consensus, it would be affirmed in discussions like this one. The status quo is a mess, and the only way to resolve it is to reach a community consensus for something other than status quo. ―Mandruss  08:09, 25 May 2018 (UTC)
  • Status quo Bearing in mind that WP:BLP1E still applies in the "breaking news" phase. I know that's aimed at articles, but the last thing I want to happen is for us to repeat an innaccurate list, potentially causing great distress to an affected family. There are some articles that a list of the victims just doesn't make any sense - e.g. The Holocaust. At the same time, sometimes it makes sense. Bellezzasolo Discuss 20:03, 2 June 2018 (UTC)
  • Status quo Going to squeeze in just under the wire to note that a case-by-case basis simply seems the most logical to me. — Javert2113 (talk; please ping me in your reply on this page) 18:43, 6 June 2018 (UTC)
  • Depends. Do what the historical secondary sources say — if they report a list of names, that's reasonable, but if not, don't. And don't go advocating the fringe theory that news reports are secondary sources: I'm talking secondary sources as defined by professionals. Nyttend (talk) 02:17, 9 June 2018 (UTC)

Memorial:Neutral

Memorial:General discussion

The two suggested "votes" may be confusing people. The options might be better framed like this:

  1. Require victim lists (if verifiable; WP:SPLIT to a stand-alone list if large)
  2. Decide separately for each article (permitted with consensus; status quo)
  3. Prohibit (no lists, except in extraordinary situations)

If people can be clear about what they mean in their comments, that would probably be more helpful than "support" or "oppose". WhatamIdoing (talk) 03:05, 24 May 2018 (UTC)

Victim lists have long been an issue. I was involved in a related local discussion nearly 5 years ago which had some interesting points raised. Cesdeva (talk) 11:47, 24 May 2018 (UTC)

Well it appears that nothing has come out of this discussion, the issue is going to continue to be fought out and re-discussed to death. Sorry if I sound pessimistic here but I have seen it play out now many times from both sides presenting the same arguments. Why would one school shooting for example be different than another with the same talking points presented? - Knowledgekid87 (talk) 17:28, 29 May 2018 (UTC)

Remarkably, at least one editor—an editor with extensive experience—has declined to help form a consensus with the rationale that there is no consensus. Apparently, avoiding pointless expenditure of editor time is seen by many as an improper use of community consensus. ―Mandruss  23:48, 29 May 2018 (UTC)
Are you seeing something above that implies anything other than the status quo (no change)? This has been discussed in one way shape or form for years now, something is going to have to give eventually. - Knowledgekid87 (talk) 17:42, 4 June 2018 (UTC)
@Knowledgekid87: I'm not sure I understand the question. If you're asking how I read the consensus to date, of course it leans toward status quo. If the trend holds, I know WP:how to lose and I'm resigned to the continued waste of time, but I will respond negatively to further "Not this again!" protests at article level. This will be the clear will of the community, and every editor should respect it. ―Mandruss  18:21, 4 June 2018 (UTC)

I suggest the closer apply extra care evaluating individual responses. We have a striking situation where there are !votes in three different sections all saying the exact same thing: names can be included if they serve an encyclopedic purpose. People are just coming at it from different angles. If we get stuck with yet another RFC on this same question I suggest extra effort to more clearly articulate that position. The current drafting looks too much like "Always include all names" vs "Never include any names". Alsee (talk) 01:08, 1 June 2018 (UTC)

Agree that the framing is poor, as might be expected from a very-low-time editor. I offered to collaborate on framing and my offer was ignored. But to me the drafting looks like "prohibit lists" (Oppose) vs "don't prohibit lists" (Support). In any case, I think it was clear from the start that the question is about complete lists of names and ages; that's what "victims list" means. It is not about prose about selected notable victims, and I'm pretty sure that some !voters have missed that essential point. It certainly is not about lists of names and ages of selected notable victims with no explanation for what makes them notable; that should never be on the table for obvious reasons. ―Mandruss  01:47, 1 June 2018 (UTC)

Increase G13 Speedy deletions to a one year grace period

Only four days since the two discussions started, but already it's freezing here hard. (non-admin closure) Narutolovehinata5 tccsdnew 04:48, 30 May 2018 (UTC)
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.

The G13 speedy deletion system means that any draft or AFC submitted article that has not been edited for 6 months may be deleted without prejudice. The obvious downside to this is that it can be a very WP:BITE thing to do especially for new editors, who are the type to use AFC. I think we can all agree that not every drafter is going to finish the draft in a short period of time. Many people may start a draft and then leave it for a while, maybe coming back to it later. To me 6 months seems like an incredibly short time period for which to penalise a drafter. People may have life events (job change, house move, weddings, babies, study) that get in the way of working feverishly on a Wikipedia draft. Coming back to an empty page of a draft you spent time working on must be a demoralising and frustrating thing for any editor.

Yes of course there are drafts that haven't been worked hard on. Of course there are drafts that have been made full of nonsense. But what harm would it do to keep them around a little longer? I'm not proposing that we shouldn't delete those drafts, simply that we extend the time frame, so the genuine drafters aren't so heavily penalised. The G13 system is deletion without prejudice. Deleting admins may glance at what they are deleting, but are under no obligation to and many good or potentially great drafts are deleted in this way.

So I propose that the G13 be extended to 13 months. Which means in theory a drafter may return to their draft a year after last editing and still have a month in lieu to work on it. This system does not abandon the G13 system but simply makes it less Bitey. Unedited poor drafts will still be deleted and genuine drafts and encyclopedia newcomers have less chance of being penalised. Egaoblai (talk) 19:39, 26 May 2018 (UTC)

6 months is a pretty fair amount of time for something to sit there without touching it. Natureium (talk) 19:40, 26 May 2018 (UTC)
  • It is very easy to request that drafts deleted under G13 be restored, and this is usually communicated in the deletion log entry. Also, as I understand G13, they only need to make one edit, even a minor one or dummy edit, to reset the 6 month time frame. We also have Template:Promising draft which can be used to prevent a G13 deletion by any editor. I guess I am not seeing a huge need for this proposal. 331dot (talk) 19:51, 26 May 2018 (UTC)
  • No. We’ve had countless discussions on G13, the grace period, and draft deletions. The community consensus is clear: draft space is an utter mess and we are not a webhost. It isn’t exactly like we’re dealinh with biographies of Nobel prize winners in most of these cases: G13 is mainly stuff that would be A7, A11, of G11 as an article. No need to keep that stuff for a year. TonyBallioni (talk) 19:57, 26 May 2018 (UTC)
  • Oppose; 6 months is plenty of time to get an article up to snuff if someone is actively working on it instead of half-assing it for exposure. Not to mention that G13s are almost always restored at WP:REFUND upon request (the main exceptions being undiscovered copyright violations and drafts that went right back into turnaround after the first undeletion). —Jeremy v^_^v Bori! 20:43, 26 May 2018 (UTC)
  • Oppose if anything it should be three months. Six is more than enough to get drafts up to snuff. And should a user want the draft back, WP:REFUND is thataway. ƒirefly ( t · c · who? ) 21:19, 26 May 2018 (UTC)
If people are working on it, then yes of course you can make a good draft in less than six months. But there are people who put the draft on the backburner for a while. it's not "half-assing", it's that people have lives outside of Wikipedia. Making it a year instead of 6 months decreases the amount of bite. What advantage does 6 months have over a year? Egaoblai (talk) 21:57, 26 May 2018 (UTC)
The "half-assing" bit is aimed at me, so I will point out that TonyBallioni is right in one. When I say someone is "half-assing" a draft, it's because the person working on it is doing it without bothering to educate themselves on core Wikipedia policies (WP:N, WP:NPOV, WP:COI, etc.) for the sole purpose of making a deadline or exploiting Wikipedia's preferential treatment by search engines. A large chunk of these users are from South Asia (more specifically the Indian Subcontinent area) and therefore part of the issue is also a language barrier, as a large number of these users are only selecting the English Wikipedia based upon its prevalence and cannot read or write English with the proficiency en.wp requires. Quite a few of these users, when I've dealt with them in #wikipedia-en-help, refuse to go to the Wikipedia for their native language because the people they're intending to target with their articles aren't there and search engines are less likely to pull up articles from the Malayalam or Bengali Wikipedias than English. —Jeremy v^_^v Bori! 04:41, 27 May 2018 (UTC)
  • Oppose. Not seeing any evidence of a problem requiring to be fixed. REFUND works and the workload there is not that big. Guy (Help!) 21:51, 26 May 2018 (UTC)
the problem is that new editors are being bitten and potentially good drafts are being lost too quickly for anyone to check. Is there any advantage for 6 months over 1 year?. Egaoblai (talk) 21:57, 26 May 2018 (UTC)
Can you cite specific examples of what you claim? 331dot (talk) 22:04, 26 May 2018 (UTC)
First, these are mainly spammers. I am 100% fine with biting spammers. Second, yes, the advantage to 6 months over 1 year means it is harder for a client to hire a new freelancer to work on their prexisting rejected draft. TonyBallioni (talk) 23:22, 26 May 2018 (UTC)
You have a very negative view of new editors. I'm not denying there are spammy editors, but your world view seems to treat every new editor as one and you can't accept that there are good faith editors who get lost in the shuffle due to bite.Egaoblai (talk) 07:14, 27 May 2018 (UTC)
  • Support Will reduce loss of viable content in draftspace, and will cut down on bitiness for draft-makers. Jjjjjjdddddd (talk) 23:18, 26 May 2018 (UTC)
    • Again, the idea that draftspace is a treasure trove of good faith contributions just waiting for formatting and proper referencing has no existence in reality, and these are people who haven't signed in for 6 months normally. They can't really be bit if they aren't users at all. TonyBallioni (talk) 23:19, 26 May 2018 (UTC)
      • Eh, true to some extent, and we should be able to summarily delete useless drafts, but there's some good stuff in draftspace that just happens to be abandoned. Think WP:DUSTY. Jjjjjjdddddd (talk) 05:18, 27 May 2018 (UTC)
  • Oppose per TonyBallioni. Compassionate727 (T·C) 00:41, 27 May 2018 (UTC)
  • Oppose Six months is a good sweet spot — if anything, there's a movement to decrease the length. Draftspace is big enough as is, and if you come back in 13 months missing something, WP:REFUND is a click away. ~ Amory (utc) 00:54, 27 May 2018 (UTC)
  • Oppose 6 months is already too long for most of the crap in Draftspace and we have a hard enough time at MfD deleting garbage which leads me to believe 3 months unedited would be better. Gnoming edits by random users often give pages a lot more than 6 month unimproved anyway. Having extensive experience in Draftspace I don't suffer from the delusion that Draftspace is full of ready to go gems waiting to be finished by some slow but soon to return editor. Legacypac (talk) 04:54, 27 May 2018 (UTC)
  • Oppose 6 months is plenty of time. If an editor hates asking for refunds they need only to make a minor edit to the draft to reset the time. That's a very low bar. VQuakr (talk) 05:04, 27 May 2018 (UTC)
  • Oppose The bar is already extremely low. 6 months is plenty of time with no edits and refunds are easy. I don't see how this change will make any improvement to the current system. — Insertcleverphrasehere (or here) 05:09, 27 May 2018 (UTC)
  • Oppose I would be in favour of lowering the time to 3 months. The draft namespace is for articles that are actively being improved to get ready for mainspace. Bradv 05:10, 27 May 2018 (UTC)
  • Oppose Solution looking for a problem. Decreasing time limit to 3 months is a good idea. If an draft has gone 6 months, there is a good chance it is beyond salvage. The AfC reviewers are already sorting the one's with potential from the one's without. Dlohcierekim's sock User talk:Dlohcierekim 07:04, 27 May 2018 (UTC)
  • Comment: Some editors mistakenly believe G13 is only about deleting drafts. While the vast majority need deletion, there are some useful ones that should be saved. Listing the pages as G13 eligible Wikipedia:Database_reports/Stale_drafts brings them to the attention of experienced editors and admins who can act on promoting or at least improving the pages. More eyes sooner on Drafts is the answer, not setting up systems that ignore them longer.
  • We should also consider expanding G13 to the huge mess of copyvio, attack, spam and other crap that are userspace drafts. There are even a few useful pages there to save if someone looked at them. Legacypac (talk) 05:20, 27 May 2018 (UTC)
  • Support as more in tune with the community philosophy (see WP:NODEADLINE in particular). For people who haven't had the good sense to avoid the draft namespace, it can be dispiriting to return after a break and see that their unfinished work has been deleted: it doesn't help much that refunds are easy: a reaction like "Great! Let me fill out this form now." isn't any more likely than "Oh, why bother.". Still, though a step in the right direction, this proposal isn't going to do much about the real problem: the indiscriminate deletion of drafts. A more meaningful solution is to abolish G13 altogether and replace it with a rule that after a certain period (6 months, 1 year, 3 months, 1 month, whatever), a draft becomes eligible for the article speedy deletion criteria. This will add more accountability to the deletion process, and it will weed out the vast amount of junk, leaving the community more time to deal with the promising content. – Uanfala (talk) 10:12, 27 May 2018 (UTC)
WP:G13 already says "Redirects and pages tagged with {{promising draft}} are excluded from G13 deletion," and the deletion comes from a human admin who is perfectly free to tag a draft with the promising draft template (not some indiscriminate bot). The only difference between your proposal and G13 is that your proposal would put more work on the few people helping with AFC. Ian.thomson (talk) 13:02, 27 May 2018 (UTC)
The only difference is that between the ideal and reality. Yes, many admins will look at a draft before deleting it and will spare it if it's got potential, but the vast majority of G13 deletions are carried out by the admins who don't seem to look at all. And {{promising draft}} isn't even respected by the bot that does the tagging. The problem with G13 as it stands is that it allows for (and leads to) the more or less automatic deletion of pretty much anything, regardless of quality or potential. – Uanfala (talk) 21:58, 27 May 2018 (UTC)
  • Oppose I get that not everyone logs in every day (I believe even I've had a couple of points where I didn't log in for a couple of months except to check messages), but if someone really cares, they need to check to see what's happened more at least once every half year. If someone believes they can post a half-written, unsourced puff piece in draftspace and that they're entitled to see it become the article they want without them so much as visiting the site once for over next half year -- that's a case where WP:CIR may override WP:BITE. Now, I get that that's an extreme example (even though I see "how dare you delete my company page" more often than I'd like), but the basic principle of "if you really cared, you should have checked back within the next six months" applies to any user. Ian.thomson (talk) 13:02, 27 May 2018 (UTC)
  • Oppose - the time limit is the very definition of arbitrary: it would make no difference whatsoever if the limit were 6 months or 6 years or 6 minutes, any page deleted under G13 can be automatically restored at WP:REFUND, no-questions-asked. It's part of the criterion. Also my perennial opposition to modifying G13 in any way that does not deprecate it. Ivanvector (Talk/Edits) 13:06, 27 May 2018 (UTC)
  • Oppose, G13 isn't even a "hard" deadline. An editor can work on a draft for years if they want to. G13 is just a cleanup mechanism that comes in if the draft is abandoned, and "hasn't been touched in six months and the editor did not respond to the deletion notice" is a pretty good sign that it is indeed abandoned. And if that turns out to be wrong, it's undeleted just for the asking. We're not a webhost, draft space is for articles that stand a reasonable chance of being acceptable encyclopedia articles one day. Seraphimblade Talk to me 15:46, 27 May 2018 (UTC)
  • Oppose - per all the above arguments --Quek157 (talk) 17:42, 27 May 2018 (UTC)
  • Oppose it's a non-solution to a non-problem --S Philbrick(Talk) 19:03, 27 May 2018 (UTC)
  • Support. It's dangerous to think of most drafts as crap. They are a resource for the community to build upon. Keeping drafts for a year means that other editors will be able to work on them. I have been able to salvage many seemingly abandoned drafts, but I know that many other abandoned drafts with potential have been deleted under G13. WP:REFUND is only useful if you know the name of the deleted draft. Eastmain (talkcontribs) 20:35, 27 May 2018 (UTC)
Nine times out of ten they do because HasteurBot notifies the main contributor(s) of each draft when it's near deletion. —Jeremy v^_^v Bori! 23:44, 28 May 2018 (UTC)
I salvag pages too but often find them becuase of G13. I'll go with my experience that 99% are crap that needs to be deleted, based on my many thousands of pages handled. Legacypac (talk) 22:56, 27 May 2018 (UTC)
  • Support - Expanding draft deletion was and remains a waste of time. As such, I see no problem but only potential benefit in putting off deletion longer. Also per the former half of Uanfala's rationale. — Godsy (TALKCONT) 06:27, 28 May 2018 (UTC)

Counterproposal - make G13 3 months

Quite a few editors have suggested 3 months as a better solution. If others agree this can close as a change to 3 months. This would reduce a lot of problems in MFD, clear out the bad quicker and get eyes on the good faster. Legacypac (talk) 07:32, 27 May 2018 (UTC)

  • support brilliant idea! reduce wasted effort and allow afC to concentrate on building the encyclopedia.Dlohcierekim's sock User talk:Dlohcierekim 07:53, 27 May 2018 (UTC)
  • Oppose per my comments above: this will make a bad situation even worse. – Uanfala (talk) 10:12, 27 May 2018 (UTC)
  • Oppose, unless we can come up with some alternative for specific project-supported drafts. For example, Wikipedia:WikiProject Missing encyclopedic articles/United States state supreme court justices has over 1,500 draft pages, in various states of completion ranging from a few lines to a few paragraphs. These are drafts for missing inherently notable subjects, and it would therefore be absurd to start deleting them. It would be equally absurd to require that all 1,500 be worked on within every three-month period, or to ask reviewers to check through 1,500 drafts every three months. bd2412 T 10:39, 27 May 2018 (UTC)
I'm familiar with those. When found stale a dummy edit or any small edit buys thrm time. Some I just finish and promote. Not a problem at all. Legacypac (talk) 12:31, 27 May 2018 (UTC)
  • Oppose Even I've had a couple of points where I wasn't able to really contribute for a season. I would support a log comparable to Wikipedia:Database reports/Stale drafts for stuff that hasn't been edited in three months, as well as notifying the user "hey, G13 is a thing" after three months just so there's no excuse after we delete it three more months later. Ian.thomson (talk) 13:02, 27 May 2018 (UTC)
  • Oppose - perennial opposition to modifying G13 in any way that does not deprecate it. Ivanvector (Talk/Edits) 13:06, 27 May 2018 (UTC)
  • Oppose - no need to change, and WP:REFUND doesn't make the draft go off and a simple refund process will make it come back and then submitted, no use and will be back somehow. Just strengthening MFD is enough? or simply ignore. --Quek157 (talk) 17:43, 27 May 2018 (UTC)
off topic
You said you were staying out of non-article space. What happened to that? Natureium (talk) 17:48, 27 May 2018 (UTC)
Please don't stalk me please. drafts are as part of AFC work where I am still having some drafts pending approval. I just posted this sometime ago and this is the reply within 5 minutes, this is creepy and worrying. Did you watchlist me? Anyway I commented in the RFC above about MFD changes to add notablity so is perfectly reasonable I am watching this page what. And can you add to the RFC please, appreciate your inputs --Quek157 (talk) 18:37, 27 May 2018 (UTC)
You can't watchlist a person. I have this page watchlisted. I'm not stalking you, you just happen to be posting everywhere so you're not hard to run into. Natureium (talk) 20:51, 27 May 2018 (UTC)
  • Oppose per Uanfala. Jjjjjjdddddd (talk) 22:40, 27 May 2018 (UTC)
  • Oppose. Why? And again, why? There are hundreds or thousands of potentially-good and nearly-there articles in draft space. Leave them be. Concentrate, instead, on the hundreds of thousands of articles in mainspace which fail WP:GNG. Narky Blert (talk) 01:38, 28 May 2018 (UTC)
  • Oppose. Again, we already have a lot of drafts that are falling into G13 because of real-life complications; this would only make things worse on that front and do fuck-all to deter the dedicated promoters. I'd actually argue it would be easier to point users to our policies and note that Draft: space is noindexed, while the whole WP is nofollowed. —Jeremy v^_^v Bori! 01:57, 28 May 2018 (UTC)
  • Oppose. I don't like knee-jerk reactions, and this looks an awful lot like one. Compassionate727 (T·C) 16:36, 28 May 2018 (UTC)
  • OpposeHow exactly will decreasing the time drafts are allowed "get eyes on the good faster"? G13 is already deleting good drafts, how will speeding up the process do anything but ensure more potential good articles get trashed without anyone checking them?Egaoblai (talk) 22:19, 28 May 2018 (UTC)
  • Oppose - none of the arguments to cut to 3 months seem to outweigh the benefits coupled with the limited inconvenience Nosebagbear (talk) 11:25, 29 May 2018 (UTC)

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.

Making widely-used icons consistent and modern

Look into most used files. We have four different information icons in the top thirty images. Most of them are also really old designs with lots of details (which was a thing in mid 2000s but not anymore) and they don't scale down to the size that they are being used. Most used icons are mostly in three categories:

  • Portal icons
  • *-stub template icons
  • *mbox templates

I hereby suggest using more modern set of icons that are more abstract (for example see Template:Astronomy-stub) or more specificity from these five sets: c:OOjs_UI_icons (icons used in the interface of mediawiki), Wikipedia 15 icons, c:Category:Material Design icons (because of the similarity), and c:Category:Emoji One BW (because of the diversity of the inventory). If not, at least putting some style guide for the icons. Ladsgroupoverleg 23:58, 26 May 2018 (UTC)

Yeah, I agree. Another icon-related thing: does anyone want Wikimedia to implement some form of HTML5 Canvas? Lojbanist remove cattle from stage 02:14, 27 May 2018 (UTC)
  • While on the subject, I would really like a new set of icons for Portal:Contents to represent the categories, they all have to be SVG and the same size, so anything in the way of better / more modern CC0 / PD icons would be great. JLJ001 (talk) 14:36, 27 May 2018 (UTC)sockstrike Galobtter (pingó mió) 17:02, 3 June 2018 (UTC)
  • All those icons look rather flat, one toned, and overall meh. —Farix (t | c) 16:30, 27 May 2018 (UTC)
  • Whole-hearted support. Ladsgroup, I think you're a hero for proposing this. A lot of our visual iconography around here is a product of the trends early-2000s that birthed Wikipedia, and it's hugely overdue for a facelift. A flatter look like that represented by those material design icons would go a long way towards updating the look and feel. However, this is the most subjective matter imaginable, so I'm not sure how far this will get. But I'll with you all the way. A Traintalk 23:44, 27 May 2018 (UTC)
  • This is something worth looking into, but of all the possible arguments in favor of changing some of the icons, saying that they're no longer fashionable is really the bottom of the barrel, in my opinion.
    Anyway, let's put together some examples of the icon set. To compare:

Some current icons:

Warning icon Please stop disruptive blah blah blah.


Compared to icons from the proposed sets:

Warning icon Please stop disruptive blah blah blah.

--Yair rand (talk) 03:09, 28 May 2018 (UTC)

The proposed icons are mostly horrible and not inline with the aesthetics of the project. The puzzle piece especially, which loses the Wikipedia logo entirely. I don't mind the new scales however. Do it on a case by case basis, but remember that most of the use of the 'bad' icons (like some assy .jpg version) is due to the substitution of old templates that have long been updated to look better. Headbomb {t · c · p · b}
I agree about the puzzle logo but other ones look way better. Specially having consistency in the look seems great to me. We can use more blue in the icons to give the sense of ink Ladsgroupoverleg 04:41, 28 May 2018 (UTC)
  • I am with Headbomb here. Most the icons look crap on Wikipedia, but there are some improvements that can be made with the icons that do look good, so by all means. JLJ001 (talk) 19:42, 28 May 2018 (UTC)sockstrike Galobtter (pingó mió) 17:02, 3 June 2018 (UTC)
  • Mixed - I would say the same - the new scales look nice, but the others are less so, especially the puzzle piece as noted. Consistency all well and good, but some consideration on whether the older or more modern design is better in each case would be advisable Nosebagbear (talk) 12:24, 29 May 2018 (UTC)
  • Support. It should be noted that the French Wikipedia is attempting something similar. Lojbanist remove cattle from stage 23:26, 29 May 2018 (UTC)
  • Ladsgroup, I genuinely have no opinion on this topic, but do you think it would be better to wait until this discussion is finished before changing all the icons? Primefac (talk) 16:59, 3 June 2018 (UTC) (please ping on reply)
    Primefac The last edit on the discussion was about four days ago and I mostly wanted to be bold and change things gradually (changing everything in one go would be complicated and I don't want to do that.) Ladsgroupoverleg 17:06, 3 June 2018 (UTC)
    Fair enough, guess I wasn't paying that much attention to the timestamps, more the fact that there's about 50/50 for/against so far. Primefac (talk) 17:10, 3 June 2018 (UTC)
    I don't think you should be changing the icons. I don't see a consensus for changing, with many complaining about the OOUI icons being flat/bad, and personally I don't like the new information icon that much; I don't hate it though, and could be convinced on it. Probably need an RfC if you want to change things; and IMO either use the new OOUI information icon or the old one, but mixing seems horrifying. At the very least, all the warning templates should use the same icon. I've reverted the changes since they don't seem to have any consensus. Galobtter (pingó mió) 17:16, 3 June 2018 (UTC)
    There is a design style guide that explains why icons have been designed this way. This is a good read. Let's make subsections to move forward Ladsgroupoverleg 17:25, 3 June 2018 (UTC)
    I've posted a link to this discussion at Template talk:Ambox. I think notices should probably be posted on talk pages of all templates that will have icons changed. --Yair rand (talk) 23:27, 3 June 2018 (UTC)
  • Oppose I *do* think it's time to change the icons somewhat, and the proposed ones do look modern and nice, but I don't think these would be best for the message we're trying to send with these icons. Jjjjjjdddddd (talk) 16:08, 7 June 2018 (UTC)

Changing information icon

This is proposal to replace blue information icons (Information.svg Information icon4.svg) with the OOjs one (OOjs UI icon info big progressive.svg) Ladsgroupoverleg 17:27, 3 June 2018 (UTC)

  • Support as proposer. Ladsgroupoverleg 17:27, 3 June 2018 (UTC)
  • Oppose - this icon is less visible to me. --Khajidha (talk) 00:19, 5 June 2018 (UTC)

Changing alert icon

This is proposal to replace red alert icons (Ambox warning pn.svg Nuvola apps important.svg) with the OOjs one (OOjs UI icon alert destructive.svg) Ladsgroupoverleg 17:30, 3 June 2018 (UTC)

  • Support as proposer. Ladsgroupoverleg 17:30, 3 June 2018 (UTC)
  • Oppose - the black ! stands out better than the red one. --Khajidha (talk) 00:20, 5 June 2018 (UTC)
  • Oppose per Khajidha. Jjjjjjdddddd (talk) 16:05, 7 June 2018 (UTC)

Changing scale icon

This is proposal to replace scale icons (Unbalanced scales.svg) with the emoji one version (Emojione BW 2696.svg) Ladsgroupoverleg 17:33, 3 June 2018 (UTC)

  • Support as proposer. Ladsgroupoverleg 17:33, 3 June 2018 (UTC)
  • Oppose - this icon is used to signal a lack of neutrality, for that the unbalanced scale seems more appropriate. --Khajidha (talk) 00:22, 5 June 2018 (UTC)
  • Oppose an unbalanced scale should be used to show lack of balance or neutrality. Graeme Bartlett (talk) 02:40, 5 June 2018 (UTC)
  • Oppose per above. Jjjjjjdddddd (talk) 16:06, 7 June 2018 (UTC)

Account passwords

Hi! When creating a new account, on the passwords, thinked I to change globally so only the characters A-Z and 0-9 be used and not special characters (such as ?, !, @, + and so) to make it easier to choose a password, and other websites disallow §, +, =, ? and so, because these passwords are harder to guess. Please make so only characters A-Z and 0-9 be used on account passwords --46.227.72.88 (talk) 16:07, 27 May 2018 (UTC)

If you don't want to use special characters, don't, but we're not going to lower security to makes things more easily hackable. Headbomb {t · c · p · b} 16:10, 27 May 2018 (UTC)
Indeed. You should not want your password to be easy to guess; if it is easy for you, it is easy for a hacker. 331dot (talk) 19:08, 27 May 2018 (UTC)

Require special characters for passwords (ok, not really, but...)

Remember a few weeks ago when someone tried to hack into every account on the site? Yeah.

Ok, so I'm already well aware that length is more important than special characters in passwords, but a request to reduce site security just pokes me in a way that makes me want to retaliate in some way (and I'll try to see that it's for the better).

Why don't we require passwords to be at least a minimum of 12 or even 16 characters? It'd be stupid to not require at least 8 characters. There's also lists of most common passwords, why don't we make it so those can't be used as passwords?

Ian.thomson (talk) 21:17, 27 May 2018 (UTC)

Isn't 8 characters already a minimum? On a more serious note, your last point is a great idea. The password page could check the Pwned Passwords API (via Have I Been Pwned?) to ensure users don't choose a previously compromised password. This could even be limited to just the "top million" if you didn't want to be too restrictive. — AfroThundr (tc) 22:01, 27 May 2018 (UTC)
A request is already open to expand the password blacklist, see phab:T151425 to track progress. — xaosflux Talk 22:33, 27 May 2018 (UTC)
Why don't we actually respond affirmatively to the mathematical reality Randall Munroe explained so well, and which Ian.thomson referenced, and require the infinitely more secure "four random common words" password format? (Shorthand: 4RCW). Is there some technical reason why this doesn't work? I can't imagine why it wouldn't, and I know one company that requires 4RCW--YouNeedABudget.com.   - Mark D Worthen PsyD (talk) 07:55, 28 May 2018 (UTC)
It seems that thousands of smart IT folks have read xkcd #936, forwarded the comic to friends and posted it on social media sites, agreed with Randall's conclusion ... and then proceeded to "increase security" for their company or employer by requiring longer passwords that are even harder to remember and still relatively easy for the bad guys to hack.   - Mark D Worthen PsyD (talk) 08:03, 28 May 2018 (UTC)
Shortly after posting the above, I remembered my teenage daughter teaching me the acronym (and website) GIYF. Darn it! I posted without checking the Google first. Looks like there is a reason why the 4RCW method won't help much. At least I was persuaded by this Ph.D.'s article on the topic: Password Security: Why the horse battery staple is not correct. Do you In who know a lot more about this topic than me agree?   - Mark D Worthen PsyD (talk) 08:15, 28 May 2018 (UTC)
Unfortunately, not all software clients can be used with a password manager. For example, I know one game client that prohibits the use of copy&paste in the password field. I'm sure it is not the only one either. —Farix (t | c) 10:28, 28 May 2018 (UTC)
The firefox addon Enable Right Click and Copy may solve your problem. It doesn't work on all pages, but is usually does work. --Guy Macon (talk) 12:29, 28 May 2018 (UTC)
I also found this:[22] (I have not tried it). --Guy Macon (talk) 12:31, 28 May 2018 (UTC)

Guy Macon's robust password advice

I am going to ignore what other websites do, because we can only control what Wikipedia does.

Every time I have looked into the nuts and bolts of how the WMF does security, it has always, without fail, turned out that they do it right, so I am not even going to bother finding out how they stop an attacker from either making millions of guesses per second or being able to lock out an admin by trying to make millions of guesses per second. Clearly the WMF developers read the same research papers that I do.

That being said, as explained at Kerckhoffs's principle#Modern-day twist, while doing things like rate limiting and key stretching are Very Good Things, we are not to rely on them. We are to assume that the attacker knows every byte of information on the WMF servers (and in fact the attacker may actually be someone who has knows every byte of information on the WMF servers -- If a nation-state offered a key WMF employee millions of dollars if he complied and made a credible threat to torture and kill his family if he didn't, there is a 99%+ chance that they would end up knowing every byte of information on the WMF servers.)

The WMF does not store your passphrase anywhere. When you enter it it a cryptographic hash is performed and the result compared with a stored hash. This means that an attacker who knows every byte of information on the WMF servers can perform a high-speed offline passphrase-guessing attack, but cannot simply look up your passphrase and use it to log on. So according to Kerckhoffs's principle, you should choose a passphrase that is easy for a human to remember and hard for a high-speed offline passphrase-guessing program to guess. I will call this "Macon's principle" so that I don't have to type "Make it easy for a human to remember and hard for a high-speed offline passphrase-guessing program to guess" again and again.

Bad ways to follow Macon's principle

  • Passwords instead of passphrases (single words instead of strings of words with spaces between them).
  • Random gibberish.
  • Short passwords or passphrases. 8 is awful, 16 is marginal, 24 is pretty good, 32 is so good that there is no real point going longer.
  • Character substitutions (Example: ch4r4ct3r sub5t|tut10ns)

Good ways to follow Macon's principle

  • Use a standard English (or whatever language you know best) sentence with proper grammar, spelling, and punctuation.
  • Make it longer than 32 characters and have it contain at least three (four is better) longish words plus whatever short words are needed to make it grammatically correct.
  • Make sure that sentence has never been entered anywhere on your hard drive (including deleted files) or on the internet. "My Hovercraft Is Full of Eels" is bad because a dictionary that contains every phase used in Monty Python's Flying Circus would find it.[23]
  • Make it meaningful, easy to remember, and something that generates a strong mental image.
  • Make it meaningful to you, but unguessable by others (don't use your favorite team, first kiss, mother's maiden name, etc.)

An example of a good passphrase that follows Macon's principle would be:

 Geoffrey painted his Subaru pink so that it would blend in with his flamingos.

(This assumes that you actually know someone named Geoffrey and that he owns a non-pink Subaru. Replace with a name/car from among your acquaintances to make it easier to remember.)

That's 78 characters that nobody in the history of the earth has ever put together in that order until I just wrote it. Typos really stand out (Geoffrey paibted his Subaru pink so that it would blend in with the Flamingos.) and are easy to correct. The sun will burn out long before the fastest possible passphrase-guessing program completes 0.01% of its search. And yet it would be far easier to remember than the far easier (for a computer) to guess BgJ#XSzk=?sbF@ZT would be.

BTW, There is no need to do the math for short passwords. Steve Gibson has done it for us. See [ https://www.grc.com/haystack.htm ]. Note that since he wrote that the password-guessing computers have gotten even faster. See see [On the Economics of Offline Password Cracking - Purdue CS].

The GRC calculation is done locally, using Javascript, so you can safely test your passwords - the password doesn't leave your computer. But if you want to be extra safe, try these examples...

  • HZn?m+jW
  • PhBixXL4
  • qza7nm3g
  • pgupwmxn
  • 54606559

...as your 8-character test password.

I generated the above from my atomic decay true random number generator, set to chose from:

  • The 95 ASCII printable characters (0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ `~!@#$%^&*()-_=+[{]}\|;:'",<.>/?)
  • The 62 ASCII a-z/A-Z/0-9 characters (0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ)
  • The 36 ASCII a-z/0-9 characters (0123456789abcdefghijklmnopqrstuvwxyz)
  • The 26 ASCII a-z characters (abcdefghijklmnopqrstuvwxyz)
  • The 10 ASCII 0-9 characters (0123456789)

Not happy with the results for an 8-character hard-to-remember password? Try entering the easy-to-remember password "Geoffrey painted his Subaru pink so that it would blend in with his flamingos." on the GRC calculator. The time to crack goes from 27.57 seconds to 10.05 million trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion centuries.

I have done a similar analyses with the assumption that the attacker uses a password-guessing dictionary instead of a brute fore attack (a competent attacker will run both in parallel) and my conclusion still holds. I can get into the details of how I calculated that if anyone is interested.

Optional modification to the above scheme

Use a password manager to manage very long (and impossible to remember) unique passphrases (and maybe usernames) and use Macon's principle to choose the master passphrase for the password manager. Also, have the password manager enter long random answers to questions like "what is your mother's maiden name"?

This optional modification to the above scheme has a few disadvantages: You are depending on your password manager being secure and bug free. Leaking the passphrases to an attacker is bad. Losing all of your passphrases is worse. Will you be able to recover if your computer is stolen?

My solution to the above is to keep a set of standard text files that look like this...

Filename of text file: Example web site.txt
Website: http://www.example.com
Username: jfhsx4ih2l91m7xawwhoup96svovfp46
Password: F@ZBgJsTzk=?#X@ScPh%b#iBxXL4F%qz
Security Question: What is your favorite sport?
Answer: iJStVIgdfXWZbhEqmidrXFTFgUCwEgAF

...and store them on a thumb drive that is encrypted with Veracrypt. A copy of the thump drive is in my safe deposit box and another copy is stored on a remote backup server in another city. --Guy Macon (talk) 12:18, 28 May 2018 (UTC)

  • We are to assume that the attacker knows every byte of information on the WMF servers (and in fact the attacker may actually be someone who has knows every byte of information on the WMF servers -- If a nation-state offered a key WMF employee millions of dollars if he complied and made a credible threat to torture and kill his family if he didn't, there is a 99%+ chance that they would end up knowing every byte of information on the WMF servers.) If some nation state cared enough about Wikipedia to resort to torture and murder, there is little that any editor could do to prevent it from happening. Frankly, editor passwords would be the least of the security concerns at that point, and there's nothing that such a nation state could do with editor passwords that couldn't be undone or fixed. While what you're saying may be true for those with developer and sys-admin access to the servers, it's completely overkill from an end-user standpoint. Assuming that the WMF sticks to some basic security standards, the only feasible attack venue editors should worry about would be an online attack (since a compromise of the servers that yielded the password database would likely have much juicer targets than editor passwords). An online attack is easily throttled and managed, and if the password database did leak out, it would be trivial to force a password reset for editors with advanced permissions. --Ahecht (TALK
    PAGE
    ) 15:25, 28 May 2018 (UTC)
  • @Guy Macon: Indeed, the security controls should be proportionate to both the risk and the likelihood of compromise. Admins (and security passionate, technically minded users) should definitely follow your advice, but for regular editors, I wouldn't reasonably expect them to keep up with all of this. For myself, I use KeePassXC in a Veracrypt container that gets synced via Keybase, but I had a difficult time getting my mom to convert to a password manager just to remember the half dozen variants she uses on everything. I'm slowly getting her to realize that if KeePaas remembers the password for her, then it can be randomized. Slow steps. Ahecht is correct that the most likely threat vector is an online attack, for which there are many mitigations already in place. — AfroThundr (tc) 15:38, 28 May 2018 (UTC)
The above is a legitimate viewpoint, but I would like to avoid advising anyone to use weaker security. That's a decision each of us have to make for ourselves based upon our circumstances. The main point that I was trying to get across is that ch4r4ct3r sub5t|tut10ns make it hard for humans to remember and easy for computers to guess, while following my advice above makes it easy for humans to remember and hard for computers to guess. If you don't care about security at all (and often you don't; why pick a good password for a %$#*! website that makes you register just to read it?) just use "swordfish" as your password. :) --Guy Macon (talk) 16:16, 28 May 2018 (UTC)

Revise WP:NPOL so that someone who wins primary qualifies for more information in Wikkipedia

In any election, the incumbent has a great advantage over a challenger. Wikipedia's NPOL policy means that incumbent is by default notable but challenger isn't. As a service to our readers, instead of just re-directing from name of challenger (who at least in the US got some coverage running in primary election) to district race URL, could we not give more information about the race as exemplified for example here?[24] I understand reasoning behind our current model. I do not propose that, after general election, we continue to host info on challengers who are not otherwise notable. I do not propose to change notability criteria for any other categories such as NACTOR etc. But I think we can do better for general elections. What do others think? HouseOfChange (talk) 19:35, 27 May 2018 (UTC)

"I do not propose that, after general election, we continue to host info on challengers who are not otherwise notable." That seems to make the proposal a WP:NOTNEWS violation. We don't temporarily host information just to make races more fair; that's simply not Wikipedia's thing. Huon (talk) 19:39, 27 May 2018 (UTC)
(ec)In an article on the race you can say as much as sources and WP:DUE allow about any candidate, and balanced coverage is good. As to biographical articles, you seem to be suggesting a form of temporary notability, which we don't do. Johnbod (talk) 19:42, 27 May 2018 (UTC)
OK so for example, if you search for Texas candidate Lizzie Pannill Fletcher you end up at page for Texas 7th district, which has zero info about challenger Fletcher but a link to incumbent she will challenge. I am suggesting that such a page (for election) has a section for some links or info about positions of both candidates. I agree with Huon that it will be unnecessarily tricky to create a new category of "temporary notability." I am searching for a way to benefit our readers without requiring painful contortions of Wikipedia principles. HouseOfChange (talk) 20:03, 27 May 2018 (UTC)
The best solution in such a situation is to add neutral, well-referenced information about each of the candidates to the redirect target, describing the race neutrally. Articles about unelected candidates tend to start out as campaign brochures masquerading as encyclopedia articles, and then are often loaded up with cherry-picked negative information added by supporters of rival candidates. It is a mess. Cullen328 Let's discuss it 20:08, 27 May 2018 (UTC)
I agree 100% with the lively description of Cullen328 about articles of politicians. Cullen, if you can give an example, on any page you like of what and WHERE such info might go, that would be a great help. Sleepily, from Sweden, HouseOfChange (talk) 20:15, 27 May 2018 (UTC)
In the current case, HouseOfChange, the information can go in the District 7 section of United States House of Representatives elections in Texas, 2018. If you look at sections for other districts, you will see that some have information about various candidates. There could be 36 neutral spinoff articles about the races in all 36 Texas Congressional districts. Cullen328 Let's discuss it 20:28, 27 May 2018 (UTC)
Thanks, Cullen328, I do not propose to write 36 spinoff articles, but I will try to wrie one or 2 and see what reception is for them. HouseOfChange (talk) 21:07, 27 May 2018 (UTC)
  • Comment generally there haven't been stand-alone articles on US House races, but based on the discussion at Wikipedia:Articles for deletion/California's 39th congressional district election, 2018 it seems that it is permitted, at least for races that generate national-level coverage (normally well-correlated with competitive races).
    As far as notability of candidates: I'm not happy with the current system, but don't see a better alternative yet. Notability is not temporary, and proposals that suggest current candidates are notable but will not be notable after the election are exceptionally unlikely to find consensus. Some candidates (Kara Eastman, Mark Walker) have been kept at AfD recently.
    Finally, as a procedural note, this is a fairly good time to have this discussion; there's enough time before any election that there's no obvious benefit for any political group associated with any policy change, but enough activity to give specific examples rather than hypotheticals. power~enwiki (π, ν) 22:35, 27 May 2018 (UTC)
  • Oppose In the case of the U.S. House of Representatives, there are very few competitive seats in any election cycle. Cook estimates that less than 100 of 435 seats are competitive [25] in 2018, for instance. That means that in three-quarters of all U.S. congressional races, the general election challenger candidate will often be either a perennial candidate or someone simply running as a party standard-bearer with no hope or intent of election and no organized campaign. Over the next six years, that means we could potentially accumulate hundreds of biographies of individuals notable for no other reason than they once spent 15 minutes filling out a certificate of candidacy. Further, many general election candidates for congressional office already are usually able to meet notability standards absent this proposal as they will frequently be former state legislators who are inherently notable, or in some other way pass the WP:GNG. Candidates for competitive house seats are rarely unknowns. Chetsford (talk) 04:56, 5 June 2018 (UTC)

Throttle edits adding excessive disambiguation links

In my long experience as a disambiguator, I have observed that the larger the number of disambiguation links added in a single edit, the more problematic that edit is likely to be in other respects as well, such as containing copyvios, overlinking, creating a sea of non-notable red-links, adding walls of text, or indiscriminate data dumps. I think an edit that adds more than, say, links to twenty different disambiguation pages should probably at least bring up a notice advising the editor to review Wikipedia's policies and MOS and consider whether they need to adjust their writing before saving the edit. I will add that, out of the hundreds of thousands of edits made on Wikipedia per day, only a handful have this characteristic. Nevertheless, it would quite often save a lot of work if the editor adding the disambiguation links (and likely other issues) would get a heads up, rather than other editors needing to puzzle them out afterwards. bd2412 T 03:36, 28 May 2018 (UTC)

bd2412, that sounds like an excellent idea. The next step would be to put in a request on phabricator. If that doesn't get results, drop me a line on my talk page and I will create a proposal and push them until I get a yes or no answer. --Guy Macon (talk) 08:30, 30 May 2018 (UTC)
  • This is in the same vein as various semi-perennial proposals for alerting users before they save certain types of edits: ones that introduce unsourced text, spelling mistakes, etc. In fact, there was a proposal in 2016 for similarly alerting editors when their contributed text contains links to dab pages. To rehash in the current context some of the reasons why these have all failed: 1) they introduces additional hoops for good-faith new editors to jump through (not good in the context of declining new editor numbers), 2) the presence of many dablinks by itself is only a minor problem that can easily be fixed afterwards, and 3) the real problem is the presence of copyvios etc, and these might or might not come along with the type of edit that would get picked up: the software will have no way of telling which edits are problematic and which aren't.
    Also, worth remembering that articles with more than 8 dablinks get swiftly tagged by DPL bot, which places them in Category:Pages with excessive dablinks (which currently has three members), where they can be examined by experienced editors. And the user who introduced any number of dablinks will promptly receive a talk-page notification (unless their edit count is below 100 or they have specifically opted out). – Uanfala (talk) 22:26, 30 May 2018 (UTC)
    • The previous proposal was to throttle the addition of any new dab links. This is for edits adding a relatively high number. To add one or two disambiguation links in an edit is easy. To add more than ten takes a special kind of absence of forethought. I would add that very frequently the sort of editors who add masses of text laden with disambiguation links are the sort who have fewer than 100 edits. Suppose for the sake of argument we were to say that we would do this for edits adding 20 new links to disambiguation pages? Or 50? Or 100 (since I have seen that happen on rare occasion)? bd2412 T 11:52, 31 May 2018 (UTC)
      • I have a lot of sympathy this goal, but AIUI throttling can only be done through the edit filter, which means that it has to be computed on every single edit at the time of saving, and that's expensive (slow) for every single edit. I don't think that the rest of the community would love having every single edit slowed down. WhatamIdoing (talk) 19:42, 8 June 2018 (UTC)

RfC: Delete IABot talk page posts?

A previous RfC halted new talk page posts by InternetArchiveBot.

This RfC is to see if there is consensus to delete the posts. It affects about 1 million talk pages. An example post that would be deleted.

There are two options for deletion:

#1 - a bot edits the 1 million pages deleting posts. Archived talk pages will be left alone. Bot operator User:GreenC has volunteered.
#2 - the wording of the post is modified to give users permission to delete posts if they want to. Since talk page posts normally can't be deleted by other users, it would remove that restriction. The wording can easily be changed via the {{sourcecheck}} template, it would not require every page be edited.

Please !vote support or oppose. Clarify choice of method #1 and/or #2 in order of preference.

- Rod57 (talk) 16:02, 29 May 2018 (UTC)

Survey

  • Support as nominator. Prefer #1 but would be happy with #2 - Rod57 (talk) 16:02, 29 May 2018 (UTC)
  • Oppose for now, as the nominator has not explained what benefit (if any) there would be in doing this. Compassionate727 (T·C) 16:14, 29 May 2018 (UTC)
Because the posts clutter talk pages and confuse editors. They won't be archived in most articles, most have no automatic archiving or enough traffic to warrant archiving. If you still oppose why not support choice #2? -- GreenC 18:23, 29 May 2018 (UTC)
  • Oppose making another million edits here. Looks like these mostly all use {{sourcecheck}} - just add some verbiage there. — xaosflux Talk 16:47, 29 May 2018 (UTC)
Choice #2 says this. Are you then in support of #2? -- GreenC 18:17, 29 May 2018 (UTC)
I'm pretty indifferent to option 2, just strongly opposed to option 1. If going for option 2, certainly need to check if there are other uses outside of this use case that could lead to unintended impacts. — xaosflux Talk 19:42, 29 May 2018 (UTC)
  • Option 2 per the {{sourcecheck}} argument. Just change the text. In most cases it'll get archived anyway. — AfroThundr (tc) 17:05, 29 May 2018 (UTC)
Choice #2 says this. Are you then in support of #2? -- GreenC 18:17, 29 May 2018 (UTC)
  • Comment - See choice #2  :-) -- GreenC 18:26, 29 May 2018 (UTC)
  • Oppose everything — literally not a single reason to make a million edits to remove once-useful things. Unless there's a good reason, we need not retroactively remove material. I don't see a need to change the template to encourage folks to delete them, they're not hurting? What's the need here? ~ Amory (utc) 19:45, 29 May 2018 (UTC)
  • Support deletion Option #1 or any deletion plan is fine. This text is spam and information pollution which wastes huge amounts of time by continually distracting users to read this text. It is of no use to anyone. This text never should have been posted and for as long as it persists it is actively spoiling the Wikimedia user experience. At least archive it all; preferably delete it outright. Blue Rasberry (talk) 19:59, 29 May 2018 (UTC)
  • Oppose option #1 as something that could cause more harm than good, especially if a new bot has to be designed to handle this workload. I just don't think it's worth the time and effort just to create more page revisions that don't do anything constructively. I would be okay with rewording, per option #2, but again, I don't see a need to do it retroactively to past posts. Surely, if anyone cared, I'm sure after rewording the post others would interpret that as being safe to remove past posts if they wish, and no one would find a problem with that. Red Phoenix talk 21:44, 29 May 2018 (UTC)
  • Oppose The posts get archived on active talk pages and lend meatiness to article talk pages that otherwise have seen little activity. I've actually used IABot's messages to do some close checking and don't want to see my work deleted, if it still exists where it hasn't been archived. Dhtwiki (talk) 21:55, 29 May 2018 (UTC)
  • Oppose option 1, indifferent on 2 as long as the template isn't used elsewhere. That said, this seems to be a solution in search of a problem - has the fact that the messages exist been raised as a problem before now? ƒirefly ( t · c · who? ) 22:15, 29 May 2018 (UTC)
@Firefly: Yes, below in the discussion, I have raised the existence of the messages as a problem. Blue Rasberry (talk) 22:51, 29 May 2018 (UTC)
@Blueraspberry: You say that the messages 'consume human time', but what evidence is there for this, or for this being a problem? Tone doesn't come across well in text, so please rest assured that I'm genuinely interested in this - do you have any data to back up that such messages eat up reader time (unnecessarily), or are they just scrolled past in a second or two. ƒirefly ( t · c · who? ) 23:01, 29 May 2018 (UTC)
@Firefly: This is spam. Spam consumes small amounts of time and attention from large groups of people giving benefit to almost none. Which of these premises do you dispute? - there are millions of these messages, tens of thousands of people read them, they have a life of years, the talkpages show tens of millions of views, there is a body of research publication which describes how spam / advertising consumes time and spoils an environment, these messages ask for minutes of time from all readers, people prefer to moderate their environment's level of spam, this kind of messaging is unprecedented in Wikimedia projects. Most people scroll past in 2 seconds but even that is unacceptable multiplied times millions. Many people read the messages the first few times and some people actually respond. Blue Rasberry (talk) 13:11, 30 May 2018 (UTC)
  • Oppose all Please do not edit one million pages (or even one hundred pages) without a clear benefit. The watchlist turmoil alone is not worth it. A worse problem is the wasted effort as puzzled editors check what happened on the talk pages they monitor. I would scratch my head if I saw a bot modify another bot's message. Johnuniq (talk) 23:09, 29 May 2018 (UTC)
  • Option 2 requires editing ONE page. Not a million. Can you re-evaluate Option 2? -- GreenC 18:25, 30 May 2018 (UTC)
  • Please make a proposal with precise wording, preferably brief. However, you don't need an RfC to edit a single template. I don't see a need to add a "you have permission to delete this" message. If someone is too inexperienced to know they can delete a bot's message if it's a nuisance they should not be fiddling with talk pages. Johnuniq (talk) 00:52, 31 May 2018 (UTC)
  • @Johnuniq: I agree that permission isn't actually needed on any given single article, but Rod57 initially proposed something roughly reflecting your position on the template's talk page and ended up running this RfC at least in part because I asserted that mass removal of the messages, regardless of whether done by bot or by encouraging human editors to do so, is something that would require community approval (mea culpa). Even (especially?) experienced editors are indoctrinated to never ever mess with others' talk page comments, so I think adding such a message to the (already transcluded) template would have an effect beyond just "stating the obvious". I suspect the "precision" you find missing in the framing of this RfC is due to an attempt at brevity and neutrality from someone who has never constructed an RfC before. I hope that tradeoff won't make necessary restarting it entirely. --Xover (talk) 06:16, 31 May 2018 (UTC)
  • oppose; per above. This has the potential to waste users time by alerting them to the automated change. Also possible is wasted editing hours as people discuss the issue during the fallout. In any case, particularly with regard to the example given above, we would almost certainly appreciate a human user leaving such a TP summary after making a non-minor edit affecting sourcing, why should a bot's contribution be less valid/useful. Agree with discussion points below - that brevity should be considered and would support improved brief messages if they can be shortened. Edaham (talk) 08:25, 30 May 2018 (UTC)
  • Oppose Solution 1 per cost benefit; would
  • Weak Support number 2 per User:GreenC . GenQuest "Talk to Me" 11:46, 30 May 2018 (UTC)
  • Oppose making edits to every talk page with such a message, there's no point in flooding watchlists for that. Don't care if the solution is changing the wording of a transcluded template, as implied might be the case in option 2. Anomie 12:17, 30 May 2018 (UTC)
  • Oppose Option 1, meh for Option 2. Don't see the point in removing the notices systematically, especially many of those were made at a time when IABot wasn't super reliable. I've removed IABot messages before myself, so if you want to add a message to a template IABot used to mentioned this is an option, sure. I don't think it's going to make much of a difference, but I'm not oppose to that. Headbomb {t · c · p · b} 12:34, 30 May 2018 (UTC)
  • Support Option #2 and Would not oppose Option #1. I manually remove these on "my" articles if they happen to annoy me (clutter), and see no reason why others should not feel free to do the same, with or without "permission" from the template message. Changing the message to explicitly allow this (subject to normal local consensus), provided it is backed by community consensus in this RfC, has effectively zero cost and mainly reaffirms the status quo. Mass removing them by bot seems excessive for the problem: they're just a bit of clutter, and we have a ton of that in various other forms. Better to avoid the watchlist noise and potential for wikidrama such mass edits can engender. I would not, however, be opposed if consensus was to bot-remove them: I just don't think it's a big enough deal either way to feel strongly about it. (PS. Kudos to Rod57 for setting up this RfC. It's good to have a community consensus as guidance, either way.) --Xover (talk) 13:11, 30 May 2018 (UTC)
  • Support #2, neutral on #1 I hear the arguments against 1 on the basis of the many edits, although I'm not sure how much of a problem it would be. However, it would be sensible to allow users to remove notices in areas where they constitute clutter. Tamwin (talk) 16:42, 30 May 2018 (UTC)
  • Oppose Option 1 and Support Option 2 which pretty much lets sleeping dogs lie. The posts are spam and were a nuisance when made, but make further nuisance only to those readers who read old posts. Waking this sleeping dog will make a new, similar nuisance to my fellow talk page stalkers. Yes, my opinion is based on a guess that the new nuisance will be bigger than the remaining nuisance value of the old spam posts. No use complaining when other guesses lead to other opinions. Jim.henderson (talk) 18:46, 31 May 2018 (UTC)
  • Support option 2: the messages are useless, but not worth the trouble of performing a million of edits. Option 2 seems like a good choice in addressing the perceived issue. --K.e.coffman (talk) 20:26, 31 May 2018 (UTC)
  • Oppose All - There is no benefit to editing over a million pages just to delete a bot message ..... They can and will be archived eventually, I and others archive talkpages and most talkpages have the archive bot .... if they're not archived then who cares ? ..... The proposal IMHO does not in any way, shape or form help with the goals of Wikipedia. –Davey2010Talk 20:53, 2 June 2018 (UTC)
  • Oppose option 1, indifferent to option 2 I'm just not seeing the problem with letting old Archivebot messages stick around: they aren't causing any harm and they'll eventually go away on their own through talk page archiving. I strongly oppose option 1 since it will require a ton of work for little benefit. Option 2 only requires a single edit, so I have no objection to it. I don't think it will accomplish much, but if the community wants it I won't oppose. Spirit of Eagle (talk) 23:11, 2 June 2018 (UTC)
  • Support option 2, to clarify that one doesn't really need to check the bot's edits nor to edit any talk page template. Those requests were just terrorism imposed by users who didn't believe in the success of the bot. Neutral on option 1: the whole message should have been a template, but the subst-worshippers would have opposed that; the real solution for the future is to avoid adding so much text in talk pages, changing Wikipedia:Substitution if necessary, to make it clear that it's vastly better to insert boilerplate text via templates. --Nemo 07:01, 3 June 2018 (UTC)
  • Oppose option 1 - the benefit doesn't justify the volume of talk spam. No opinion on Option 2; I have WP:OneClickArchiver enabled which can remove them from the talk page already. power~enwiki (π, ν) 23:52, 4 June 2018 (UTC)
  • Oppose both options. This is unnecessary, will clutter watchlists and history, and remove slightly useful posts. Graeme Bartlett (talk) 02:50, 5 June 2018 (UTC)
  • I will add that option 2 will be much worse than the original posting of messages on the talk page, since all the talk pages will be changed, and will waste so much time in people finding out what happened, for no benefit at all. Graeme Bartlett (talk) 22:57, 6 June 2018 (UTC)

Discussion

The persistence of advertising and spam messages consume a huge amount of human time and attention and bring no benefit. The Wikipedia community currently does not anticipate or measure the costs of mass messaging millions of discussion posts to hundreds of thousands of readers. If a message has a life of years, then if great numbers readers spend their time considering great numbers of messages, then this wastes hundreds of hours of Wikimedia community time in an unsatisfying user experience. We have to keep Wikipedia clean of unproductive distractions! See my previous rants on this topic:

No bot should be allowed to consume hundreds of human hours about its automated activities! Remove these messages immediately and avoid ever allowing this again! Blue Rasberry (talk) 21:47, 29 May 2018 (UTC)

No evidence any significant amount of time is spent on these. They were turned off precisely because everyone just ignores them. On active talk pages they'll be archived quickly, on inactive pages they won't get seen. ~ Amory (utc) 00:46, 30 May 2018 (UTC)
I'm in general agreement with Bluerasperry on the principle, but must note that I consider the concern somewhat overblown on this particular instance of the issue. In general we should strive to be mindful of editor attention, including both article and user talk page messages, and "noise" in people's watchlists; but not to the exclusion of useful functionality or information. There is certainly wasted attention caused by these messages, but they are not entirely devoid of compensating value (how much is a subjective call). And excessive effort expended on them, relative to all the other more pressing issues the project faces, is likewise not a good use of the same limited resource (editor attention). --Xover (talk) 13:00, 30 May 2018 (UTC)
@Xover: I really appreciate your acknowledgement that editor attention is a limited resource. I can understand and accept that different people will calculate cost/benefit in time in different ways, but I find it challenging to understand how anyone could say that the cost is zero or immeasurable. Thanks for the reply. Blue Rasberry (talk) 14:08, 31 May 2018 (UTC)
No one said the cost was zero, just that what the exact cost is is at best a guess that depends on a lot of assumptions, which ultimately yields little to no insight on anything. Headbomb {t · c · p · b} 17:11, 31 May 2018 (UTC)
@Bluerasberry: Per Headbomb, I don't think anyone is asserting that the cost of editor attention is zero. But they may disagree that leaving the old messages in place affects (uses) editor attention to any degree worth mentioning, or they may care so much more about the editor attention wasted by noise in watchlists and possibly discussions and wikidrama arising from the removal as to consider the other to be insignificant. Or they just think other factors are more important. An RfC !vote is the distilled result of the conclusion drawn after considering the various factors and assigning them your particular relative merit: it is not an expression of ignorance of, or active dismissal of, other concerns. It's "Here's what I think is important", not "What you think isn't important", if you'll pardon the simplification. --Xover (talk) 05:19, 1 June 2018 (UTC)
I would not criticize others. For myself, I fail to understand the other side, and for myself, I feel a lack of ability to express what I see in a way that makes me feel understood. Thanks for the encouragement. Blue Rasberry (talk) 10:35, 1 June 2018 (UTC)
I'll note that we have a reasonably accurate proxy of the attention gains by the bot's activity, namely clicks on its userpage. --Nemo 07:19, 3 June 2018 (UTC)
  • Can they at least be put under 1 <h2/> tag titled == "External links modified" == and then each time the bot runs it just adds the date as an <h3/> (===6 June 2018===)?  Nixinova  T  C  04:28, 6 June 2018 (UTC)

First designs for page, category, and namespace blocks

Hello all!

The Wikimedia Foundation's Anti-Harassment Tools team is working on building the ability for admins to block a user from a page, category, and/or namespace instead of the full site. With input from your comments, we've created the first round of designs for this feature. This involves some changes to Special:Block and we want to make sure we're thinking through all the details. We'd appreciate for you to review them and share your feedback at this discussion.

Thank you! — Trevor Bolliger, WMF Product Manager (t) 23:21, 30 May 2018 (UTC)

Discussion at Wikipedia talk:Manual of Style/Portals#RfC: Adopt as a MoS guideline

 You are invited to join the discussion at Wikipedia talk:Manual of Style/Portals#RfC: Adopt as a MoS guideline . - Evad37 [talk] 03:00, 31 May 2018 (UTC)

Nutshell templates

I am proposing that the nutshell templates be used in Wikipedia's encyclopedic articles to provide a quick summary about a particular subject. Please let me know what you think of this proposal.
Example: United States

--2601:183:101:58D0:B420:71FD:AA18:2464 (talk) 21:54, 3 June 2018 (UTC)

No. That’s what the lead section is for. Beeblebrox (talk) 22:29, 3 June 2018 (UTC)
The first sentence at United States reads: "The United States of America (USA), commonly known as the United States (U.S.) or America, is a federal republic composed of 50 states, a federal district, five major self-governing territories, and various possessions." We think our readers are capable of reading and comprehending a 33-word sentence; 10-year-olds are not our target audience. What reader benefit does your nutshell add that justifies the added clutter? ―Mandruss  22:31, 3 June 2018 (UTC)

Why do policy and guideline pages use the nutshell template? Why not use the first sentence of the article? --2601:183:101:58D0:B420:71FD:AA18:2464 (talk) 23:03, 3 June 2018 (UTC)

See WP:SHORTDESC. This is a project that does almost exactly what you are looking for. Bradv 23:28, 3 June 2018 (UTC)
Nutshell banners work well when the page is a lengthy set of instructions and the reader needs help to understand what they should do or focus on. For an encyclopedia article, what Brad noted. A database of 5 million short descriptions on any topic is quite useful on its own, can be used on mobile apps, book reading apps, Google search result page, etc.. but when landing on the encyclopedia page itself, it's redundant with the lead section. -- GreenC 14:04, 7 June 2018 (UTC)

A discussion about the Main Page

A discussion about changing the Main Page is being held here. Please weigh in so that a rough consensus may emerge. Thanks122.163.93.250 (talk) 03:26, 4 June 2018 (UTC)

Background: please see this discussion started by Jimbo Wales on his talk page.

I propose that a site-wide banner be displayed through June 20, 2018, on all language Wikipedias including the English Wikipedia, when geolocation indicates that the reader is in an EU jurisdiction, explaining the upcoming June 20 European Parliament vote on the copyright law changes being considered there which could severely impact all Foundation projects, including a link directly to https://saveyourinternet.eu/

Note that the Wikimedia Foundation already has an official position on this issue: https://blog.wikimedia.org/2017/06/06/european-copyright-directive-proposal/ Doctorow (talk) 03:13, 6 June 2018 (UTC)

Background information

Collated information on the effects of the law on Wikipedia

Filtering proposal

(taken from @Doctorow:'s message on Jimmy's talk page)

  • Sites that make material available to the public are required to filter according to rightsholder-supplied lists of copyrighted content
  • Even if they do filter, they are still liable if infringing material is uploaded and made available
  • If you believe that you have been unfairly blocked, your only remedy is to contest the block with the host, who is under no obligation to consider your petition
  • There are no penalties for falsely claiming copyright on material -- I could upload all of Wikipedia to a Wordpress blocklist and no one could quote Wikipedia until Wordpress could be convinced to remove my claims over all that text, and Wikimedia and the individual contributors would have no basis to punish me for my copyfraud
  • There was a counterproposal that is MUCH more reasonable and solves the rightsholders' stated problem: they claim that they are unable to convince platforms to remove infringing material when the copyright rests with the creator, not the publisher (e.g. Tor Books can't get Amazon to remove infringing copies of my books because I'm the rightsholder, not them); under this counterproposal, publishers would have standing to seek removal unless creators specifically objected to it
  • There is a notional exception for Wikipedia that carves out nonprofit, freely available collaborative encyclopedias. This does get WP a lot of latitude, but Article 13 still has grossly adverse effects on WP's downstream users -- anyone who mirrors or quotes WP relies on the safe harbours that Article 13 removes. Think also of all the material on EU hosts that is linked to from Wikipedia References sections -- all of that could disappear through fraud or sloppiness, making the whole project (and the whole internet) more brittle

Position of Wikimedia organisations

Questions?

Please post any questions about the law and how it might affect Wikimedia projects:

  • Do we currently make use of copyrighted material in a way that would be affected by being in violation of this "law"?Slatersteven (talk) 18:26, 7 June 2018 (UTC)
    • @Slatersteven: yes, "it could also require Wikipedia to filter submissions to the encyclopedia and its surrounding projects, like Wikimedia Commons. The drafters of Article 13 have tried to carve Wikipedia out of the rule, but thanks to sloppy drafting, they have failed: the exemption is limited to "noncommercial activity". Every file on Wikipedia is licensed for commercial use." ref.
    • @Slatersteven: No, no direct impacts on Wikimedia projects as the text currently stands in both Council and Parliament. All non-for-profit projects would be excluded, which means all our projects. If our content is used commercially this would happen on another, non-Wikimedia service. That being said, the wording is not final and sloppily written, so no guarantees it will stay this way. But there is a clear political will to exclude all Wikimedia projects. --dimi_z (talk) 20:20, 7 June 2018 (UTC)
Supplementary
I asked how we would be in violation of it, maybe I was not clear. If this rule was in place now what do we do that would mean we would could be prosecuted for being in breach of it (assuming that it does not have an exemption)?Slatersteven (talk) 09:21, 8 June 2018 (UTC)
  • What effect would this law likely have on sources Wikipedia uses for references? E.g academic journals and newspapers. John Cummings (talk) 18:31, 7 June 2018 (UTC)
    • "Under Article 11, each member state will get to create a new copyright in news. If it passes, in order to link to a news website, you will either have to do so in a way that satisfies the limitations and exceptions of all 28 laws, or you will have to get a license."refJohn Cummings (talk) 19:44, 7 June 2018 (UTC)
  • What effect would this law likely have on websites that Wikipedia sources open license media content from? e.g Flickr John Cummings (talk) 18:31, 7 June 2018 (UTC)
    • Flickr would have to filter all uploads. --dimi_z (talk) 20:20, 7 June 2018 (UTC)
  • Does this law effect Wikimedia Commons? John Cummings (talk) 19:13, 7 June 2018 (UTC)
    • Yes, see answer to question 1.
    • No it doesn't affect Commons, as commons is also a non-for-profit service (but compromises not final).--dimi_z (talk) 20:20, 7 June 2018 (UTC)

Discussion

  • Support as proposer. EllenCT (talk) 23:20, 4 June 2018 (UTC)
  • Oppose for similar reasons as not doing anything about net neutrality and not coming off as political. TonyBallioni (talk) 23:24, 4 June 2018 (UTC)
  • Oppose. No using banners to advocate for or against political policies unless there's an existential threat involved. --Yair rand (talk) 23:30, 4 June 2018 (UTC)
    Further, even if this is an existential threat, the correct way to act against it would not be to link to an external site, and certainly not one like that. "The European Commission and the Council want to destroy the Internet as we know it and allow big companies to control what we see and do online." That's not a sentence Wikipedia can be associated with. --Yair rand (talk) 00:23, 5 June 2018 (UTC)
  • Oppose As with the last time someone suggested a political banner, I see no reason that this is appropriate for wikipedia. Natureium (talk) 23:36, 4 June 2018 (UTC)
  • Apparently there is an existential threat, see the post by Doctorow at 19:44, 4 June 2018 here. This proposal should not have been made without clear information. Johnuniq (talk) 23:39, 4 June 2018 (UTC)
The first link in this section includes that description. I agree it certainly does represent an existential threat to the freedom of content re-use, even if the exception for encyclopedias was carved out to prevent direct legal attacks on the existence of the wikipedias. Other projects such as Wikisource would certainly be directly at risk, but they don't reach as many EU citizens as enwiki banners would. EllenCT (talk) 23:47, 4 June 2018 (UTC)
--Guy Macon (talk) 23:43, 4 June 2018 (UTC)
  • Support. According to [26], "France, Italy, Spain and Portugal want to force upload filters on not-for-profit platforms (like Wikipedia) and on platforms that host only small amounts of copyrighted content (like startups). Even if platforms filter, they should still be liable for copyright infringements of their users under civil law, just not under criminal law." There is a time to panic, and unless someone can come through and show that all this is not true, then this is that time. If the EU enacts this, we should immediately and permanently block all access to Wikipedia from the EU, globally lock EU-linked editors on all WMF projects, and disband all EU Wikimedia chapters and liquidate any assets there. For a start. We should do that in two weeks. Or we can do a banner now. Your choice. Wnt (talk) 23:53, 4 June 2018 (UTC)
    European chapters have no legal responsibility whatsoever for Wikimedia sites, IIRC. Does the WMF even need to listen to European copyright laws at all? What we need now is an analysis by WMF Legal on what the ramifications of this would be. Panicking isn't helpful. --Yair rand (talk) 23:57, 4 June 2018 (UTC)
    There is a duty of care. If the above comes to pass, anyone participating in a European chapter would be subject to very extensive legal harassment and it is not reasonable to pass that responsibility on to them. Johnuniq (talk) 00:07, 5 June 2018 (UTC)
  • Comment It's not reasonable to claim that the WMF is not subject to EU law and thus action is not necessary. I'm skeptical about some of the claims made by opponents of this measure, but if they are accurate I would support an EU-wide blackout in response. I'd like to hear whether the WMF or their lawyers have an opinion before !voting. power~enwiki (π, ν) 00:06, 5 June 2018 (UTC)
  • It may not appear reasonable, but it is the case the the WMF servers are in the US, and US opyright law is controlling, not EU copyright law. There may be personal risk for individual editors, but there's no more risk to the WMF's projects than if China changed its copyright laws, or Melanesia. Beyond My Ken (talk) 01:28, 5 June 2018 (UTC)
    • Beyond My Ken: I’m going to take the opportunity to point out that Wikimedians are already individually liable for every action we take on WMF projects, so if the concern here is that individuals will be held more accountable for stealing the intellectual property of others, well, good for the EU in my book. If there is actually an existential threat to the WMF, I’m sure their legal team would be on it. TonyBallioni (talk) 01:46, 5 June 2018 (UTC)
    • US copyright law is (fortunately for us) not all-controlling. Local copyright law is also important. WMF does need to comply. The point is the opposite; individual editors are not affected; WMF is. But it's not complaining. Hawkeye7 (discuss) 02:28, 5 June 2018 (UTC)
  • I think you have it backwards, but I'm not prepared to mount a detailed exegesis. My understanding is as my comment above. Beyond My Ken (talk) 04:25, 5 June 2018 (UTC)
  • Support This has wide-ranging implications for the sources WP relies on, for downstream users of WP, and for WP itself. It's an unworkable and dangerous proposal that it antithetical to WP and any future project founded on similar principles. [Wikimedia has already taken an official position in opposition to this https://blog.wikimedia.org/2017/06/06/european-copyright-directive-proposal/] a year ago when the proposal was first mooted. Now it's on the brink of passing and it's actually gotten worse in the intervening year. Note that I'm a consultant to the Electronic Frontier Foundation which has opposed this since the start, so I'm hardly impartial, but WMF and EFF are on the same side here, and I think Wikipedians should be too. This is a real problem for the whole project and needs to be averted. Doctorow (talk) 00:19, 5 June 2018 (UTC)
  • Comment added to Template:Centralized discussion. Holding off on a !vote per Power. TeraTIX 01:19, 5 June 2018 (UTC)
  • Support absolutely flabbergasted with the mountain of oppose votes solely on the grounds of "political bias". The proposed law has wide-ranging implications, which at worst could mean closing Wikipedia in the EU. It doesn't help that the proposal was made so soon after the net neutrality one was closed. Net neutrality was arguably harmless, but I just can't see how this law could possibly not have substantial negative effects on Wikipedia. We can't afford to gamble on Wikipedia exceptions being added to the final bill. The one political cause we should campaign for is our own. TeraTIX 23:30, 8 June 2018 (UTC)
  •  Question: Is there a Wikipedia article on this topic? Thanks. Mike Peel (talk) 01:28, 5 June 2018 (UTC)
I've created Directive on Copyright in the Digital Single Market. It's fairly difficult to find "neutral" sources here, and I'm not even sure how the EU makes legislation. Hopefully the magic of collaboration will improve it. power~enwiki (π, ν) 06:16, 5 June 2018 (UTC)
  • Oppose per TonyBallioni's concerns about being perceived as politically biased. — BillHPike (talk, contribs) 01:31, 5 June 2018 (UTC)
  • Oppose Unless the WMF is supporting such a banner (Jimbo != WMF) we have generally decided that politically-oriented banners are not appropriate. If the WMF want to enforce one, if they feel the issue is significant enough, they have ways to push that themselves. --Masem (t) 01:49, 5 June 2018 (UTC)
  • Oppose: While I'm sympathetic to the arguments here, I am somewhat weary of requests for politically-oriented banners. If the Foundation wishes to do it themselves, they can (and, by all means, they should, if they feel that strongly about this issue), but the voters of Europe have made their choices, and it's not our place, as a worldwide community of editors, to browbeat, cajole, or even attempt to persuade them otherwise, through the usage of Wikipedia. So, just as I voted on net neutrality (twice), I vote again: please, no more political banners/alerts/whatever on Wikipedia. — Javert2113 (talk; please ping me in your reply on this page) 02:40, 5 June 2018 (UTC)
  • Oppose for many of the reasons stated above. While I can see the harm to the wider internet if this passes, I'm not convinced that this poses an existential threat to Wikipedia which I believe is the only case where such banners are appropriate. Winner 42 Talk to me! 02:55, 5 June 2018 (UTC)
    • @Winner 42: this article outlines the direct threats of the law to Wikipedia, thanks, John Cummings (talk) 19:54, 7 June 2018 (UTC)
      • Wow, that reads like it was written in response to this thread. I did find one factual error though. Doctorow states, "Every file on Wikipedia is licensed for commercial use." A relatively large amount of copyrighted content is already used under fair use doctrine and is not licensed for commercial reuse. That said, this hardly rises to an existential threat. Worst case, some European sources get harder to find. I think Wikipedia could reasonably ignore most of what this is because it is US based and I seriously doubt that Europe has the political capital to block or fine Wikipedia. Winner 42 Talk to me! 17:18, 8 June 2018 (UTC)
  • Oppose any political banners, as always. — Godsy (TALKCONT) 03:44, 5 June 2018 (UTC)
  • Oppose As above and echoing the oppose votes for net neutrality banner further up. We should be careful with political banners. doktorb wordsdeeds 04:38, 5 June 2018 (UTC)
  • Oppose per TonyBallioni and oppose Political banners and this is a political issue and feel there other fora are better for this.Pharaoh of the Wizards (talk) 05:49, 5 June 2018 (UTC)
  • Oppose Though I'm sure the proposal is with good intent, ultimately this is an encyclopedia and not a campaign rally. Chetsford (talk) 07:27, 5 June 2018 (UTC)
  • Oppose and suggest some plan to formally document somewhere that generally politically-themed banners from any country will not be run, to save editors time in discussions like this. It is all evident from recent proposals, that consensus cannot be reached on issues like this. –Ammarpad (talk) 07:35, 5 June 2018 (UTC)
  • Oppose. I don't think we should be in the business of championing political causes, and adding a guideline to that effect sounds like a good idea. If the WMF decided this was a threat to the movement and wanted to campaign against it, that would be a different matter. That is part of their job, after all. – Joe (talk) 10:59, 5 June 2018 (UTC)
  • Oppose. On June 11, net neutrality will be adopted as official U.S. policy, and if internet can survive in America, it can survive in Europe too. wumbolo ^^^ 11:48, 5 June 2018 (UTC)
  • Oppose, at this point we should ask WMF for more information and advice about this situation instead of speculating based on opinion pieces and advocacy sites (such sites may very well be correct, but they do not offer an unbiased perspective on controversial topics). Also, as already pointed out by others: it would be helpful to discuss a more general guideline about prohibiting political (and other) advocacy on English Wikipedia and to clarify the handling of possible exceptional cases (if any). GermanJoe (talk) 12:27, 5 June 2018 (UTC)
  • Comment Not an existential threat as Wikipedia can easily exist without the EU, see also the Turkey block. While bad for editors in the EU (including myself), if this comes to pass we might as well fork the encyclopedia, it seems a saner strategy at this point. I find it interesting btw. how people point at WMF whereas WMFs strategy has been to ask the community. Seems a bit circular. :) —TheDJ (talkcontribs) 14:01, 5 June 2018 (UTC)
    • Sure, for that matter Wikipedia can continue existing even if tomorrow a biological attack kills the entire humanity. It just won't have any user. --Nemo 21:09, 5 June 2018 (UTC)
      • Well it's clear that the community is fine with that, isn't it ? The ideals have eroded to the point where we effectively ARE the Encyclopaedia Brittanica that we replaced. —TheDJ (talkcontribs) 10:19, 6 June 2018 (UTC)
  • Support, we need to be able to address laws that directly affect Wikipedia. (Note that I am not thrilled by the not very informative nature of https://saveyourinternet.eu/ ). We regularly have banners claiming Wikipedia will die if users don't donate -- the potential threat from bad legislation seems worse than two years without donations. —Kusma (t·c) 14:07, 5 June 2018 (UTC)
  • Oppose, the community is here to build an encyclopedia, not for political campaigning. Proposals like this are on their way to WP:PERENNIAL. – Finnusertop (talkcontribs) 18:45, 5 June 2018 (UTC)
  • Support compared to net neutrality, this appears to actually have a direct and major effect on wikipedia in the EU, closer to WP:SOPA. Hope to get a statement from the WMF on how exactly this would affect us though. Galobtter (pingó mió) 21:05, 5 June 2018 (UTC)
  • As Galobtter and Kusma say, this is legislation which directly affects our copyleft and wiki model: not only it directly affects Wikipedia, but of all possible topics in the world it's the one where we can't avoid having an opinion and can't avoid being the most competent to talk (copyleft is the third pillar, folks). On the other hand, it's a bit hard for a community like ours to give a clear and short message among stacks of open letters signed by hundreds of organisations, piles of papers by hundreds of academics, hundreds of competing amendments. Realistically, the true menace will be clear after the JURI vote and the final call to arms will be before the vote in the European Plenary, like last time. After the committee vote, it's certainly too late to have a good law, but it won't be too late to stop a bad one. If we use all our bullets now, we will be harmless when the lobbies come up with yet another trick against Wikipedia. --Nemo 21:30, 5 June 2018 (UTC)
  • Support great idea. Nocturnalnow (talk) 21:45, 5 June 2018 (UTC)
  • Oppose yet ANOTHER PROPOSED WIKI-BANNER CRYING WOLF about the end of civilization as we know it. When can these well-intentioned—but badly conceived proposals—and the accompanying Wiki lawyering, just stop? If the WMF speaks out on the issue, ping me... GenQuest "Talk to Me" 23:17, 5 June 2018 (UTC)
Ping. This is highly relevant for everyone to read.--Jimbo Wales (talk) 14:04, 7 June 2018 (UTC)
  • Oppose per all the oppose comments - Exactly as the opposition to the US net neutrality banner. Also this would mean identifying from cookies/IP adresses the location of our users/readers. Our encyclopedia is international and it must remain apolitical. Kudpung กุดผึ้ง (talk) 07:42, 6 June 2018 (UTC)
@Kudpung: "Also this would mean identifying from cookies/IP adresses the location of our users/readers" eh. we already do that for almost every single banner.. Since at least 2009. —TheDJ (talkcontribs) 10:24, 6 June 2018 (UTC)
TheDJ, I have no idea. I'm an editor not an IT expert. Kudpung กุดผึ้ง (talk) 14:23, 6 June 2018 (UTC)
Apolitical? LOL. I have a list of articles I would like you to make apolitical.... HiLo48 (talk) 08:12, 6 June 2018 (UTC)
HiLo48 then as a Wikipedia editor there are things you can do about it. Hope your list is not too long...Kudpung กุดผึ้ง (talk) 14:23, 6 June 2018 (UTC)
Kudpung Some I can work on. Give me time. Some are owned by unprincipled Admins who would rather see me banned forever. There is no hope there. (For those articles or those Admins, and maybe Wikipedia.) HiLo48 (talk) 21:48, 6 June 2018 (UTC)
  • Oppose Not appropriate to push that POV, even though many of us might agree with it. HiLo48 (talk) 08:14, 6 June 2018 (UTC)
  • Oppose per GenQuest. Wikipedia is not for righting great wrongs, in articles or otherwise. --Joshualouie711talk 15:13, 6 June 2018 (UTC)
  • Oppose We are not a forum, and that must just as much apply to this as anything else. Wikipedia must not and should not engage in advocacy. Once we do that then any claim of neutrality goes out of the window, we play into the hands of those who say we are not neutral.15:17, 6 June 2018 (UTC)Slatersteven (talk)
  • Support. Like the net neutrality proposal, this is not inherently political. Like net neutrality, this also has to do with something that threatens the very premise of WMF's purpose. But unlike net neutrality, this law may prevent EU users from accessing Wikipedia because Wikipedia doesn't pay the appropriate fees to news sources for using short snippets of text, and so forth.
    I initially thought this was about the image copyright law that banned images of certain structures in the EU, but this is much, much worse. Talk about heavy-handed... epicgenius (talk) 15:58, 6 June 2018 (UTC)
  • Support: this law will have very serious consiquences for Wikimedia projects as outlined by the proposer, Julia Reda, WMF, WMDE and others. John Cummings (talk) 15:48, 7 June 2018 (UTC)
  • Oppose – Wikipedia is not a soapbox, whether political or not. But wait, why would we think this is a bad idea anyway? Isn't a robust and effective filter to prevent copyright violations one of the things we've repeatedly asked the Foundation for in the various community wishes consultation exercises? Isn't it exactly what we desperately need and want for this project, instead of relying on a script written by a user and the one dedicated admin who monitors it? Since the vote is imminent, can we take it that the WMF has already dedicated substantial human and financial resources to preparing an effective filter in case it turns out to be needed? Will it be ready in time? Justlettersandnumbers (talk) 17:17, 7 June 2018 (UTC)
  • Support Before it is too late. Yann (talk) 20:42, 7 June 2018 (UTC)
  • Strong oppose - Copied from the recent proposal for a Net Neutrality banner, after reading much of this discussion (I can't say it any clearer than this). I'll note that something does not need to be "partisan" to be political by my understanding and use of the word. First definition at m-w.com: "of or relating to government, a government, or the conduct of government".
    Wikipedia is an encyclopedia, not a platform for political statements supported by a majority of the few editors who happen to show up in a discussion on this page. That's regardless of the merits of the issues or how Wikipedia might be affected by them. We are Wikipedia editors, not political activists (although each of us is free to be a political activist off-wiki). In my view, this proposal should go the way of the proposal to show an anti-Trump statement before the U.S. presidential election. Furthermore, I think we should consider an explicit policy against using the encyclopedia as a platform for political statements. ―Mandruss  21:13, 7 June 2018 (UTC)
  • Support per Guy Macon and Wnt. Jc86035's alternate account (talk) 06:43, 8 June 2018 (UTC)
    • I will abstain from voting. But just to point out that if we do it, we should have our own banner, as we did on de.wp and bg.wp. We are in a particular situation where Wikimedia projects have been carved out from the proposal as the text currently stands. We need to explain why we still worry with a little bit more nuance, at least on the landing page. --dimi_z (talk) 08:22, 8 June 2018 (UTC)
  • Support Wikimedia projects and the Wikimedia commununity get involved in any political issue which is an existential threat to Wikimedia projects. There is a preponderance of evidence that this political issue is an existential threat to Wiki and for that reason it is fine for us to take a political position. It is true that Wiki is "neutral" but neutrality is relative and rational and aligns with an ethical code. Our ethic code includes values like "publishing an encyclopedia" and "making the encyclopedia accessible". I feel that we have met an appropriate standard of evidence in this case, and I agree that WP:reliable sources say that Wikimedia projects are facing an existential threat with this political issue. It is fine for us to advocate, lobby, and demand our right to develop and provide access to the encyclopedia we are sharing. I also feel that it is not necessary to settle any political controversy around this issue. I am willing to acknowledge the legitimacy of critics' concerns about our incomplete information on the law and lack of total certainty that this law is bad. For me, it is enough that we are diligent to cite reliable sources which confirm that some authorities have identified a danger.
I see "oppose" !votes which suggest that Wikipedia should avoid reacting to any country's legislative process as a way of achieving neutrality. I feel that this is misguided, because while Wikipedia is neutral about many topics, we always take a position that every country should allow Wikipedia, access to information, and the educational resources we provide. I will not entertain anyone's arguments that restricting access to Wikipedia should be part of the Wikipedia mission. There is no reason why we should expect that the law of every country is best for Wikipedia. It is fine for us to say that Wikipedia is basically good, and to expect that the laws conform to the existence of Wikipedia. Citizens like us make laws for the public good. People do not exist to conform to laws which fail to consider the public good. It is right to start with the assumption that Wikipedia is good and that good laws will encourage its development. Blue Rasberry (talk) 21:31, 8 June 2018 (UTC)
  • Strong support A lot of the oppose votes seem to come from editors who won't be affected by this legislation, which makes me question if they truly understand the potential consequences. Speaking as someone who will be, from what I understand of it (correct me if I'm wrong), it will make it nigh-on impossible to do anything more than trivial edits. We would no longer be able to upload fair use images, cite web sources, or even quote copyrighted material. How on Earth are we supposed to write decent articles with those restrictions? This could be detrimental to Wikipedia and those in the EU who wish to edit it. The WMF may not be bound by this legislation, but my ISP will be. This is not just a political crusade. Adam9007 (talk) 22:03, 8 June 2018 (UTC)
  • Comment: Then do something about your law makers. Do you understand the current legislative actions affecting internet, copyright law, and legality of use for our users in China? How about Turkey? Spain? Thought so. Wikipedia is here for people to access—or not. They can do so, as best they can from the countries they live in. These are countries where they have –politically– elected the officials who then propose, debate, and enact the laws they deem necessary. We are not here to advocate for or against any such laws, any such country, or any such lawmakers. That's politics. We're here to build an encyclopedia. Period. GenQuest "Talk to Me" 00:13, 9 June 2018 (UTC)
  • Conditional moot. This discussion will probably be closed after 20 June 2018. Steel1943 (talk) 22:38, 8 June 2018 (UTC)
  • Oppose - Just like the net neutrality discussion we had a while back: I'm sympathetic to the ideals, but I'm opposed to Wikipedia being used as a political platform regardless of ideology. Unless of course, the Wikimedia Foundation itself decides to release a statement themselves, but in any case, there are alternative outlets for statements like these to be expressed. Narutolovehinata5 tccsdnew 23:18, 8 June 2018 (UTC)
  • Strong oppose Direct advocacy on a political matter is about the farthest you can get from maintaining neutrality. "Please do not add commentary, your own point of view, or your own personal analysis to Wikipedia articles", to quote {{uw-npov2}}. Go start a blog if you want to publicize your opinions about political matters, whether in your own country or another. Nyttend (talk) 22:58, 8 May 2018 (UTC) This is intentionally copy/pasted from my vote on net neutrality. Nyttend (talk) 02:20, 9 June 2018 (UTC)
  • Strong support. The oppose voters must be missing the fact that a major part of fair use methodology that is absolutely essential for Wikipedia's functioning will be rendered effectively illegal unless Wikipedia tithes to every news source it cites and quotes. If we're not going to protest for the sake of the internet, then do it for the sake of Wikimedia's budget. DaßWölf 02:37, 9 June 2018 (UTC)

WAIT, how is this political?

WAIT. before you oppose on 'not-political' grounds, be aware that this is not something that it politicised in the EU, it is something that has not been reported on in the media, and the public are largely not aware of. This EU proposal is far more dangerous than any of the net neutrality debates, in a direct way to Wikipedia. Net Neutrality doesn't directly affect Wikipedia, but the changes to copyright that article 13 contains may make it impossible for Wikipedia to operate in the EU; the 'link tax' might completely shut down access to Wikipedia in Europe if enforced, and the rules for copyright basically eliminate fair use, making all the European branch language Wikis largely impossible. That is way more of a big deal than a bit of political activism. Please do not bandwagon this one, THINK. I was against the other net neutrality banners, but this is NOT THE SAME THING. I urge you guys to please reconsider, because this is not a partisan political issue in the EU, and that this is actually a potentially huge existential threat to Wikipedia itself. Even Jimbo Wales has said so over on his talk page.Insertcleverphrasehere (or here) 20:39, 5 June 2018 (UTC)

  • It is being done through the political process, thus it is political. The WMF isn't worried about it, so why should we be? TonyBallioni (talk) 21:01, 5 June 2018 (UTC)
Where have you been told that the WMF isn't worried about it? It is not a partisan issue like net neutrality, so Wikipedia wouldn't be 'taking sides'. This is trying to be snuck through the political process with nobody noticing. — Insertcleverphrasehere (or here) 21:09, 5 June 2018 (UTC)
Regardless, if this is a threat to the WMF model, then the WMF should be clearly issuing a statement against it and/or issuing something to say they support a message. (WMF supported the Protests against SOPA and PIPA). If we had this, I would see no problem then including a banner message to warn about this. --Masem (t) 21:16, 5 June 2018 (UTC)
Err, they already did: wmfblog:2017/06/06/european-copyright-directive-proposal/. Judging from the statement, WMF seems rather worried about article 13, which would probably make the WMF subject to some kind of liability. The European users and associations originally cared about other things, necessary for our copyleft wikis: freedom of panorama, public domain, orphan works. But then, maybe that's considered "political" too. --Nemo 21:17, 5 June 2018 (UTC)
  • I detest hidden pings; if you're going to ping me, at least make it so I can see my name. Anyway, I agree with Tony and Masem; if it's an existential threat in the view of the whole of the Foundation, not just Jimbo, something will be done. Moreover, it's not our place to attempt to sway the minds of voters regarding the proposed policies of their lawmakers. (Hint: contact your lawmakers and spread the word about this.) — Javert2113 (talk; please ping me in your reply on this page) 21:22, 5 June 2018 (UTC)
@Javert2113:Sorry about the hidden ping, I pinged everyone that had made a 'political' oppose above, and it was a long list of names. — Insertcleverphrasehere (or here) 21:51, 5 June 2018 (UTC)
It's fine. I'm just a bit grouchy today, to be honest. Thank you for the ping; I probably wouldn't have seen this otherwise. — Javert2113 (talk; please ping me in your reply on this page) 21:52, 5 June 2018 (UTC)
  • Whether or not the WMF is worried about it, or whether or not I'm personally worried about it, I still oppose. While I understand the proposed banner would not be encyclopedic per se, I think the general spirit of WP:NPOV should still apply to publicly-facing content and the proposed banner - linking to a site that says a specific piece of legislation "threatens everything you do" - is not in line with that. That said, I appreciate the spirit in which the banner is proposed. Chetsford (talk) 22:11, 5 June 2018 (UTC)
  • I think your guess is probably a good one. I'd be opposed to any type of persuasive banner regardless of the specific words used or the topic referenced. Chetsford (talk) 22:35, 5 June 2018 (UTC)
  • I think the issue is that it isn't clear exactly what consequences this might have, particularly for Wikipedia. Article 13 is pretty broad in its language, which makes it a bit unclear where it will be enforced and where it won't. When similar laws passed in Spain I know that google news shut down in that country (at least linking to Spanish publishers). A lot of these links are pretty fearmongery, and I am not sure anyone really knows what consequences this might actually have. Everyone seems to agree that it will be bad to some degree however. If a Lawyer from the WMF could give us confirmation on this (can someone ping somebody?) that would be the best. I'm not sure if wmfblog:2017/06/06/european-copyright-directive-proposal/ represents a WMF position on the topic or not... — Insertcleverphrasehere (or here) 22:44, 5 June 2018 (UTC)
  • The worst case scenario, it seems, is that Wikipedia in the EU goes the way Google News did in Spain. That, in the future, Wikipedia will be inaccessible to EU citizens. However, I oppose the persuasive banner regardless of the consequences. If the citizens of the EU, acting through their MEPs, decide WP is not welcome in the EU we should respect their decision, not chain ourselves in the guest bedroom and demand to stay. Again, though, I do appreciate the spirit in which the banner is proposed and agree it would be unfortunate if the worst came to pass. Chetsford (talk) 22:52, 5 June 2018 (UTC)
  • Meh, the WMF is not worried about it. They are insulated by being (as an entity) based in the US, the material based in the US etc. This will not impact Wikipedia or any of the major encyclopedias in any significant manner. It will be an issue for editors in the EU but as to how much - that remains to be seen. What it is highly likely to totally fuck right up is Wikia - a site that routinely (and is in fact built around) violates copyright. And since Wikia is a for-profit cash-generating machine of a certain someone, who happens to live in the EU and so is subject to EU law, its not surprising they are 'concerned' about legislation that will directly impact that. Only in death does duty end (talk) 10:10, 6 June 2018 (UTC)
  • Oppose We are not a forum, and that must just as much apply to this as anything else. Wikipedia must not and should not engage in advocacy. Once we do that then any claim of neutrality goes out of the window.Slatersteven (talk) 14:58, 6 June 2018 (UTC)
    • Too late. clpo13(talk) 17:06, 6 June 2018 (UTC)
      • The whole point of the project and the foundation is advocacy for free and open knowledge, for everyone to contribute, share and make money off. A highly radical concept in 2001 and still in most parts of the world. —TheDJ (talkcontribs) 19:33, 6 June 2018 (UTC)
        • Completely wrong. Not right at all. 100% wrong and 0% right. The point of the project is to provide that free and open knowledge. Not to advocate for it, or for anything else whatsoever. --Trovatore (talk) 19:36, 6 June 2018 (UTC)
  • Support although I doubt a proprosal on en-wiki can affect all other language wikis, so probably just here. I'm quite flabbergasted whenever I hear the "we shouldn't be doing advocacy"-line. Obviously we shouldn't be advertising for political parties or recommending the next big dietary supplement, but there's absolutely nothing wrong with telling our readers whenever a proposed policy would severely **** with our editing model. I wonder if one would get the same reaction if the proposal was more obviously authoritarian. It's also incorrect that the WMF hasn't said anything about this as explained above, and various elements of the WMF-affiliate ecosystem has been working against this, such as the WM EU-group (full disclosure, WMDK, which I'm a part of, has done so as well). Despite the carveouts for online encyclopedias in the proposal, it would still impact some of our other projects, as well as the general free-knowledge infrastructure, such as forced remuneration. Sincerely, InsaneHacker (💬) 16:28, 7 June 2018 (UTC)
I absolutely agree. This is not just a vague human rights thing, this is something that may well have direct financial consequences for WMF. On that bases I'd go as far as to support WMF overriding whatever consensus happens here to make the blackout happen. DaßWölf 02:49, 9 June 2018 (UTC)
  • Support I agree with Kusma, including caveat that the saveyourinternet link is not ideal. Mike Linksvayer (talk) 17:22, 7 June 2018 (UTC)

Julia Reda AMA

For those few interested, tomorrow Julia Reda (one of the few defenders of the Internet within the EU politics), is doing an AMA tomorrow at 12:00 CEST on reddit https://www.reddit.com/r/europe/TheDJ (talkcontribs) 14:03, 5 June 2018 (UTC)

Looks like it has started: https://www.reddit.com/r/europe/comments/8oywxz/i_am_mep_julia_reda_fighting_to_saveyourinternet/ --Nemo 11:29, 6 June 2018 (UTC)

Article outlining the threats of the law to Wikimedia projects

Cory @Doctorow: has written an article for Electronic Frontier Foundation that outline the threats posed by the law to Wikimedia projects and what can be done to oppose it:

Insertcleverphrasehere (or here) 21:31, 7 June 2018 (UTC)

Wikipedia article on the subject

Directive_on_Copyright_in_the_Digital_Single_Market has been started, it is currently not very comprehensive, please help expand it. John Cummings (talk) 21:20, 8 June 2018 (UTC)

According to the (fairly critical) de:Leistungsschutzrecht für Presseverleger Germany has already such legislation, maybe that is something worth inspecting? Jo-Jo Eumerus (talk, contributions) 21:34, 8 June 2018 (UTC)

How to/should we add a Wikidata item link to Authority control

Currently, there is no link from the {{Authority control}} navbar template to the Wikidata item page, where the information displayed is gathered. The Wikidata item page is where an editor may add/remove/correct authority information on a person/entity. A common complaint against {{Authority control}} is that the template (and thus Wikidata) contains information on the wrong subject, or that the links are useless, or the associated link is broken, or frustration from how/where to correct it (there are other complaints as well, but they are outside the scope of this discussion). This proposal/survey seeks to allow editors to more easily access the Wikidata item linked to the Wikipedia page to make such additions/removals/corrections. While gaining some support, it has been suggested at Template talk:Authority control#Adding Wikidata item link to aid navigation to poll a larger audience, so voilà.

A 'Wikidata item' link exists on the left hand margin of any Wikipedia page which currently has a Wikidata item associated with it, similar to commons, wikiquote, wikisource, wikispecies, etc. Also similar is our placement of a 2nd link to commons, wikiquote, wikisource, wikispecies, etc. at the bottom of the page in the external links, to aid navigation and visibility. So the addition of a 2nd link to Wikidata would be in line with current behavior.

This will not affect dormant transclusions of {{Authority control}}; i.e. those which do not display on the page.


Option 1 - RHS in-line 'Wd: Q2144892' links as the first item:

Pros: it's short, so the chances of adding an extra vertical increment to the height of the {{Authority control}} template is also small. After scanning 400k transclusions, 50% of {{Authority control}} templates display 3 or fewer links from Wikidata, and 90% display 8 or fewer, so those 50% would very likely retain their current height (I'll update these numbers again at 690k). Also, parameter suppression of some kind will probably happen in the next 1-few months, making even more templates 1-liners.
Cons: it's lumped together with the other authorities so it (Wikidata) might run the risk of being misidentified as an authority (which it isn't), but I've only seen this concern raised once (part of the reason I'm here). This hasn't been a problem with a sister template, {{Taxonbar}}, which has about ~50% of the transclusions of {{Authority control}}.


Option 2 - LHS 'Q2144892' link on a separate line:

Pros: less chance of being misidentified as an authority, and more obvious linkage to the corresponding Wikidata item than Option 1.
Cons: will force all {{Authority control}} templates that are 1 line tall (~50%) to be 2 lines tall.


Option 2Wd - LHS 'Wd: Q2144892' links on a separate line:

Pros: lowest chance of being misidentified as an authority, and more obvious linkage to the corresponding Wikidata item than Option 1 and Option 2.
Cons: same as Option 2, and slightly wider.


Option 2Q - LHS 'Q2144892' links on a separate line (stylistic variant of Option 2Wd; Q and 2144892 link to different pages):

Pros: same as Option 2, plus the additional link describing what Wikidata is, and is "cleaner looking" than Option 2Wd.
Cons: same as Option 2.


Option 2Wikidata - LHS 'Wikidata' link & RHS links display ID names instead of numbers:

Pros: same as Option 2, but much more reader friendly, and LHS is constant width regardless of Q# size, and the RHS (with this example) is slightly shorter than any Option 2.
Cons: same as Option 2.


Option 2pencil - LHS ' Edit this at Wikidata' link:

Pros: same as Option 1, and widespread use elsewhere, so intuitive.
Cons: less descriptive than Option 2Wikidata, and hard to see for users who invert browser colors.


Option 2edit - LHS '[edit on Wikidata]' link:

Pros: same as Option 2 and Option 2Wikidata, and widespread use elsewhere, and maximally intuitive.
Cons: possibly too enticing?


Option 3 - any of the above.

Pros: various.
Cons: various.


Option 4 - no change.

Pros: status quo.
Cons: less mobility to Wikidata, and thus less potential for editors to add/remove/correct information.

AC Wikidata item link survey

  • Option 2edit, 2Wikidata, 2pencil, 2Wd/2Q, 2, 1, in that order, as nom.   ~ Tom.Reding (talkdgaf)  23:18, 5 June 2018 (UTC)
  • Option 2Wikidata, if not, 2Wd, failing that, 2. I feel 2Wd is the best here, or failing that option 2. 2Q is bad and confusing. Option 1 is baaaaad. Personally, I'd just add the full Wikidata:Q2144892. The objectings (below) to this are silly, since it makes editing what is presented harder if there are errors, and presents Wikidata as authoritative.Headbomb {t · c · p · b} 23:52, 5 June 2018 (UTC)
  • Options 2edit/2pencil, 2Wikidata, 2Wd, and 2, in order. We shouldn't add it to the authority field, so option 1 is a no-go, and 2Q is confusing for the user. Option 2Wd gives the best indication of what the Q link is for, although just calling it "wikidata" would suffice. Option 2edit is probably the most clear, but the pencil reduces the template back to one line, which is nice. — AfroThundr (u · t · c) 00:47, 6 June 2018 (UTC)
  • Options 2 or 2Wd in that order. Oppose 1 as very bad. Oppose 2Q as too difficult for mobile users to navigate. I also oppose 2pencil and 2edit. IMO we should not be including calls to action such as "edit this" or "edit that" since it seems to encourage the least competent drive-by readers to start editing things and, while WMF projects do not demand much in the way of competence, Wikidata is not a good jumping off point. Chetsford (talk) 02:40, 6 June 2018 (UTC)
By that reasoning, the "V · T · E" in every navbox template should also be removed. There haven't been significant issues of navboxes getting messed up because of the edit links being displayed. We need to give readers some indicator of where the data is drawn from and how to make corrections or additions. — AfroThundr (u · t · c) 20:24, 8 June 2018 (UTC)
"V · T · E" isn't an overt call to action since none of those abbreviations will necessarily be obvious to the drive-by reader. "Edit" or "Edit here" or "Edit this" are all calls to action; it's an announcement to the reader that we want them to edit it. I don't really want every rando reader to start editing a Wikidata entry. "This Can Be Edited" would be a descriptive indicator that was not a call to action but space considerations would obviously preclude that. Chetsford (talk) 23:19, 8 June 2018 (UTC)
  • Option 4. There is no need for a WikiData link, especially since we now transclude most from WD (at least up to 22 per subject are transcluded, up to 43 possible). WD is NOT an authority, and anyway it is already linked from the toolbox. There is no ‘one size fits all’, on many articles, both the in-AC link ánd the link in the toolbox will be visible at the same time on one physical computer landscape oriented screen. No objection agains a ‘sisterlink’ like template at long articles (but no standard inclusions there either, it does need merit). —Dirk Beetstra T C 04:05, 6 June 2018 (UTC)
    • As it is relevant here, today I did this. The link to Commons is in the toolbox, anddisplaying it so prominently in this case suggests that there is more to get on Commons. However, commons in this case has just three other cropped immages of the same as in the article - nothing to ADD. For much of WD (we are set to transclude 43, we sometimes display up to 22), the WD link has NOTHING TO ADDin terms of authority control (and there are enough requests to have more parameters to be added ...). The inclusion at the bottom should be a choice, not a standard for the 10s of thousands of articles that have an AC. If WD really has more to offer, include a sister link. —Dirk Beetstra T C 00:12, 7 June 2018 (UTC)
    • On a short page like David H. Sanford the link in the lefthand box ánd on the AC would be almost next to each other, hence there is no easier access. —Dirk Beetstra T C 10:21, 8 June 2018 (UTC)
  • Option 4. The reason given as a "con" is actually a "pro". We don't have the WD link in other templates that are filled way too often from Wikidata (official website, commons cat, ...). AC is already a poorly designed reader-unfriendly template, and efforts are under way to drastically change it. Adding yet another link and another undecipherable code after a meaningless abbreviation is not the way to go. If not option 4, then whatever, but definitely not option 1. We shouldn't put IDs from unreliable wikis into our "authority control" templates (not just Wikidata, but also musicbrainz and so on). If any option 2 is chosen, then don't add the Q-number, just add "Wikidata", so readers have a better chance of knowing what the link means (something that should be done for all the others as well, give the short "name" of the site instead of the meaningless ID, so people know that they are looking at a link to a Czechian, Swedish, US, ... repository). Fram (talk) 06:56, 6 June 2018 (UTC)
    • I've added the 2 - names to give an idea of what I mean. Fram (talk) 07:07, 6 June 2018 (UTC)
      • I've renamed Option 2Names to Option 2Wikidata following convention & updated subsequent references to it.   ~ Tom.Reding (talkdgaf)  11:23, 6 June 2018 (UTC)
  • Option 4 per Beetstra and Fram. To be honest, I'd be quite happy if Wikidata folded but since that is unlikely to happen any time soon, the less connection there is, the better. - Sitush (talk) 07:12, 6 June 2018 (UTC)
  • Option 3 Adding the Wikidata link/ID is useful. Option 1 has the benefit of (almost) matching what is used in this template on other wikis (e.g., commons). I quite like the last Option 2Wikidata with the full display of the names rather than the acronyms and numbers. But any of the options would work aside from option 4. Thanks. Mike Peel (talk) 09:51, 6 June 2018 (UTC)
  • "No link to Wikidata" is painful. I think we've generally established that a template pulling from Wikidata should provide in the context of the template a way to edit the content at Wikidata (this is how Module:Wikidata functions broadly). OTOH, I don't think any of the options above provides the call to action in the way that Module:Wikidata does presently (the little pencil icon). I would prefer to see that here rather than the Wikidata ID or even the nomenclature for Wikidata.

    Regarding the specific proposals: Some Pencil Icon Version > 2Wikidata > 2. I'm partial to 2Wikidata for a non-Wikidata-specific related improvement. That said, I believe the intent is for the template to provide the links internally so that people who are curious about any particular identifier can understand (with some level of encyclopedicity) what it is they would end up looking at without taking up oodles of space with the template where it is provided (by use of the abbreviations). I'm not sure if those links are so valuable in fact or not, and I might suggest the general link to authority control/help:authority control suffices for "hey, what is this template doing? what are these links here for?" rather than specific links to each of the authority controls. That leaves me somewhere in the realm of option 2 as a last resort. Flat rejects: 2Wd for previous comments, 2Q per sea of blue rationale, 4 per first paragraph, 1 per con listed, and 3 because I have a specific preference. --Izno (talk) 13:14, 6 June 2018 (UTC)

  • Option 2pencil (per Izno) or Option 2edit . This has become the standard way of indicating "edit this on Wikidata". All of the presented options betray into thinking that Wikidata is one of the authority control files. It's not (is it?). The problem this proposal wants to fix is not that readers want to use Wikidata as an authority control; it's that editors can't find how to edit the actual authority files stored on Wikidata. – Finnusertop (talkcontribs) 16:23, 6 June 2018 (UTC)
    • Could you provide some examples of this standard? Also, is your second choice then Option 4 - no change?   ~ Tom.Reding (talkdgaf)  16:29, 6 June 2018 (UTC)
I think you're the first person to enter this conversation that was aware (or at least vocal) about such standards!
I guess Option 2edit needs to be made for "[edit on Wikidata]"?   ~ Tom.Reding (talkdgaf)  18:04, 6 June 2018 (UTC)
  • Anything but 2Q Option 2pencil I disagree with the arguments for Option 4 that another wikidata link would be redundant, as it's not obivious in any way that the wikidata link in the sidebar had any connection to the data presented in the authority control template. The only option I am really opposed to us 2Q. It seems like an WP:EASTEREGG, is likely to be confusing when editors don't realize why they're not always being sent to the page they expected, and the single-character "Q" link is a small target to hit. --Ahecht (TALK
    PAGE
    ) 16:46, 6 June 2018 (UTC)
  • Option 4 Per Sitush. Only in death does duty end (talk) 12:04, 7 June 2018 (UTC)
  • Option 4 - we already have a wikidata link in the toolbox. I agree with Sitush here. Ealdgyth - Talk 13:05, 7 June 2018 (UTC)
    • Then we should eliminate {{commons}}, {{wikiquote}}, {{wikisource}}, {{wikispecies}}, etc. too.   ~ Tom.Reding (talkdgaf)  13:42, 7 June 2018 (UTC)
    • The links to commons, wikiquote, wikisource, wikispecies etc are NOT STANDARD in the toolbox, as opposed to WikiData. As I said above, I did this. That template did, on that page, not ADD anything (not even in the toolbox). On most pages where AC is transcluded it does not necessarily add anything (especially since we have up to 22 identifiers transcluded, what is it supposed to do, even more identifiers to be found?). And I would not necessarily oppose careful use of a sister link to WD where it adds something. A blanket transclusion with AC is distinctly different from having a chosen sisterlink. —Dirk Beetstra T C 15:15, 7 June 2018 (UTC)
      • If the only concern against adding a WD link to AC is the presence of the same link elsewhere on the page, then it's an irrelevant concern due to the ubiquitous existence of the above templates, as described in the opening paragraphs of this proposal. Please read them.   ~ Tom.Reding (talkdgaf)  15:26, 7 June 2018 (UTC)
      • I'd also argue that "I don't like Wikidata, and/or I want it to go away, and/or I don't want to do anything to improve it nor Wikipedia" is antithetical to all involved Wikis, and also not a valid point, unless there are plans to dismantle the project.   ~ Tom.Reding (talkdgaf)  15:34, 7 June 2018 (UTC)
  • Option 4: per Beetstra and Fram; but Sitush raises the best argument. I've never seen the use of Wikidata, to be frank. But that's a conversation for elsewhere. — Javert2113 (talk; please ping me in your reply on this page) 15:50, 7 June 2018 (UTC)
    • I've never seen the use of Wikidata, to be frank. This is precisely what this proposal seeks to improve.   ~ Tom.Reding (talkdgaf)  16:10, 7 June 2018 (UTC)
      • Unless you meant figuratively seen, which I now suspect was the case, then yes, a conversation for elsewhere.   ~ Tom.Reding (talkdgaf)  16:14, 7 June 2018 (UTC)

AC Wikidata item link discussion

Please keep the discussion focused on the merits of the available options.   ~ Tom.Reding (talkdgaf)  23:18, 5 June 2018 (UTC)

I added some text to clarify 2Q. Johnuniq (talk) 23:34, 5 June 2018 (UTC)

Can we please promote this to an RfC, that attracts more editors and will get independent closure with a bit mere authority? —Dirk Beetstra T C 04:09, 6 June 2018 (UTC)

Why are the options confusingly numbered 1, 2, 2Wd, 2Q, 2, 3, 4? Could we change to having them as 1, 2a, 2b, 2c, 2d, 3, 4 - or something else that's more straightforward? In particular, we shouldn't have two that are just "option 2"! Mike Peel (talk) 09:53, 6 June 2018 (UTC)

I renamed the second option 2, that was my mistake. Fram (talk) 10:03, 6 June 2018 (UTC)

Pinging Headbomb & Chetsford, just to inform you that Option 2pencil and/or Option 2edit were created after your vote (and since you didn't vote Option 3 nor Option 4), in case you wish to amend. The available options appear stable now...   ~ Tom.Reding (talkdgaf)  11:32, 8 June 2018 (UTC)

Misleading opening statement

@Tom.Reding: you state: A 'Wikidata item' link exists on the left hand margin of any Wikipedia page which currently has a Wikidata item associated with it, similar to commons, wikiquote, wikisource, wikispecies, etc. Also similar is our placement of a 2nd link to commons, wikiquote, wikisource, wikispecies, etc. at the bottom of the page in the external links, to aid navigation and visibility. So the addition of a 2nd link to Wikidata would be in line with current behavior.

There s NO STANDARD LINK to commons, wikiquote, wikisource, wikispecies, etc. There IS a standard link to WikiData on all pages with an associated WikiData item. But as a list of non-exhaustive examples:

All have A WIKIDATA LINK in the toolbox, and NO LINK to commons, wikispecies, wiktionary, wikitravel etc.

At the time of my removal here, the article Giovanna Fletcher had a commons link at the bottom (IMHO useless as it did not provide significant material), and NO link to commons in the toolbox at the left.

Adding this link leads, by definition, to duplication, as opposed to other ‘sisterlinks’. —Dirk Beetstra T C 05:50, 8 June 2018 (UTC)

And anyway, also for those sisterlinks - since they can now be linked from the toolbox, barring exceptions those templates are, in my opinion, then excessive and should be removed, but that is not for here. —Dirk Beetstra T C 05:58, 8 June 2018 (UTC)

Just so we clearly understand the argument: we had sisterlinks in the document (e.g. through {{commons cat}}). Through WikiData coding that now sometimes results in duplication on the page as a second link to e.g. commons appears in the left hand box. Now, because we duplicate commons at the bottom in the article ánd in the top-left box, it is argued here that the duplication of the existing WD link in the left hand top box is fine. —Dirk Beetstra T C 07:34, 8 June 2018 (UTC)

@Beetstra: A link is shown in the sidebar to commons, wikispecies, etc. in the left-hand side-bar where it is available (defined as an interwiki link in the Wikidata entry, or as a manual interwiki). There is a large overlap between those links being shown and the sister project templates also being included (far from 100%, since there are many cases where those templates have not been added even if the link does exist, and there are templates that provide a link where it's not an interwiki on Wikidata). Of course, if a link doesn't exist, then it can't be shown, which is the case in the examples you have given here. Meanwhile, nearly every Wikipedia entry has a corresponding Wikidata entry, so you see that link in the sidebar far more often. So there is nothing wrong or misleading with the opening statement here. Mike Peel (talk) 11:09, 8 June 2018 (UTC)
P.S. a commons link now appears for the first item in your list as I just created it. Up to you if you want to add the photo that's on commons into the article. Mike Peel (talk) 11:19, 8 June 2018 (UTC)
Be careful, the photo is clearly of a different person than the subject of the article.--Ymblanter (talk) 14:25, 8 June 2018 (UTC)
If a commons cat exists for the page, a link will appear in the margin. If a Wikispecies entry exists for the page, a link will appear in the margin. If a Wikidata item exists for the page, a link will appear in the margin. Lo, if a <another wiki> entry exists for the page, a link will appear in the margin. If there's Wikidata item associated with the Wikipedia page (and no forced params in {{Authority control}}), then both the template and the link in the margin are 'dormant'. You've done an excellent job at finding variation on this theme, but not to prove the point you think you're making. The example pages above have Wikidata entries associated with them, but none of the other Wikis. Clearly you've misunderstood the system and need to reevaluate.   ~ Tom.Reding (talkdgaf)  11:12, 8 June 2018 (UTC)
No, I did not misunderstand. Your argument is still that duplication is fine because we do that elsewhere. I disagree, I would even oppose the other duplication - especially in cases where the corresponding commons cat does not add anything extra over what is already in the article, or just has limited content. —Dirk Beetstra T C 11:35, 8 June 2018 (UTC)
I would say we should get rid of {{commonscat}}, especially since it pulls data out of Wikidata anyway.--Ymblanter (talk) 14:30, 8 June 2018 (UTC)
@Ymblanter: I was indeed considering that we could get rid of all sisterlinks-type cats, as they are all in the tools. It is just duplication. —Dirk Beetstra T C 14:46, 8 June 2018 (UTC)
I personally would be fine with that, but I know some people feel very strongly about the sister links.--Ymblanter (talk) 15:01, 8 June 2018 (UTC)
I can see arguments for some cases to be there, but not general. There are indeed strong feelings there, would likely need an RfC. —Dirk Beetstra T C 15:11, 8 June 2018 (UTC)

Proposal to change "on the article's talk page" for deleted articles

If one goes to Wikipedia: Articles for deletion, one can often see notices after a discussion has closed saying "The following is preserved as an archive of the debate. Please do not modify it". This notice then says that subsequent comments can be added to a deletion review or to the article's talk page. However, making comments on an article's talk page is difficult if the article has been deleted here. My proposal is that we change the wording if an article has been deleted. Vorbee (talk) 19:12, 6 June 2018 (UTC)

Conversely, the talk page is the single best place for subsequent comments if the article hasn't been deleted.
(I'm going to preemptively oppose any suggestion that Template:Afd top and Template:Afd bottom change to require additional parameters, either the article's name or whether it's been deleted. People do still close discussions with just the edit button.) —Cryptic 19:50, 6 June 2018 (UTC)
  • If the article has been deleted, then the appropriate venue to go is Deletion review not talkpage and this has already been linked. Nothing requires change here. –Ammarpad (talk) 12:34, 7 June 2018 (UTC)
  • Yes, we can go to Deletion review but that still means that the phrase "on the article's talk page" remains for deleted articles. All I am really proposing is that we remove this phrase if an article has been deleted, as it might confuse new users of Wikipedia. Vorbee (talk) 15:16, 7 June 2018 (UTC)

RFC for an Altered Main Page Design

Following on from the discussion on the issue linked to above (point 16), a full RFC has been launched on the proposed style which is accessible here.

Please give your opinions on the new design. Nosebagbear (talk) 19:22, 6 June 2018 (UTC)

Minor visual update to access locks

Following a an old RFC, the current access lock scheme for CS1|2 template is

  • (current) Freely accessible / Free registration required / Paid subscription required

The first icon is meant to convey open access, the second one is meant to convey limited access, the third one is meant to convey closed access. This scheme has as a few problems.

First, the red lock is not very recognizable as a lock. To fix this, I propose a more recognizable red lock

  • (new1) Freely accessible / Free registration required / Paid subscription required

However, an additional problem is that Green/Blue/Red makes does not convey progression, and was picked over a more logical Green/Yellow/Red by a non-statistically significant 1 vote, mostly because the yellow didn't look very yellow. It also tends to get lost in the see of blue, e.g. (JSTOR 01234 Free registration required)

  • (old1) Freely accessible / Free registration required / Paid subscription required

To fix this, I propose a better intermediate level lock: grey

  • (new2) Freely accessible / Free registration required / Paid subscription required

Some people also didn't like the red, feeling it was too aggressive, so we could stick to green and grey:

  • (new3) Freely accessible / Free registration required / Paid subscription required

The "new2" scheme only has advantages compared to the current scheme: It has more recognizable icons, better accessibility, and better conveys levels of access. "new3" loses easier distinctions between limited and closed access, but is also less aggressive.

Which of the proposed schemes should we use?

  • new2 > old1 > new3 > new 1 > current. Headbomb {t · c · p · b} 02:45, 7 June 2018 (UTC)
  • new2, failing that new1, failing that current. Both of these have sufficient distinction in color and shape, with grey as a more intuitive color progression than blue thus my preference for new2. Current is not particularly intuitive but the different symbols are nonetheless quite distinct and thus recognizable enough once their meaning is learnt. Not a fan of new3: these symbols are displayed at a small size and the two different grey symbols are sufficiently "similar-ish" (very similar shape, fairly similar ratio of grey-vs-white even if the *pattern* in which it is used differs) that I suspect they may be hard to distinguish for people with limited vision. AddWittyNameHere (talk) 03:04, 7 June 2018 (UTC)
  • I'm going to rank these, if you don't mind, as well. I concur wholly with AddWittyNameHere. new2 looks best to me, though I really do object somewhat to the grey; then new1 and current, and finally, new3 (like AddWittyNameHere said, two grey locks are hard to distinguish, and that's bad for accessibility reasons). Great work, by the way! — Javert2113 (talk; please ping me in your reply on this page) 03:08, 7 June 2018 (UTC)
  • new2, and failing that, new1. Gray and gray doesn't help distinguish anything, especially when there aren't three right next to each other. New red lock looks nice. ~ Amory (utc) 10:29, 7 June 2018 (UTC)
  • New2 looks fine. Grey conveys "no information really", which is right for the middle lock (once you require login, restrictions have an almost infinite granularity) but not when we know for sure that something is paywalled. --Nemo 10:44, 7 June 2018 (UTC)
  • old1, new1, current, in that order, because progression/streetlights, and grey is more ambiguous than blue. ~ Tom.Reding (talkdgaf)  12:21, 7 June 2018 (UTC)
  • new4, old1, new3 Some people will only be able to visually distinguish a single element; color, lock body (open, partial, filled) or intensity (light, shaded, dark) so each icon needs to be distinguishable by a single element. I would suggest a new4 which makes the distinction between the open, half-filled and filled body of the lock more crisp and varies the color intensity/tone in a noticeable way between the three. I would also suggest a slight increase in size since some will not be able to resolve the body of the lock; removing the dot in the 'open' making the body white; and removing the dot in 'locked' making it solid. This should result in a more crisp image which is easier to resolve. Jbh Talk 15:44, 7 June 2018 (UTC) Last edited: 15:55, 7 June 2018 (UTC)
The problem with Lock-green-alt.svg is that it looks like an lowercase a. This is particularly bad when printed, or in grayscale. Headbomb {t · c · p · b} 18:44, 7 June 2018 (UTC)
You are right! Maybe using a different shaped lock body … like the keyed padlocks that are shaped more like an upside-down Ü See second and fourth pictures in gallery vs the first one at Master Lock. Jbh Talk 15:13, 8 June 2018 (UTC)
@Jbhunley: those get confused with HTML security locks like this one. Headbomb {t · c · p · b} 15:15, 8 June 2018 (UTC)
Ahh... I had not thought of that. Jbh Talk 15:19, 8 June 2018 (UTC)
  • new1 - That's the only one I think is the best option, To me the gold lock doesn't convey "Limited access" and the grey ones could be confused with something being hidden ? ... Not sure on the that but yeah I prefer new1. –Davey2010Talk 15:51, 7 June 2018 (UTC)
  • new1 per Davey. --Ahecht (TALK
    PAGE
    ) 18:15, 7 June 2018 (UTC)
  • new 3. I don't think the red is necessary, and draws unwarranted attention. Natureium (talk) 18:20, 7 June 2018 (UTC)
  • new 2, new 1, current (in that order). @Davey2010 and Ahecht: Doesn't limited access usually mean that it's partially hidden (such as you can view the first few paragraphs or something)? LittlePuppers (talk) 23:14, 7 June 2018 (UTC)
@LittlePuppers: The mouseover text says it means "free registration required". --Ahecht (TALK
PAGE
) 23:27, 7 June 2018 (UTC)
Ah, okay, I see that now. Thanks, Ahecht! LittlePuppers (talk) 23:38, 7 June 2018 (UTC)
  • comments: If this topic is supposed to be, or to act like, an RFC (as proposer described it here), shouldn't it be treated as if it were an RFC? Shouldn't proposer add {{RFC}} so that editors who don't watch this page can know that it exists?
    I question the notion that there is a problem here to be solved. Where is the evidence that readers are confused by the shapes/colors of the current lock definitions? So far, all we have is proposer's opinion that the the red lock is not very recognizable as a lock and that Green/Blue/Red makes does not convey progression and that some people also didn't like the red.
    Where is the evidence to show that the red lock with a transparent opening is more recognizable as a lock than the current red lock? GBR isn't necessarily intended to 'convey progression'; just difference. The individual locks could be any color as long as the chosen colors meet the accessibility guidelines against both white and black backgrounds. People are comfortable with GYR but shades of Y that are accessible against both white and black are rather more bilious than yellow so blue was suggested as a more palatable option. Doesn't seem like a problem that needs fixing. Yeah, so some people don't like the red; some people don't like the blue (the sea-of-blue argument) and some people don't like the bilious yellow. Ok, we will never please all of the people all of the time so without a significant uprising to indicate that the red is disliked by most people, doesn't seem like a problem that needs fixing.
    In the original RFC, Editor NMaia suggested emojis as a possible option. That suggestion wasn't taken up but, upon reflection, I think it should be. The emojis are standardized Unicode characters: U+1F513 🔓 , U+1F510 🔐 , and U+1F512 🔒 . With a bit of css, these characters can be manipulated: Example title link🔓. Further, because the emojis are characters, the no-wrapping issue for url access signalling might be resolved by the simple insertion of a word joiner character (&#8288; U+2060) between the url's marked-up title text and the emoji (see this discussion about why the current url access signals are allowed to independently wrap to the next line). —Trappist the monk (talk) 14:10, 8 June 2018 (UTC)
If you want data, I asked about 10-12 non-Wikipedian their opinions of the red lock, and about half recognized the dial-less lock as a lock. Everyone recognized the dial lock as a lock. Additionally every single one was confused by the Green/Blue/Red scheme ("why blue/what does blue mean", or made a comment "why don't you use yellow?"), but no one was confused by Green/Yellow/Red or Green/Grey/Red scheme. Headbomb {t · c · p · b} 14:17, 8 June 2018 (UTC)
• Building something off emoji may be the best idea. They are the most 'standard' icons and people across the world will be familiar with the iconography even if the visual details vary from implementation to implementation. Jbh Talk 15:18, 8 June 2018 (UTC)
I could support this idea, I think, so long as the free-to-read Unicode character could be differentiated somehow: maybe a white background? The opened lock might be hard to see. (As you can tell, I don't know anything about Unicode characters, or if they could be changed.) — Javert2113 (talk; please ping me in your reply on this page) 15:23, 8 June 2018 (UTC)
Emojis are by far the worst of ideas. Their appearances varies, they often look downright awful, and are often barely distinguishable, even to those with perfect vision, and aren't simply designed to convey information and meaning. And we also lose the association with the PLOS Open Access icon (this one meaning free to re-use). Headbomb {t · c · p · b} 15:24, 8 June 2018 (UTC)
Oh, and here I thought it was my terrible eyesight. Yeah, emojis might not be the best idea after all. — Javert2113 (talk; please ping me in your reply on this page) 15:40, 8 June 2018 (UTC)
  • new1 ~nmaia d 14:33, 8 June 2018 (UTC)
  • new2. I applaud Headbomb for conducting the study, which found that every one of the dozen or so participants were confused by the blue lock. We need more of this: ask the readers when you are making decisions that affect them. – Finnusertop (talkcontribs) 18:47, 8 June 2018 (UTC)

Polling templates

I suggest including the polling templates on Commons to Wikipedia. It would look better on Requested moves, Articles for deletion, and Proposed mergers and other Wikipedia proposals.
https://commons.wikimedia.org/wiki/Category:Polling_templates
--192.107.120.90 (talk) 14:03, 7 June 2018 (UTC)

RfC on the enforceability of logged voluntary editing restrictions

There is currently a discussion at Wikipedia:Requests for comment/Enforceability of logged voluntary editing restrictions, all are invited to participate. TonyBallioni (talk) 14:07, 7 June 2018 (UTC)

Idea lab

Problem behaviors

Wikipedia is generally a wonderful place to write and connect. Problem solving techniques such as Rfc's and third-party really do work pretty well most of the time. But there are some things--some people--that do seem to fall through the cracks fairly dependably. I would like to see a 'Be nice-Be respectful' policy that when violated can be reported, and if nothing else, that Wikipedia would keep track of the number of violations the same person gets over and over, so I would like to see a policy for consequences for repeatedly biting, not only newcomers, but anyone that disagrees with them. People just get away with that here because it isn't about consensus on content. I have seen more than one editor driven completely off Wikipedia because of personal attacks, slanders, insults, and various kinds of bad behavior by the same person. Nothing ever happens about it. I think that's wrong. Something should happen. It violates Wikipedia's stated policy and that policy should be better enforced. Jenhawk777 (talk) 22:56, 29 April 2018 (UTC)

  • We do have Wikipedia: Etiquette but I am not sure what happens to Wikipedians who violate the policies listed here. Vorbee (talk) 17:00, 30 April 2018 (UTC)
I don't know about 'solutions'; but I and a few others are actively exploring if we can figure out if we can make it easier for admins and others to 1. find problematic comments (assuming that's part of the challenge): https://meta.wikimedia.org/wiki/Research:Detox Feedback very welcome. Some more ideas we've experimented with some are at https://conversationai.github.io/ Iislucas (talk) 18:44, 24 May 2018 (UTC)
Nothing. Nothing happens to them. They move on claiming they do it all for the good of Wikipedia. That's the problem. Instant reverts, threats, insults based on ideology, point of view, differences of opinion, not based on consensus--things where one person is not clearly "right"--but the one person is asserting their "position" by domineering and intimidating. Nothing happens. They get you to leave. That's all that happens--at least that is all I have seen so far. I have been on Wikipedia about a year and a half, I have observed this one editor have just over a dozen of these types of conflicts, and people repeatedly contact Admin. about him and nothing happens. He seems bullet-proof. And that's just wrong. What are the chances more than a dozen people are in the wrong instead of him? Wikipedia needs to do a better job at this. What are the options? I would take any improvement at all. Jenhawk777 (talk) 22:54, 30 April 2018 (UTC)
Behaving like a dick can, and does occasionally get people blocked (you've probably already seen Wikipedia:Civility#Dealing with incivility). If the problematic behaviour has been gross, and you have recent examples of it that you're willing to present succinctly, and with diffs, then you can start a thread at WP:ANI. – Uanfala (talk) 23:11, 30 April 2018 (UTC)
I suppose I can start keeping a record since Wikipedia doesn't, but I am afraid of retribution if nothing comes of it. This person is vindictive. I was looking for a more proactive approach from Wikipedia.Jenhawk777 (talk) 16:00, 1 May 2018 (UTC)
this is an example right now. Not sure what idea can come out of this thread though; I would like to see civility enforced more, however we do already have a policy (two, WP:NPA and WP:CIVILITY) which are in the range of "Be nice-Be respectful' policy". I think it is not as much as there being a lack of policy but people unwilling to enforce for whatever reason. Galobtter (pingó mió) 16:07, 1 May 2018 (UTC)
Thank you for acknowledging the issue is real. Yes, we have perfectly good policy, but what good is policy without enforcement? I completely agree that is the problem. Disputes over content are solvable. Wikipedia cares about its content and has made good provision for multiple pathways toward resolution. Not so with personal abuses and attacks. Wikipedia does not keep a record of how often any individual gets called for a mediation dispute or watch for other signs of problem behavior and as far as I know, there is no special path for reporting that particular kind of problem--and certainly no enforcement of the policies we have. I simply want that person to stop. I personally have no ability to enforce the minimum behavior requirements of the larger group--that we all agree to--onto the group's few misanthropes. I can't see how this can be improved without some kind of policy change. Jenhawk777 (talk) 05:39, 2 May 2018 (UTC)
────────────────────────────────────────────────────────────────────────────────────────────────────
Yes, the issue is very real. Extreme perpetrators can be reported at WP:ANI and its related noticeboards, where administrators will decide what to do about it. But usually, rudeness is tolerated and you have to be grossly insulting or disruptive to be sanctioned. The reporting process is also quite bureaucratic and needs good understanding of it to be effective: where else would someone reporting abuse be told, "You haven't reported it properly, so we will ignore you"? I believe that this sad state of affairs is one of the biggest reasons why our community struggles to keep high-quality editors. You and I are not the only ones to have brought it up in one forum or another before now, but as long as the majority of the more vocal editors (especially administrators) are prepared to tolerate it, nothing will be done.
@Jenhawk777: However, from what you say it sounds like you have an abuser who may be overstepping the mark. If you drop me a private email with their username (let us know here if you need help with that), I will take a look and see if anything can be done — Cheers, Steelpillow (Talk) 14:38, 3 May 2018 (UTC) [updated 14:49, 3 May 2018 (UTC)]
DID overstep--not happening right now; we are no longer working on the same article. I am so grateful for the offer, but it just isn't enough to protect myself in one instance. Everyone should be protected. I have watched this person run several people off of Wikipedia. If it hadn't been for one of the good ones stepping in and saying, 'come work with me over here in a corner for awhile', I wouldn't have known Wikipedia could actually be rewarding and fun. I have tried to do that for some of the others, but they are so discouraged from the experience--and the fact it seems to them that no one cares--that they just leave. I know there are people here who care. The responses here are evidence. But Admin needs to do a better job at this. It is a problem for Wikipedia even if they don't recognize it. When people go away in this manner, they say bad things about Wikipedia. And frankly, there isn't an endless supply of people who want to write for free who are willing to put in the time to develop enough experience to actually be any good at it. Even factoring in inevitable losses, this should still be seen as an issue. Thank you again for the kind offer, but what I really need is a suggestion for a workable policy change. Jenhawk777 (talk) 18:42, 3 May 2018 (UTC)
Policy is not at issue. The problem is enforcement, it is too hard to get things done. For reasons I cannot understand, the further up people are in the hierarchy, the less they seem to want to recognise that. This is about winning hearts and minds, not policy. And sadly, I am no good at that. — Cheers, Steelpillow (Talk) 19:17, 3 May 2018 (UTC)
Well, apparently, I am even worse--I can't even get agreement here among people who actually agree with me. :-) Whatever the problem is, those with some actual influence need to act. Jenhawk777 (talk) 07:29, 7 May 2018 (UTC)
Agree to a point. But I don't think enforcement will work, for exactly the reasons you say. See comments below. Andrewa (talk) 21:26, 7 May 2018 (UTC)

Following the threads of this section I came across the Wikipedia:Kindness Campaign to which I've now signed up and which I recommend. Perhaps just promoting this WikiProject is what is needed.

I certainly think there's a problem. We cannot expect to attract and keep new editors, and particularly the sort of editors on which Wikipedia depends, in the current environment.

And I think something specifically focused on restoring no personal attacks to general acceptance might be the key here. See User:Andrewa/gentle editor for some of my ideas on that, and comments on its talk page or (far better) here (or even both) of course very welcome!

There has been no consensus to abandon (or even modify) NPA, but it seems to have happened anyway. I guess the other possibility is an RfC to modify or abandon the policy, and regard these behaviors as acceptable, but I myself believe that would be the beginning of the end for Wikipedia. I could be wrong. Andrewa (talk) 05:51, 9 May 2018 (UTC) Andrewa (talk) 21:26, 7 May 2018 (UTC)

Okay, so if enforcement isn't the answer--what is? I am a member of Wikipedia:Kindness Campaign and practice that--even with the person who kept attacking me--they criticized me for my "excessive civility" too! I don't think joining up is high on their list. You know, I need to add here that most of the people on Wikipedia are great--helpful, patient, kind--but when there is one whose behavior is so egregious, for so long, it can color everything. I'm trying not to let that happen. That's why I'm here. We have a lot of different kinds of people here with lots of different views and need to treat everyone with respect even if they have the audacity not to think like we do! Perhaps this is a personality thing that can't be fixed. IDK. I admit I'm feeling a little discouraged about all this. Jenhawk777 (talk) 20:33, 9 May 2018 (UTC)
I think we need to demonstrate (and perhaps first build) consensus among Wikipedians in general and admins in particular and perhaps even within ARBCOM that NPA is important. Enforcement might follow in some cases, but demonstrating that consensus might be enough without enforcement being necessary, and without demonstrating that consensus enforcement will not help, IMO, and won't happen anyway. Interested in other ideas, and ideas as to how to best do this. I've linked above to my own best attempts so far.
The only other possibility I can think of is an appeal to the founder. I'm almost concerned enough to give that a go.
Hang in there. If enough people give up on NPA, IMO it's the end of Wikipedia. Hard to imagine? Where did Kodak go?
If it did happen, the world would not end, and thanks to copyleft neither would most of our work so far. Citizendium (which ruthlessly enforces NPA) or another fork (well, currently it's not strictly a fork, but might become one again) would take over. But far better to fix Wikipedia IMO. Andrewa (talk) 22:54, 9 May 2018 (UTC)
We've been trying to build said consensus pretty much continuously for the 5 years I've been around, with no success. We are self-governed, and those participating in the self-governance are a self-selected few who are not representative of the whole. The way we decide things is not likely to change in the foreseeable future.
Over the years I have watched the ongoing debate and given the problem much thought, and I've come to believe that (1) it is intractable in the current environment, and (2) the only hope is through gradual attrition and evolution. As stated, the policy is already in place, and it is routinely ignored with various rationales for ignoring it. Any new initiative to stop ignoring it would fail for the same reasons as the many others that have come before; nothing has changed sufficiently to make the difference. More at the essay WP:DISRESPECT.
The only other possibility I can think of is an appeal to the founder. Good luck. The founder no doubt has his opinions, but they don't carry any more weight than those of any other editor. Those opposing stricter enforcement of behavior policy are not going to withdraw their opposition because of a statement by him.
I promise you that this thread is a dead end and a waste of time. ―Mandruss  23:26, 9 May 2018 (UTC)
Cancelled process mini.svg
I guess we sometimes need to dismiss what's not possible, but the purpose of this page is to incubate and encourage new ideas rather than assess them.
Jimbo is the only member of the founder user group, and has some other privileges as well. He's been understandably reluctant to use them but they are still there for the moment at least.
Agree that Those opposing stricter enforcement of behavior policy are not going to withdraw their opposition because of a statement by him. I'm one of them, so I should know! I'm hoping we can find a more effective way.
In fact one of the key problems I see is the common assumption (which I think you may be making too) that the only way to encourage adherence to NPA is by stricter enforcement. My hope for this thread is that we can brainstorm some other ways.
The other key mistake is to assume that violations of NPA are also violations of civility. In fact NPA is far, far broader then that. That's probably where I think ARBCOM and WP/ANI (on which I lurk from time to time) have gone wrong... once we give up on NPA and fall back to mere civility, we tend to fall back from encouragement to enforcement too. Andrewa (talk) 02:02, 10 May 2018 (UTC)
Mandruss--ouch. I hope you're wrong--but I'm afraid you're right. This could be a waste of time, but as I see it, we can't know till we've spent it. I have to try. I love Wikipedia--but using a colorful but descriptive metaphor--I think it keeps stepping on its own foreskin.
I went and read WP:DISRESPECT since I had never seen it before. Forgive my straightforwardness at this point, but in my POV, that is not a good or helpful article. It's not hard to identify disrespect--anyone on the receiving end of it can do so. I was recently reading an article on the neuroscience of making friends; basically, treating people with respect boils down to being as cooperative as possible and as pleasant as possible: correct others as you would like to receive correction. That's pretty much it. It's not difficult to understand, and there is no value that I can see in trying to make it more complicated than it is. If someone feels disrespected that should be addressed; period. It should be that simple.
Perhaps I simply haven't been around long enough and I don't understand how complicated this problem can become. Even if we used the same steps for personal attacks that we have for content disputes--what would be the end goal? To force an apology? No, that would not only never work--it would be disrespectful! But if there is no recognition of violation of existing policy, and there is no clear consequence--something like the three revert rule--three attacks in a row and you're blocked--then in my view this is not a real policy--this is just hypocrisy. We either stand up for what we claim to believe in or we don't. If we don't, let's take down the policy and admit it's a free for all here. Jenhawk777 (talk) 04:11, 10 May 2018 (UTC)
Perhaps I simply haven't been around long enough and I don't understand how complicated this problem can become. Perhaps. ―Mandruss  05:10, 10 May 2018 (UTC)
Well, I've been around for a while, and I think you're hitting some nails squarely on the head. But yes, it's complicated. We're not going to make Wikipedia perfect here, but we can make progress IMO.
WP:DISRESPECT is an essay not an article, and it's not obvious to me how much of it is the opinion of the person citing it but they're one of three contributors and mentioned by the creator. I don't find it helpful either, but one trap to avoid is assuming that if you treat others the way you want to be treated, they'll be happy. They may not want to be treated that way just because you do! See this off-wiki essay of mine. So that essay is well worth reading if only to understand the other mindset.
And that's the problem with having something like the 3RR for personal attacks. What's good vigorous discussion for one person can be offensive to another. That's one reason that NPA is so sweeping. Any idiot can understand it, and most of them do. (;->
You might also find User:Andrewa/Rules, rules, rules helpful. It's another essay, quite recent, trying to point out how radical and interrelated some of our rules are. Or wp:creed is another of mine, older but a favourite.
Hang in there! Andrewa (talk) 06:27, 10 May 2018 (UTC)
I wrote the essay two years ago and it has been on my user page since then. Recently others decided it should be in WP space. No, it's not my opinion, it's my understanding of the prevailing consensus position, with which I disagree. It ends with "Do you buy it?" Just thought I should clarify that, since it's not clear to me that it's clear to you. ―Mandruss  07:34, 10 May 2018 (UTC)
It's still there on your user page I see, and that explains its history. It would have been helpful IMO if a talk page entry had been created when the essay was copy-and-pasted from your user page. As it is, it's arguably a copyvio... the enigmatic reference to your user page in the edit summary doesn't satisfy the copyleft requirements. I'll fix it.
Fixed. Andrewa (talk) 15:50, 10 May 2018 (UTC)
It still doesn't seem any help to us in incubating ideas on this page. But let us move on. Andrewa (talk) 11:22, 10 May 2018 (UTC)
Mandruss, thank you for explaining--and for not taking offense! I apologize if my statement did offend in any way. I agree with you that treating others the way I want to be treated doesn't always make people happy. My assertion is that they should be treated the way they want to be treated--as long as it is within reason. But let's be real. Some people are just bad-tempered. That's just the way it is. Some people won't apologize or admit to an error if their lives depended on it. So what to do about the uncooperative? Is there anything we can do?
Andrewa, vigorous discussion is not the issue. Just today I saw a discussion where one User was attempting to ask the editor I had the problem with to be patient with newcomers, that teaching is a better response than ridicule, that it's easy to forget what it was like when you were new, that threatening and belittling someone with 190 edits for what they don't know yet is counterproductive, that what appears a point of view in a newcomer is often just an interest (Amen!) and more in that vein--it was wonderful--absolutely respectful and kind. His response was "I'm not talking about this" and he deleted the discussion.
This kind of thing happens with him about every four to six weeks--someone has a problem with him, calls for some kind of arbitration with him--it's a pattern. It's easy to see why: his first response to anything he doesn't like is a mass revert without explanation or discussion. If you ask why, you get insulted. If you had a brain you would know you're a crap writer. If you try to adapt it to what you think the problem is and put it back, you get threatened. You can ask for compromise till you're blue in the face. Mostly you'll get ignored. There is no discussion--vigorous or otherwise. I can't tell you how many times I tried to discuss. I ended up with an Rfc where every single vote was in my favor--and it made him so angry he put his point of view in long, long "notes" to counter that. Consensus was against him--he didn't care. He's been doing this for years apparently and is basically bulletproof because of longevity. And because Wikipedia makes no effort to keep track of how many conflicts an editor is involved in or how frequently the same editors are involved in them. That's what I have seen. Jenhawk777 (talk) 19:24, 10 May 2018 (UTC)
The NYRM2016 fiasco had some similar issues. Several of those determined to prevent the move made repeated personal attacks on me and others. (And succeeded somehow in getting a no consensus decision despite the policy and facts both being clear and undisputed. The only change when NYRM2017 succeeded a year later was that we'd had an RfC that clarified that NYS wasn't the primary topic, which surely was clear before the RfC, but the 2016 closers firmly refused to confirm or deny this. I doubt the full story will ever be told. But what concerns us here is just the behaviour.) I reported these personal attacks twice at ANI, with diffs. The first time several non-admins agreed it was clearly a personal attack, but there was no evidence any admin even looked at it, and it was auto-archived through lack of further discussion. The second time, nobody even commented.
If that's not busted I don't know what is.
The "idea" we're supposed to be discussing is to have a policy prohibiting personal attacks. There seems to be no question that we already do have one! Andrewa (talk) 03:16, 13 May 2018 (UTC)
I don't see this discussion as limited to policy only, it has also included discussion of some kind of follow through and/or increased enforcement of the policy we already have. Though I do have to say that any policy without any enforcement is a policy in name only-- in my opinion.
Oh man! Been there! You have all my empathy! Any suggestions for monitoring/enforcement/policy changes/fire-bombing--anything? Jenhawk777 (talk) 20:03, 17 May 2018 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────

Rudeness

This is kind of a weird idea, but I would like it if some of you considered improving the article Rudeness, with a particular emphasis on instrumental rudeness and the difficulty of determining what counts as "rude". I think that a clearer understanding of the incentives and the complexities would help us all. WhatamIdoing (talk) 02:00, 25 May 2018 (UTC)

I agree. That's kind of a weird idea. Face-smile.svgMandruss  02:06, 25 May 2018 (UTC)
Ha ha! The line between humor and rudeness is a little smudged isn't it? Thanx for the invite. I will take a look there, but I think I am probably done here. Wikipedia is, apparently, mostly happy with the status quo. The policy should read "Wikipedia is not for the faint of heart. Edit here at your own risk." It would at least be honest. Jenhawk777 (talk) 02:46, 25 May 2018 (UTC)
More accurately, a majority of the tiny fraction of editors who determine practice concerning these matters are happy with the status quo. They are self-selected, not elected representatives, and are therefore not "Wikipedia". The distinction is crucial. ―Mandruss  02:53, 25 May 2018 (UTC)
It's a rather weird situation. WP:NPA is a policy, and if any other policy is openly flouted, say at WP:RM, then many editors will descend in enthusiastic defense of the need to comply with say the WP:AT policy just because it is policy, because it reflects wider community consensus, etc.. NPA is extreme: Personal attacks harm the Wikipedia community and the collegial atmosphere needed to create a good encyclopedia... Insulting or disparaging an editor is a personal attack regardless of the manner in which it is done. (emphasis as in the original, omitted text indicated by ellipsis) It presumably represents consensus. None of the editors (and sysops) who regularly violate it have raised an RfC or even a discussion to have it weakened. How has it come to be so widely ignored? Andrewa (talk) 07:06, 25 May 2018 (UTC)
How has it come to be so widely ignored? The venues where practice is actually determined, such as WP:ANI, are downright nasty environments, and they are widely avoided by editors with milder dispositions who don't care to be around that unpleasantness. That leaves the controlling group highly skewed in the direction of editors who are either (1) combative and hostile, or (2) relatively unbothered by combativeness and hostility—so we have (quite naturally) ended up with a culture that tends to tolerate and excuse combativeness and hostility. That means widely ignoring written behavior policy. My question, not that it matters at this point, is how that managed to become written policy in the first place.
If we had a representative system of government with wide participation in elections, the "milder majority" would for the first time be fairly represented in decisions regarding editor behavior. I have little doubt that the resulting culture would be quite different, and Wikipedia would be a very different place at which to volunteer one's time. But the odds of that happening in our lifetime approach zero, as we would never reach the clear consensus required for such a change. Hence, intractable. ―Mandruss  07:40, 25 May 2018 (UTC)
I'm not sure the article is all that relevant. The lead there reads Rudeness (also called effrontery) is a display of disrespect by not complying with the social norms or etiquette of a group or culture. But that's too general... what is rudeness in our particular group or culture ie English Wikipedia? To make the article relevant, we'd need to find sources that described Wikipedia culture in particular, and cite these. Our own opinions as to what should be considered rude don't belong in the article namespace. They do however belong in the project namespace (here) and the project talk namespace (eg WT:NPA). Andrewa (talk) 07:06, 25 May 2018 (UTC)
I don't think that editing anything in main space can help. For a start it can be challenged over a lack of reliable sourcing, and then it irrelevant if you don't think you are being rude, with "I am just speaking plainly - and anyway they deserve it," kind of self-excuses. Nor do I think that a direct appeal to our founder can go anywhere. I once disagreed with him and he responded with exactly the kind of deliberately offensive insult we are complaining about here. Wikipedia needs a change of its corporate culture and that is extremely difficult if the head honcho is blind to their own failings and therefore themself part of the problem. But I am not wholly dispirited, see the next subsection. — Cheers, Steelpillow (Talk) 10:27, 25 May 2018 (UTC)
I think that a lack of understanding is a problem in these discussions, and when editors don't know anything about a policy-related issue, they often look at relevant articles. (See, e.g., Review article, which is linked in more than 3,000 pages outside the mainspace – 12 links in messages to editors for each link in the mainspace. People use that article to understand Wikipedia's rules.)
I don't think that we can deal with the civility problem when most editors conceptualize the source of rudeness as "Poor guy, he lost his temper" instead of "Hey, that guy chose to be rude. Why would a rational person do that? Oh, I get it: editors choose to be rude because being rude helps you win disputes in this community".
The smaller problem is the difficulty of defining rudeness: it's not just how the recipient feels, it's not just what the speaker intended, and it's definitely not what the speaker later claims to have intended when someone complains about it later. Think about the wikilawyering we see with NPA – the guy who claims that "You're stupid" is a personal attack, but "Everything you've posted on this page is stupid" is not a personal attack. Guess what? They're both personal attacks. They're both uncivil. They're both rude. They're both the kind of thing that we don't want in this community. But until we understand the difficulty of defining this, we won't get very far. And, yes, I do believe that reading some high-quality sources that discuss the subject of rudeness directly will help improve these discussions. (And if you're going to consult some sources, you might as well improve the article while you're at it...  ;-) ) WhatamIdoing (talk) 05:27, 29 May 2018 (UTC)

Best practice

I think the only way ahead is to look at best practice in the wider world and see if there is anything there we can learn from. I have some experience of civility codes in both commercial and public organisations, all in the UK. Here are some of my observations:

  • It is becoming increasingly accepted that rudeness and disrespect are in the mind of the recipient; if they feel insulted by you then you have insulted them, whether you intended to or not. WP:IUC needs updating accordingly.
  • Rudeness is about more than just words. Aggressive behaviours can be equally rude, not only in active aggression such as reversions but also in passive aggression such as refusal to acknowledge or discuss an issue or to admit any personal failing. WP:IUC could make this clearer.
  • Overly-detailed prescriptive guidelines are the wrong way to implement policy. An enlightened moderator is absolutely essential in dealing with incidents that escalate. As it stands today, WP:IUC is a classic example of how not to do it and does nothing but provide ammunition for logic-chopping excuses and "I have nothing to apologise for" attitudes. If it is simplified and refocused on perceived intent, that should help the moderating Admins to make better decisions.
  • Apologising for unintended harm, such as a perceived insult, is increasingly becoming mandatory. It is in this respect analogous to a fine for a parking offence, where the parking itself is only a civil offence but failing to pay the fine is a criminal one. Such a forced apology may well be mealy-mouthed and insincere, but it has been seen to be made and that is the crucial thing. Once somebody has been forced to cough up several such, they will begin to get the message. WP:CIVIL is grossly behind the times in this respect. It also needs a shortcut such as WP:APOLOGY (which currently redirects to an essay) to help raise awareness of its critical importance.
  • To be effective and deal with expert wrigglers, moderators also need a generic getout clause allowing, "we just find it unacceptably disrespectful overall" judgement even though specifics may be vague. An example would be an unjustified demand for an apology, where the demand is really just a cynical revenge manoeuvre. I don't know to what extent our Admins have this already.
  • Logging and tracking of escalated incidents is the norm. "You have been called here on three separate occasions already this year" type information should be available to moderators at the click of a button. Typically, the data is time-limited to prevent lifelong black marks. I don't know of our Admins have such tools, but they should.

Phew! I had no idea this list was going to be so long. I just want to re-emphasise that all this is established best practice that I have seen working well in the outside world, it is not my personal rant. No wonder we Wikipedians are in such a pickle! — Cheers, Steelpillow (Talk) 10:27, 25 May 2018 (UTC)

It is becoming increasingly accepted that rudeness and disrespect are in the mind of the recipient; if they feel insulted by you then you have insulted them, whether you intended to or not. I feel insulted by that assertion!

Actually, I find that assertion problematic because such a subjective criterion makes it very easy for someone to claim insult and demand apology as a method to derail the discussion or to harass an opponent. Or, worse, for someone to find insult in an accusation that they have insulted someone, which could then repeat //ad infinitum//. You mention this, saying An example would be an unjustified demand for an apology, where the demand is really just a cynical revenge manoeuvre, but that directly contradicts the assertion that the insult is in the ear of the hearer rather than in the intent of the speaker or the judgment of a neutral party. Anomie 16:44, 25 May 2018 (UTC)

Haha, cute. But the ear of the hearer is not the same as their scheming. You have provided an excellent illustration of why moderators need to be free to exercise their common sense, thank you. — Cheers, Steelpillow (Talk) 19:00, 25 May 2018 (UTC)
I think that "the ear of the hearer" isn't the whole story. That approach suggests that if you sweetly smile while cussing at someone in a language that they don't understand, then you've not been rude. I cannot agree with this. On the other side, according to this model, if you do something that is widely accepted as being polite or even deferential, such as a strong young man holding open a heavy door for an elderly woman, and she says that anyone who holds a door open for an elderly woman is either sexist or ableist or both, then he's being rude.
That's not how it works. Cussing at someone who doesn't understand your disrespect is still rude, and holding a door open for someone who might need the help is still civil, even if the targets of these behaviors don't see it that way. WhatamIdoing (talk) 05:40, 29 May 2018 (UTC)
Such a forced apology may well be mealy-mouthed and insincere, but it has been seen to be made and that is the crucial thing. It seems not everyone agrees that forced apologies accomplish anything useful.[27][28][29][30] We even have an article about the non-apology apology. Anomie 16:44, 25 May 2018 (UTC)
Yes, and utterly ineffective it has all turned out to be. The real world has discovered that this approach does not work, maybe it's time Wikipedia grokked that too. — Cheers, Steelpillow (Talk) 19:00, 25 May 2018 (UTC)
If Wikipedia had the wisdom to take lessons from the real world, we wouldn't have self-selected self-governance, which is the root of most of its problems in my view. ―Mandruss  03:08, 26 May 2018 (UTC)
@Steelpillow: I find your list brilliant, and just what I was looking for when I first came here, and I agree with each of your suggestions--especially logging and tracking. The objections are addressable.
Anomie In my experience subjectivism is already present in this issue. Recognizing that won't make it worse and might make it better. WhatamIdoing If there is a misunderstanding of intent, it is easy enough to say so. I did just this past week. "I meant no disrespect" generally works. Steelpillow You could be right that forced apologies may not be the best approach, but the real question is whether it would be better than what we have. If Admins had that logging feature, compliance could be considered to demonstrate good faith overall. Accepting that everyone screws up occasionally, it is the repetition of negative behaviors that demonstrate a pattern and without evidence of remorse that could all be weighed to determine overall good faith. Sort of a systemic approach. Mandruss I disagree with your conclusion.
I personally think Steelpillow is on to something. The suggestions are specific and doable. Jenhawk777 (talk) 18:30, 30 May 2018 (UTC)
"I meant no disrespect" is meant to change the mind of the target. The workflow you're talking about is this:
Do something respectful (e.g., use the word "sir" when addressing a man 40 years older than yourself) > Target felt insulted > Try to change the target's mind > If target insists that the respectful behavior was rude, then you actually were rude?
That's not reasonable. Respectful behavior does not become insulting just because someone is feeling grumpy about getting old or being addressed in a formal fashion by a stranger. IMO a more accurate and civilized flow looks much closer to this:
Do something respectful = You were being polite, even if the other person has a problem with the culture that both of you live in. WhatamIdoing (talk) 01:45, 31 May 2018 (UTC)
Agree (with Jenhawk777). All well worth a try. I still think it would be less trouble for more effect to just reinstate wp:NPA, but there seems no immediate prospect of doing that. (I'd love to be proven wrong on that.) Andrewa (talk) 01:50, 31 May 2018 (UTC)
WhatamIdoing > "I meant no disrespect" is not intended to change the mind of the target--at least not when I say it. It is merely meant to inform. People do jump to conclusions about intent, but they can't actually read minds and know for certain what my intent was--unless I inform them. I have found it helps generally.
I also find acknowledging the other point of view is sometimes all it takes. For example, your scenario is not wrong even though it is not the same as mine. It is a perfectly legitimate approach that gets to basically the same place I do--(accept differences)--without all the steps in between. Perfectly okay, (but I like my steps).
If they still insist I was rude, then in their minds, that is their reality, so for them the answer to "was I actually rude?" is yes. They certainly have as much right to define their reality as I do to define mine. In my mind, my only legitimate approach at that point is to say I am sorry they have been distressed--because I care about other people's feelings. It isn't about one point of view being right--my intent was still my intent--so much as it is not assuming that just because my intent was to be polite that it actually came off that way to the recipient. An apology in this scenario simply acknowledges the legitimacy of other points of view.
At that point, if they are still upset, I would say there is reason to believe there are other issues going on. That is when we need some way to get Admin or something involved. So what do you think about Steelpillows suggestions? What about a logging program that keeps track of the number of conflicts an editor regularly gets into? What about inventing a conflict resolution protocol from scratch? That's one extreme to the other, I know, but throwing all the possibilities out there seems legitimate here. I would love to hear your ideas. Jenhawk777 (talk) 09:06, 31 May 2018 (UTC)
If I may add to that, how often have I heard the phrase, "I was trying to be polite" after some misunderstanding arose. Trying to be polite and managing to be polite are different things. For example in some cultures it is polite to stick your tongue out in greeting, in others it is rude. Get it wrong and you have committed a deadly insult, whether you intended to or not. So yes, it is very possible to be rude without intending to be. Furthermore, telling the offended party that they need to change their ways only rubs salt in the wound. "I am so sorry, I meant no disrespect, please can you forgive me", is a far more constructive response. — Cheers, Steelpillow (Talk) 10:06, 31 May 2018 (UTC)
Jenhawk777, when someone misinterprets your intention, why do you want to inform that person of your intention? Could it be that you are hoping to change his mind, away from his erroneous conclusion about your intention and towards an accurate understanding of your intention? WhatamIdoing (talk) 15:23, 31 May 2018 (UTC)
I am hoping to cast oil upon troubled waters, to soothe, and calm the storm of offended feeling. They may continue to think my behavior was rude, but they may also feel less inclined to pursue beating me up for it because intent--motives--matter, generally as much as actual behaviors for most people.Jenhawk777 (talk) 15:36, 31 May 2018 (UTC)
@Steelpillow: Is there some way to make the recommendations you suggested to Wikipedia? Jenhawk777 (talk) 19:19, 3 June 2018 (UTC)
I don't know the best way. People at Wikipedia talk:Policy have been saying that there is no formal process. Perhaps Wikipedia:Village pump (policy) would be a good place to take them next and get some more focused feedback. Or maybe it is better to post a link there back to this discussion? — Cheers, Steelpillow (Talk) 20:39, 3 June 2018 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── I don't think it's appropriate for me to copy your ideas and post them there for you, but if you do decide to do that, please tell me and I will go there and participate in discussion there too. Thank you! Jenhawk777 (talk) 14:46, 4 June 2018 (UTC)

OK. I have started a thread there by asking much the same question as in my last post. — Cheers, Steelpillow (Talk) 16:31, 4 June 2018 (UTC)
Awesome. Jenhawk777 (talk) 01:52, 5 June 2018 (UTC)

watchlist change size feature problem - abuse is easy

Any thought welcome!

Currently watch page shows the resulting *change* is page size, rather than the amount of content being changed.

This is used by abusers. By smartly doing edits with 0 byte page change difference.

A vandal will remove some lines and add other less useful lines. But make sure that the total size of the page is unchanged. Thus avoiding detection by users having the page watched. They will assume it is an iota added or so.

My suggestion is to have bytes changed instead. Which will remove this issue and give information similar to now.

Alternatively, an optional procedure can scan the edit and: IF bytes changed >> than size change by factor X then present the extra number in the watchlist (i.e. instead of "(+12)" you will see "(+12/1000)" when 1000 bytes changed with 12 bytes size change) — Preceding unsigned comment added by YechezkelZilber (talkcontribs) 06:23, 13 May 2018 (UTC)

There are many multi-byte characters so it should probably be characters changed if anything. But it's difficult to count. It depends how a diff is interpreted. Our diff software tries to compare lines with lines. If newlines are added or removed then the software may count it as whole paragraphs being removed and inserted. See e.g. [31]. I don't think an automatically counted character change would be better than the change in page size. It would be better in some cases but worse in others, and it would often be confusing. Maybe both numbers could be given but that would also confuse many users. PrimeHunter (talk) 10:38, 13 May 2018 (UTC)
Agree about the peculiarities of the diff program.
I meant characters, and said bytes.
A procedure can be programmed that will infer situations where lots has changed with a small size change. This can be done without stepping into the diff morass (using total character counts is one easy shortcut).
I agree that size should be kept. My suggestion was to add characters edited only when there seems to be a discrepancy. As a countermeasure against abuse. Jazi Zilber (talk) 11:30, 13 May 2018 (UTC)
I think it's a great idea, I can't see how it would be any more confusing than the current display and I'm guessing it's a very easy change to code and test. But at the same time I wouldn't make it all that high a priority. We'll always have these people, and my guess is that they each have a certain amount of time to waste and will waste it on us regardless of how hard or easy we make it. And this would probably not reduce the amount of time it takes to fix it, it would just get us on to the case more quickly.
But it would make repairing the damage a lot quicker in some cases, giving a better reader experience, and that's our bottom line. Andrewa (talk) 20:25, 13 May 2018 (UTC)
I would strongly agree with this as an idea - just as big edits with summary "typo" is a hint, sometimes smart vandals who have balanced edits leave a non-typo summary, so I see it then. That said, there must be many that are being missed. Good thinking.
Great idea. Sometimes the diffs get confused and a simple change of a paragraph character and a couple of others may be interpreted as a whole new paragraph replacing the old one. As that is a problem with the diff engine and can be attacked separately, I would prefer overlarge diff sizes to undersized ones. — Cheers, Steelpillow (Talk) 18:59, 29 May 2018 (UTC)

From a technical perspective, the problem here would be that a diff is actually one of the most expensive operations there is, and requiring that for every saved revision is likely to come at significant computational cost. The idea seems rly nice though. —TheDJ (talkcontribs) 19:08, 29 May 2018 (UTC)

I thought mediawiki saved incremental changes and (apart from checkpoints) only maintained the full page in its current state. All we need to do is note the size of the diff file (aka the incremental change) when it is created, possibly normalised with metatdata ignored. The overhead comes only in stitching together the diff before-and-after view later, if requested. — Cheers, Steelpillow (Talk) 20:38, 29 May 2018 (UTC)
You thought wrong. Anomie 11:57, 30 May 2018 (UTC)
According to this, since v1.5 "Wikimedia sites use a MySQL-backed external storage cluster with blobs of a few dozen revisions. The first revision of the blob is stored in full, and following revisions to the same page are stored as diffs relative to the previous revision." (A break for a new blob is called a checkpoint). So OK the diffs may not be separate files but they are still small, labelled fragments whose size should not be too hard to check. Where does the History list get its page size changes from and is that list cached anywhere? — Cheers, Steelpillow (Talk) 14:40, 30 May 2018 (UTC)
It appears that page is inaccurate. By default each new revision is stored as a standalone blob with the full text of the revision. At one point many years ago a maintenance script was run on Wikimedia wikis to recompress old revisions in the manner described, and there's talk about doing that again, but it's not an automatic process. Anomie 14:09, 31 May 2018 (UTC)
Are pages stored as BLOBs or CLOBs? While I'm asking, does Wiki still use MySQL or has it moved to MariaDB? Just curious. Martin of Sheffield (talk) 15:34, 31 May 2018 (UTC)
Isn't "CLOB" and Oracle term? Anyway, the MySQL/MariaDB schema uses the "blob" type, and the configuration used here compresses all revisions with gzdeflate. The actual data is stored in separate databases dedicated to the purpose, separate from the databases that store most of the rest of the data. The database servers on the Wikimedia cluster currently use MariaDB. Anomie 01:42, 1 June 2018 (UTC)
You may be right, but the MariaDB provides {TINY,,MEDIUM,LONG}TEXT as the equivalent character versions of {TINY,,MEDIUM,LONG}BLOB. Anyhow, thanks for the reply. Martin of Sheffield (talk) 09:16, 1 June 2018 (UTC)
OK, thank you for the update Anomie. Is there a current description of it anywhere? — Cheers, Steelpillow (Talk) 08:10, 1 June 2018 (UTC)
Calculating diffs everytime might be costly. But having the said diff calculated after each edit and saved in the logfile of the entry (or where ever) will make it a once off action. An action that is minor relative to the multiple costs of activating an edit. Of course this advance calculating is a great optimization idea to be used at various stages of costly computations (I once optimized this way to the tune of X45 speed gain) Jazi Zilber (talk) 14:41, 30 May 2018 (UTC)

Most Americans don’t realize Robert Mueller’s investigation has uncovered crimes

Wikipedia is failing at its job to educate people. The state of articles on American politics is not explaining basic facts about what's going on with everything from net neutrality to climate change. We are under siege by political advocacy agents in a whole host of subject areas. [32] Andrevan@ 23:49, 23 May 2018 (UTC)

Everything mentioned in that article is already in various articles at Wikipedia. There's nothing written there that isn't already written here. I'm not sure what else needs to be done. --Jayron32 00:02, 24 May 2018 (UTC)
For example, see Special_Counsel_investigation_(2017–present)#Criminal_charges. Maybe it needs updating, I wouldn't know, but it looks quite comprehensive and detailed. You can try to include a number count of criminal charges and guilty pleas in that article's lede section, though of course this, too, would then need regular updating. ---Sluzzelin talk 00:04, 24 May 2018 (UTC)
(ec):OK, the Vox article is interesting but says nothing directly about Wikipedia - our name is not even mentioned. Americans, when polled always appear to be highly misinformed. I'll suggest several possible reasons:
  • Note that 3% in the poll reported by Vox who say that they've heard nothing at all about the Mueller investigation. That's likely the pollee telling the pollster to get lost. 2% of Americans will tell pollsters that they've never heard the name George Washington.
  • the 59% who say that they don't know for sure if the investigation has uncovered actual crimes probably believe
    • lying to the FBI is not a real crime
    • from pure political motivation, that all the evidence is being made up
    • that only charges against Trump or other current office holders "really count"
  • Mom is driving the kids to school when she gets the pollsters call, or Dad is trying to watch a baseball game.
In any case Wikipedia can't be held responsible for the perceived lack of education among Americans. Schools, universities, the news media, churches, parents, etc. surely have more responsibility for this than we do.
But if you'd like to improve the situation, please try to improve the relevant articles. The usual way is one editor at a time making one edit at a time. But if you want to try to organize a project or other means, please do. But remember that editors run into such requests at least once a month. If you do run into political advocacy agents and have evidence of this, please report it to WP:Coin. Smallbones(smalltalk) 00:46, 24 May 2018 (UTC)

8Everybody can be quite ignint when they want to be, esp. when it comes to dead horses. None of this is en.Wiki's business. cinco de L3X1 ◊distænt write◊ 17:28, 24 May 2018 (UTC)

  • Thanks for above comments. My concern is that actual Russian agents are attempting to infiltrate Wikipedia and are pushing POVs on many topics. I first observed this about 5 years ago in the Wikipedia:Requests_for_mediation/Ghouta chemical attack mediation. See for example the recently blocked Trust Is All You Need who seems determined to remake the articles on socialism to be the orthodox Soviet communist line. Or, some of the users on the Donald Trump articles pushing Sputnik and RT, per Drmies. Liberal use of checkuser has privacy concerns, and people can easily block evade as TIAYN has been doing. I think we need a mechanism to check this kind of thing. I also think ArbCom possibly can't solve this if it requires a technical solution. How are other major websites dealing with this? Andrevan@ 20:15, 24 May 2018 (UTC)
    • ArbCom needs to get busy here and realize that it's not simply a matter of pro and con. The biggest problems aren't the socks and the trolls, but the POV editors who wikilawyer the hell out of everything. Drmies (talk) 23:55, 24 May 2018 (UTC)
Agree I am in complete agreement that tracking down and addressing POV editors is a significant problem. I'm concerned about whether purely volunteer editors can take this on by themselves. I'd love to get involved in a good discussion about what we might do but that doesn't seem to be the point of the section so it ought to be started as its own discussion.--S Philbrick(Talk) 20:37, 2 June 2018 (UTC)
  • Comment When did Wikipedia become a political discussion forum? (As a relevant aside, I'd like to see Wikimedia create a sister project which would be a discussion forum, but that's a whole 'nother kettle of fish.) I'm a big fan of allowing a lot of leeway when brainstorming new ideas, but this section starts with a misleading headline, followed by a rant that's not backed up by any wiki diffs, not to mention the absence of any proposed solution. In other words it's a poorly articulated problem statement, and nary a hint of what might be done.--S Philbrick(Talk) 20:24, 2 June 2018 (UTC)

Expert review

Moved from WP:Village pump (miscellaneous): --Pipetricker (talk) 08:06, 1 June 2018 (UTC)

I'd appreciate feedback on an idea. I'm thinking of establishing a free expert review service for Wikipedia featured articles on academic topics - topics well-covered by reliable journals, such as medicine and astronomy. Once an article meets the FA criteria, the world's leading experts on the topic would fact-check it and tell you what they think of its comprehensiveness and neutrality.

I can only offer this service if I'm allowed to put two prominent links at the top of the current article version, one linking the reader to the version that passed review, and the other linking to a simple diff between the current version and the fact-checked version.

The world's topic experts aren't going to review an article if the version they endorse disappears into the article's history in a day or a month. They will if we link to the reviewed version. And the "simple diff" is a service to the reader: it shows them at a glance how the article (and topic) has evolved since the expert-review.

I've thought deeply on this for a long time. I asked BMJ, the publisher of The BMJ, to recruit experts to review Parkinsons disease, and they obliged. One of the reviewers was a main author of the current PD diagnostic criteria and another is the most-published author on the illness. This was a very high quality review. That's the standard of review I intend to maintain.

Do you think rigorous independent expert-review of featured articles is a good thing, and would you support prominently linking to the reviewed version and the diff? --Anthonyhcole (talk · contribs · email) 13:34, 30 May 2018 (UTC)

  • I'd be in favour of this, for what would inevitably be a rather limited number of articles, with some kind of simple control/approval process. In line with WP:MEDRS principles, I think there should a time-limit of up to 5 years set on the links, unless there's some kind of re-review. Johnbod (talk) 13:58, 30 May 2018 (UTC)
  • Not sure who will recall, but there were 2 similar proposals offered back in 2016: User:Atsme/WikiProject_Accuracy, which was presented at meta:Grants:IdeaLab, and a similar project was presented at the same time by another editor: Academic Reviewers. There's also Proposal:Expert review which is along the same lines. Atsme📞📧 14:08, 30 May 2018 (UTC)
How do you feel about those two prominent links at the top of the current version, Atsme? --Anthonyhcole (talk · contribs · email) 16:48, 30 May 2018 (UTC)
I'm fine with it. When I was researching for Project Accuracy, I spoke to quite a few academics (various teaching levels) and explained the significance of the GA & FA symbols on articles. Their responses are what inspired me to design the Seal. I still believe that once an FA goes through the drill of expert/academic review, they should be afforded some protection which makes that "seal" worth something. Atsme📞📧 16:59, 30 May 2018 (UTC)
  • Thank you, Atsme. I'm not sure where I stand on universal automatic protection for articles that have passed expert review. I think I'm against it but need to do more thinking about it. --Anthonyhcole (talk · contribs · email) 17:14, 30 May 2018 (UTC)
  • You're quite welcome, AHC - and if I may briefly explain why I feel some level of protection is needed...once an article has been reviewed to top level, any additions that follow will not have been reviewed; therefore, any newly introduced inaccuracies may be read/cited before the err is caught. The onus will fall on the promoting reviewers (presumably whose links are at the top). At least with some level of protection, it will allow the time needed to review & clear the new material. It is not that we are changing "the encyclopedia anyone can edit", it's simply a brief delay from time of edit to time of publication, but only for those promoted articles. Atsme📞📧 19:45, 30 May 2018 (UTC)
  • I think Dengue fever has been semi-protected since it was published in a peer-reviewed journal in 2014 and that hasn't ruffled any feathers. I see your point about protection. It may further encourage expert collaboration, too. As I say, I'm still making up my mind on this. But it's something for later, anyway. It's by no means a deal-breaker for me. Before I start spending my time and money on this, though, I need to know whether the community will let me do it. --Anthonyhcole (talk · contribs · email) 02:53, 31 May 2018 (UTC)
  • Hmm, the prominent links could be a hatnote, like the one we have linking to introduction articles, e.g like on General relativity. I think that at-least would be accepted by the community, and having a reviewed version does seem good; I'm just thinking - if we're not using the reviewed version as the default, we're sort of un-endorsing it; at the same time the fact that the reviewed versions would get out of date +general principles means we can't keep articles fixed on that. Not precisely related to this, but looking at the Project Accuracy pitch; most readers are not really critically looking at Wikipedia, and thus I don't think having reviewed versions would somehow make Wikipedia more reliable in the eyes of people Galobtter (pingó mió) 17:29, 30 May 2018 (UTC)
Was also here to say this, we already have Wikijournal where people can send FAs to get peer reviewed by professionals. Having one more similar process would drain the reviewer man-power. FunkMonk (talk) 14:16, 31 May 2018 (UTC)
It doesn't have to be separate - it can be coordinated in those topic areas. There's more to WP than just meds and science. Atsme📞📧 14:24, 31 May 2018 (UTC)

Jens, Mike, Dank and FunkMonk, I've been watching the development of Wikijournal of Medicine since its inception. My model differs in several important ways from Wikijournal of Medicine. The quality of the reviewers I'm offering is the highest possible. That's not the case with Wikijournal of Medicine. I won't be using the same pool of reviewers as Wikijournal of Medicine so I won't be draining that resource. I'm proposing we offer the Wikipedia reader a link to a simple diff showing them clearly the difference between the last reviewed version and the current version; Wikijournal of Medicine doesn't have anything like this in its model. My proposal includes a prominent link to the "reliable" version. The Wikijournal of Medicine model uses a tiny, essentially meaningless little book icon that no readers will understand without clicking and few will click. The names of all my reviewers will be published and prominently displayed on the reliable version; in the WikiJournal model the reviewers may remain anonymous. I'm not proposing to start a new journal to host the reliable version - the reliable version of an article that has passed review simply sits in the history of the article, available to readers who click the prominent link. There are other important differences too but this list should make it plain these are not the same product.

Let me emphasise this important distinction: The traditional academic publishing model relies on the reputation of the publisher, whom the reader trusts to run a high quality review by anonymous peers/experts, and the reputation of the authors, whose names are all disclosed. Both elements - the reputations of the publisher and the authors - are essential to rigorous science publishing. Wikipedia permits authors to remain anonymous and Wikijournal of medicine allows the reviewers to remain anonymous - leaving only the reputation of the publisher as a guarantee of reliability. That's not enough. WikiJournal has no reputation to speak of yet; in my model we use highly esteemed journal editorial boards with an already-established strong reputation for reliability to select only the very best reviewers. But even if WikiJournal were to develop a reputation rivalling Lancet and BMJ the WikiJournal model would still be inadequate. Humans - with careers and personal reputations and egos to protect - need to put their name behind the article. In my model the experts stake their reputations on the reliability of the reviewed article. I can't stress enough how important this particular difference between the two models is. (Although several of the other differences are very significant too, in terms of epistemology.) ---Anthonyhcole (talk · contribs · email) 15:45, 31 May 2018 (UTC)

I'm not saying that WikiJournal of Science meets all our needs and we don't have to consider other journals. I'm saying that there's already precedent for putting a special symbol (the book symbol) at the top of an article to notify readers that there's been some external form of review, and the symbol serves to send them to that paper. - Dank (push to talk) 16:28, 31 May 2018 (UTC)

Would this idea only be for featured articles?Vorbee (talk) 10:15, 2 June 2018 (UTC)

Yep. I only want to submit our very best work to experts (they're busy people) and the FA process is the best system we have for assessing quality. --Anthonyhcole (talk · contribs · email) 11:39, 2 June 2018 (UTC)
  • Support Both the concept of the expert review process as well as the inclusion of a link to the reviewed version. I see a suggestion that it can be done with a hatnote. I agree that it should be something akin to a hatnote but there may be a legitimate argument for making it look a little different than a hatnote as the concepts aren't exactly the same. (Generally, a hatnote is going to direct you to a completely different article, and if I'm looking at an article and it seems to be the right subject, I might not pay attention to a hat note, even though in this case it might be the one I'd prefer to see.)--S Philbrick(Talk) 20:11, 2 June 2018 (UTC)
  • Question – How many articles would this actually affect, in practice? I count 52 FAs in the Health and medicine category, which isn't that many when you think about it. I haven't counted FAs in other "academic" categories like astronomy, but let's be generous and say there are 250 of them. Is it really worth it to create a whole new system for the benefit of 300 articles, many of which figure to be in less need of expert help than B- and C-class articles? It's not like the medical WikiProject is cranking out FAs like crazy; most of the time we don't see any medical articles coming through FAC. Never mind that the vast majority of readers aren't going to bother clicking on a small icon that goes to a potentially years-out-of-date version of an article (they don't do it often for the talk page links to the version that passed a given process), or that experts might propose edits that would damage an article (not knowing our norms for a given topic). Without enough work on relevant articles, I fear that such an idea wouldn't be worth the effort. There's no point in pushing for experts to sign up for a review service if they won't have anything to do. Giants2008 (Talk) 00:49, 4 June 2018 (UTC)
  • Mixed Support encouraging such reviews, oppose fossilizing the reviewed version with a diff anywhere, especially in the article space itself. There should be no marker on the article text, and I'm leery of even a talk page notice, which would tend to encourage WP:OWN-type issues and fossilization of articles. I like that experts want to help review our articles, I don't like that someone will use this to prevent future improvement. --Jayron32 01:50, 8 June 2018 (UTC)

Make "thank log" more visible

Dear all on WP:Village pump,

First time here, if this was the wrong place to post such idea please advice me to reroute.

To promote the atmosphere of appreciation and encourage positive collaborating on the WP environment, I'd like to suggest we make thank log from and towards a user more visible, for example, make it a direct link from Tools, or somewhere default in a user page. Also, we can make it more visible that some users are generally more appreciating. The idea is still very early stage, I'd like to hear what people thinks about that.

Xinbenlv (talk) 18:26, 5 June 2018 (UTC)

Wiki Loves Earth upload links

Quite a while ago I said I was going to open this discussion, after an FL review and subsequent discussion at List of National Parks of Canada led to upload links for Wiki Loves Earth 2017 being removed from the article. To see what I mean, see this revision. Back in October, editor Yilku1 started a featured list removal discussion specifically mentioning the upload links as a disqualifying feature, and so they were one of the first things I removed from the article when I took on reviving it - at that time WLE 2017 was long over, besides.

Several months later, WLE organizer Braveheart questioned me about the removal (see discussion here). The multiple upload links were intended to provide an easy way for a reader browsing the list to upload content to Commons which would be automatically categorized for the park associated with the link, or at least that's how I understand it. While I agree that the links are useful for readers interested in contributing graphic content, I also feel particularly in this featured list that an upload links for a separate wiki takes up space that would be better used for content - it wasn't really an issue in the pre-review version but it definitely would have been a problem in the greatly expanded list after the review closed. I didn't have an answer at the time and still don't about how to better support these links, so I'm seeking ideas here.

Is there an attractive, less intrusive way that links of this sort could be included in an article or list (inline or otherwise)? Ivanvector (Talk/Edits) 20:18, 6 June 2018 (UTC)

Thanks for the ping Ivan! I think it depends on what people see as tolerable. On German Wikipedia, upload links are usually displayed like in de:Nationalparks in Österreich, which is probably the smallest you can make these links without making them useless. I'm not sure why technical features have an impact on the outcome of featured list discussions, that seems like a discussion we would have had back in 2006 or 2007, not 2018 when Commons is seen as an integral part of Wikipedia. Braveheart (talk) 21:17, 6 June 2018 (UTC)
It should go on the talk page, as it is related to improving the article. Graeme Bartlett (talk) 23:14, 6 June 2018 (UTC)
I agree, just like {{image requested}}. —Cryptic 23:50, 6 June 2018 (UTC)
Who's going to look at a talk page when they want to add pictures? Braveheart (talk) 09:03, 7 June 2018 (UTC)
I kind of like the way that dewiki does it, per the link Braveheart provided above. This is different from an image request, which is used to request providing one image for an article that doesn't have any; this is for encouraging users to upload their own content which may or may not actually be used in the article (in the case of the Canada parks list, likely not). This is a multimedia project, after all, our pages don't need to look like dead trees all the time and we can use code to hide the icons from appearing in printed versions. In the Canada list, icons beside the images would exacerbate cramped space in the list, but what if they were inline below the image instead? There's already space there for most of the parks, thanks to the long descriptions. Ivanvector (Talk/Edits) 16:07, 8 June 2018 (UTC)

Documenting the risks of creating a Wikipedia article

Anyone who has spent time at WP:AfC and WP:AfD knows that Wikipedia attracts people who wants to promote themselves, company, product or service. There is a constant stream of crufty new articles to deal with.

To help offset this, might there be a page that details the downsides and pitfalls of Wikipedia, the risks. It really is "anyone can edit" and can become a public sounding-board for negative material. Very often COI editors create an article, later regret it and seek deletion. Meanwhile they end up having a horrible experience. Some of these cases can be documented as examples, so users have all the information they need before embarking on creating a page. It could even be incorporated into the AfC process, so new editors agree and understand the risks before creating the page. Similar to a stock prospective that is required to disclose all risks to buyers. -- GreenC 14:26, 7 June 2018 (UTC)

Could you give an example of a COI editor creating an article, regretting it and later seeking deletion? I thought that pleas for articles to be deleted at Wikipedia: Articles for deletion were generally from people other than the person who created the article. Vorbee (talk) 15:37, 7 June 2018 (UTC)
That's an interesting idea, and I agree that it's worth exploring. We have Wikipedia:Your first article which discusses notability and sourcing requirements, but it doesn't really touch on the potential pitfalls associated with having a Wikipedia article. A lot of people don't fully grasp the consequences of anyone-can-edit and WP:OWN. (Of course, people who don't understand how Wikipedia works are also people who probably won't read warnings we try to give them, no matter how clear and conspicuous....)
I would probably try to stay away from "case study"-type approaches; widely-publicizing specific bad interactions and bad experiences that borderline-notable individuals and organizations have had with Wikipedia feels a bit harsh. TenOfAllTrades(talk) 19:28, 7 June 2018 (UTC)

An oft-cited essay exists at Wikipedia:An article about yourself isn't necessarily a good thing – Finnusertop (talkcontribs) 20:04, 7 June 2018 (UTC)

That's basically what I had in mind.  Done -- GreenC 02:05, 8 June 2018 (UTC)

Miscellaneous


Longest serving Wikipedians

I note that I have been contributing regularly for 14 years come the end of the month - who else has been around for 'a long time' (whether on a regular or occasional basis)? Jackiespeel (talk) 16:39, 16 May 2018 (UTC)

Congratulations! I've got nearly 13 years. --Zac67 (talk) 17:48, 16 May 2018 (UTC)
Check out the Category:Members of the Ten Year Society of Wikipedia editors and Wikipedia:List of Wikipedians in order of arrival/2001. Also Wikipedia:Wikipediholic. Rmhermen (talk) 17:49, 16 May 2018 (UTC)
Is there a 15-Year Society yet? I am a for-interest wikian. Jackiespeel (talk) 18:38, 16 May 2018 (UTC)
@Rmhermen: - How do people get added to Category:Members of the Ten Year Society of Wikipedia editors? Ross-c (talk) 10:05, 18 May 2018 (UTC)
Interesting! Where is there info about phase II & phase III? And what was the "slashdotting"? (btw, Thanks, Jackie, Zak, and esp Rmhermen! I saw your name on 2001 list! rags (talk) 14:12, 21 May 2018 (UTC)
@Ross-c: You just put the userbox on your page, see Wikipedia:Ten Year Society. --Zac67 (talk) 14:45, 21 May 2018 (UTC)
Thank you. Ross-c (talk) 18:13, 21 May 2018 (UTC)
I use {{User Wikipedian For}} to track how long I've been on Wikipedia. That template could be updated to auto-add people to categories. I have my 15 year mark coming up this year. Jason Quinn (talk) 06:49, 27 May 2018 (UTC)
Had an idea once: Using Echo and a bot to wish 50 users each day to have a happy Wikipedia birthday. I built a prototype, but figured I'd get flak for developing it. — Dispenser 10:47, 29 May 2018 (UTC)
Slashdotting = Slashdot effect. Smmurphy(Talk) 01:15, 5 June 2018 (UTC)

Expert review

WP:Tag needs professional help

WP:Tag/WP:TAG redirect somewhere else besides WP:Tags. None of these disambiguate nearly as many things as are necessary. I mean, I was trying to remember what way of putting parameters into <graph> would be equivalent to {{#tag:graph|etc}}, and looking up [[WP:#tag]] is hopeless because "#" wasn't a valid index character in 1980 and it won't be searchable in the year 198,000 either. But none of those redirects will get you to Help:Magic words, I can assure you. We need a super-duper disambiguation page to cover what I think must be hundreds of incompatible but similar-sounding meanings for the word "tag". I don't even understand all the uses of the word over at MediaWiki and how many are irrelevant to Wikipedia, they have ways of adding custom tags by which I mean stuff in < > and all sorts of fun stuff. I thought I should ask if anyone had suggestions for a way to organize it all. Wnt (talk) 23:20, 31 May 2018 (UTC)

You can certainly create such a dab page. Ruslik_Zero 08:27, 2 June 2018 (UTC)

EU Proposed Copyright changes 'Link Tax' and Wikipedia

The EU parliament is voting on proposed new copyright law (in 2 weeks no less) that may impact Wikipedia's ability to link to news websites (a proposed 'link tax' among other things such as "Making platforms directly liable for all copyright infringements by their users"). Could anyone with a background in law please review this and come back whether there is a concern for Wikipedia and if we should be worried? SoWhy?[33][34]Insertcleverphrasehere (or here) 07:24, 4 June 2018 (UTC)

This looks exceedingly dangerous, exceedingly stupid ... and is being amazingly little covered by the press. If this is half as real as it looks, then we cannot trust the media to give even basic coverage of the most crucial issues; they are not media at all, only a vicious political censorship cartel. On the other hand, there is the possibility that somehow we are being misled. I want more data than I have to work with. [note: more data is available; see below]]
To quote [35]:

France, Italy, Spain and Portugal want to force upload filters on not-for-profit platforms (like Wikipedia) and on platforms that host only small amounts of copyrighted content (like startups). Even if platforms filter, they should still be liable for copyright infringements of their users under civil law, just not under criminal law.

What is clear here is that Wikipedia needs to do an overall analysis of this ASAP, including of course relevant articles. If the story holds up, then accommodation is not an option -- they don't have unlimited money to give away because editors want to cite their sources! In that case the WMF needs to get developers and legal personnel on basic housekeeping such as:
  • Blocking all connections from the European Union
  • Globally locking all accounts that a basic AI robot detects might be associated with an EU resident
  • Permanently disbanding Wikimedia France, Wikimedia Italy, Wikimedia Portugal, etc.
  • Liquidating all equipment and real estate in the EU
It should be noted that, due to numerical factors, it won't be effective for the WMF to allow local projects autonomy to make any banning decisions; they will have to take direct authority to exclude editors of many nationalities. It may be time to make it a strictly American project with no participation whatsoever permitted from other countries, save to make copies of the data if they are able to access it. Wnt (talk) 23:45, 4 June 2018 (UTC)
See also Jimbo Wales' comment thread and the banner proposal. Wnt (talk) 23:56, 4 June 2018 (UTC)
(pinged) Sorry, copyright law is not my field but this is something the WMF's lawyers probably can and should handle and not individual Wikipedias. Regards SoWhy 09:00, 5 June 2018 (UTC)
  • What is clear here is that Wikipedia's lawyers should be left to do an analysis of this on their own time, and that what we don't need is Chicken Little-level panic over what isn't our problem here. The foundation has lawyers for a reason, and it's not our place to do their job for them. It's our job to write encyclopedia articles. Full stop. --Jayron32 01:52, 8 June 2018 (UTC)
@Jayron32: WMF weighed in on this some time ago: [36] They are listed as a sponsoring organization at https://saveyourinternet.eu/ . It is a bad proposal for Wikipedia, at the level of creation, reuse, and sourcing of materials: [37] At User talk:Jimbo Wales the founder of Wikipedia is speaking out against it. Wnt (talk) 11:02, 8 June 2018 (UTC)
I'm no expert, but from what I've heard of this, it would mean that editors such as myself would be unable to post fair use images, link to online sources (which would mean we can't cite web sources!!! Face-surprise.svg), or even quote copyrighted material. It would make it nigh-on impossible for me to write a GA video game article, as that would generally require the use of a screenshot. If I'm right about this, it is extremely serious and needs a lot more attention than it is receiving. Adam9007 (talk) 21:02, 8 June 2018 (UTC)

Language Filter

Hello,

until recently, there was a language filter extension for Wikipedia: https://chrome.google.com/webstore/detail/language-filter-for-wikip/ibgceajjjioihilfcdppneoljcaofokk?hl=ru&gl=CZ Unfortunately, its development has been stopped.

This filter was absolutely indispensable. Lots (probably hundreds of millions) of users are bilingual and want switch between two languages, or want to switch to English because articles in their mother tongue are not as good. Examples of both/either of these conditions would be: English-Swedish, English-Latvian, English-German, English-French, English-Chinese, English-Spanish, ...

The Wikipedia language bar has lots of entries that are of no relevance to 99.99% of users. E.g. even though I grew up in South-West Germany, Wikipedia articles in the local dialect (Alemannic) are of no user to me whatsoever. Same goes for dozens of official languages that are simpliy irrelevant to 99%. The Chrome extension allowed users to define languages that would subsequently show up at the top of the list, and clearly emphasized visually. This was very very helpful and one of the most frequent clicks I did on Wikipedia.

Please implement this into Wikipedia ASAP. __________

PS. On a side not, I would also like to mention that in mobile view, it would be really helpful if at any point the user had access to a menu of the contents/headlines/sub-headlines of any given article - instead of having to scroll down for minutes in the hopes of searching what he is looking for.

--80.187.105.82 (talk) 13:18, 8 June 2018 (UTC)

This is already done by the built-in software, without the need for extensions. If the languages that appear initially are not the ones the user needs, the user can click the "More" button, and select the right language, and this language will subsequently appear in the initial list.
The list of languages on mobile devices works differently, but there's a plan to make it more similar. It will take some time to develop, however.
As for your last comments, this is also how it works on the mobile site: it initially shows the first paragraph and a list of headings. Perhaps you are using the desktop view on your phone? Scroll all the way down and tap on "Mobile view". --Amir E. Aharoni (talk) 20:55, 8 June 2018 (UTC)