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

Hyperlink-internet-search.svg
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

Year range for two consecutive years

Recently a single user moved 497 249 figure skating pages that had xxxx–xx year in title to xxxx–xxxx without discussion. I requested they be moved back, but was told I should start a discussion on village pump first.

To focus the discussion, I'm particularly interested in titles of sports articles that have a two consecutive years range in the title. For consistency, I feel all these articles should use the same format, either xxxx–xx or xxxx–xxxx. Currently, from my searches, xxxx–xx is the preferred format. I believe for consistency (and since it's okay with the MOS), the figure skating should be reverted to their original page names. Alternatively, all other pages with this issue (presumably several thousand pages) should be moved to xxxx–xxxx format.
Thus I'm asking everyone what format should be used? Thank you all, 15zulu (talk) 00:01, 9 September 2018 (UTC)

Edited above to correct number of pages moved. Initially I counted the number of lines in user contributions which lists each page moved as two contributions. So total number of pages moved was 249. Sorry for any confusion, 15zulu (talk) 04:37, 6 November 2018 (UTC)

Should sports articles use xxxx–xxxx or xxxx–xx date format for two consecutive years? — Frayæ (Talk/Spjall) 09:36, 9 September 2018 (UTC)

I believe the move to 2015-2016 was justified. Years and year ranges should be spelt out in full to avoid ambiguity. Examples of problems include 2004-05 (could mean May 2004) and 1999-00 (wtf). The solution is to spell these years out in full, and for consistency it should be done always. If thousands of pages are named incorrectly, the sooner we get started with fixing them the better. Dondervogel 2 (talk) 04:59, 10 September 2018 (UTC)
  • Question is too broad WP:DATERANGE is already clear that XXXX-XX is OK: "Two-digit ending years (1881–82, but never 1881–882 or 1881–2) may be used in any of the following cases: (1) two consecutive years; ..." Its applicability for a given sport should be based on the conventions of that sport in reliable sources. Prescribing a specific format for all sports is undue. WikiProject National Basketball Association and WikiProject College Basketball use XXXX-XX.—Bagumba (talk) 05:58, 10 September 2018 (UTC)
@Bagumba: The 500 articles that were unilaterally moved are mainly about figure skating. This RfC is intended to clarify the situation on sports articles title date format before deciding to revert a non-trivial number of moves. The question is deliberately broad for overall consistency. The current guideline which says xxxx-xx "may be used" but that in general xxxx-xxxx is "preferred" is not at all helpful when dealing with such a large number of good faith moves. — Frayæ (Talk/Spjall) 08:23, 10 September 2018 (UTC)
It is a mistake to generalize it about sports. It should be dependent on the convention of the specific domain e.g. ice skating. With all due respect to WP:BB, it seems over-aggressive to change 500 articles in the same domain en masse without first asking about its background and the fact that it maybe "right". If, in fact, they made these changes and already aware of the MOS:DATERANGE exception, it also seems rash to make widespread changes from an accepted format to their self-described "preferred" style without dropping a note at the affected WikiProjects.—Bagumba (talk) 10:33, 10 September 2018 (UTC)
@Bagumba: There does not appear to be a specific guideline for skating articles and I am not aware of any notification or discussion that occured beforehand. At the same time, 500 moves is a lot to undo without a good reason. What do you suggest is done moving forward? — Frayæ (Talk/Spjall) 10:45, 10 September 2018 (UTC)
I think this is a figure skating issue, and not a general or sports issue. The orginal mass move failed WP:RMUM: It seems unlikely that anyone would reasonably disagree with the move. There was not a problem per WP:DATERANGE, which allows XXXX–XX, and it's debatable if this is an improvement when 500 some-odd figure skating articles were already consistently named. The onus is on the orginal mover to gain consensus for the new XXXX–XXXX title. This could have been done at WP:RM, but the RfC is already open, so let's go from here.—Bagumba (talk) 10:29, 11 September 2018 (UTC)
The previous RFC was regarding all year ranges xxxx–xx, so this question about sports is significantly less broad. As of right now, figure skating has no guidelines in place on Wikipedia and a single user unilaterally decided to move approximately 500 pages from xxxx–xx to xxxx–xxxx. Going by my original research, isu.org primarily uses xxxx/xx format while news sources use xxxx-xx format. The figure skating WikiProject is mostly defunct and it's likely most people editing figure skating pages will not see any question posed there. Regardless, while specific sports can have their own format, I feel that we should have generic/default Wikipedia guidelines too. 15zulu (talk) 08:08, 11 September 2018 (UTC)
FWIW, I went and left a notification of this RfC at Wikipedia_talk:WikiProject_Figure_Skating.—Bagumba (talk) 10:10, 11 September 2018 (UTC)

I noticed that not all events that span two years have the second year in their articles. 2008 NFL season is one such example. At what point do we include the second year in the title?

I'm under the impression that it's included if a significant portion of the event takes place in the second year. In other words, an event that starts in October and ends in January would probably do with just the first year. Would I be correct? --Ixfd64 (talk) 18:42, 11 September 2018 (UTC)

The conventions at Wikipedia obey the conventions outside of Wikipedia. The NFL, by convention, only calls its seasons by one year, even though the playoffs extend into the next year. Wikipedia did not invent or create this convention in the naming of its articles, it merely followed the existing convention. That's how we do everything here. We don't make up things, and then create our own reasons why we made them up, we obey what reliable sources do. --Jayron32 18:51, 11 September 2018 (UTC)
Thanks for the explanation. However, what about other events that don't have an official naming convention?
For example, suppose there is a large series of protests in Washington D.C. that lasts from October 2020 to April 2021. Would the article be titled "2020-2021 Washington D.C. protests" or just "2020 Washington D.C. protests"? --Ixfd64 (talk) 18:57, 11 September 2018 (UTC)
I have no idea. It would depend on what reliable sources were already calling the events. Show me what they are called when sources outside of Wikipedia write about them. --Jayron32 19:03, 11 September 2018 (UTC)
A descriptive title like that may be constructed owing to the absence of a single recognizable name for the series of events, or a recognizable name which is unsuitable for Wikipedia due to NPOV or BLP issues. In such cases I'd follow MOS and use 2020–21 Washington D.C. protests (don't forget the en dash!). – Reidgreg (talk) 17:35, 12 September 2018 (UTC)
  • Use whatever form the RS use – as discussed above. For the figure skating example, the ISU seems to use XXXX/XX (their web site is a mess but that's what the cited ISU sources use for example at 2015–2016 Grand Prix of Figure Skating Final). I'm not crazy about the slash but that's what they use. Kendall-K1 (talk) 00:29, 12 September 2018 (UTC)
    As I mentioned above, while ISU primarily uses xxxx/xx format, news sources for figure skating (including general news sources & figure skating specific sources) use xxxx-xx format. Also other figure skating organizations, like USFSA and Skate Canada, use dash. While one primary source uses slash, the majority of reliable secondary sources use dash. 15zulu (talk) 04:08, 12 September 2018 (UTC)
    We do not use slashes to indicate date ranges per DATERANGE. No comment on the actual concerns in this RFC, but that's a solid "we do not use slashes, ever". --Izno (talk) 16:24, 12 September 2018 (UTC)
    A slash may be used in place of an en dash for adjacent years when supported by a majority of sources, per MOS:SLASH and MOS:DATERANGE (special periods), but the former also generally discourages slashes which are one of those troublesome characters than can be interpreted as markup (along with ampersands, numeros, etc). If sources use a mix of styles, better to stay consistent with Wikipedia's broadly accepted style of xxxx–xx. – Reidgreg (talk) 17:35, 12 September 2018 (UTC)
  • Support xxxx–xx (with en dash, not a hyphen as in many of the above examples) as spelled out in MOS:DATERANGE. While 2004-05 is confusing and might be May 2004, the dash in 2004–05 indicates this is a range MOS:ENTO. The xxxx–xx format is particularly good for periods of less than a year which overlap calendar years, like fiscal year 2004–05, the winter (northern hemisphere) of 2004–05, and sports and television seasons. If it describes a period of 366 days or more, though, or if there are any clarity issues, I'd tend to use xxxx–xxxx. MOS is a guideline, and exceptions can be made if the context leads to confusion. I'm just not seeing why there would be any confusion here, or any reason to vary from the established style guideline. Adhering to the style guideline gives Wikipedia a consistent and professional look, and is meant to help avoid silly style warring. – Reidgreg (talk) 17:35, 12 September 2018 (UTC)
    • Agree. Normal English-language usage should prevail absent a much stronger rationale than has been suggested. 121a0012 (talk) 03:36, 16 September 2018 (UTC)
  • Support xxxx–xxxx - The range of xxxx–xxxx should be used, as the goal of any written text is to be as clear as possible and that presents the most clear title. The distinction the previous editor said about periods of more than 366 days would be lost on most editors; I've been editing here for years and I've never known that might be a reason for such usage. A previous example of 1999-00 is also a clear example where this just fails and looks bad. There is no title space shortage issues (titles aren't long and this isn't print), other date ranges (in non-consecutive years) use this style and per WP:CONSISTENCY would also work better and this would also eliminate the may be used [...] issue which just leads to endless page-by-page fighting over meaningless issues. --Gonnym (talk) 11:46, 13 September 2018 (UTC)
    Well put. Dondervogel 2 (talk) 12:02, 13 September 2018 (UTC)
  • Support xxxx-xx, not only for two consecutive years, but for ranges of years within the same decade, and maybe more. What's wrong with 1939-45, for example? I reject the notion that it's ambiguous. Sure, out of context 2002-05 could mean May 2005 as well as 2002-2005 in some contexts, but in most if not all cases the context makes it obvious, and xxxx-xx is just as WP:PRECISE as xxxx-xxxx, and is obviously more WP:CONCISE. I'll concede crossing a century boundary probably should use xxxx-xxxx (e.g., 1997-2002), but that should be treated as an exception, not a rule that affects all other ranges. --В²C 18:17, 25 September 2018 (UTC)
  • Support xxxx-xx for two consecutive years, for sure. For years spanning centuries, you need xxxx-xxxx. In between, don't care, doesn't matter, editors should do what they like and leave alone what they find. We should probably say exactly that in the guidelines. That's my story, but some additional points:
  • Argh, don't say reliable sources when you mean notable sources (or scholarly sources). Since it's not a question of whether xxxx-xx or xxxx-xxxx is true, reliability does not enter the equation. Readership and maybe scholarly standing do. The difference can matter in these discussions, so correct terminology is helpful.
  • But anyway, sources are used here for content. If sources all say an event occurred on the eighth day of October in 1881, we report that in the article. If the sources all use the format "October 8th, 1881" we ignore that formatting. Of course we do. We have our own style guide, and don't/shouldn't much care what style guide the editor of the Podunk Times happens to use. (Or rather: what the outside world is a data point, but only that. If virtually everyone uses a particular format, that's a reasonable argument for us using that format too -- not proof, but a reasonable argument.. If it's like 75%-25% or something, forget it, ignore that.) Official use, too.. in the spirit of WP:OFFICIALNAME, who cares if the 43 Man Squamish League uses 2017-2018? They don't get to tell us how to write. If they used 2017-8, should we use that then? 2017-018? MMXVII-III? The official use is a minor data point, but no more.
  • Big trout to the editor who changed all those pages -- this is roiling the text for no purpose, substituting their own personal idiosyncratic preference for the personal idiosyncratic preference of the person who originally titled the articles. This is pointless and stop doing that. The pages should be rolled back on principle -- it's important to support WP:BRD on principle precisely to quash this sort of behavior -- and then take the argument to talk (actually the person wanting the change should do this). FWIW I don't even think that WP:BOLD should apply to title changes in the first place -- as we see here, it can be a massive headache.
So absent a clear rule, let the person who did the actual work of the project -- you know, actually researching, writing, and titling those articles -- at least the satisfaction of titling them as they think works best. We'll give the same courtesy to you. Within reasonable guidelines -- it's reasonable to allow a between xxxx-xx or xxxx-xxxx, but not allow xxxx-xxx or roman numerals, because those are weird and hard to read. Herostratus (talk) 03:40, 26 September 2018 (UTC)
  • Who cares? use either. I respect MOS and page style discussions, but this is one of them where I think an RfC causes more effort than it is worth and we don’t need a community consensus for it. Stick with whatever the stable title is. TonyBallioni (talk) 03:45, 26 September 2018 (UTC)
    • ... an RfC causes more effort than it is worth ...: I reiterate my original point that the question posed by this RfC was too broad for the specific problem at hand, so it follows that this has not been productive.—Bagumba (talk) 04:36, 26 September 2018 (UTC)
    • Well, the stable titles for the figure skating articles for years has been xxxx–xx. As previously stated, a single user unilaterally & without discussion decided to change the format for ~500 pages. I was told that pages cannot be changed back without discussion, thus we're having this discussion. While Bagumba stated it's too broad to have generic guideline for sports, others above are discussing making guideline even broader, for all topics not just sports. Wikipedia MOS is very broad on purpose and while projects can have their own MOS, there should be some generic rules for when there isn't any project MOS. 15zulu (talk) 07:30, 26 September 2018 (UTC)
      • 15zulu, whomever told you that was wrong. Per WP:RMUM, if the title wasn't stable (read: the move took place within the last month) they should have been reverted to their original stable titles. TonyBallioni (talk) 01:23, 30 September 2018 (UTC)
  • Support xxxx-xx for two consecutive years, for sure. For years spanning centuries, you need xxxx-xxxx. per WP:COMMONNAME used in the vast majority of the main stream media discussing cricket. --DBigXray 19:32, 1 October 2018 (UTC)
  • Oppose xxxx-xx The new version is ugly and was done without consensus, and also pointless. Per BRD, this mass move should be reverted and the other editor should really be here. – FenixFeather (talk)(Contribs) 00:07, 13 October 2018 (UTC)
Um, "xxxx-xx" is the old version (and supported by previous RfC for sport seasons & similar), "xxxx-xxxx" is the new version (to which 500 pages were moved without discussion). As for the other editor, they participated in discussion at WP:RMT (which occurred after the moves) where I stated that I posted here, but feel free to contact them. 15zulu (talk) 21:50, 13 October 2018 (UTC)
Oh, oops. In that case, the pages should still be moved back to the old title because it's not nice to just move a bunch of pages like that for no reason. I would support this mass renaming if it had been done with consensus. – FenixFeather (talk)(Contribs) 20:03, 19 October 2018 (UTC)
  • Keep all the digits – elision of digits is pointless in our digital medium where space is relatively free. This kind of abbreviation does not help clarity or readability. Dicklyon (talk) 04:26, 13 October 2018 (UTC)
  • Neutral on xxxx-xx for two consecutive years (not too huge a fan, but it's fine), but for any period that spans more than two years (or two centuries), STRONGLY SUPPORT the full xxxx-xxxx. Paintspot Infez (talk) 15:38, 16 October 2018 (UTC)
  • Keep all the digits by default; permit tabular data exceptions when it's only a two-year span. The compressed format can be appropriate in tables, some lists, and maybe infoboxes to save space (I'm being purposefully rather inclusive about what "tabular data" means). It should never be used when the -xx part is -01 through -12, except when applied consistently to a bunch of other tabular data in same format in the same material, because something like "2002–03" and "1911–12" are completely indistinguishable from hyphenated YYYY-MM dates in many fonts. This also applies to "2002/03" dating as used in some contexts; always use 2002/2003. "Use what the sources use" is ridiculous; we'd end up with randomly conflicting date formats, even in the same paragraph in many cases, and this idea has been rejected many times before at WT:MOSNUM, etc. In short, if we just adopted whatever style a numerical majority of sources applied, to every style question, we would have no Manual of Style at all, and our articles on Star Trek would be written exactly the way they are at a Star Trek wiki, our legal articles would be written in impenetrable legalese, etc., etc. WP uses sources for facts, not how we write about them.  — SMcCandlish ¢ 😼  11:58, 11 November 2018 (UTC)

So to summarize above (please correct me if I misstated your opinion):

  • 15zulu (me): move should've been discussed & should be undone; RS, i.e. figure skating news articles, use xxxx-xx
  • Frayæ: any further action should be discussed before moves undone or other moves made
  • Dondervogel 2: move was good; all articles should be moved to xxxx–xxxx
  • Bagumba: move should've been discussed; each sport/project should decide based on RS
  • Ixfd64: comment/question
  • Jayron32: titles based on RS
  • Kendall-K1: titles based on RS, ISU uses XXXX/XX
  • Reidgreg: xxxx–xx
  • 121a0012: xxxx–xx
  • Gonnym: xxxx–xxxx
  • Born2cycle: xxxx–xx
  • Herostratus: xxxx–xx; move should've been discussed
  • TonyBallioni: move should've been discussed & should've been undone; stick to stable title
  • DBigXray: xxxx–xx
  • FenixFeather: xxxx–xxxx but move should've been discussed
  • Dicklyon: xxxx–xxxx
  • Paintspot: neutral for two consecutive years
  • SMcCandlish: xxxx-xxxx, with possible tables exception

Majority agree that the move should have been discussed first. Not counting myself, 5 editors stated articles should be xxxx–xx, 4 editors stated articles should be moved to xxxx–xxxx, 3 editors stated titles should be based on RS (which from my observations of figure skating news articles would mean xxxx–xx), 1 editor stated titles should be go back to stable state (i.e. xxxx–xx), and the rest were neutral/comments/questions. From that I conclude: figure skating articles should be moved back to xxxx–xx and any similar moves should be discussed first. Further thoughts? Thanks, 15zulu (talk) 11:03, 29 October 2018 (UTC)

@15zulu: Thanks for taking the time to summarize this. As far as my position, since the move wasn't discuss and WP:DATERANGE allows xxxx-xx, the affected figure skating pages should revert back to their original xxxx-xx, given that there is no consensus for xxxx-xxxx. This is consistent with WP:RMUM: If you disagree with such a move, and the new title has not been in place for a long time, you may revert the move. Regards.—Bagumba (talk) 10:23, 31 October 2018 (UTC)
  • xxxx-xx - Such a big and potentially controversial move should've been discussed first. 4 digits are not necessary in the second year in the range, especially for consecutive years. Matt14451 (talk) 13:08, 4 November 2018 (UTC)
  • Use either format for consecutive years, as allowed by MOS. Source conformity can be a weighing factor. Undiscussed mass-moves should be reverted, and a standard WP:RM discussion should be opened. — JFG talk 23:51, 4 November 2018 (UTC)
  • xxxx-xx is clear and concise. SportingFlyer talk 04:56, 5 November 2018 (UTC)
  • The discussion regarding RS is irrelevant IMO because this is about writing style. We have our own house style, intended to promote uniformity across the English Wikipedia. For this house style my preference was and remains xxxx-xxxx, across the board, because it removes all ambiguity (there could be exceptions permitting xxxx-xx, but only where space is of the essence). Second best is xxxx-xx, again for all articles. The present mix of xxxx-xxxx for some articles and xxxx-xx (or even xxxx/xx?) for others is untidy and unencyclopaedic, and fails to achieve the objective of uniformity. Dondervogel 2 (talk) 15:46, 9 November 2018 (UTC)
  • There is now a proposal at WT:MOSNUM to amend the MoS to bar the use of YYYY-01 thru YYYY-12 in articles and titles ("unless in close proximity to other ranges in this format that end with numbers outside the 01–12 range"). Wikipedia talk:Manual of Style/Dates and numbers#Clarifying date ranges in YYYY–YY format. 80.41.128.3 (talk) 12:53, 10 November 2018 (UTC)
  • Per WP:NAMINGCRITERIA: Article titles are based on how reliable English-language sources refer to the article's subject. For the most part, people searching for a season article will most likely be searching under its common name, not a wikipedia MOS guideline for a numbering/dating system. Vice versa, people outside of that region's dating style probably will not be searching for the article at all if they do not already know the common name. Many seasons that last between consecutive years are most commonly called xxxx–xx (in North America at least). So based on that, using XXXX–XX when used in the majority of reliable source meets the Recognizability, Naturalness, Precision, and Conciseness pillars of WP:NAMINGCRITERIA as well as the WP:COMMONNAME. Furthermore, most of the articles that are called "XXXX–XX season" clarify the extent of the time frame with phrases in the lead (ex: the season lasts from October 2018 until April 2019) and a duration parameter in the infobox, which should clear up any potential confusion to meaning of the title. I am pretty sure that is exactly why the "consecutive year exclusion" exists in DATERANGE in the first place. Yosemiter (talk) 23:28, 11 November 2018 (UTC)
    What they search for is irrelevant; redirects exist for a reason. We have five, not one, naming criteria and they're all co-equal. If the most common name fails one or more of them, we use the second-most common. More to the point here, however: WP:AT is not a style policy. Never has been, never will be. Otherwise we would have no MoS, or at least nothing in it could ever apply to titles. Yet in reality we cite it about 100 times per day at RM, and we do in fact apply MoS to titles; it's the most common ruleset we apply to titles (probably more MoS than AT arguments are applied, and accepted, at RM, since moves more often involve style twiddles like over-capitalization or mis-hyphenation than a completely wrong name having been chosen). The naming conventions pages that deal with style, such as WP:NCCAPS, are simply summaries of MoS points as they apply to titles, and are derived from MoS, not vice versa. In short, you do not understand our title policy, the applicability of our guidelines, or how WP article titling works.

    We do not, in fact, apply reasoning like "If the majority of sources spell something the XYZ way, then WP must do it too." We routinely, nearly daily, reject that reasoning. For a style matter to be "imposed" on Wikipedia by off-site stylization, the style in question must be found with nearly complete consistency in all reliable sources for the case in question (e.g., virtually no one writes "Ipod" in professional-grade publications, thus we write "iPod" like everyone else does, despite it being weird from an English-language-norms perspective). We never, ever have that sort of near-unanimous consistency in sources for the date formatting of sports seasons, TV-show seasons, election cycles, fiscal years, or any other circumstance in which people want to use confusing and inconsistent abbreviated date formats. The only practical use for them on Wikipedia is in tabular data, and only then when space is at a premium, and enough of them are used in one place that no one can be confused into thinking that something like "2002–03" is a YYYY-MM date.

    The rather recent (and recurrently controversial) "consecutive year exclusion" exists in DATERANGE because people who don't understand any of this stuff have gnashed their special-interest (mostly sports wikiproject) teeth long enough that they've tendentiously worn out reasoned opposition and gotten their pet peeve inserted. I'll happily bet real money this will not last, because the result is a stupid, reader-confusing, editor-frustrating mess that serves no one's interests. It serves no interest at all other than making a handful of editors happy that they get (for now) to mimic what they see in a football or TV magazine. Cf. actual policy at WP:NOT#NEWS: "Wikipedia is not written in news style." That includes sports and entertainment journalism, and that, in turn, includes their lazy, ambiguous date formatting.

    PS: I say all this as someone who founded a sports wikiproject, and regularly edits TV-related articles. This isn't about topics, but about the specialized-style fallacy, the nonsense idea that sources reliable for facts about a topic are somehow the most reliable sources for how to write about that topic for a general audience, when they are really often the worst, being representative of only how specialists write for other specialists in the same area (be that professionals in science/law/etc., or fans in sports/sci-fi/hip-hop/etc.). Failure to understand that specialist writing does not dictate WP writing style is the proximal cause of about 90% of style-related squabbling on Wikipedia.
     — SMcCandlish ¢ 😼  20:14, 13 November 2018 (UTC)

RfC: Proposed deletion policy

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

  • I don't see any consensus in the discussion to change the wording of the concerned policy.Amidst the infighting between (1):- being transparent, (2):- the concept of article-ownership, and (3):- imposition of over-bureaucratic means, none has managed to stay ahead as a clear winner.
  • Among all the proposals that were put forward, Proposal 2 fared the best but many specifically opposed on the grounds of addition of the phrase of significant contributors and sans the addition, it's fairly equivalent to what currently exists.
  • The community has firmly rejected ☒N:-
  • That an editor nominating an article for proposed deletion is required to notify the article's creator or any significant contributors.
  • That there is any need to explicitly mention the specific circumstances under the purview of which, ideality may be deviated from.
  • That there exists any mandatory requirement to provide a rationale for de-prodding an article.(This is not a license to engage in mass-de-prodding(s) and test the limits.)
  • And some 'outlandish' proposals like abolishing the entire proposed deletion process, preventing article-creators from deprodding their own creations and limiting PROD to a semi-automatic tool.

WBGconverse at 11:47, 8 November 2018 (UTC)


There is an issue currently with the proposed deletion policy (PROD) which is causing some confusion and ambiguity. In January this year, user Green Giant boldly edited the policy to simplify the wording, but in doing so, changed the suggestion to notify article creators to a requirement. It appears as though this was not compelled by any discussion to make that change, and it was also certainly in good faith and possibly not intended to have changed the meaning in this way. Up until this change, our various deletion policies all suggested notifying article creators and significant contributors as a courtesy, but did not require it (and requiring AfD notification is a perennial proposal). With Green Giant's change, PROD stands out as the only deletion process requiring notification. The change has also not been well publicized or recognized - this post is inspired by an editor reported to ANI for failing to notify, and several editors and administrators responding that they were not aware of the change.

I am proposing a three-pronged discussion/straw poll to determine the community's current opinions about proposed deletion. Please comment in one of the sections below. Ivanvector (Talk/Edits) 13:33, 24 September 2018 (UTC)

Also, just because it's come up a few times already, note that WP:BLPPROD is a separate policy from WP:PROD, with different criteria and different processes. I'm not saying anyone shouldn't talk about that other policy, I'm just making a note of it to avoid what might end up being a confusing discussion. Ivanvector (Talk/Edits) 11:29, 25 September 2018 (UTC)

PROD proposal 1: Require notification

The editor nominating an article for proposed deletion is required to notify the article's creator or any significant contributors.

  • Oppose. Reyk YO! 13:40, 24 September 2018 (UTC)
  • Oppose. Since nobody owns any Wikipedia article, then why should it be required to notify someone just because they happened to create the first revision? Also worth noting is that, a times such editor (who made first revision) may have long left Wikipedia or many editors contributed to the article more than them —thus more worthy of notifying. Making this notification a requirement will just add another layer of bureaucracy to already ineffective process and more importantly, it will go further to undermines the authority of OWNERSHIP policy. –Ammarpad (talk) 13:55, 24 September 2018 (UTC)
  • Oppose, because there will be times this isn't feasible, but they really should be making every effort to notify the creator. And "or any significant contributors" is bad here for two reasons. Firstly, but less importantly, it should be "and any other significant contributors". Secondly, the term "significant" is undefined; that doesn't mean we should spend months defining it, it means we are better off not using it. If we do end up going with this crappier option it should just say "the article's creator". Fish+Karate 13:58, 24 September 2018 (UTC)
  • Oppose per Ammarpad. Suggesting is a significant difference from mandating; one's a matter of courtesy, and the other's a matter of rule creep and WP:BURO. Thank you for noting that this seems to have been done by accident. Nyttend backup (talk) 14:06, 24 September 2018 (UTC)
  • Support The PROD process does not initiate a discussion and so it's too easy for a proposal to pass unnoticed by anyone. As the process is frequently used for new articles created by new editors, the disappearance would seem quite mysterious to such editors and there would be no note on their talk page to explain what had happened and how they can appeal at WP:REFUND. Silent removal would be uncivil per WP:BITE. Andrew D. (talk) 14:13, 24 September 2018 (UTC)
  • Oppose Creators don't have any more claim to an article than any other contributor. If it's mandated that creators be informed, other contributors should be informed as well, but someone must then decide who is worthy of being notified. I would be annoyed to receive a talk page message every time an article I edited was PRODed. Natureium (talk) 14:26, 24 September 2018 (UTC)
  • Oppose per WP:GRAVEYARD. At the point where you PROD an article, the creator may have been indef blocked. What would be the point of notifying them, other to rub salt in wounds? Ritchie333 (talk) (cont) 14:42, 24 September 2018 (UTC)
  • Oppose Mainly for the required to notify any significant contributors. As Natureium said, they would be annoyed every time an article that they edited was PRODed. Twinkle has the feature to notify the article creator of a PROD, and I think it is good practice to do so. But requiring it of people is needlessly bureaucratic. Jip Orlando (talk) 14:46, 24 September 2018 (UTC)
  • Support per Andrew Davidson. The PROD process already lacks adequate scrutiny, and this lack of scrutiny will be even worse if the creator and contributors are not notified. It would be even better to place a notice of relevant PRODs on each deletion sorting list, but this rarely seems to happen. James500 (talk) 14:54, 24 September 2018 (UTC)
Here is an example of a notification that was so out of place, it was reverted and the talk page protected. It was AfD rather than PROD, but that's not really the main point - mandatory notifications would mean we would need to post in the talk page of globally banned editors, which by definition they can't do anything about. Ritchie333 (talk) (cont) 15:43, 24 September 2018 (UTC)
We don't have to choose between "notify everybody no matter what" and "you don't ever have to notify anyone". We can say "notify the creator except, obviously, if they cannot participate in the discussion (indefinitely blocked, community banned, globally banned, deceased...)". — Rhododendrites talk \\ 15:49, 24 September 2018 (UTC)
  • Support as long as it's an "or", and not a requirement to notify everyone. As long as somebody sensible gets a notification (namely, not the person who created the redirect, but the person who actually created the article), it doesn't have to be comprehensive. --SarekOfVulcan (talk) 15:04, 24 September 2018 (UTC)
  • Support - I've never found any of the oppose rationales convincing at all. We can say "required ... unless there is an obvious reason not to, such as being blocked or banned". That's the exception. A suggestion isn't strong enough when it should be done in nearly all cases except for obvious exceptions. It's not because it's an ownership thing, it's common courtesy because we're editing in a community of editors and all dedicate considerable time and effort to the encyclopedia. There is literally no downside whatsoever to this proposal, if handled with obvious exceptions. Reading more than the headline for proposal 2 (which seems contradictory to the heading), it seems what I'm saying is also very close to that. Require (with exceptions).Rhododendrites talk \\ 15:38, 24 September 2018 (UTC)
  • Support (with exceptions) for creators only. There may be some difficulty in defining who is a "significant" contributor and a requirement shouldn't stop the process. --Enos733 (talk) 16:32, 24 September 2018 (UTC)
  • Oppose per Ritchie333 and my argument below: there are legitimate reasons not to notify, additionally, I feel sorry for any admin reviewing expired PRODs after this: having to check article history plus notification history would add a lot of unnecessary time and to be blunt, it would prevent me from ever looking at CAT:EX (not that I am particularly active there, but I wouldn’t even check at that point.) TonyBallioni (talk) 16:41, 24 September 2018 (UTC)
  • Support creator, Oppose significant contributors. --Guy Macon (talk) 16:51, 24 September 2018 (UTC)
  • Support with exceptions for creators only. Obvious exceptions for users that are indefinitely blocked, community banned, globally banned, or deceased, for users that have indicated on their talk or user page that they do not want to recieve such notifications or that they have retired from Wikipedia, or for cases where notification would be impossible due to user talk page bans or protection levels. --Ahecht (TALK
    PAGE
    ) 17:00, 24 September 2018 (UTC)
  • Just as a note “support with exceptions” would have the disadvantage of making this unenforceable: people seem to forget that admins have to manually check all of this stuff. Either people would ignore this as dead letter the instant it was approved or the exceptions wouldn’t exist because it’s too much work to check all of them. TonyBallioni (talk) 17:09, 24 September 2018 (UTC)
  • people seem to forget that admins have to manually check all of this stuff - why? I don't see that as part of the proposal. The point is to make sure notification is part of the process, and that there is grounds to object if someone routinely prods without notifying. All of this could be made a simple part of the prod template to display differently if no notification parameter is present, and automated with Twinkle. If someone doesn't notify, it's a behavioral issue of not following process. Refund is already cheap, so there's not much difference to refund due to non-notification as with refund for any other purpose. In short, I don't see why this should change anything other than that which can be automated, and to give some teeth to the requirement that can be enforced at ANI, etc. where necessary. — Rhododendrites talk \\ 17:14, 24 September 2018 (UTC)
  • Because we can’t delete unless the policy requirements are met. If no notification existed, we’d then have to check if one of the exceptions existed. This is a waste of admin time for a non-issue: the overwhelming number of people already use Twinkle on its default settings. What this proposal is suggesting is adding additional work (and if we have exceptions, two additional layers of work) to solve a problem that quite frankly doesn’t exist. TonyBallioni (talk) 17:19, 24 September 2018 (UTC)
  • Support for creators only. It's simpler to have a requirement without exceptions, if a creator has died etc there may well be editors watching te talk page to help with any issues. However, hardly anyone bothers to alert major contributers so that can be left out because if they are interested in the article they should have it on their watchlist so will be informed that way provided there is a proper edit summary, thanks Atlantic306 (talk) 17:20, 24 September 2018 (UTC)
  • Oppose because watchlists are a thing. --Jayron32 17:28, 24 September 2018 (UTC)
  • Oppose - nobody OWNs an article (and the creator might not be the most significant contributor), watchlists exist for a reason, and there are multiple exceptions in which notification is not required and might even constitute rubbing in someone's face (retired user, blocked user, TBANed user, etc.). Icewhiz (talk) 17:33, 24 September 2018 (UTC)
  • Oppose "Suggest" is exactly right, and applies to the article's creator. (I believe that Twinkle does this automatically.) I STRONGLY oppose any requirement to search through the article's history and notify significant contributors. --MelanieN (talk) 17:48, 24 September 2018 (UTC)
  • Oppose in favor of Option 2 below. shoy (reactions) 18:01, 24 September 2018 (UTC)
  • Support (with a remark): It is so annoying to get your articles deleted. (I have experienced it.) (By your I mean those that have spent lots of time on writing them.) Thus, the most involved (remark: how do you define that?) should be notified so that they can correct or add something to the articles. Per W (talk) 18:51, 24 September 2018 (UTC)
  • Oppose notifying the article creator should be recommended and is good practice, however I don't think even that should be an absolute requirement. Earlier this year I nominated a large number of articles created by a now-banned user for deletion, and I didn't bother notifying them. "Significant contributor" could be a lot more people and it's a lot less likely that they would care. That term is likely to be interpreted as anybody who made non-trivial changes to the article (more than reverting vandalism, fixing typos, formatting templates, etc). Hut 8.5 19:16, 24 September 2018 (UTC)
  • Oppose in most cases If the article is BLP prodded and has been created within 7 days or a few weeks, you can make it a requirement to notify the creator of the article. But for most other PROD cases, it's best to not make it a requirement to notify the creator due to as stated above the creator of the article may not be as big of contributor to it as others and may not even be active anymore. PROD is supposed to be non controversial, adding a requirement to notify the creator of a PROD sort of takes away from that IMHO. JC7V-constructive zone 19:43, 24 September 2018 (UTC)

@Ivanvector, I Struck the BLP Prod part. I won't talk about BLP prods here again. My bad. If the prodded article is new (created within a week or so) I believe that notifying the creator should be mandatory because at that point they are more attached to the article than they would be if they had created 10 years ago. However if the article is like 5 years old for example and has many many contributors who did more work on the article than the creator or if the creator is gone, then it makes no sense to be required to contact the article's creator. Users who PROD an article should use a case by case basis for deciding whether to notify the creator of the article and not have to officially notify them. Twinkle users can still notify the creator automatically and some users can still do it because they want to not because they have to. No more Bureaucracy. JC7V-constructive zone 19:53, 24 September 2018 (UTC)

The way I read WP:BLPPROD, notification is required. But BLPPROD is also a separate policy. Ivanvector (Talk/Edits) 19:46, 24 September 2018 (UTC)
  • Oppose as instruction creep. Xxanthippe (talk) 22:33, 24 September 2018 (UTC).
  • Oppose as instruction creep, and based on the idea that people do not own the articles they created nor any contributions they made. People are responsible to pay attention to the parts of Wikipedia they are interested being involved in. We should not add extra burden to those seeking to clean up the cruft that constantly accumulates. HighInBC Need help? {{ping|HighInBC}} 01:16, 25 September 2018 (UTC)
  • Oppose due to the "significant contributors" part and due to instruction creep. This is generally irrelevant anyway because all the tools we use at New Page Patrol automatically send notifications to the creator. — Insertcleverphrasehere (or here) 01:57, 25 September 2018 (UTC)
  • Oppose: instruction creep and does not work in some cases. --K.e.coffman (talk) 05:52, 25 September 2018 (UTC)
  • Support but only for creators because this is easy to do automatically--Twinkle is the simplest way. Anything else is too complicated and debatable. I suppose we could develop a way to programmatically that would identify everyone who had contributed more than x% of the content or Y bytes, but I cannot see it would be worth the effort. There are higher priorities for development. DGG ( talk ) 07:39, 25 September 2018 (UTC)
  • Support but only for creators (this is sufficient, and mandating more would be unnecessarily burdensome). Per about support arguments, basically. AfD is different because that's a discussion with a lot of people (and FWIW IMO you should notify the creator -- the script does it automatically I think. Since you should there's no reason to add a except if you're lazy or don't care exemption, which is what making things optional does, usually). I mean, I haven't seen a compelling argument that "Enh, I just can't be bothered to notify the creator and I really don't give a rat's ass about that" should be valorized. If it shouldn't be valorized, why should it be even allowed? It there's some particular reason to not notify the creator -- she's banned, or is a troll, or hasn't edited in seven years -- probably no one will object not notifying, although again I don't see the harm in notifying the creator even then.
But... kudos to the OP for bringing this up, and trouts to the person who made the change without discussion. I think that WP:BRD applies here, and the previously existing state is the default, and the proposition to change (to a requirement) should have to show consensus support for the change to not be rolled back (which I'm not seeing this consensus to change so far). I say this as someone who supports the proposition on the merits, on the basis that procedure should applied correctly here, and I call on the closer to note this. Herostratus (talk) 09:04, 25 September 2018 (UTC)
  • Oppose - I think the prior version that it is a suggested course of action fits the vast majority of the parameters. I would have stated support, with the caveats of some of the above editors, but I think that that position is most well served by returning it to the suggested phraseology. In addition, I believe that currently both the curation tool and TW automatically send notification to the first person to work on an article. I also feel that this change might produce an undue burden on an already stretched thin admin corps.Onel5969 TT me 13:45, 25 September 2018 (UTC)
  • Oppose—practically the point of proposed deletion is to reduce bureaucracy by being simple for the "obvious" cases. Requiring notification undermines that simplicity. PRODs can even be opposed after the fact and undeleted on request; I don't see the point of adding needless requirements to such an otherwise minimal, non-binding process. {{Nihiltres |talk |edits}} 14:20, 25 September 2018 (UTC)
  • Oppose While this si agenerally a best practice it should not be a hard-and-fast requirement, for the various reasons already stated above. Beeblebrox (talk) 18:45, 25 September 2018 (UTC)
  • Oppose Simply put, we do not require editors to notify the article's creator when the article has been nominated for deletion. The {{prod}} tag should not by any different. —Farix (t | c) 18:50, 25 September 2018 (UTC)
  • Oppose We should not be making creator notification mandatory. — AfroThundr (u · t · c) 22:28, 25 September 2018 (UTC)
  • Support for creators, but 'significant conributors' can be hard to define, so wouldn't support mandatory for those -- Whats new?(talk) 07:11, 27 September 2018 (UTC)
  • Support with common sense exceptions (e.g. long-term blocked users; users who haven't edited in 5 years), and if there are other clearly identifiable significant contributors then they should be notified as well. This requirement should be applied to every deletion process without exception. Thryduulf (talk) 12:21, 27 September 2018 (UTC)
  • Oppose as instruction creep and cause no one owns a given page. -DJSasso (talk) 15:48, 27 September 2018 (UTC)
  • Oppose per above. -FASTILY 05:54, 28 September 2018 (UTC)
  • Oppose. I am not willing to clutter the talk page an inactive editor who hasn't been around for years, and I will not be compelled to do it. —Xezbeth (talk) 09:16, 28 September 2018 (UTC)
  • Oppose - It's common sense really .... It's courteous to notify that creator but on the other hand it's pointless notifying someone who's either indeffed or inactive, You simply take the common sense approach here. –Davey2010Talk 22:17, 29 September 2018 (UTC)
  • Support only for creators - contacting significant contributors is a significant addition to the complexity of nomination. Really "creators and sig contributors" and "creators only" should have been made as separate propositions. Additionally, this would make it very hard to nominate via script (twinkle etc), since it isn't designed for contacting more than the creator. Nosebagbear (talk) 22:45, 29 September 2018 (UTC)
  • Support with common sense-for the creator and if an editor has a lot of edits on an article they could and probably should be notified. Its just polite and respectful in a community that should be supportive of collaborative principles. If we think of courtesy,ie the other guy first, perhaps this is a less difficult situation to decide on.(Littleolive oil (talk) 17:21, 6 October 2018 (UTC))
  • Oppose per WP:OWN. If an article is that important to someone, they'll have it on their watchlist. Number 57 20:13, 9 October 2018 (UTC)
  • Oppose As per WP:OWN, if someone cares about the article, they'll have watchlisted it. MoonyTheDwarf (BN) (talk) 19:25, 10 October 2018 (UTC)
  • Oppose with the current wording which appears to be a device to suppress PRODs, but PRODs are sometimes useful. Robert McClenon (talk) 19:14, 15 October 2018 (UTC)
  • Oppose There should be no reason to notify the creator when their opinion likely won't matter anyway (not like with AFD's which can be improved in the spirit of WP:BEFORE). As to significant contributors, if "their" article gets deleted, they can always request it to be restored.—Mythdon (talkcontribs) 08:20, 17 October 2018 (UTC)
  • Oppose, mostly per WP:OWN. A courtesy notice is nice in many cases, but requiring it goes to far. That's why you have watchlists. And WP:AALERTS. Headbomb {t · c · p · b} 02:04, 25 October 2018 (UTC)
  • Support Per WP:OWN. Hawkeye7 (discuss) 02:32, 25 October 2018 (UTC)
  • Oppose per WP:OWN.The article creator has no greater rights over 'their' article than any of the other editors or indeed anyone else. Amisom (talk) 19:11, 28 October 2018 (UTC)
    The proposal is not about giving anyone "rights", it is about facilitating a collaborative editing process. Hawkeye7 (discuss) 05:19, 29 October 2018 (UTC)
    @Hawkeye7: OK, then read my comment as if it said: Oppose per WP:OWN.The article creator has no greater standing in relation to 'their' article than any of the other editors or indeed anyone else.
  • Support Yes there is WP:OWN, but I don't think we need to make it any easier to scare away new article creators. SL93 (talk) 01:41, 29 October 2018 (UTC)
  • Support basic fairness. I can think of no instances where it would be inappropriate,; if the creator were in bad faith, the articles should be deleted at CSD, not PROD. DGG ( talk ) 03:43, 29 October 2018 (UTC)
  • Weak support. Support the first part (creator), but requiring to identify major contributors, ugh. Too much work. Maybe 'creator or a major contributor', giving the nom a choice? --Piotr Konieczny aka Prokonsul Piotrus| reply here 08:52, 29 October 2018 (UTC)
  • Oppose. If no one comes to defend the article, its utility is doubtful. Staszek Lem (talk) 18:34, 29 October 2018 (UTC)
  • Oppose – This requirement would only encourage knee-jerk de-PRODding, thus defeating the whole purpose of the PROD process. — JFG talk 13:08, 3 November 2018 (UTC)
  • Oppose - Nabla (talk) 19:09, 3 November 2018 (UTC)
  • Oppose. This would complicate a process that is supposed to be simple; and would be actively countrproductive in the sense that "is anyone actually watching this article?" is a valid thing for the PROD process to test. An article with no active eyes on it has no chance of improvement, which lends weight to any issues identified in the PROD. Beyond that, the addition here was accidental and clearly deviates from long-standing policy; nobody has actually identified any existing problems with the prod process that this change would solve. --Aquillion (talk) 09:48, 4 November 2018 (UTC)
  • Comment. What would be really nice would be if someone could develop an enhancement that flags articles in your watchlist that are currently at AfD or have a prod tag on them. Determining which editors who are still active might care about an article isn't straightforward, and flagging articles in watchlists is perhaps the best option for making interested editors aware. --Michig (talk) 09:55, 4 November 2018 (UTC)
@Michig: Jolly good idea; perhaps open a new thread with this suggestion? — JFG talk 23:46, 4 November 2018 (UTC)
I've made a proposal here. --Michig (talk) 06:58, 5 November 2018 (UTC)
  • Oppose, bureaucracy and unclear definition of major contributors. Stifle (talk) 10:04, 5 November 2018 (UTC)
  • Oppose, it's good practice, it's courteous, but it shouldn't be elevated into a procedural loophole. Cabayi (talk) 11:10, 6 November 2018 (UTC)

PROD proposal 2: Do not require notification

The editor nominating an article for proposed deletion should attempt to notify the article's creator and any significant contributors, as a courtesy.

  • Support the "creator" bit, Oppose the "significant contributors" bit. Reyk YO! 13:40, 24 September 2018 (UTC)
  • Support, as the better of the two options, although "should notify the article's creator wherever possible" is better. No need for the nebulous "any significant contributors" (and if it has to be there, and I think it should not, it should say "any other"). Fish+Karate 13:54, 24 September 2018 (UTC)
  • Support, I put myself in this section too. I'll also point out that PRODded articles can be automatically REFUNDed, so an editor who finds out their article was deleted in this way can just go ask for it back. But (also for this reason?) I have leanings toward deprecating the process too, which is why I brought it up here. Ivanvector (Talk/Edits) 14:08, 24 September 2018 (UTC)
  • Oppose If the article is removed and there's no notice then nothing left behind. One of the main principles of a Wiki is that there should be transparency and a good audit trail. Andrew D. (talk) 14:16, 24 September 2018 (UTC)
  • Oppose, specifically the "significant contributors" part, because this requires some method of determining who is a significant contributor and who is a lesser contributor and this gets murky. Natureium (talk) 14:26, 24 September 2018 (UTC)
  • Oppose for the 'significant contributors.' I'd support if the significant contributors clause was omitted because I see notifying the creator as good practice. Jip Orlando (talk) 14:48, 24 September 2018 (UTC)
  • Neutral SarekOfVulcan (talk) 15:05, 24 September 2018 (UTC)
  • Support (2nd choice) - My view, described above, is that it should be part of the PROD instructions to notify the creator, with obvious exceptions (sock puppet, community banned, etc.). I.e. a smidgen stronger than the "should attempt to notify" here. BTW the heading makes it sound like this second proposal is just the opposite of #1. "Do not require notification" doesn't imply "should attempt to notify". Suggest changing it. — Rhododendrites talk \\ 15:41, 24 September 2018 (UTC)
  • Support the above is added bureaucracy and there are legitimate reasons not to notify: as an example non-G5 spam creations by socks. I notify every time but this, and I think there are very good reasons not to notify blocked users. Also, oppose the and significant contributors bit: it will never be followed because Twinkle doesn’t do it, and Twinkle is how most of these happen. TonyBallioni (talk) 16:38, 24 September 2018 (UTC)
  • Oppose significant contributors, Support creator. --Guy Macon (talk) 16:52, 24 September 2018 (UTC)
Throwing out a scenario: at the ANI I mentioned, the reporter was annoyed that another editor PRODded an article they had written which was an expanded redirect. Technically (and as Twinkle sees it) the "article creator" is the editor who made the redirect, not the reporter who made all of the significant contribs. Ivanvector (Talk/Edits) 17:49, 24 September 2018 (UTC)
  • Support as a non-required courtesy. Significant contributors are actually more important than creators (there are a number of prolific creators running about creating stubs...).Icewhiz (talk) 17:37, 24 September 2018 (UTC)
  • Support as a non-required courtesy for the original author. Leave it up to the nominator whether to notify any other significant contributors. --MelanieN (talk) 17:51, 24 September 2018 (UTC)
  • Support - Better than Option 1 above, reduces bureaucracy. shoy (reactions) 18:00, 24 September 2018 (UTC)
  • Support creator, oppose significant contributors unless the wording is tighter. If that means someone who expanded it from a stub to a start class article then OK, if it means someone who added a sentence once then no. Hut 8.5 19:19, 24 September 2018 (UTC)
  • Oppose as written the word should implies a requirement and goes directly at odds with as a courtesy. Something like "The editor nominating an article for proposed deletion may attempt to notify the article's creator or other contributors if they feel it may increase the chances of the article being improved to the point that it benefits the project." HighInBC Need help? {{ping|HighInBC}} 01:19, 25 September 2018 (UTC)
  • Oppose "should" implies a requirement. Figuring out who is and who is not a 'significant contributor' is arbitrary. Side note: the 'creator' should be the creator of the first non-redirect revision. — Insertcleverphrasehere (or here) 02:00, 25 September 2018 (UTC)
  • Support but I thought this was already policy. Personally, I regard not trying to do so as a grave error in basic fairness. There are situations in CSD where notification would be counterproductive, but they do not apply to prod. DGG ( talk ) 07:41, 25 September 2018 (UTC)
  • Support If there are significant contributors then their interest can be assumed. Graeme Bartlett (talk) 08:39, 25 September 2018 (UTC)
  • Oppose - as per Natureium and Insertcleverphrasehere. Cwmhiraeth (talk) 10:15, 25 September 2018 (UTC)
  • Support for the article's creator, oppose for significant contributors (isn't that what watchlists are for?). Onel5969 TT me 13:48, 25 September 2018 (UTC)
  • Weak oppose: per HighInBC, "should" is normative and implies a requirement; "is encouraged to" or similar would be OK. While it's best practice, PROD is so lightweight, and easily reversible, that it's not hugely important if contributors aren't directly notified. {{Nihiltres |talk |edits}} 14:25, 25 September 2018 (UTC)
    In my experience, in Wikipedia policy, "should" is most often interpreted as a strong suggestion, not a strict requirement. "Must" is a requirement. Ivanvector (Talk/Edits) 15:23, 25 September 2018 (UTC)
    When possible, we should avoid it being necessary to interpret policy with domain-specific norms. Phrases like "is encouraged to" lack the ambiguity of "should" you're apologizing here; we should avoid needless ambiguity. {{Nihiltres |talk |edits}} 15:07, 27 September 2018 (UTC)
  • Counter proposal Adopt the same language used at Wikipedia:Articles for deletion#substantial. —Farix (t | c) 18:56, 25 September 2018 (UTC)
  • Support Notifications to the creator should be optional. — AfroThundr (u · t · c) 22:28, 25 September 2018 (UTC)
  • Support. PROD is a useful process and notification is a nice courtesy, but mandatatory notification would be inappropriate bureaucracy. Note to closer: To avoid redundant postings, please count this !vote as an oppose on each of the other sections. Thx. Alsee (talk) 05:53, 27 September 2018 (UTC)
  • Support (oppose all others). PROD should be an all-around lighter option to the nom than AfD, which does not require notification. There are also cases where notification might be totally unwarranted (permanently blocked users, retired users, deceased Wikipedians). Listing all such exceptions would be WP:CREEP. – Finnusertop (talkcontribs) 07:26, 27 September 2018 (UTC)
  • Oppose per above. Strongly implies requirement, which is what I'm opposing above as well. -FASTILY 05:54, 28 September 2018 (UTC)
  • Support again per common sense and courtesy - Notify those who are active if you want, Don't bother for those inactive or indeffed. –Davey2010Talk 22:20, 29 September 2018 (UTC)
  • Support per WP:OWN. Number 57 20:13, 9 October 2018 (UTC)
  • Support - This is normally done for the nominator if they use Twinkle and it doesn't become confused. Robert McClenon (talk) 19:15, 15 October 2018 (UTC)
  • Oppose per my reasoning in proposal #1.—Mythdon (talkcontribs) 08:21, 17 October 2018 (UTC)
  • Support in principle, but I don't agree with the proposed wording. "You may notify the article's creator and other contributors..." seems better than should attempt. Headbomb {t · c · p · b} 02:08, 25 October 2018 (UTC)
  • Support Everyone should be doing this already. Hawkeye7 (discuss) 05:21, 29 October 2018 (UTC)
  • Support, as less bad of the options - Nabla (talk) 19:10, 3 November 2018 (UTC)
  • Support though "should normally notify" would be better than "should attempt to notify". Somebody who does a bunch of prods and doesn't notify a couple of blocked or vanished editors should be normal and easy to tell from someone who prods a slew of articles and never notifies anyone. ϢereSpielChequers 00:21, 4 November 2018 (UTC)
  • Oppose, adds instruction-creep and seems actively counterproductive. Articles require maintenance - every article should have eyes on it. If an article doesn't, then I would usually take that as one indication that it being prodded is probably a good thing. --Aquillion (talk) 09:45, 4 November 2018 (UTC)
  • Oppose; identifying major contributors is too significant a burden. Stifle (talk) 10:04, 5 November 2018 (UTC)

PROD proposal 3: Deprecate PROD

Boldly closing this proposal early as it doesn't have a snowball's chance in hell of passing. IffyChat -- 09:29, 16 October 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 proposed deletion process is deprecated and marked historical; all nominations for article deletion are done through articles for deletion, except in cases where one of the criteria for speedy deletion apply.

  • Oppose. Reyk YO! 13:40, 24 September 2018 (UTC)
  • Oppose, would be a step backwards. Fish+Karate 13:47, 24 September 2018 (UTC)
  • Support Deletionists keep trying to exploit and abuse the process. It is supposed to be for uncontroversial deletions but is repeatedly used to try to delete good faith contributions without discussion. Andrew D. (talk) 14:18, 24 September 2018 (UTC)
Care to provide a concrete example? Or do you just want to attack a bunch of unnamed "deletionists"? Hijiri 88 (やや) 09:18, 25 September 2018 (UTC)
User:Shadowowl/PROD log would be a good place to start. Notice that it's mostly blue links. Andrew D. (talk) 10:10, 25 September 2018 (UTC)
@Andrew Davidson: With the exception of the massive strings of BLPPRODs -- many of which appear to have been de-PRODded without a citation of a reliable source, in violation of policy (the most recent, and egregious, being this) -- in July and August of this year, it seems be about 50/50, and even were that not the case, the large number of blue links, if anything, would seem to show that the system works to preserve the articles that don't need to be deleted, surely?
Also, if you're going to talk about Shadowowl in that manner in a discussion in which they are not already involved, the least you could do is ping them. Calling someone a "deletionist" and saying they "keep trying to exploit and abuse the process" is a pretty strong accusation to make.
Hijiri 88 (やや) 10:44, 25 September 2018 (UTC)
I looked at the log also. I counted 139 PRODs and 78 BLPPRODS on that list. The PRODS are approximately a 2-1 ratio of Blue to Red links. It is a little more Blue than the one day I looked at and commented on below (3 Blue links on this log were from that day). I don't see someone who is abusing the process, maybe a little over aggressive with the tagging but not abuse. I did see one article where it was PRODed, removed and then Shadowowl reinstated the tag and another editor removed it a second time. There was also an article where Shadowowl added a PROD tag and realized it had already been to AFD and immediately removed the PROD. I have seen abuse of the process where an editor added a PROD tag, immediately removed it and came back 7 days later readded it like it had been there the whole time. That was an abuse of the process and they are no longer editing. What I see here is a system that works the way it supposed to work. Shadowowl should look at their log and reevaluate their tagging but this is not a reason to remove the whole process. ~ GB fan 14:43, 25 September 2018 (UTC)
  • Oppose While I don't find PROD to be all that useful because anyone can remove it for any reason, it has its place. Natureium (talk) 14:26, 24 September 2018 (UTC)
  • Oppose Although it's not always useful. What would be more useful, in some cases, is to expand the CSD categories. For example, a suitable speedy category would be BLPs with no sources. Alternatively, require all BLP creations to go through AFC. (In fact, requiring ALL new articles to have sources would drastically reduce the number of PRODs anyway...) Black Kite (talk) 14:28, 24 September 2018 (UTC)
    BLPPROD requires a reliable source to remove the PROD tag, which basically makes it a CSD criterion without the speedy. --Izno (talk) 14:31, 24 September 2018 (UTC)
  • Yes, but that often doesn't work. For example, someone creates an article on a non-notable sportsperson. When it is BLPPRODed, they add a cite from an otherwise reliable source pwhich is simply something like the name of that person in a list. Or for an actor, a reliable source mentioning them in a cast list of a TV programme, even if their appearance was for 15 seconds in the background. That sort of thing. Black Kite (talk) 14:36, 24 September 2018 (UTC)
  • Just pedantically noting that WP:BLPPROD is a separate policy. It's based on this one, but separate. Ivanvector (Talk/Edits) 14:39, 24 September 2018 (UTC)
@Black Kite: I like what you say here, but requiring AFC for all BLPs would make the process I go through whenever I link to the name of a still-living scholar in an article I'm writing on classical Japanese poetry (or whatever) that happens to already be a blue link to an unrelated topic even more frustrating. I either have to unlink pending the article's creation, or speedily create a stub: I always pick the latter option, and while even my stubs are better-sourced and less "stub-like" than most of the stuff you're probably talking about, requiring them to go through AFC, when the whole point is to replace an identically-named redirect, would be counterintuitive and just unnecessary work. (For reference, the articles in question are Jun Kubota, linked from Fujiwara no Nagaie, and Hiroshi Ono (scholar), linked from Man'yōshū.) Hijiri 88 (やや) 09:29, 25 September 2018 (UTC)
  • (edit conflict) I would strongly support requiring all new articles to have at least one source, and if someone opened this RfC they would be a wikipedia hero. Natureium (talk) 14:37, 24 September 2018 (UTC)
  • Well then, why don't you be the hero Wikipedia needs? Reyk YO! 14:39, 24 September 2018 (UTC)
  • I just don't have the brainpower right now to draft a cogent RfC. Natureium (talk) 14:51, 24 September 2018 (UTC)
  • Support In practice, PROD is basically a useless process. In my experience, most PRODS are removed without fixing anything or without any explanation, and unless policy is changed so that cannot be done, then there is no point: PRODS all end up at AFD anyways, so it doesn't save any time. --Jayron32 14:34, 24 September 2018 (UTC)
  • No, it has its place. Have a look at WP:PRODSUM - you'll always find a number of old articles in there that were created, were never notable, but have lain around not being useful for years. As a perfect example, the very first article currently in the list is a 4 1/2 year old article about an Under-16s football competition that was cancelled and never happened ... it's not eligible for CSD, and oit's got a source, but there's no way it should exist. Black Kite (talk) 14:41, 24 September 2018 (UTC)
  • If it only worked that way. In practice, what happens is, if I were to PROD some article, a user would come along within minutes and remove the PROD without explanation or fixing anything, or at best say "Has a source, take it to AFD." That's the point. Hypothetically, PROD should work that way. In practice, bad-faith editors who have no intention of making the article better come along and just force you to use AFD. This is why we can't have nice things... --Jayron32 15:14, 24 September 2018 (UTC)
  • Unfortunately, in many cases you are right. However, I think it's still useful - there is some stuff that gets PRODded that even the most rabid inclusionist won't de-prod because they know they'll be accused of disruption. It's happened before. Having said that, I still think expanding CSD is a better route... Black Kite (talk) 15:49, 24 September 2018 (UTC)
  • Oppose It can be a way to get rid of older articles which no longer meet Wikipedia's standards for inclusion without spending lots of community time on the issue. Best, Barkeep49 (talk) 14:38, 24 September 2018 (UTC)
  • Support. PROD is an unsatisfactory process. It should not be possible to nominate an article for deletion for any reason. A valid reason should be required. The PROD process has a lack of adequate scrutiny because there are too many PRODs and not enough patrollers. Most PRODs are erroneous, and they often slip through the net because the community is not watching closely enough. James500 (talk) 14:42, 24 September 2018 (UTC)
I believe any PRODded article can be restored simply by going to WP:REFUND and asking for it back. Ritchie333 (talk) (cont) 14:44, 24 September 2018 (UTC)
I wouldn't be surprised if the above was a reference to this, where a bunch of one-sentence sub-stubs about astronomical bodies about which not much more could be said than a single sentence, that duplicated information from elsewhere on the encyclopedia, were successfully PRODded, the above user requested they be undeleted, they were AFDed, and all deleted with unanimous consensus, excepting a piecemeal OSE statement on one of them from yours truly. Hijiri 88 (やや) 09:49, 25 September 2018 (UTC)
Wow, what a pointless waste of time that was. I'm starting to wonder if competence-related topic bans from PROD should be easier to hand out. Reyk YO! 10:03, 25 September 2018 (UTC)
"Too many PRODs"?! There were 36 yesterday. On a weekday there are usually fewer than 20. And the suggestion that "most are erroneous" isn't backed up by the evidence. Yes, there are some, but they should be rejected by the deleting admin anyway. Black Kite (talk) 14:49, 24 September 2018 (UTC)
The number of PRODs is huge. The last time I checked there were about 40 per day on average. On several occasions I have examined the PRODLIST over a period of many weeks and I found that consistently more than half of the PRODs listed there were erroneous. And I have seen a lot of erroneous PRODs slip through the net. James500 (talk) 15:15, 24 September 2018 (UTC)
"I have seen a lot of erroneous PRODs slip through the net" Let me know what, and I'll put them in your userspace for improvement (provided they are not vandalism, libel or copyvios). It's pretty much my SOP. As it is with anyone in Category:Wikipedia administrators willing to provide copies of deleted articles. Ritchie333 (talk) (cont) 15:24, 24 September 2018 (UTC)
I will go one step further as a contested PROD belongs in the mainspace not the userspace if you are contesting any PRODs. ~ GB fan 17:23, 24 September 2018 (UTC)
  • Oppose I've used PROD a few times (mostly successfully). AfD has a lack of participation problem for some things. PROD is good for, as it says, uncontroversial deletion where lack of participation is not a problem. Editors can always contest it and then the process is completely stopped. It's good for, as others have said, for removing older articles that are not up to scratch as far as the inclusion criteria goes. Jip Orlando (talk) 14:55, 24 September 2018 (UTC)
  • Oppose Reduces bureaucracy in a few cases, which is a good thing. --SarekOfVulcan (talk) 15:00, 24 September 2018 (UTC)
  • Oppose - No case has been made here. Don't even know why this is connected to the other proposals. — Rhododendrites talk \\ 15:42, 24 September 2018 (UTC)
  • Oppose - Looking at the reasons for support above I was wondering if I could find evidence to support the comments. I looked at the last 5000 deletions dating back to 00:01 21 Sep 18, of those there were 74 normal PRODs and 3 BLPPRODs. On average there were less than 20 articles deleted per day. That is not an overwhelming number of articles to look at. I also looked at one day of PROD nominations, 18 Sep. On that day if I counted correctly there were 33 pages nominated for PROD with only 16 of them left. Of the 17 PRODS that are no longer on the list, 1 was removed because it was a Draft and therefore ineligible. 1 was deleted as an A7. 2 were merged with another article and redirected. 2 are now at AFD and the rest were declined for a variety of reasons and have no pending deletion action. I did a quick look at the nominations without looking at the actual articles themselves and none of the nomination statements are problematic. In my quick look I do not see the problems mentioned above. ~ GB fan 17:23, 24 September 2018 (UTC)
  • Oppose. I agree it reduces bureaucracy sometimes. –Ammarpad (talk) 17:27, 24 September 2018 (UTC)
  • Oppose. PROD saves time for deletion of very poor content by blocked or long retired users. If the creator is around - it is indeed mostly useless.Icewhiz (talk) 17:39, 24 September 2018 (UTC)
  • Oppose as AFD is already backlogged with low participation and endless relists so this would make it worse, regards Atlantic306 (talk) 17:40, 24 September 2018 (UTC)
  • Comment mostly in response to Atlantic306's sentiment above: PROD is meant to be for uncontroversial deletions. If an uncontroversial deletion sits at AfD for a week with nobody objecting, there's little difference between that and a formal PROD, just a different page. It also ought to be a simple close and not really add to the backlog, and somewhat likely would result in a WP:SNOW delete which would be faster than PROD. On the other hand if a PROD is controversial then they wind up at AfD anyway. Ivanvector (Talk/Edits) 17:47, 24 September 2018 (UTC)
  • Oppose PROD is a very useful halfway point between the instant-removal of Speedy and the community deliberation process of AfD. If something sits at PROD for a week, where anyone can remove the PROD for any reason, then it really is uncontroversial and should be deleted without further ado. If someone objects later that it shouldn't have been deleted, undelete requests are routinely granted. --MelanieN (talk) 17:55, 24 September 2018 (UTC)
  • Oppose PROD still has an important role to play. shoy (reactions) 17:56, 24 September 2018 (UTC)
  • Strong oppose PROD is a critical time-saver for new page patrolling that allows editors to unilaterally handle uncontroversial deletes that don't quite meet speedy deletion criteria. signed, Rosguill talk 18:17, 24 September 2018 (UTC)
  • Oppose it has a role to play and getting rid of it would mean additional load on the AfD process for no particular reason. AfD requires a substantially greater amount of editor time than PROD does. I'm open to persuasion if someone could show data which indicates that the process doesn't work very well. Hut 8.5 19:22, 24 September 2018 (UTC)
  • Oppose PROD should be made stronger (with disruptive editors like two of this proposal's supporters so far being required to provide an explanation for removing PRODs, since currently they are allowed remove it just for shits and giggles), not deprecrated. Hijiri 88 (やや) 21:59, 24 September 2018 (UTC)
  • 'Oppose more time would be wasted. Xxanthippe (talk) 22:31, 24 September 2018 (UTC).
  • Oppose pbp 23:35, 24 September 2018 (UTC)
  • Oppose The PROD process is about getting cleanup work done with a minimum of bureaucracy(no offence intended towards out esteemed bureaucrats). The last thing AfD needs is a bunch of articles that nobody has any interest in defending. HighInBC Need help? {{ping|HighInBC}} 01:21, 25 September 2018 (UTC)
  • Oppose, while a lot of prods get contested and sent to AfD, it is a useful process that helps reduce wastage of valuable time of experienced editors at AfD discussions. — Insertcleverphrasehere (or here) 02:03, 25 September 2018 (UTC)
  • Oppose its the simplest way to get rid of stale junk. I would support getting rid of it if it meant automatic deletion but it does not: I and a few other editors try to scan the lists on a regular basis to deProd anything that might need discussion, and this is enough of a check. I've been doing it for many years--I remove maybe 5%, and others remove an equal amount. About half of that 10% eventually get deleted. DGG ( talk ) 07:44, 25 September 2018 (UTC)
  • Oppose prod still works well. Graeme Bartlett (talk) 08:34, 25 September 2018 (UTC)
  • Oppose - PROD should remain an option. @Black Kite: An effective alternative to PROD for unsourced BLPs is returning the article to draft. Cwmhiraeth (talk) 10:59, 25 September 2018 (UTC)
  • Oppose - keep the existing tier of PROD - particularly as per the arguments of Rosguill, HighInBC, DGG, and MelanieN. Onel5969 TT me 13:51, 25 September 2018 (UTC)
  • Oppose. Proposed deletion fills a specific niche: cases that'd be ignored or "snow" deleted at AfD, but that don't meet the narrow speedy deletion criteria, can be deleted with minimal effort on the part of volunteers (compared to the non-negligible overhead of AfD). It's designed to be minimal; a contested PROD should either be immediately moved to AfD, left alone, or (if after the fact) restored. If someone can produce evidence that it's not working in practice, then I'd be open to reconsidering, but my current position is that it's a good design. {{Nihiltres |talk |edits}} 14:42, 25 September 2018 (UTC)
  • Oppose Per reasons above. We shouldn't try to axe this process. — AfroThundr (u · t · c) 22:28, 25 September 2018 (UTC)
  • Oppose there is no reason to axe a process that works well. -DJSasso (talk) 15:50, 27 September 2018 (UTC)
  • Oppose – it works. SemiHypercube 00:31, 28 September 2018 (UTC)
  • Oppose per above. Just no. -FASTILY 05:54, 28 September 2018 (UTC)
  • Oppose  pythoncoder  (talk | contribs) 19:14, 29 September 2018 (UTC)
  • Oppose - Very still useful process, especially now that PROD has extended to files. Also, it helps being an alternative to FFD, which formerly suffered from tremendous backlogging before the implementation of File PROD-ding. Those saying the process is useless should realize the benefits of PROD-ding, especially to files. See this, for example, and then type either "PROD" or "File:". George Ho (talk) 22:10, 29 September 2018 (UTC)
  • Oppose - PROD still works, Admittedly I don't use it now as I prefer to AFD everything but I've certainly seen it work on different articles, If it works then keep it. –Davey2010Talk 22:24, 29 September 2018 (UTC)
  • Oppose - I'd prefer people to send it through AfD where there is a 1% lack of surety, but PROD does remove a significant number of articles that would otherwise clog the process unnecessarily. Nosebagbear (talk) 22:42, 29 September 2018 (UTC)
  • Oppose Prod largely works; the biggest issue is the ability to remove it without a rationale. Number 57 20:13, 9 October 2018 (UTC)
  • Oppose - PROD is exactly what it is meant to be, a useful policy to get rid of crud (non-controversial deletes), and getting rid of it would either burden AFD or require new CSDs. Robert McClenon (talk) 19:17, 15 October 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.

PROD proposal 4: Require notification for creator, with some exceptions

Many of the !votes for proposal 1, both support and oppose, cited the needs for exceptions and opposed pinging signficant contributors. This is an attempt to capture that:

The editor nominating an article for proposed deletion is required to notify the article's creator, except in the following circumstances:
  • The page creator is indefinitely blocked, community banned, globally banned, deceased, or otherwise unable to respond to the nomination
  • The page creator has indicated on their talk or user page that they do not want to recieve such notifications or that they have retired from Wikipedia
  • Notification would be impossible due to the nominating user being banned from the page creator's talk page or due to the protection level of the page creator's talk page
  • Support as proposer (pinging users that !voted either way for #1: @Reyk, Ammarpad, Fish and karate, Nyttend backup, Andrew Davidson, Natureium, Ritchie333, Jip Orlando, James500, Rhododendrites, SarekOfVulcan, Enos733, TonyBallioni, and Guy Macon:). --Ahecht (TALK
    PAGE
    ) 17:09, 24 September 2018 (UTC)
  • Oppose as the exceptions are bureaucracy that would create more work for no benefit. TonyBallioni (talk) 17:11, 24 September 2018 (UTC)
  • Oppose Too many rules to keep track of, when a suggestion of notifying the creator is sufficient. Is there anyone upset that their articles are being PRODed without notification? If so, they should probably stop creating so many articles that could qualify for deletion. Natureium (talk) 17:13, 24 September 2018 (UTC)
  • Supportish - Doesn't need to be this long, but it's also not true that these are rules that everyone must keep track of. There's nothing here that shouldn't already be common sense. The existing problem is that people don't follow common courtesy/common sense of notifying in those cases when it should be done. Page creators should be notified by default. That's it. Nothing else to remember. Our policy should reflect that. If it was created by a bot, by a banned user, by a deceased user, then of course there's no requirement to notify, and I cannot imagine anyone objecting to someone not notifying in those cases. Spelling out that there are cases when notification shouldn't be necessary shouldn't be necessary, but here they are because those exceptions seem to be the basis for most of the opposes in the first proposal. I can't imagine anyone feeling like they need to remember this list (Twinkle will notify the page creator regardless of the above -- these are just when it's not necessary). — Rhododendrites talk \\ 17:21, 24 September 2018 (UTC)
  • Comment - I would prefer "is expected to make a good faith effort to..." because it's simpler without the need for additional guidance, allowing context to rule. But I support notification as a criteria in principle, because PROD is the only deletion criteria where the creator (or anyone) can unilaterally challenge the nomination and send to AfD instead. Adding that failure to notify isn't necessarily on the back of reviewing admins to check (it need not be part of the deletion criteria per se to be a generally accepted community expectation), but would be a good faith reason to restore the article if requested, seeing that, if restoration is requested, it could be presumed that the PROD would have been challenged and therefore should have gone to AfD instead. Common sense would dictate that the restoring admin should notify the nominator so they may decide whether to take the article to AfD. GMGtalk 17:19, 24 September 2018 (UTC)
  • Oppose because watchlists are a thing. --Jayron32 17:27, 24 September 2018 (UTC)
  • Oppose. If the creator is interested - there is a watchlist. There is no need to create a long and arcane list of allowed exceptions.Icewhiz (talk) 17:41, 24 September 2018 (UTC)
  • Oppose Leave it as a suggested courtesy notification. Do we really have a serious problem with PROD nominators who never notify the creator? If so, counsel that nominator. This proposal is a solution in search of a problem. --MelanieN (talk) 17:59, 24 September 2018 (UTC)
  • Comment I agree with GMG that there should be a reasonable expectation that a good-faith attempt be made to notify the creator. But I'm leery about adding a list of exceptions for the reasons mentioned above. Jip Orlando (talk) 18:02, 24 September 2018 (UTC)
  • Oppose As far as I can see, we already are required to do this, although that is perhaps because of POV-pushers wording the PROD instructions in such a way as to force the process's users to do things that aren't actually required by policy. Forcing this in a formal manner is a bad idea, and the above exceptions don't go nearly far enough: many page creators are subject to TBANs, etc., or are simply not active anymore. On top of this, if policy requires a notification, that normally overrules talk page bans. This proposal is just a mess. Hijiri 88 (やや) 22:15, 24 September 2018 (UTC)
  • Oppose as instruction creep. Xxanthippe (talk) 22:29, 24 September 2018 (UTC).
  • Oppose - its fine as a recommendation, though I think it should recommend sending the notification to the creator of the first non-redirect revision. — Insertcleverphrasehere (or here) 02:06, 25 September 2018 (UTC)
  • Oppose, stop making this stuff complicated. "When you tag an article for proposed deletion, let the creator know unless this is not appropriate." That's all we need. Fish+Karate 08:59, 25 September 2018 (UTC)
    • I think this should be offered as an alternative (or even better: When you tag an article for proposed deletion, let the creator know unless this is not appropriate (e.g. an editor has indicated they do not wish to receive such notifications). Best, Barkeep49 (talk) 18:42, 25 September 2018 (UTC)
  • Oppose- I agree with the sentiment, but I do think this will end up being more instruction creep than we really want. Reyk YO! 09:01, 25 September 2018 (UTC)
  • Comment If this is adopted, then inactive creators (e.g. no edits for over a year but no obvious indication of retirement) should also not be required to be notified as well as those listed above, as there's no point notifying someone who's never going to pay attention to the notification. IffyChat -- 10:20, 25 September 2018 (UTC)
  • Oppose This is really no different than Proposal #1 and my reason still stands. —Farix (t | c) 18:58, 25 September 2018 (UTC)
  • Oppose as instruction creep and cause no one owns a given page. -DJSasso (talk) 15:50, 27 September 2018 (UTC)
  • Support- This makes the most sense of all the options. I think the creator should be notified. If someone took the time to create the article they should at least be made aware of its proposed deletion. I always notify when I prod anyway.--Rusf10 (talk) 00:20, 28 September 2018 (UTC)
  • Oppose per above. Reeks of process creep and promotes WP:OWN -FASTILY 05:54, 28 September 2018 (UTC)
  • Oppose as IMHO no different from #1 to which I opposed aswell. –Davey2010Talk 22:26, 29 September 2018 (UTC)
  • Oppose; making further requirements increases the burden of this intentionally simple process. By the way, Ahecht, sorry for the delay, but I don't log in frequently; my main account is better for notification. Nyttend backup (talk) 13:34, 2 October 2018 (UTC)
  • Oppose per WP:OWN. Number 57 20:13, 9 October 2018 (UTC)
  • Oppose as stated, appears to be a method to suppress PRODs in order to make it easier to keep crud. Robert McClenon (talk) 19:18, 15 October 2018 (UTC)
  • Oppose as stated in proposal #1; creator's opinion likely doesn't matter anyway.—Mythdon (talkcontribs) 08:22, 17 October 2018 (UTC)
  • Oppose, for the same reasons as why I opposed #1. Headbomb {t · c · p · b} 02:12, 25 October 2018 (UTC)
  • Support as a minimum. But the exceptions are unnecessary if the process is made automatic. DGG ( talk ) 03:45, 29 October 2018 (UTC)
  • Support. Not all use watchlists. Not all log on weekly. A user_talk page notice provides the best notification, to the user, and to others watching or reviewing the user. In fact, when reviewing drafts, the author's user_talk page is very useful for the record of CSDs and PRODs. The user's contribution history is near useless, because the worst of their contributions are hidden from non-admins. Sometimes not notifying is appropriate, such as when the author is already blocked, or the author is not the real author, there being a history of a redirect, or a request for article creation. Surely, Twinkle does this so easily that this is not a practical problem. --SmokeyJoe (talk) 04:52, 29 October 2018 (UTC)
  • Oppose current system seems to work pretty well, and it should either be notification is required, or it isn't. Exceptions just make it hard to enforce. zchrykng (talk) 16:01, 29 October 2018 (UTC)
  • Oppose - useless instruction creep. Staszek Lem (talk) 18:37, 29 October 2018 (UTC)
  • Oppose – This would only encourage knee-jerk de-PRODding, sometimes by creators who have not contributed to the article for years, and are suddenly reminded "oh yeah, I once wrote an article about my street, why do these dorks at WP want so bad to suppress it? Damn, WP:ITEXISTS, you jerks!" — JFG talk 13:12, 3 November 2018 (UTC)
  • Oppose, leans towards WP:OWN and adds pointless instruction-creep that would complicate a process that is intended to be streamlined. Wikipedia articles require constant maintenance; if there is nobody watching the article at all who wants to save it, and the prod passes the test of the admin who actually has to implement it, then it's reasonable to delete it. Giving the article creator some special weight or presence in this process doesn't make any sense and doesn't fit with the general idea behind WP:OWN - article creators should never be given any sort of special weight or status in any policy. --Aquillion (talk) 09:43, 4 November 2018 (UTC)
  • Oppose any hard requirements as instruction creep and would just result in more traffic at AFD. Stifle (talk) 10:04, 5 November 2018 (UTC)
  • Oppose, it's good practice, it's courteous, but it shouldn't be elevated into a procedural loophole. Cabayi (talk) 11:12, 6 November 2018 (UTC)

PROD proposal 5: Require an explanation for removal of a PROD template WITHDRAWN

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.

Either in an edit summary or on the talk page. Should be uncontroversial: proposing deletion requires an explanation, preventing trolls and POV-pushers from quietly getting pages deleted without explaining why, but currently no explanation is required the other way, resulting in messes where someone who has not even read the article, or is just having a laugh, removes the PROD and a resulting week-long AFD sees unanimous consensus for deletion or equivalent (see [1]). Hijiri 88 (やや) 22:15, 24 September 2018 (UTC)

  • Support As nom. Yes, dealing with individual abusers of the policy could be handled wih TBANs and blocks, but when it's been going on this long and the permissiveness of the policy itself is generally blamed, I think it would be a good idea to try fixing the policy first. Hijiri 88 (やや) 22:15, 24 September 2018 (UTC)
Okay, it's obvious this is going nowhere, so I'm withdrawing. However, it seems the reason it's going nowhere is not because other users disagree with me on the principle here, just on whether it would be better to enshrine the principle in policy or deal with it on a case-by-case basis, so I'd still like to discuss below. Hijiri 88 (やや) 02:10, 25 September 2018 (UTC)
  • Oppose PROD is intended for articles where deletion is uncontroversial. If someone objects, for whatever reason, then deletion is by definition controversial. Let's not set up a kind of AfD-lite, where people end up arguing about whether the explanation or rationale is good enough or not. Just send it to AfD and let the community decide. If there are some people who are abusing the process and unPRODding everything, they could be subject to a topic ban if the behavior is egregious. If it's just that they are little bit more keep-ist and the PRODder is a little bit more deletionist, that's what AfD is for. --MelanieN (talk) 00:59, 25 September 2018 (UTC)
  • Oppose in reality but support in spirit. As the numbers above bear out PROD's are relatively few and there has not been any sort of widespread trolling documented. So discussion is good, being considerate and saying why you're removing a PROD is good, creating bureaucracy and opportunities for editors to accuse each other of not following policy or removing a PROD in bad faith to solve a problem that hasn't been shown is not something I can support at this time. Best, Barkeep49 (talk) 01:04, 25 September 2018 (UTC)
  • Oppose PROD is only inline with our discuss and reach consensus model because it is only used for undisputed deletions. If someone disputes it then there are other avenues for deletion. If there is a problem with people just bulk removing prods that can be dealt with using our disruption policy. HighInBC Need help? {{ping|HighInBC}} 01:24, 25 September 2018 (UTC)
@MelanieN and HighInBC: Both of you open your !votes with the statement that PROD is only for uncontroversial deletions, but what about when the only reason deletion is "controversial" is because User X doesn't like deletion and wants to create more hoops to jump through to get an article (or four articles in the space of eight minutes, or 23 articles out of 50 mainspace edits over a period of two weeks) deleted? Hijiri 88 (やや) 02:10, 25 September 2018 (UTC)
This wasn't asked of me but as someone who, to my regret, inclusionists would call a deletionist I don't see an issue. The editor there didn't do this for all PRODs and so some editorial discretion is being applied. That seems completely with-in the spirit of what PROD is designed to do. Would doing so with a discussion further the project? Yes, but that doesn't mean there weren't reasons or we need to legislate this sort of action out of existence. Best, Barkeep49 (talk) 02:31, 25 September 2018 (UTC)
As I said above, and HighInBC did too: if the person is being disruptive, actually demonstrably disruptive, in removing PRODs - but not in other areas of the 'pedia such that they should be blocked - then a topic ban is probably the best remedy and AN would be the venue. --MelanieN (talk) 03:16, 25 September 2018 (UTC)
P.S. A "requirement to provide an explanation" wouldn't help with a dedicated PROD remover like the one you cite here. They would just change their edit summary from "remove prod" to some canned rationale like "remove prod, subject appears notable". And you'd be right back where you were. What you have here is not a system problem; it is a user problem. We don't rewrite our systems because of one user. --MelanieN (talk) 03:24, 25 September 2018 (UTC)
  • Oppose I'd love if this was something we could enforce, but new editors will have no idea of this rule even if we put it in bold letters on the template and will just lead to edit wars restoring the template. If the editor removes the PROD, they will get a discussion at AfD explaining to them why it wasn't appropriate, which helps them learn. Helping new editors learn is important. — Insertcleverphrasehere (or here) 02:08, 25 September 2018 (UTC)
  • Oppose The prod template provides a place for the proposer to state their case. There is no corresponding place for an opposer because a prod is opposed by removing the template and so it goes away. If discussion is wanted then this is typically done by taking the matter to AfD and, per WP:BRD, the onus is on the proposer to start such a discussion. Discussions don't belong in edit summaries as they are supposed to be succinct summaries of what was done in the edit. Per WP:REVTALK, "Avoid using edit summaries to carry on debates or negotiation over the content or to express opinions of the other users involved. This creates an atmosphere where the only way to carry on discussion is to revert other editors!" For example, consider the recent case of Azia. There was a lot wrong with this proposal for which the stated concern was "Completely unsourced and topic of minimal notability. Suggest a merge." Everything said here is wrong. The article has sources and states them clearly at the bottom of the article. The topic is a town in Nigeria and all such places are considered notable. And the proposal is to merge the content. Merger is not done by deletion and there's a different template for making such proposals. Explaining all these errors requires some space and effort and the prod process does not provide this. It is, by design, a lightweight process. If you make it more burdensome then you'll just reproduce AfD. Andrew D. (talk) 07:13, 25 September 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.

!Voting "oppose" on an already withdrawn proposal is evidence enough that it was a user problem, with a user actively engaged in trolling "the deletionists", so I guess MelanieN's advice regarding how to deal with such user problems applies. Thank you to whoever closed the above, anyway. Hijiri 88 (やや) 08:55, 25 September 2018 (UTC)

PROD Proposal 6: PRODs cannot be declined by article creator

I'd like to toss this out for what it's worth. pbp 15:02, 1 November 2018 (UTC)

  • Oppose The whole point about prods is that they are completely uncontroversial, even if the person is the creator, if they object that means it is no longer uncontroversial. -15:56, 1 November 2018 (UTC)
  • Oppose. The quality of prod nominations is often so bad that an article creator should be free to remove a prod. --Michig (talk) 13:27, 3 November 2018 (UTC)
@Djsasso: @Michig: Let me ask you this: why wouldn't an article creator remove a PROD from an article they created? Allowing article creators to decline PRODs is a lot like not having PROD at all. pbp 23:09, 3 November 2018 (UTC)
Sometimes the prod is culling early articles that the creator now knows are not really notable, at least that's the scenario that I am aware of. For example players who made a notable team but never actually came off the bench. ϢereSpielChequers 00:30, 4 November 2018 (UTC)
Obviously a lot of the time article creators don't remove prods, even though they currently can, as a lot of articles get deleted via prod. --Michig (talk) 07:39, 4 November 2018 (UTC)
  • Strong Oppose. Good grief. Softlavender (talk) 00:33, 4 November 2018 (UTC)
  • Oppose Yeah, this is a bad idea for multiple reasons: it would actually be counterproductive in that article creators, even good-faith content contributors, would be forced to turn to disruptive "keepist" editors who will happy deprod anything they think is low-vis enough that no one will notice; in the rare occasion that a legitimate "deletionist" shows up (... I dunno ... INeverCry, I guess?) they could just target low-vis articles that only the article creator is watching; on those few events that preventing the article creator specifically from deprodding would be useful (Tanka prose for example) AFD actually works just fine despite the presence of disruptive keepist editors. Hijiri 88 (やや) 00:42, 4 November 2018 (UTC)
    I think you mean "inclusionist" Hawkeye7 (discuss) 09:06, 6 November 2018 (UTC)
  • Oppose. PROD is basically speedy with a "speak now or forever hold your peace" component. If a PROD is contested, that means AfD is needed. bd2412 T 01:35, 4 November 2018 (UTC)
  • Oppose the article creator should be permitted to have as much input as anyone else. Lepricavark (talk) 03:15, 6 November 2018 (UTC)
  • Oppose I get the idea that there could in theory be someone going through the prod queue and deprodding systematically. But I'm not aware that that actually happens and people deprodding to protect their own work is not that issue. ϢereSpielChequers 07:49, 6 November 2018 (UTC)
  • Oppose I'd like to toss this out for what it's worth. Hawkeye7 (discuss) 09:01, 6 November 2018 (UTC)
  • Is there such a thing as a SNOW oppose? - Here's a scenario, someone creates a niche article; say on the bio of a notable bowls player. Then, as it's a little niche, someone puts on a PROD. The article creator then cannot undo this, and has to get someone else to do this for them. We'll get tonnes of people trying to get things de-PRODed. However, if it's a non-popular item, they may not get as many eyes on it; and thus much harder for someone to remove it organically. However, the article itself, was notable. If the article doesn't fail any speedy criteria, and the creator, or anyone else doesn't agree it should be deleted, it should go to WP:AfD. Lee Vilenski (talkcontribs) 09:08, 6 November 2018 (UTC)
  • Oppose – Impractical and unfair, per Lee Vilenski's scenario. — JFG talk 10:14, 6 November 2018 (UTC)
  • Oppose - unless the article has been tagged for projects it's possible that only the author is the only interested person aware of the article. Cabayi (talk) 11:15, 6 November 2018 (UTC)

PROD Proposal 7: PROD only through Twinkle

As nothing seems to have consensus yet, I'll suggest this formally. The PROD tag can only be added through Twinkle or a similar semi-automated editing tool. That tool should send a talk page notification to the page creator, unless they are prohibited by a {{nobots}} style tag on the page creator's talk page, or the PROD nominator explicitly opts out of sending a message. Editors who cannot or do not use Twinkle are encouraged to used the WP:AFD process to propose deletions. power~enwiki (π, ν) 16:03, 1 November 2018 (UTC)

  • Support as nom power~enwiki (π, ν) 16:03, 1 November 2018 (UTC)
  • Oppose This seems like an end run around the fairly clear consensus forming above that you do not need to notify. Secondly users should not be forced to use certain tools to be able to take part in standard processes like PROD>. -DJSasso (talk) 16:09, 1 November 2018 (UTC)
  • Oppose per Djsasso. We should not mandate the use of specific tools to be able to do certain things. Reyk YO! 16:12, 1 November 2018 (UTC)
  • Oppose. Nobody should be forced to use tools to automate anything. --Michig (talk) 13:28, 3 November 2018 (UTC)
  • Oppose per wot Michig said. ϢereSpielChequers 00:32, 4 November 2018 (UTC)
  • Oppose. It is ridiculous to require all editors to use automated or semi-automated tools to edit Wikipedia or to PROD an article. Softlavender (talk) 00:35, 4 November 2018 (UTC)
  • Strong oppose. I PROD the old-fashioned way and I like it that way. bd2412 T 01:36, 4 November 2018 (UTC)
  • Oppose, not all editors can use these tools. Stifle (talk) 10:04, 5 November 2018 (UTC)
  • Oppose per above. Lepricavark (talk) 03:16, 6 November 2018 (UTC)
  • Oppose - the choice of toolset (if any) is up to each individual. Cabayi (talk) 11:17, 6 November 2018 (UTC)
  • Oppose per all the above users rightly pointing out that automated tools should never be a requirement for any process. IffyChat -- 14:43, 6 November 2018 (UTC)

PROD Proposal 8: Require a rationale to de-PROD

The main issue with the PROD process is article creators performing knee-jerk de-PRODding, sometimes without a good grasp of our notability policy. The PROD notice should include the requirement that de-PRODding requires a policy-based rationale asserting notability, with appropriate links to educate unaware editors. Merely removing the tag with no explanation could be reverted on-sight, with a gentle warning to the infringing de-prodder. If a rationale is provided in the de-prod action, that constitutes a good basis to either keep the article, or to start an AfD with stronger arguments for and against. — JFG talk 13:21, 3 November 2018 (UTC)

  • Oppose. Barely any prod nominations are policy-based. Arguments against prods are likely to be guideline-based rather than policy-based. --Michig (talk) 13:29, 3 November 2018 (UTC)
  • Oppose Notability is not a policy; it's just a guideline and so explicitly allows for exceptions. The OP doesn't seem to understand this and many article creators will not understand such complexities either. The prod process does not provide a discussion in which to explain and debate such issues. Anything of this sort should be done at AfD where it can be properly discussed and resolved. Andrew D. (talk) 22:49, 3 November 2018 (UTC)
  • Support Makes sense. pbp 23:09, 3 November 2018 (UTC)
  • Support Okay, my insincere "procedural oppose" did no good, it seems. And once again Andrew Davidson, the one who even those who oppose this kind of proposal think should be specifically required to explain deprods because of his problematic tendency to deprod without explanation, then show up at the subsequent AFD and make a counter-policy argument, is opposing this, which ... yeah, just no. Hijiri 88 (やや) 00:01, 4 November 2018 (UTC)
  • Oppose. We don't require specific policy-based rationales for numerous kinds of deletion, so it makes no sense to require it of PROD. Softlavender (talk) 00:36, 4 November 2018 (UTC)
  • Oppose prod is for uncontentious deletions, if it is contentious it should go to AFD. We have more than enough things to argue about on Wikipedia, please don't add "was this prod decline reverted on a correct understanding of policy". ϢereSpielChequers 00:39, 4 November 2018 (UTC)
  • Oppose, unworkable as written. Requiring that they say something when deprodding might work - that is, they have to provide an edit summary, no matter how brief or cursory - but requiring that it be policy-based opens a can of worms that the prod system (intended to be streamlined, simple, and requiring minimal review or oversight) can't really handle. If someone provides a rationale, and you want to argue that it's not policy based, and you start a discussion over whether it's policy-based where people weigh in to reach a consensus... that's WP:AFD, which is where contested deletions should go. --Aquillion (talk) 09:38, 4 November 2018 (UTC)
  • OP comment – Striking "policy-based" from my proposal, as several editors explained that notability guidelines are not policy. @Michig, Andrew Davidson, Softlavender, WereSpielChequers, and Aquillion: Thanks for your remarks; would that update make you reconsider? — JFG talk 23:43, 4 November 2018 (UTC)
    • This was SNOW Opposed above: WP:Village pump (policy)#PROD proposal 5: Require an explanation for removal of a PROD template WITHDRAWN. Plus, you can't drastically change the content of the proposal after several people have !voted on it. My !vote remains Oppose, as it has been for all three of these identical proposals. Softlavender (talk) 00:00, 5 November 2018 (UTC)
    • Prod is not always about notability, so explaining why you think the topic is notable isn't always going to help. I think we should encourage deprodders to give a rationale for their deprodding, and that rationale somewhat belongs in the edit summary. Currently the start of the instructions just say "Any editor (including the article's creator or the file's uploader) may object to the deletion by simply removing the tag" whilst in Wikipedia:Proposed_deletion#Objecting you are "strongly encouraged" to give a rationale and to consider doing a couple of other things. I'd be inclined to reorganise the bit where you are "strongly encouraged" to "consider" as that reeks of compromise rather than clarity. But more important, and back to your point. I'd be OK with the start of the instructions being "Any editor (including the article's creator or the file's uploader) may object to the deletion by removing the tag, but please say why in your edit summary" The template currently states that "Although not required, you are encouraged to explain why you object to the deletion, either in your edit summary or on the talk page" could this go to "Please explain why you object to the deletion, ideally in your edit summary"? ϢereSpielChequers 08:36, 5 November 2018 (UTC)
Re-wording PROD instructions to encourage editors to provide a rationale would be a good step forward. Current message is too permissive. I'd be happy to help craft a new message if this suggestion gets traction. — JFG talk 09:25, 5 November 2018 (UTC)
  • Oppose per above. The point of PROD is to delete those pages that everyone agrees are candidates for deletion; if no one objects for any reason, the page is deleted. However, if someone does object, the page can go to AfD, which is where the policy-based discussion can happen. I see no reason to change this. CThomas3 (talk) 00:12, 5 November 2018 (UTC)
  • Partial support This should be used as an ANI sanction only. SportingFlyer talk 03:35, 5 November 2018 (UTC)
  • Oppose per above, especially WereSpielChequers. Once you have to discuss the topic's inclusion, AFD is the place to do it, not the talk page. Bad-faith de-PROD-ing can already be sanctioned as disruptive behavior. Regards SoWhy 09:05, 5 November 2018 (UTC)
  • Oppose again. The whole idea with prod is that if you don't think it should be deleted it needs to go to Afd. Doesn't matter what your reasoning is. -DJSasso (talk) 12:15, 5 November 2018 (UTC)
  • Oppose requirement. However, an explanation in the PROD notice that an unexplained removal is more likely to result in AFD than a justified removal - that may result in a more considered removal and reduced workload all round. Cabayi (talk) 11:21, 6 November 2018 (UTC)

General discussion: Proposed deletion

  • The specific wording change I'm referring to changed the fourth step of the nomination process from:
4. The article's creator or other significant contributors should ideally be left a message at their talk page(s) informing them of the proposed deletion, except for cases where contributors are no longer regarded as active editors on Wikipedia. This should be done by adding the {{subst:Proposed deletion notify|Name of page}} tag, or other appropriate text.
to:
4. Inform the page creator or other significant contributors of the proposed deletion (except contributors are no longer regarded as active editors on Wikipedia), with a message on their talk page(s) by adding: {{subst:Proposed deletion notify|Name of page}} or other appropriate text.
(emphasis in original) Ivanvector (Talk/Edits) 13:48, 24 September 2018 (UTC)
  • Generally it's polite to notify the page creator. But sometimes, such as when it's a permabanned user or a dynamic IP that's now changed, there may be no point. Twinkle notifies automatically, and I'm happy to let it do its thing, but if I were to PROD something manually I'd check to see if notifying the page creator is worth it. Reyk YO! 13:43, 24 September 2018 (UTC)
    • Pages by a permabanned user don't need to be PRODded, they can just be deleted under CSD G5. IPs can't create pages. Fish+Karate 13:47, 24 September 2018 (UTC)
      • Pages by a user who wasn't permabanned at the time they made the page, but were permabanned later, are not eligible for G5 speedy. And IPs used to be able to create pages, and there's still lots of hopeless IP creations still out there. I AfD'd one just today. Reyk YO! 13:49, 24 September 2018 (UTC)
        • Fair point, although I guess that's covered by "except contributors (who) are no longer regarded as active editors on Wikipedia" (my typo fix in bold). Fish+Karate 13:52, 24 September 2018 (UTC)
          • Just another example as to why it shouldn't be mandatory; I almost always notify PROD/AFD creators, but a while back I came upon one created by a fairly well known editor who was deceased... Black Kite (talk) 14:30, 24 September 2018 (UTC)
    • This is generally where I fall. "Highly encouraged in most situations" with a quiet "use judgment." Like BK above me, it is worth using judgment on edge cases, and I certainly favor a "You should definitely do this, it's a really good idea, but if you have a good reason for not doing it, that's fine." ~ Amory (utc) 16:31, 24 September 2018 (UTC)
  • I'm just curious what reasons people have for not using Twinkle. Seems like it really simplifies the whole process (especially for AfD, but also for PROD). — Rhododendrites talk \\ 15:43, 24 September 2018 (UTC)
I spent more than a year doing this stuff manually IIRC, because I thought Twinkle was an add-on third-party software, and not an in-browser extension, because I don't know how to computer. GMGtalk 17:22, 24 September 2018 (UTC)
You are not the only one. This may be a fairly common reason. · · · Peter (Southwood) (talk): 06:18, 26 September 2018 (UTC)
Twinkle automatically leaves a notice for the creator of the page (if you tell it to); it can't identify "significant contributors", or cases where the creator shouldn't be notified. It's really a non sequitur in regards to the subject of this RfC. ansh666 18:28, 24 September 2018 (UTC)
  • leave out except when creators are not considered active, as its easier to inform them routinely and other editors may be watching their talkpages, regards Atlantic306 (talk) 17:37, 24 September 2018 (UTC)
    • Seconded. Samsara 18:20, 1 October 2018 (UTC)
  • Just a note, I've changed the wording back to the previous version, pending an actual consensus in favor of changing the policy (currently, there's a strong majority in opposition to the change, and per WP:CONLEVEL policies should not be changed by BOLD editing to begin with). (Swarmtalk) 19:53, 24 September 2018 (UTC)
  • I find it strange that I read the section headings and expected a debate on whether we should notify article creators and significant contributors, but the actual debate is about what counts as reasonable effort in notifying creators and significant contributors. It seems that we generally agree that the prodder ought to notify and are debating edge cases. But isn't PROD about relatively uncontroversial attempts at deletion, and any edge cases should go straight to AfD? Deryck C. 11:14, 29 October 2018 (UTC)
  • There should be *automated* warnings for certain actions (nominations for deletion included, some tags, ...) to users watchlisting the article *and* opting-in for such warnings. Creators should have no special right nor the burden of being warned in the cases they do not care anymore (and I bet there are more than a few of those). On the other hand, the watchlist is mostly useless as warning about deletions, and it could be a useful improvement to get such drastic changes to show up more prominently - Nabla (talk) 19:22, 3 November 2018 (UTC)
  • Comment: Notification of the creator is absolutely unnecessary because any article creator who only belatedly discovers that their article has been PROD deleted can automatically get a copy of the deleted article without even providing a rationale. This is why PROD works so well as the first stop in article culling: Articles that are just drive-by spam from SPA accounts who have since left Wikipedia are easily culled without further ado, and articles from good-faith editors who may have been absent or distracted during the week that the PROD was placed can easily get their article restored. Best of both worlds. Softlavender (talk) 04:40, 5 November 2018 (UTC)

Requirement to explain DePROD

  • While we're talking about the PROD policy, I'd like to propose that a person deproding a page, be required to give an explanation of why (either in the edit summary or on the talk page). Too many times do people deprod without any reason. This allows the extreme inclusion group to force AfDs which waste everyone's time. If I have to give an explanation of why an article I PROD should be deleted than I don't think its too much to ask for the person deProding it to explain why it should be kept. That explanation may convince the person proposing deletion not to go any further or at the very least give them a point to refute when creating an AfD.--Rusf10 (talk) 00:27, 28 September 2018 (UTC)
  • Moral support- I don't see this having much chance of getting up, but I generally agree.Reyk YO! 08:44, 28 September 2018 (UTC)
  • Weak Support The reason why PROD exists is so that obviously unsuitable articles (WP:SNOW) can be deleted without much of a fuss. I would support only requiring the page author or apparent SPAs to explain the dePROD, since they would likely object to deletion. funplussmart (talk) 01:16, 30 September 2018 (UTC)
  • Strongest possible support requiring a rationale is the only thing keeping PROD from being a farce, which it basically is.--Jayron32 01:20, 30 September 2018 (UTC)
  • Comment This is the same as the withdrawn Proposal 5 above. --MelanieN (talk) 02:33, 30 September 2018 (UTC)
  • Strong oppose It is up to wanna-be-deleters to justify deletions. If they want a discussion the AFD is the way to proceed. The people that just remove the prod, probably have no idea about the procedures here, and so you are giving an unfair advantage to the established editors that do. If however, there is someone removing a lot of "prod"s for no reason, or a wiki-political reason, then that is disruptive editing that can be dealt with in another way. Not only that, prods can also be overturned after deletion, without reason. It is better to simplify the process rather than add more even work. Graeme Bartlett (talk) 02:48, 30 September 2018 (UTC)
  • Hmm. "Wanna-be-deleters," I am hearing of this for the first time. So what of the wanna-be-keepers? Why can't they provide reason to justify keeping if they indeed believe the article should stay?. Why? –Ammarpad (talk) 05:20, 30 September 2018 (UTC)
    Because our Wikipedia:Deletion policy requires that a bona fide reason be given for deleting an article. Hawkeye7 (discuss) 02:59, 25 October 2018 (UTC)
  • Oppose per the closed discussion above. Note also that most prodders don't provide a detailed reason – they usually just make a vague wave to some other page. For example, consider Rusf10's most recent prod: "as per WP:NOTNEWS". One could wave back with exactly the same policy, which states "editors are encouraged to include current and up-to-date information within its coverage, and to develop stand-alone articles on significant current events". The devil is in the details and prod is not the place for this because there's no provision for discussion. Andrew D. (talk) 08:54, 30 September 2018 (UTC)
Yes, the devil is in the details: details like how the reason "the closed discussion above" was closed in the first place was because of Andrew's disruptively showing up to harangue me after I'd already withdrawn my proposal. The "consensus" was weak at best, and even the outright opposes (of whom there were two; one was essentially a "support in principle, but oppose as unpractical") appeared to agree that Andrew's behaviour was problematic and should be addressed with individual sanctions rather than an amendment to policy. Hijiri 88 (やや) 08:37, 1 October 2018 (UTC)
  • Oppose for now Per my own identical proposal above, I agree with this in principle, but the reason I withdrew it is because it's not going to happen at the moment. Dealing with the disruptive deproders individually, perhaps with sanctions, should be a priority; see if problems persist even with good-faith editors after that happens, then propose changing he policy. Hijiri 88 (やや) 08:37, 1 October 2018 (UTC)
  • Oppose By contrast, the risk of losing valuable articles by prodders unfamiliar with subject content is significant. DONOTLIKE prodding is all too common and should be reverted on sight, no explanation needed. Don't like it? Go through AfD. Samsara 18:17, 1 October 2018 (UTC)
  • Oppose because removing the prod template is all you actually need from de-prodding. Adding the template means "I think this should be deleted, and I think that doing so will be uncontroversial". Removing it, even if there's not a single word typed, means "I think this should not be considered an uncontroversial deletion". If you want it deleted, then your next step should be AFD, not badgering the editor who thought the deletion might be controversial to provide an explanation that will WP:SATISFY you. You already have all the explanation you actually need: someone disagreed with you, and therefore it does not qualify for PROD. WhatamIdoing (talk) 20:42, 1 October 2018 (UTC)
  • Oppose per WhatamIdoing. Use AFD. Johnbod (talk) 22:39, 6 October 2018 (UTC)
  • Weakest possible support I like the idea in concept, but in practice 99% of the rationales are going to be WP:ITEXISTS, WP:ILIKEIT, WP:ITSIMPORTANT, WP:VALUABLE, etc., making it effectively useless. --Ahecht (TALK
    PAGE
    ) 16:39, 9 October 2018 (UTC)
  • Oppose per WhatamIdoing; PROD is for strictly uncontested cases, and a successful de-PROD does not produce prejudice against other sorts of nominations. Keep it simple. {{Nihiltres |talk |edits}} 17:30, 9 October 2018 (UTC)
  • Support This is the biggest problem with prods – removals by IPs with no rationale that just mean countless hours wasted on AfDs that will almost always result in a delete outcome. Number 57 20:13, 9 October 2018 (UTC)
  • Oppose, as Nihiltres makes a good point. We could consider changing policy to disallow IPs from deprod'ing articles and use a bot to enforce it, which would at least add some accountability. When a regular user deprods, you can always just ask them why. With an IP, that is often impossible to do. Dennis Brown - 16:58, 12 October 2018 (UTC)
  • Oppose - The burden should be on the person nominating an article for deletion to explain their rationale, even when prodding it. However, I think Dennis's proposal is also something to seriously consider. There are quite a few good, productive IP editors who can be trusted to reasonably contest PROD tags, but there are at least as many vandals or otherwise inexperienced unregistered users who simply delete tags and move on. It makes sense to limit this ability to registered users. Kurtis (talk) 18:01, 14 October 2018 (UTC)
  • Oppose - The PROD process works as it is supposed. Articles are deleted that n one has any concerns about. If someone has any concern about an article being deleted it shouldn't be deleted via PROD. This would just add a bureaucratic step that add nothing to the process. I can agree that it is best to explain why the PROD was removed but see no reason to mandate it. ~ GB fan 19:51, 14 October 2018 (UTC)
  • Oppose - Too many IPs posting drive-by PRODs with no rationale. [2] Hawkeye7 (discuss) 02:46, 25 October 2018 (UTC)
  • Oppose The whole rationale for PROD is that it's for non-controversial deletions. If it's to be turned into something else, a kind of ultralite AfD, I could see an argument for that, but the case should be made explicitly, not folded into a procedural requirement. --Trovatore (talk) 03:14, 25 October 2018 (UTC)
  • Support as making at least a token effort to explain one's decision (just as a PROD-er has to explain their reasoning) is civilised. Amisom (talk) 19:15, 28 October 2018 (UTC)
  • Support. Because sometimes a trolling anti-deletionist will do a massive dePROD just because they hate the idea of a PROD, and it is difficult to deal with them outside asking an admin for a POINTy disruption evaluation. --Piotr Konieczny aka Prokonsul Piotrus| reply here 08:55, 29 October 2018 (UTC)
  • Oppose adding a formal requirement. If there is disagreement, the Prod process already escalates to AfD automatically. Deryck C. 11:10, 29 October 2018 (UTC)
  • Oppose. It should be encourage, but if someone believes an article shouldn't be deleted, it's not an uncontroversial deletion. A significant number of prod nominations each week are thoroughly incompetent, coming from editors who seem to look for any articles in bad shape and try to get them deleted for that reason alone, irrespective of whether they are likely to be uncontroversial deletions. Removal of prod tags is not the main problem here. I would also note that a deprod should not automatically result in an AfD nomination, as taking articles that are unlikely to be deleted to AfD results in an unnecessary drain on resources. Deprods with an explanation of why the subject is notable are routinely taken to AfD by some editors as a knee-jerk reaction. Those editors are the problem. --Michig (talk) 17:53, 29 October 2018 (UTC)
  • Agree with the principle, we should explain every non.trivial action. But as U:WhatamIdoing explined quite well, (de)proding is self explanatory. So, oppose - Nabla (talk) 19:26, 3 November 2018 (UTC)
  • Oppose. Too much scope creep in this. Once we start require explanations, then we'll get into "well, your explanation wasn't good enough for me" sort of nonsense. Softlavender (talk) 00:39, 4 November 2018 (UTC)
  • This was already SNOW Opposed above: WP:Village pump (policy)#PROD proposal 5: Require an explanation for removal of a PROD template WITHDRAWN. Why is it being re-introduced? Softlavender (talk) 03:21, 4 November 2018 (UTC)
  • Oppose. Only if PROD requires a reason. But then, a reason for, a reason against, go to AfD. —SmokeyJoe (talk) 06:07, 4 November 2018 (UTC)
  • Oppose We have 3 sections all proposing the same thing...but might as well oppose here as well. -DJSasso (talk) 12:16, 5 November 2018 (UTC)

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

Official websites that violate copyright

Editors in this thread appear to be of the opinion that is is permitted to link to websites which violate copyright so long as it is the official website of the subject of the article. Citing WP:COPYLINK:

In articles about a website, it is acceptable to include a link to that website even if there are possible copyright violations somewhere on the site.

This is at odds with WP:ELOFFICIAL:

These links are normally exempt from the links normally to be avoided, but they are not exempt from the restrictions on linking.

WP:ELNEVER in turn states:

material that violates the copyrights of others per contributors' rights and obligations should not be linked, whether in an external-links section or in a citation

Furthermore, copyright violations is part of the TOU and is therefore not an issue which is subject to consensus.

Simply put, if there is a local policy that permits copyright violating links, then the local policy is wrong, and should be changed or ignored. GMGtalk 14:31, 16 October 2018 (UTC)

  • The official website link itself does not violate copyright. Same reason while why some youtube links violate copyright that does not mean we can't link to "youtube.com" or other youtube links. Technically, one could also link to sci-hub pdfs of public domain material etc Galobtter (pingó mió) 14:41, 16 October 2018 (UTC)
  • And YouTube has a regime in place to detect and remove copyright violating material, even if it lags behind uploads. This is not the case when linking to a site for which the violation of copyright is their core purpose, and who is frequently changing domains in order to avoid enforcement of copyright laws. Linking to such as sight is helping to bypass the copyright protections they are trying to avoid, and is therefore contributory copyright infringement. GMGtalk 14:54, 16 October 2018 (UTC)
  • I have yet to find anything indicating that simply linking to a website that contains copyrighted material on one of its other pages has been ruled contributory copyright infringement. Directly linking to copyrighted material on another page definitely has, but the homepage of a service that simply can be used to obtain copyrighted material? Seems more like original research than anything explicitly established in policy. --tronvillain (talk) 16:58, 16 October 2018 (UTC)
  • There are plenty of old copyright violations on Youtube. As a matter of fact, I'm listening to one right now, and furthermore it's easily reachable using Youtube's native search, in much the same way that copyright violations are accessible on Sci-Hub using that site's search bar. DaßWölf 02:07, 17 October 2018 (UTC)
  • There's no conflict with WP:ELNEVER: no material that violates the copyrights of others is being linked to. Unless you can tell us how to click through to copyrighted material from those pages? --tronvillain (talk) 15:08, 16 October 2018 (UTC)
    • This is the crucial point - the mainpages of Sci-Hub and The Pirate Bay do not contain any copyrighted material. SmartSE (talk) 15:10, 16 October 2018 (UTC)
      • And unlike The Pirate Bay, you can't browse to anything on Sci-Hub. --tronvillain (talk) 15:13, 16 October 2018 (UTC)
        • Yes, you can. Note the dozen-plus links to journals on their home page, because it is a website whose purpose is to violate copyright. GMGtalk 15:15, 16 October 2018 (UTC)
          • I'm not seeing a "dozen-plus links to journals on their home page", and I'm looking pretty carefully. There's the search area, the "About" section, the "Ideas" section, the "Community" section, the "Donate" section, and some share buttons. Where are these links? --tronvillain (talk) 15:26, 16 October 2018 (UTC)
            • Are you looking at their original website, or one of the dozen alternate domains they've registered to circumvent copyright law? GMGtalk 15:31, 16 October 2018 (UTC)
              • I'm looking at the pages you removed. Unless for some reason we're talking about different websites that weren't being linked to? --tronvillain (talk) 15:35, 16 October 2018 (UTC); edited 15:46, 16 October 2018 (UTC)
                • Regardless, the claim that the link is not copyright violating is hollow when the entire point of the site linked to is to violate copyright. GMGtalk 15:53, 16 October 2018 (UTC)
                  • So these links you're talking about don't exist in the pages you removed? Great, I'm not just missing something obvious. It's really not hollow, when the policy you're citing is about linking to material that violates the copyrights of others, not to websites that can potentially be used to obtain such material. --tronvillain (talk) 16:00, 16 October 2018 (UTC)
                    • Except that courts have ruled that providing a service by which the public can easily and illicitly access copyrighted works is itself copyright violating. GMGtalk 16:07, 16 October 2018 (UTC)
                      • So, you're arguing for expanding WP:ELNEVER beyond not linking to copyrighted material to not linking to anything that might provide be used to access copyrighted material? I thought you were arguing for changing WP:COPYLINK, but okay. --tronvillain (talk) 16:21, 16 October 2018 (UTC)
                        • ELNEVER covers material that violates the copyrights of others. There is no change to ELNEVER necessary. There is already precedent that these services themselves, including this service in particular is copyright violating. GMGtalk 16:24, 16 October 2018 (UTC)
                          • That decision clearly says that Sci-Hub violated the American Chemical Society's copyright by distributing their copyrighted material, but it doesn't follow from that that their homepage in and of itself constitutes material that violates the copyrights of others. That particular interpretation presumably needs some consensus, or a clarification of the terms of use. --tronvillain (talk) 16:58, 16 October 2018 (UTC)
                            • The Pirate Bay ruling above does clearly state that these services qualify as a public broadcast for the purposes of copyright. The services themselves are copyright violating, and these sites serve no other purpose other than to facilitate the violation of copyright. GMGtalk 17:03, 16 October 2018 (UTC)
                              • Really? No other purpose? How do you explain the following link to a torrent of the GIMP v5.12 Open Source Image Editor, downloaded from The Pirate Bay? [3] --Guy Macon (talk) 13:31, 25 October 2018 (UTC)
                                Yeah, the "torrent sites = piracy" canard is silly. All sorts of things are distributed on them, including public domain material, and copyrighted material explicitly permitted to be distributed on them. It goes from silly to sillier when people try to blame the medium itself, the BitTorrent protocols.  — SMcCandlish ¢ 😼  20:39, 13 November 2018 (UTC)
                                • Example text Yes, we are all very lucky that these sites are being dragged through court, banned in multiple countries, constantly having their domains shut down and relocating, all so they can bravely provide us with legal content. (Didn't Pirate Bay try to buy their own nation once?) God bless them. God bless them every one. GMGtalk 20:47, 13 November 2018 (UTC)
  • It seems to me that this is a question that should be bumped up to the WMF’s attorneys. Blueboar (talk) 16:46, 16 October 2018 (UTC)
    • You might be right there. --tronvillain (talk) 16:58, 16 October 2018 (UTC)
      • I'm not sure we're going to get much more than a boiler plate statement, but ping User:Jrogers (WMF) anyway in case they'd like to weigh in. GMGtalk 18:03, 16 October 2018 (UTC)
  • Why would we link to a site that is known solely for hosting copyright material illegally? This link has no encyclopaedic utility. What are people going to do if they click the link? All they will find there is self-serving claims by a site that is, bluntly, criminal. Guy (Help!) 11:01, 17 October 2018 (UTC)
@JzG: Sci-Hub probably has more "encyclopedic utility" than Wikipedia. And saying "what are people going to do if they click the link?" is no different than saying "what will people do if they read the article?" Or "what will people do if they hear the name?" Obviously, they might look for it. Gee, that would be a shame. Violating "intellectual property" is the same kind of illegality as violating a slave-owner's carnal property. Wnt (talk) 01:26, 18 October 2018 (UTC)
What rot. The link on the Sci-Hub article is largely decorative. Clicking it says less about the site than we do because it presents the site from a perspective that is objectively incorrect. Contributory copyright infringement is also a thing. Guy (Help!) 16:02, 22 October 2018 (UTC)
Looking at the site is an objectively incorrect way of learning about the site? A link is "decorative" ... and that's why you're fired up to delete it? If what you say has a meaning, I'm not convinced at this point. Wnt (talk) 02:58, 27 October 2018 (UTC)
  • If the site's reason to exist is to distribute material clearly against copyright, we should not link to it at all. Site's where copyright violations may exist but that is not the reason or function of the site and particular now due to actions of the site's operators, like YouTube or Researchgate, we can link to. --Masem (t) 11:13, 17 October 2018 (UTC)
    Masem - What's your opinion when this is say, the official site of the subject in question. For instance, we have an article on The Pirate Bay, which has a official website to that page. Pages like WireShare also have a similar page setup. Lee Vilenski (talkcontribs) 11:24, 17 October 2018 (UTC)
    I removed the links on the Pirate Bay article also, but was reverted. GMGtalk 11:26, 17 October 2018 (UTC)
    If it is the official site, we should not include and probably have a message why no link is included. Wires are seems to be a client that can be used to violate copyright, but requires users to give that material, so it's less of a prolem. --Masem (t) 11:31, 17 October 2018 (UTC)
    Wireshare/Limewire is an opensource P2P client. By that reasoning literally every P2P client can be said to be 'used to violate copyright' - as can every web browser, archive tool (winrar) etc. The difference is that Pirate Bay exists only to provide direct links to copyright infringing material (with a smidgeon of public domain) and SciHub similar (and actually hosts copyright infringing material itself). Only in death does duty end (talk) 11:36, 17 October 2018 (UTC)
    And the 'official' link, if it can be called such on wireshare is to its source page at github. Github hosts a huge array of opensource projects. I dont think anyone is going to suggest we start removing github links as it enables copyright infringement are they? Only in death does duty end (talk) 11:40, 17 October 2018 (UTC)
  • Include these links is my official vote. The text in the "Restrictions on linking" section should be taken to mean that you should not include a link if and only if clicking the link would directly cause the user to download [including as extended content directly included within a web page] copyright-infringing material. Not because he might find out more about how or where to do so or read some philosophy or download some program that might make it easier for him to decide to do so. Wnt (talk) 01:29, 18 October 2018 (UTC)
  • I also vote that these links should be included: It should not be the role of Wikipedia editors to police the copyright behaviour of readers. If clicking on a link does not automatically trigger a copyright violation, and if there is no clear instruction from WP legal that this is not permitted, then Wikipedia users should be entrusted to make their own decisions with the information available.Kyle MoJo (talk) 08:51, 19 October 2018 (UTC)
  • If it is legal under US law for Wikipedia to link to the homepage of these websites, then these links should be included as they are for any other website. If we permit ourselves to censor links based on moral objections to the site's contents (as opposed to legal objections) then this will be a never-ending debate. (Which objectionable site's official links should we remove next, Pornhub's, AlphaBay's?) Sizeofint (talk) 15:50, 19 October 2018 (UTC)
  • I think there's a distinction to be made between linking to a page that is itself a copyright violation, and linking to a service that sometimes hosts copyright violations somewhere on it. For me, the difference is between linking to the main YouTube page (which has no copyright violations) and linking to a video on YouTube that is itself a copyright violation. If the page we link to is itself kosher, there's no reason we shouldn't link to it (provided it meets other policies and guidelines, yada yada). --Jayron32 16:14, 19 October 2018 (UTC)
That misses the main thrust of the issue though. YouTube is a legitimate site that happens to have some copyrighted material on it (so is Wikipedia if we're being honest). No one is raising a fuss in that regard. The problem is when we have a site whose core purpose is the violation of copyright, and which courts have ruled are in-and-of themselves copyright violating services. That's potentially legally problematic, especially for sites that have been blocked in multiple countries, and for whom our article is likely higher in search results than their actual website.
I don't expect legal to actually give us an opinion on the matter, although I have emailed them and notified them of this thread. (Legal, in my experience, doesn't express much of an opinion on copyright unless they have a takedown notice in hand.) But just because legal won't preempt themselves in public on an issue they may have to one day argue in court, doesn't mean this doesn't have foreseeable potential legal implications. GMGtalk 00:06, 20 October 2018 (UTC)
I think the en.wiki community is neither required, nor particularly competent, to judge fine legal niceties like this. If the Foundation lawyers are worried about it, they'll let us know; it's certainly been pointed out to them. If they're not, I don't see why we should be. --Trovatore (talk) 00:18, 20 October 2018 (UTC)
Even if there is some lawsuit out there by the ACS (one of the worst offenders in terms of paywalled articles), that would only speak to their liability to ACS about ACS articles according to a court far from Sci-Hub's own country. A private lawsuit between those parties could not have produced an overall determination of the "core purpose" of the site as some kind of law or regulation that everyone else is supposed to know about or follow. I think that the core purpose of the site is obvious: it is meant to allow people all over the world to share the text of articles to which they have access with people who express their interest; in other words, it is an interlibrary loan site very similar in nature and operation to WP:WikiProject Resource Exchange or ResearchGate, though more efficient. While American Chemical Society may be eager to extract a few dollars from peasants particularly desperate to see some article, this foolish crusade comes at a substantial cost -- because what is the ordinary voter going to do who hears about a chemical controversy and runs into a paywall telling him he's not allowed to see the publicly funded science for himself? He is going to do what any intelligent person would do in that situation and conclude that "chemicals are bad for you." You can't blame a person for having a stupid point of view when you have hired guns standing over him to force him to be stupid. But I digress. Wnt (talk) 20:44, 20 October 2018 (UTC)
Interlibrary loan terms are agreed to in contracts and subscription packages, and have various restrictions (and generally a charge on the part of the borrowing library, explicitly to protect copyright). Sci-hub, by it's own admission, has none of that. Every source agrees that it's intentionally and knowingly violating copyright laws on the articles. There's never been a colorable legal argument made by Sci-Hub or any of its defenders to the contrary; indeed, part of its justification is that those laws are unjust, harmful and deserve to be defeated, but not that they aren't being violated as they currently exist. That's it's whole reason for existence. The fact that I think modern copyright law is insane (which it is) doesn't change that it is the law at the moment.Just a Rube (talk) 11:46, 22 October 2018 (UTC)
To the best of my knowledge, any such guidelines are not universally followed even in the United States, and it is worth noting that Sci-Hub is not in the United States and is free to follow whatever legal standards its country adopts for Fair Use. The site has not been shut down, its maintainers have not been arrested, and so the only question is whether your national network is going to censor foreign traffic because it contains dangerous information, or ban local discussion of how to access such networks. Wnt (talk) 03:10, 27 October 2018 (UTC)
  • No link the site's entire purpose is to violate copyright law. There is no non-infringing purpose behind it. Anyone who wants to find the site can find it easily without including a link.Just a Rube (talk) 11:46, 22 October 2018 (UTC)
    • Really? No non-infringing purpose? How do you explain the following link to a torrent of the GIMP v5.12 Open Source Image Editor, downloaded from The Pirate Bay? [4] --Guy Macon (talk) 13:31, 25 October 2018 (UTC)
      • Given that Gimp is only at v2.10, one has to ask out legit that is. It is known that software pirates often rename files to mask what they offer, this looks like such a case. --Masem (t) 13:36, 25 October 2018 (UTC)
        • I don't want to delve into nitty gritty of version numbers of package components, so I'll just cite Darkwood, TPB AFK, 3D printer data distributed on Pirate Bay. I'm sure there are other "legitimate" uses. (Well, you can argue the last isn't legitimate since the data is banned in the U.S. under the 1st and 2nd amendments, but Pirate Bay isn't in the U.S., and the U.S. actually targeted one person only, so... but Wikipedia made me take out Infowars' link to the topic that came up, because you know that's fake news ... computers are all about the owner of the computer telling everyone else what to do for no reason at all, so I shouldn't be surprised at any of you any more. You live to serve your Master, period.) Wnt (talk) 03:29, 27 October 2018 (UTC)
  • Do not link to any dedicated copyright violating service. I'm not above admitting to using Sci-Hub, or the Pirate's Bay on occasion, but that should not be taken as any sort of push to legitimize them. If there is no other significant service offered by the site, then there is no encyclopedic value offered by including the link. Peer-to-peer networks and clients are not dedicated copyright violating services, but -like YouTube or google image search- are services which are frequently misused for that purpose. ᛗᛁᛟᛚᚾᛁᚱPants Tell me all about it. 12:43, 22 October 2018 (UTC)
  • Yes link. The purpose of the link is key. You can't use a link to point to infringing content relevant to some article, but of course you can use a link to identify and access a site itself. Alsee (talk) 01:27, 25 October 2018 (UTC)
  • Yes link - Linking to a domain is not infringeing copyright. What our readers do once they navigate to a site is up to them. It would be pretty stupid for a website article not to have the URL - it's one of the fundamental pieces of information about the topic and we are not meeting our readers' expectations if we do not include them. If there are legal issues with us linking to the, them WMF legal will let us know, but the fact that these links have been present so long indicates that they are not. SmartSE (talk) 12:11, 25 October 2018 (UTC)
  • Yes Link. Even a site like The Pirate Bay has legitimate uses. For example, it is the fastest way to download older versions of Slackware Linux. And a site like Google can easily be used to find copyright-infringing material. --Guy Macon (talk) 12:36, 25 October 2018 (UTC)
  • No link - It’s not just that the admitted purpose of the site is to violate copyright, and linking to the site aides and abets illegal activity; but the site is used for spreading malware. O3000 (talk) 13:25, 25 October 2018 (UTC)
  • Yes Link. It seems like a silly political statement to leave the link missing and looks like an error.Sushilover2000 (talk) 14:29, 25 October 2018 (UTC)
  • Well here's the Foundation Legal response:

I'm a bit late replying, but thought I'd offer a couple thoughts. First, the actual legal doctrine is nigh-impossible to do anything with. Links like this vary by country, and the current doctrine in Europe asks questions about the specific knowledge of the person doing the linking and whether the link is for commercial purposes, among other things. I would suggest that the Foundation is not going to overrule the community if people think that specific links are appropriate and important for an encyclopedia article on a notable topic, but there is a chance we could receive legal demands in specific cases that cause us to have to change something, which we would evaluate on a case by case basis if it came up. Also, just as a matter of community good will, if you know that a particular Wikipedia page is being used as a hub to facilitate copyright infringement for some reason, it's probably good to make changes to prevent that, regardless of the specifics of what the law says.

For whatever difference that makes to anyone. GMGtalk 21:25, 25 October 2018 (UTC)
It means I really regret that Mike Godwin, a couple of months after dissing the FBI on our behalf, somehow ended up bundled off to a loony bin. He was never prone to mumble! Nor would he have been one to contemplate retreating without a fight based on mere demands from the right-placed parties. But that kind of private law isn't something you can try to anticipate -- they're nonetheless saying they'll do whatever whenever, and we can go back to our regularly scheduled article unless and until they make it a ruin. Wnt (talk) 03:04, 27 October 2018 (UTC)
Also, just as a matter of community good will, if you know that a particular Wikipedia page is being used as a hub to facilitate copyright infringement for some reason, it's probably good to make changes to prevent that, regardless of the specifics of what the law says And what about WP:NOTCENSORED?
  • Here is an idea. Forbid any links to any site that may link to any other site that may link to copyright infringing material. That makes it simple: we can set up a bot that removes every citation on Wikipedia. No more arguing about sources if all the sources are removed! The only downside is that the copyright-industrial-complex will say that this is not good enough, and that we need to form death squads to kill suspected infringers. --Guy Macon (talk) 05:44, 27 October 2018 (UTC)
Your logical fallacy is: slippery slope. This site is dedicated to copyright violation. It's not about some links to a site that might hypothetically link to another site that violates copyright, it's about direct links to a site whose sole reason for existence is the systematic violation of copyright. Guy (Help!) 10:52, 27 October 2018 (UTC)
From between the serapham, JzG has judged the sole reason for existence of a site. Yup, these sites are only for copyright violation. Unless they're also for distributing documentaries and games legally, as I cited above, or more interestingly, for violating censorship not-laws against making a drawing of a gun that someone could use to program a 3D printer. Really, I think the 3D printing business could be Pirate Bay's biggest draw in a few years, because just think of all the stuff various governments will be looking to ban blueprints for. I mean, what if you could 3D print the little plastic thingamajjig that is absolutely required to close your microwave door and authorize its electronic Brain to allow you to turn it on and which is designed to break every 3 years to make you buy a new one? Making one the right length with the right curve to fit would violate, oh, patents, design patents, business model patents, and copyrights on their mode of operation, right? Somebody gotta ban it, and it'll turn up on Pirate Bay. Or what if you could 3D print eyeglasses that aren't within the legal range of farsightness to be sold cheaply on a rack at the drugstore, undermining the doctors' racket? Somebody gotta ban it. Or what if you could make something to bypass location tricking on a fancy new self-driving car and make it visit a location proles aren't allowed to? It would be out and out terrorism! What if you could download a banner opposing fascism or supporting democracy during the key period before the election in Brazil where such content is taken as obviously partisan against Bolsonaro? [5] Obviously gotta ban that, worldwide. So I see potential for all kinds of Illegal Activities On Pirate Bay that don't fall strictly into the realm of copyright violation. Wnt (talk) 12:49, 27 October 2018 (UTC)
And according to our Sci-Hub article, that website has a significant amount of public domain content that heretofore was hidden behind paywalls. Sizeofint (talk) 17:01, 27 October 2018 (UTC)

Foundation Legal isn't stopping us from linking, so legality isn't the issue here. To summarize the above discussion, it seems like those opposed to linking are mostly just making moralistic arguments in favor of attempting to police the behavior of our users. If this discussion is indeed such a moral judgement, then I suppose I'd toss my vote in favor. But of course, I was under the impression that Wikipedia is not censored. Benjamin (talk) 08:24, 3 November 2018 (UTC)

  • "Should not" does not mean "must not". Stifle (talk) 10:05, 5 November 2018 (UTC)
  • Yes Link. The site may indeed contain copyright-infringing material, but I find it unlikely that the site itself is a copyright violation, as some above seem to be arguing. If so, whose code did they copy? If it's that much of a problem, add a warning. --Auric talk 15:11, 12 November 2018 (UTC)

Removing warnings on one's own talk page

One thing that has frequently happened to me is that I would be looking through a user's talk page before giving a warning, lo and behold, they were given a level 4 warning and I didn't know it because they blanked their talk page. It is extremely inefficient to browse diffs to see what warnings they were given. Per WP:BLANKING, people can delete warnings as evidence that they read the warn. I would like to propose a change to that policy that allows users to remove warnings only if the warned user and issuing user come to an agreement or a set amount of time has passed (lets say 6 hours) which allows recent changes patrollers to see if the user is a persistent problem or just a one off incident. Kyle Bryant (talk) 02:31, 17 October 2018 (UTC)

Wikipedia:Perennial proposals#Prohibit removal of warnings. – Finnusertop (talkcontribs) 10:13, 17 October 2018 (UTC)
If the WMF wanted to help us with this, they could easily make it so that a person just reading the talk page doesn't see the deleted warnings but a special button makes them visible. They could allow anyone to push that button, only extended confirmed users, or only admins.
I wonder, would a script be able to automate most of the work of searching the history for deleted warnings? --Guy Macon (talk) 10:56, 27 October 2018 (UTC)
    • Support proposal for button, as the warnings easily get deleted and out of view so making problematic editing situations difficult to judge Atlantic306 (talk)
  • Meh... I don’t find it onerous to look in the talk page history to see if a user has received previous warnings. No big deal. Blueboar (talk) 14:14, 4 November 2018 (UTC)
  • Oppose; the purpose of a user talk page is to serve as a means of communication with that editor, not as a wall of shame documenting that editor's past mistakes. If the five seconds it takes you to click on "history" is too long for you, you're the one editing too quickly and without due care and attention. ‑ Iridescent 14:26, 4 November 2018 (UTC)
  • Oppose- If some chucklehead wanders by to plaster a frivolous warning on my talk page, of course I am going to remove it. Reyk YO! 14:33, 4 November 2018 (UTC)
    Urge to warn frivolously...rising...Deacon Vorbis (carbon • videos) 14:46, 4 November 2018 (UTC)
  • Oppose because it took all of my stockpile of self-control for the day not to go post a snarky warning on the OP's talk page and therefore it's all Wikipedia's fault I just ate a giant chocolate-chip cookie for lunch. Opabinia externa (talk) 21:37, 4 November 2018 (UTC)
  • Question, how difficult would it be to just make a user script that looks at the page history and displays a list of warnings, from say the last 2 days, or maybe a configured amount? If possible it would remove the need for policy changes while allowing people who want/need the information to get to it easily. zchrykng (talk) 22:04, 4 November 2018 (UTC)
  • Oppose, but I would support adding a separate log for user warnings, with a tab visible to admins showing recent warnings to a given user. bd2412 T 22:30, 4 November 2018 (UTC)
  • Oppose. I can't make much sense of the idea that if I give someone a warning I have to also have a discussion with them and come to an agreement about when they can remove the warning from their page. If I were an asshole, I could withhold that agreement indefinitely just to stick it to them. WP has plenty of assholes. More to the point, if I'm leaving someone a warning, I have way better things to do that have a pointless discussion with them about the archiving of their talk page. Especially since their disagreeableness and inability to work toward compromise with other editors may be the proximal cause of them receiving the warning. In short, WP:NOT#BUREACRACY.  — SMcCandlish ¢ 😼  10:31, 11 November 2018 (UTC)
  • Oppose - Would create more problem than it solves.
    The script ideas above aren't bad, but how often does a script-qualified editor who doesn't feel strongly about the need devote the time to create a script because there is a consensus among a few people at the Village Pump? I don't know. ―Mandruss  11:21, 11 November 2018 (UTC)

Request for comment on the specific term "fuck off" – sanctionable or not!

Resolved: Discussion already closed, without consensus for any policy change.  — SMcCandlish ¢ 😼  06:55, 12 November 2018 (UTC)

Discussion here.--David Tornheim (talk) 22:51, 27 October 2018 (UTC) [revised 09:19, 31 October 2018 (UTC)]

Expand criteria for women's teams/coaches/players in WP:NHOCKEY

Recently I dePRODed the Cara Morey article. Failure to meet WP:NHOCKEY was given as one of the reasons why it was proposed for deletion. Reading through the criteria, it appeared to me that there are no entries applicable to women's teams or coaches. When I stated this, I was told that the criteria for females was to have been in the Olympics or to have played in World championships. Considering this far narrower criteria for women, and the wider opportunities for men to have a presence on Wikipedia as notable players or coaches, it seems to me that more opportunities for participation in various competitions or leagues should be added to WP:NHOCKEY to be inclusive qualifiers of women's ice hockey, particularly as the organizations themselves are pushing for more females to participate in both playing and coaching. I am no expert on any sport by any means, but I am in favor of having more opportunities for women to have articles if they are indeed notable, so I thought I would present this here for more knowledgable editors to discuss. LovelyLillith (talk) 20:43, 28 October 2018 (UTC)

I think the first question has to be how popular women's ice hockey is as a spectator sport (which is how players would derive notability if not playing for their national sides). If enough people are watching the matches for the leagues to be fully-professional, then the leagues should probably be added to the list. If the leagues are semi-pro or amateur, then in all likelihood the players in them are unlikely to be given default notability. Number 57 21:50, 28 October 2018 (UTC)
@Number 57: In response to professional women's hockey as a spectator sport, four of five NWHL teams play in NHL teams' practice facility, with seating up to about 2000 max. The other is a local rec center in a Stamford park. As far as I tell, the NWHL does not publish attendance figures, however, those arena capacities are below what would be accepted for an expansion team in the ECHL, and are more in line with would be found in the Federal Hockey League or non-Major Junior ice hockey. (Although every game so far at the TRIA Rink for the Whitecaps have been reported as "sold-out", but with a four-game sample size.) As to "fully-professional", as of last season both the NWHL and CWHL pay player salaries, but not nearly enough for the players to not also need a second job in order to make a living. On the other hand, I don't agree that either being widely spectated or being well-paid directly implies notability per the WP:GNG, which is more about significant independent media coverage of each person as an individual. Although it can, and usually does, correlate (more spectators -> more media). Yosemiter (talk) 17:56, 30 October 2018 (UTC)
Note the hockey-specific notability criteria are used as a predictor that the general notability guideline can be met. If it can be shown that the general notability guideline is met, the article can be kept. The hockey-specific criteria are just there to keep obvious cases from being quickly deleted, so they are set very conservatively. isaacl (talk) 21:54, 28 October 2018 (UTC)
I've also raised this issue in the past. I've never come across a criteria which extremely explicitly discriminates against women's sport before, and I've seen articles deleted because of it where a man in the exact same equivalent league with the exact same equivalent referencing would be a unanimous keep. It's an odd one out - I can't think of another notability criteria on Wikipedia period which specifically names only men's competitions as resulting in notability (and yet purports to cover women). I couldn't care less about hockey as an Australian, but it sits very badly with me. The Drover's Wife (talk) 00:08, 29 October 2018 (UTC)
WP:NBASKETBALL comes close. Players are notable if they play for the NBL but not the WNBL. Hawkeye7 (discuss) 05:29, 29 October 2018 (UTC)
Which is absurd. The University of Canberra Capitals were far more likely to be household names in their area than the Sydney Kings were in theirs, with the newspaper and television coverage to boot. This is a perfect example of where the assumptions a minority of editors make break with reality. The Drover's Wife (talk) 08:52, 29 October 2018 (UTC)
For better or worse, the general notability guideline is based on a subject receiving suitable coverage in independent, non-routine, non-promotional, reliable sources. The sports-specific notability guidelines do not seek to replace the general notability guideline, so equivalence of achievements is not used to determine their criteria. The criteria are set based on their ability to predict the existence of suitable sources such that the general notability guideline is met. isaacl (talk) 08:44, 29 October 2018 (UTC)
Except that they're not - they're based on an assumed notability, regardless of its relationship to actual sources. And this is is how you can have a male player considered notable and a female player considered not notable with the exact same sourcing - and a level of sourcing that is extremely common across Wikipedia's sports coverage generally at that. There is no reasonable basis for holding women to a higher sourcing standard than men for the sole reason that they're women. The Drover's Wife (talk) 08:52, 29 October 2018 (UTC)
If suitable non-routine, independent, non-promotional reliable sources can be produced, then the article can pass an article for deletion discussion. In addition to not setting a lower bar, the sports-specific notability guidelines are not used to set a higher bar, either. There are plenty of members of the hockey WikiProject who would love to have more coverage of women hockey players and would back up any discussion if the sources are there. isaacl (talk) 18:09, 29 October 2018 (UTC)
@The Drover's Wife: Except "a male player considered notable and a female player considered not notable with the exact same sourcing" is not true. In Wikipedia:Articles for deletion/Tatiana Rafter, I immediately pointed out two other male players with more coverage of the so-called "exact same sourcing" that were deleted (here and here) without argument in the same time frame. Yosemiter (talk) 19:03, 29 October 2018 (UTC)
Number 57 is right. Quite frankly, most Women's sports receieve nowhere near as much coverage in sources of any kind compared to the equivalent Men's sports. It's not our job to give coverage to Women's sports where reliable sources don't just because the Men's equivalent gets covered by reliable sources. The WP:NSPORTS SNGs should make clear where coverage is equivalent (e.g Tennis), and where it isn't (most other sports). IffyChat -- 12:09, 29 October 2018 (UTC)
  • Is the criteria for women hockey players not also significant writing in reliable source texts? Is there some extra hurdle for writing articles about female hockey players? --Jayron32 14:05, 29 October 2018 (UTC)
    • This isn't about an extra hurdle. What WP:NHOCKEY provides is a substitute for significant writing in reliable sources. There just needs to be a record of having played at a certain level or in certain number of games, rather than an article discussing a given player. The criteria seem to be tied to the sizes of the audiences for the various leagues. Where audiences are large, this criteria is saying that players can be well-known in the Wikipedia sense because they have been seen by large numbers of people, rather than having in-depth written coverage. StarryGrandma (talk) 16:46, 29 October 2018 (UTC)
      • If you don't have reliable sources to add content to articles, where are you getting the information you are putting in articles? --Jayron32 16:50, 29 October 2018 (UTC)
        • The issue is notability. If a person is notable enough for an article, then local newspapers, interviews, team websites, and other sources that don't establish notability are fine for content. StarryGrandma (talk) 17:05, 29 October 2018 (UTC)
          • That's bass-ackwards. It is the newspapers and interviews and other sources that establish notability. Please read WP:GNG or WP:42 or the like. The lack of reliable, independent source texts is what determines whether or not we have an article. The only reason for the concept of notability to even exist at Wikipedia is to establish if we have enough useful source text to even bother writing the article. If the source text exists, we write it. If the source text does not, we don't. It's not more complicated than that; any confusion caused when understanding the concept of notability at Wikipedia is largely caused by people who couldn't find enough good source text to write articles about things, so tried to create loopholes in this otherwise sensible standard. --Jayron32 18:05, 29 October 2018 (UTC)
              • Not really, the criteria is significant commentary, beyond WP:ROUTINE. Having a source that says Bob Smith scored two goals in a minor league game in a local newspaper is not the same as a, e.g. Newsweek interview with the person. Headbomb {t · c · p · b} 18:12, 29 October 2018 (UTC)
                • That's about content not about notability. We would never write about the performance of a single, routine game in an article about an athlete. If the entirety of a person's life story exists entirely of such writing, then they aren't notable, per WP:GNG, no matter what their job title is. The whole point of notability is to establish that enough good content can be put in an article. You've just brought up an example of content that would never be added to an article. --Jayron32 18:26, 29 October 2018 (UTC)
      • The sports-specific notability guidelines do not provide a substitute for meeting the general notability guideline. They just provide a buffer to avoid quick deletion when there is very good reason to believe that the general notability guideline can be met. (This was the consensus agreement when the guidelines were created, and it has been affirmed many times since then.) isaacl (talk) 18:15, 29 October 2018 (UTC)

Here's what I wrote in an earlier discussion.

Simply put, the caliber difference and the visibility of women's hockey/NWHL in general is what makes the NWHL players less notable than NHL players. The NWHL is a 3 year old league, 5 teams, with a 2.5 million dollar budget, which more or less bring it to par with the NHA. The NHL is over 100 year old, has 31 teams, and is considered the premier hockey league in the world, with revenues in the $2.5 billion range. While NHL teams are exclusively North American, it draws players from all over the world because no other league compares to it. Norway women don't train for years hoping to be part of the NWHL. While the NWHL may want to be the equivalent of the NHL for women, if you compare its status amongst in women's hockey, it falls short of the status of the NHL in men's hockey.

This still applies. When leagues have equal status in a sport, leagues should be treated as equivalent for notability. The top male/female leagues of tennis, badminton, ping pong, curling, bowling, etc... have equal status. The top male/female leagues of hockey, baseball, basketball, football, don't. Headbomb {t · c · p · b} 16:19, 29 October 2018 (UTC)

I don't really want to repeat what I wrote at Wikipedia:Articles for deletion/Tatiana Rafter again, but the short version is that GNG-worthy coverage needed to consider ALL players in the CWHL and NWHL notable is too inconsistent. It is mostly relegated to coverage from the local NHL team's SBNation site, less than that of the NHL team's AHL affiliate, and tends to come from the more blog-like posts on that site rather than the paid editors (SBNation is a bit of mix these days). So the hockey project treats women hockey players on a case-by-case basis for GNG, some of which pass. Having spent some time trying to fix women's team pages this year in the CWHL, I have had a hard time finding reliable sources from as recent as 2010 (as I mentioned at Wikipedia talk:WikiProject Ice Hockey/Archive72#Looking for some clarification) when the CWHL appears to have only been consistently covered in personal blogs until a championship game. As discussed in that AfD, women's hockey gets about as much coverage on its own as a niche sport like water polo or lacrosse (which also do not have a SNG, but there may be other reasons for that). Yosemiter (talk) 18:41, 29 October 2018 (UTC)

Also, as it pertains to women's teams, they are presumed notable in both the CWHL and NWHL. However, as I pointed out in the above archived discussion, finding reliable references for many of the teams from prior to about 2014 has been quite difficult. I challenge any editor to find what arenas the Quebec Phenix played their home games in reliable refs, without using any wikipedia references (because I had to fix them using recently, it was apparently wrong here for years). Yosemiter (talk) 14:47, 30 October 2018 (UTC)
A tricky situation here. Should NHOCKEY be gender blind or not, in its application to ice hockey? GoodDay (talk) 18:22, 31 October 2018 (UTC)
As much as it pains me to say it, no, it shouldn't. NHOCKEY, like all of NSPORTS, is essentially a shortcut to answering "does this person have enough non-routine coverage to make them notable per GNG?". While playing a game in the NHL or 200 games in the AHL is a pretty good indicator that the person gets non-routine coverage, thanks to bias in public interest (as reflected in the media), the same isn't true for women's hockey. --Ahecht (TALK
PAGE
) 18:34, 31 October 2018 (UTC)
Then there's the transgenders in ice hockey & how NHOCKEY should deal with them. GoodDay (talk) 19:01, 31 October 2018 (UTC)
Okay, so technically gender of the player doesn't actually matter, it's whether they play in a men's leage or a women's league. If a transgender person (or a woman for that matter) played in the NHL or 200 games in the AHL, for example, they would pass NHOCKEY. --Ahecht (TALK
PAGE
) 16:13, 1 November 2018 (UTC)
Harrison Browne did receive plenty of coverage in the NWHL as transgender, but not really for anything that could be written as a NSPORT-type SNG, just that fact that he was transgender and playing hockey. As for women in the AHL, if it were to happen, they would almost certainly (speculation of course) meet GNG for the rarity of it. In the times that women have played in the pro leagues that are traditionally male (as there are no league bylaws stating a player must be male), they have received coverage for it (Shannon Szabados, Manon Rhéaume). But I am also unaware of any female players that have played in the men's leagues (at any level) that did not also play for an Olympic team anyways. Yosemiter (talk) 16:32, 1 November 2018 (UTC)
  • I come in here from two directions: first, as a partisan of women's hockey, where I wager I'm one of the few in this discussion to actually have been a season ticket holder for a women's collegiate team (Northeastern University) and certainly the only one to have seen the first woman to play in the American Hockey League (Erin Whitten for the Adirondack Red Wings) ... and second, as the original author of the NHOCKEY guideline. As such, editors like Ahecht and Yosemiter are exactly right. The purpose of NHOCKEY, as with the other NSPORTS guidelines, is solely "does this person have enough non-routine coverage to make them notable per GNG?". At the hockey Wikiproject, we've done extensive examinations -- because this question's been coming up time and time again -- of individual key players, and over and over again, the media just doesn't care. My classic example is that when the Boston team won the inaugural NWHL championship, in a city with intense media and sports coverage, neither of the Boston dailies reported it. It sucks, it's unfortunate, but there are no grounds beyond the ideological to make any changes here. Ravenswing 18:57, 31 October 2018 (UTC)
  • As more evidence for what the current SNG implies, I previously linked Wikipedia:Articles for deletion/Joey Anderson as a subject that failed NHOCKEY 3 months ago, had about 1,000 G-News mentions at the time, and was deleted without argument as WP:TOOSOON and only routine mentions. This is about 4-5 times as much coverage as a typical player in the NWHL that has won an award/achievement (because as Ravenswing said, we have looked into this often). Since being deleted, the subject debuted in an NHL game less than a week ago. The subject now has over 4,000 hits just by stepping on the ice. You do not see that kind of uptick in news coverage for any women's league, which if it did would at least imply that participating in that league presumes any player notability per the GNG. Yosemiter (talk) 13:46, 1 November 2018 (UTC)
  • The current situation for the two women's pro leagues is very much like the infancy of men's pro leagues 100 years ago. Reliable sources for that time period are iffy and few in many cases (look at the player stubs from back then), but NHOCKEY presumes notability for that older era, so there does appear to be a double standard there. Obviously, women's leagues do not get the attention that men's do, but a lot of that is strict repetition of the same stories, games, etc. In women's hockey we are missing an opportunity to be encyclopedic and document this initial period by imposing the same standard on women's that we do on men's. A lot of these women players are pioneers just like those early male players. If we applied the same standard, then most of those early male players probably should not be in Wikipedia. And is that what we really want? I would rather be encyclopedic and over-include than under-include in this instance. Alaney2k (talk) 17:01, 7 November 2018 (UTC)
    • @Alaney2k: I don't necessarily disagree agree with you about the older players, but media coverage from 100 years ago vs. now is apples to pineapples, they sound related but have nearly nothing in common. 100 years ago, media coverage of the pro leagues is somewhat assumed, and when asked, editors have been able to dig out print archives of coverage. The general media was definitely more localized and there was less routine coverage articles as the United States was not as sports obsessed (as there were very few teams in any sports). It somewhat implies that any coverage of a player then would be greater than routine. Obviously, it was also well before the proliferation of blogs and personal editorials causing an over saturation of routine, non-independent, and marginally reliable sources. So maybe that part of the SNG should be removed, but historically-based GNG arguments are always hard to make because a lot of it is that they were likely covered in GNG sources, but it is both difficult to prove or disprove without going to a library. That is most definitely not the case with the NWHL or CWHL, which have only been around for the last 11 years. Yosemiter (talk) 22:45, 7 November 2018 (UTC)
    • @Yosemiter: The content for many of the players for 100 years ago is mostly just stats. A mention of a player back then would basically be termed routine reporting. There were no biographical articles. Often I had to dig that out of obituaries from 50 years later. I'm not pushing for mass inclusion of women or a mass removal of men. I just think we can't apply the same standard to a fully-developed commercialized industry to a nascent one. And as I've pointed out, NHOCKEY already does this for early men's play. It should do something similar for current women's play. NHOCKEY actually is very forgiving to players who've only played a single game in the NHL also. That is a low standard and it certainly undercuts any argument that NHOCKEY is a very good indicator of general notablity. Most single-game players in the NHL from before the 1950s are very difficult to find anything other than very minimal coverage. Alaney2k (talk) 00:48, 8 November 2018 (UTC)
  • I strongly support this. We're currently at a point where some of the best women's hockey players in the world aren't allowed to have articles because they fail WP:NHOCKEY, and the community at AfD tends to interpret WP:NHOCKEY very strictly. Recently there were several articles deleted that I swear passed WP:GNG with coverage in Sports Illustrated, ESPN, et cetera, for women playing at the highest level of the sport. We don't need to adjust the SNG all that much either - I would propose award winners in the NWHL/CWHL/European leagues and making sure we look at WP:GNG when considering when an article is appropriate as opposed to the strict deletionist interpretation of the SNG. SportingFlyer talk 23:13, 7 November 2018 (UTC)
    • The women you mention aren't allowed articles because independent reliable sources aren't talking about them, not because of a failing of WP:NHOCKEY, and the purpose of NHOCKEY isn't to WP:RIGHTGREATWRONGS. If articles are deleted that pass WP:GNG, that is a failing of WP:AfD, not NHOCKEY (since NHOCKEY says at the top "Failing to meet the criteria in this guideline means that notability will need to be established in other ways (e.g. the general notability guideline, or other, topic-specific, notability guidelines)"). --Ahecht (TALK
      PAGE
      ) 16:13, 8 November 2018 (UTC)
    • NWHL awards are not particularly well covered. A cursory google search for the 2017 winners led me to primary sources, blog entries and some local news coverage about the MVP, specifically. I love women's hockey with a passion, but the coverage isn't there. Saying that some top women's players don't qualify doesn't seem correct. If objective sources are calling someone one of the top players in the world, there should be sufficient material to establish notability, regardless of NHOCKEY. Per the example further up - I don't think Harrison Browne passes NHOCKEY, but he has enough coverage for an article. I would support explicit mention in NHOCKEY about what level of women's hockey qualifies (if this hasn't been added already) - which at the moment, I think should be top level international play. Canada Hky (talk) 18:22, 8 November 2018 (UTC)
      • We actually did a search of award winners and leading scorers for the NWHL awhile back and we couldn't find enough sources on all of them. Now of course some of them had sources, but in order to be a new line in any of the NSPORTS criteria the generally agreed idea is that GNG has to be met for 99.999 percent of the people it applies to. Now I forget how many we found sources for but I think it was more than half of the women's players who had won awards in the NWHL didn't have sources found for them. The media just doesn't cover it. As Ravenswing mentions above, when even the local paper doesn't mention the local team won the championship, its pretty hard to say that media is covering the players when they aren't even covering the team all that much. -DJSasso (talk) 15:24, 9 November 2018 (UTC)
        • I agree on the lack of reliable coverage for NWHL award winners. I was disagreeing with the previous statement that this means some of the top women's hockey players in the world don't qualify for articles. The top players generally qualify, but not all the NWHL award winners are top players in the world. Canada Hky (talk) 16:05, 10 November 2018 (UTC)
    • A typical AfD for a woman hockey player usually goes like this:

      Nomination: Person appears to fail GNG based on lack of significant coverage in independent media, recives many mentions and routine coverage in blogs. Also subsequently fails NHOCKEY by not participating in the senior level IIHF tournament and no Olympic appearances. (paraphrased of course, sometimes it is simply "Fails GNG. Also fails NHOCKEY").

      Comment: They play in the highest level they can play in, should meet the spirit of NSPORT.

      *Reply to Comment: To meet NSPORT, it implies they must meet GNG. No evidence this league receives significant coverage, mostly just mentions and tons of routine coverage from the The Ice Garden (an SB Nation women's hockey blog). See this AfD.

      Keep: But they are a significant person because it is the top level national league. (An NFOOTY phrasing often used, an odd misconception that the coverage of any hockey league is anywhere close to the most popular sport in the world, such as when it was used as a Keep for the Turkish league here.)

      *Reply: See above response about GNG. And there are no "national" pro leagues in North America for hockey. They operate independent of a national governing body and usually have teams in both Canada and the United States.

      Keep: [An assortment of reliable sources, each with a mention or maybe a paragraph/quote from subject].

      *Reply: No real significant depth of coverage in multiple, just mentions.

      And it usually goes on like this ad nauseam. Some are good arguments for borderline coverage, but almost always it comes back to "men at the same level meet the SNG, why not women?" And the simple answer is simply: "Because unfortunately, the general media has decided not cover these teams or players anywhere close to their traditional leagues making coverage too inconsistent to create a hard-set SNG". Yosemiter (talk) 17:35, 9 November 2018 (UTC)

If I understand it correctly. We're being asked to treat female hockey players equally with male hockey players, by not treating female hockey players equally (i.e give them exemptions) with male hockey players. GoodDay (talk) 20:17, 10 November 2018 (UTC)

  • @SportingFlyer:, I'd like to address a comment of yours from a few days back. While other editors answered what I would have, there's a principle here: no one is "entitled" to an article. Leaving aside examples in this discussion how curiously flexible some inclusionists have been in defining "best women's hockey players," there is no group, gender, nationality, ethnicity or faith community entitled to have the provisions of WP:V or WP:GNG waived in their favor, Just Because. Ravenswing 09:09, 12 November 2018 (UTC)
  • @Ravenswing: I agree with you. That being said, I think there are players who play in the NWHL who do individually pass WP:GNG who have articles deleted recently. The problem with the "media doesn't cover this!" argument is that it looks at women's hockey as a group instead of looking at the individuals in the group who would pass WP:GNG. I was particularly disappointed with the deletion of the Katie Fitzgerald article, for instance. As I noted above, the bigger issue in my mind is in my experience hockey AfDs are based around whether someone passes the hockey SNG or not and either don't consider GNG or consider non-routine coverage as routine in identifying GNG. SportingFlyer talk 10:01, 12 November 2018 (UTC)

Ref. desk protection

The current protection level on Reference Desk pages seems to be doing a good job filtering recent vandalism there. Unfortunately it also seems to be deterring people who want to post post legitimate questions there. For comparison, the Math Desk (which is the one I normally monitor) got about a question per day this time last year, but hasn't a new question posted in over a week this year. The protection level seems to be designed for main space article pages, and I assume it works well there, but the Ref. Desk is a somewhat different situation. It seems that most people posting questions to the Ref. Desk have little or no interest in editing articles, and so either have no account or an account with very few edits. So the block is keeping out most of the people the Ref. Desk is there to help. Another issue is that this particular vandal is using tools that the current protection level was not designed to deal with: shifting IP addresses, automated edits, and a large supply of dummy accounts. With a computer doing most if not all of the actual work, the vandal really has no incentive to stop and the vandalism continues again soon after each block is lifted and continues until the next one is imposed. The result is that Wikipedia admins are putting in more work with setting up the blocks and banning accounts than the vandal is in doing the damage in the first place.

I'm not sure what the solution is, but the situation has gone on for over 3 weeks now and there is no sign it will change any time soon. I do have a few ideas, and I'm certain others can come up with more, though I don't know which will be effective or even technically possible. But perhaps some combination will be an improvement over the present situation.

  • Since the vandal seems to have no problem changing to a new IP address or a dummy account, limit the number anonymous/new account edits to only a few per day. This would be equivalent to imposing the current semi-protection block for 8 hours after any such edit. This would help frustrate bot editing but still allow legitimate questions to be asked.
  • Install a 'spam filter' on new edits for the page to automatically revert and ban the author of posts containing certain words. There are ways around this but it should at least ensure that the vandal has to put some work into getting edits saved. Legitimate questions posted should have no problem getting through such a filter.
  • Change the protection level to Pending changes. The people who monitor the reference desks tend to check it frequently so there should be no problem with unprocessed edits.

Unless an alternative is found, I think there will eventually be no choice but to make the current semi-protection level permanent, effectively limiting access to a small minority of the people who might use this valuable service. I don't know if other areas of WP have been attacked the same way, but it appears to me that as more sophisticated tools become available to vandals, WP will need a more sophisticated arsenal to combat them.

(Per WP:DENY I'm keeping this discussion away from the Ref. Desk itself and its talk page, but if it's better placed somewhere else please feel free to move it.) --RDBury (talk) 16:16, 30 October 2018 (UTC)

  • I'm not sure how to technically throttle editing in the way you suggest.
    Regarding the filter: It's being done, by This filter. It doesn't work much. The troll is savvy enough to vary their message enough to dodge the filter. Updating the edit filter with new words only serves to cause him to change to new words. It's the manner of attack (repeated, rapid posting of the same message over and over every few seconds) which is the problem. Defeating the edit filter isn't too hard.
    Pending changes doesn't matter; the offending edits are still in the page history, and he uses section headers and edit summaries which are beyond-the-pale offensive and need to be removed immediately. Pending changes leaves all of this visible except to unregistered users, so it's not really useful.
    Good luck in coming up with a better solution. Don't think we aren't trying! --Jayron32 16:23, 30 October 2018 (UTC)

An utterly unacceptable solution would be to trust the users. For example, you could set up a bot with admin privileges to revert all contributions from a given IP or non-confirmed account to the Refdesks retroactively for 24 hours and block the same account ongoing, and have it take this action whenever anyone on a list of Refdesk regulars (which could be autocompiled, and could be limited to persons with extended-confirmed access) would name the IP on the bot's talk page. Namers would be warned, of course, that it is an offense to make the report frivolously; there'd be criteria. The result would be that any protection or manual admin deletions would be unnecessary.

An even more unacceptable solution, which I prefer far more, is to utterly give up the moral panic about what if somebody looks at the edit history. If you must, have a bot post every 50 edits that everything alleged in this edit history is mechanical bollocks. Let the users clear the spam when/if they see a need. Party like it was 1999 and democracy had a future! Wnt (talk) 19:34, 2 November 2018 (UTC)

We've got better than a bot, we've got real, live human beings basically doing exactly that! You don't even need to tell them, usually they just take care of it, though sometimes they may not notice it needs taking care of, so we have WP:AIV as a good place to get those people's attention. But generally, this particular troll is noticeable enough that someone usually stops them within a few minutes. --Jayron32 19:50, 2 November 2018 (UTC)
That would be great if they didn't say it's too much work and they need to permanently semi-protect the desks. But a bot could do what they do immediately, automatically, without the need for such measures. Wnt (talk) 11:33, 3 November 2018 (UTC)
Thanks User:Jayron32 for removing the block early since the spammer seems to be taking a break. I had a feeling that not much could be done in terms of prevention without changes to the infrastructure. But I'm glad to hear that people are at least thinking about the problem. Another idea I was thinking about is to require some kind of reverse Turing test whenever an anon or new user makes an edit. Again, probably not possible with the current infrastructure. (I know that, for licensing reasons, WP refuses to use CAPCHA, but presumably there is some open-source alternative. I haven't created a new account recently so I don't know if one is in place for creating new accounts.) WP can't be the only site that's faced with this kind of problem, so it seems unlikely that a solution doesn't already exist somewhere. --RDBury (talk) 20:30, 3 November 2018 (UTC)
Wikipedia requires a CAPCHA for anon and unconfirmed users who add URLs to mainspace articles. --Ahecht (TALK
PAGE
) 16:16, 8 November 2018 (UTC)

I agree with OP. It is of utmost importance that newcomers not be prevented or discouraged from asking questions. Benjamin (talk) 21:37, 5 November 2018 (UTC)

Just an update, the spammer has returned so the issue is still ongoing. --RDBury (talk) 23:55, 5 November 2018 (UTC)

From stubs needs reference included

For the Wikipedia as encyclopedia credibility and respecting the Wikipedia:Verifiability policy I propose the need of at least one reference link in any Wikipedia article. It means a new page should'nt got stub classification without at least one acceptable external link.

This clearly mentioned at one section only - at the end of Wikipedia:Stub#Creating_and_improving_a_stub_article

This has a softer approach "Strongly encouraged" what against the above statements Notability#Notability_is_based_on_the_existence_of_suitable_sources,_not_on_the_state_of_sourcing_in_an_article

  • I am asking the community to agree/ support it and spread this consideration over the guidelines.

Several guides to mention this factor e.g.:

--Rodrigo (talk) 11:54, 1 November 2018 (UTC)

You should clarify that you mean "references"/"citations" not "links" or "external links", since many old and now rather obscure topics will be almost entirely offline or non-indexed. (Indeed, I feel like Google finds less every day). But I do think that given the very harsh treatment that WP:Articles for Creation are given, it makes no sense to let people be posting entirely sourceless new articles at this point. Wnt (talk) 23:08, 3 November 2018 (UTC)

@Wnt: Link means not only hyperlink, it not certainly a web document. It may refer any written/ recorded document book or known newspaper/ documentary. --Rodrigo (talk) 12:53, 6 November 2018 (UTC)

Proposed works of art naming convention

New convention proposed at Wikipedia:Naming conventions (works of art); discuss at Wikipedia talk:Article titles#RFC on works of art naming convention (not here). Dicklyon (talk) 17:19, 2 November 2018 (UTC)

Trans-language editor's rights

Hello English community! I'm an (ex-)avid editor from your sister Spanish Wikipedia. I was just wondering about the possibility to allow users from other languages to review GA or FA here. You see... in the last years Spanish Wiki has suffered from a decline in editions due to the outflow of editors there. However, I personally found myself so thankful for all the work you do! Many articles that I edited, were translated primarly from here! For that reason, I'll find it very interesting if I could help in some manner towards you. Thanks a lot, for real! --Gtr. Errol (talk) 03:37, 6 November 2018 (UTC)

Sure, but you'd be expected to speak English here and apply our GA and FA criteria here. We certainly aren't overflowing with reviewers. Jo-Jo Eumerus (talk, contributions) 07:21, 6 November 2018 (UTC)
  • Any editor can participate in the GA and FA process, and many more participants are needed. You would just have to learn how the project works here. But once you have done that you are more than welcom to review as many articles as you can.·maunus · snunɐɯ· 07:23, 6 November 2018 (UTC)
  • Hey Gtr. Errol. To add on the above, There are lots of areas where it would be valuable to have increased input from bi-lingual Spanish speaker. I'm working on an article right now where I can't read 90% of the sources. We also have comparatively few bilingual editors active at Articles for Creation, and drafts that rely heavily on non-English sources often take an immense amount of time to get reviewed. We've also got more than 3,000 articles in Category:Articles needing translation from Spanish Wikipedia. So there's definitely no shortage of work that needs done. GMGtalk 20:30, 8 November 2018 (UTC)
Hello, GreenMeansGo! Well, I'm aware that at any Wikipedia version there's always work to do! I can help you for sure, so why didn't get in touch by writting me what exactly you want me to do? I hope I can be helpful. By the way, I've been abscent for almost 5 years now, so I just edit casually, and not as hardcore as I did some time ago. I'm always amazed by English Wikipedia; it sincerly upholds what really Wikipedia means. --«[Gtr.]» Errol 21:19, 8 November 2018 (UTC)

RfC on schools' inclusion criteria

Should Wikipedia have one set of criteria about articles on schools up to and including the high school level and a different set for articles on schools of higher education? (I.e. beyond high school, e.g. universities.) -The Gnome (talk) 12:46, 9 November 2018 (UTC)

Background

This follows a series of discussions and RfCs in other pages, over the years. (See "Links to relevant threads," herebelow.) This RfC tries to take on the issue of school notability and inclusion of schools articles in Wikipedia slowly and piecemeal. It is posted here following the suggestion that the PUMP is the appropriate place for such a broad-policy question. Editors are encouraged to add to the link-sections below if they believe something is amiss.

List to relevant threads

List to relevant policies, guidelines, essays

Ping-o-mat

Notifying editors who got involved in past discussions:

Survey

  • No need - Both types of institution should be covered by WP:ORG. Blueboar (talk) 13:09, 9 November 2018 (UTC)
  • No need every possible article which could ever be written is already covered by WP:42. If a SNG contravenes that principle, it is wrong, and if an SNG agrees with it, it is redundant. --Jayron32 04:55, 10 November 2018 (UTC)
  • Remove distinction: they should just comply to WP:NORG. I'd also support removing the pesky exemption from CSD for schools that are patently non-notable. StraussInTheHouse (talk) 16:08, 10 November 2018 (UTC)
  • Need: It is easier with some criteria that can be applied directly to avoid endless discussions about relevant articles that however gets a request for deletion or to avoid creating articles that are clearly not notable. Within sports there are criteria about which competitions or divisions give presumed notability to a player. For schools there are quite good criteria on Swedish Wikipedia (I know that each Wikipedia has its own rules.): sv:Wikipedia:Relevanskriterier#Skolor_och_andra_institutioner_för_lärande and sv:Wikipedia:Att_skriva_om_utbildning#Skolor_och_lärosäten. Hopefully Google translates them reasonable well, but here is a summary:
  1. Universities etc: Presumed to be notable
  2. Secondary schools: In some cases (old ..) presumed to be notable
  3. Primary schools: not notable (should be in the article about the administrative unit to which they belong, as well as the not notable secondary schools)
  4. School buildings: if built by some famous architect
The GNG is quite abstract, so there is need for concrete criteria. Per W (talk) 11:10, 11 November 2018 (UTC)
  • No need, using NORG for both, per Blueboar/Jayron32. I will point out there have been past attempts to have school-specific notability guidelines, but these never gained consensus (per what Per W is describing). --Masem (t) 06:32, 12 November 2018 (UTC)
  • Uncertain what to use for specific criteria, if any at all other than WP:GNG. I should however note that simply being verified to exist DOES NOT make any educational institution inherently notable enough to warrant a page. We shouldn't presume something is article-worthy just because it's a college/university/school. Perhaps WP:NSCHOOL could make a more explicit note of this. Snuggums (talk / edits) 06:36, 12 November 2018 (UTC)
  • I'm not sure if we do need a SNG for schools (I'm leaning towards yes), but I'd rather that we don't allow articles on every single secondary school. There has to be a cut-off somewhere. Narutolovehinata5 tccsdnew 06:40, 12 November 2018 (UTC)
  • Yes schools are not just ORGs they are a special kind of organization that attract articles. Everyone would like to see their high school and University on Wikipedia. Schools tend to produce notable graduates. They are important infrastructure like highways and town councils and they play an important role in building communities. Wikipedia does a public service by covering schools because it allows some verification that people are listing real schools on their resumes and not diploma mills. I believe every legitimate post sec degree granting school should have a page, while high schools and elementry schools should be covered within a page on their school district. If there is no school district (say an independant/private school) high schools should have pages and elementary schools not. I strongly favor a bright line rule like WP:GEOLAND rather than a fuzzy guideline that results in endless debates about the notability of this or that school, how reliable the sources are and so on. Why is school X notable while school Y across town in the same district is not? Sports and crime stories are going to decide notability if we have a fuzzy rule. Legacypac (talk) 06:41, 12 November 2018 (UTC)
  • "Everyone would like to see their high school and University on Wikipedia". While that may be true for most, I can recall cases at OTRS where teachers have contacted us asking for the article on their school to be deleted because it is a target for vandalism. Just the other day, I removed some highly derogatory content from Berachampa Deulia Uchcha Vidyalaya that had gone unnoticed for more than a year. This is partly why I think we should focus on quality over quantity with schools articles. Cordless Larry (talk) 08:09, 12 November 2018 (UTC)
  • I lean toward "no need" but am open to being convinced otherwise, mainly because of the years of dispute history involving this stuff. In the views of those who think we need special rules for schools, please explain a) why NORG isn't good enough, and b) why it can't just be fixed in NORG instead of in a probably pointless WP:POLICYFORK that we'd be likely to merge anyway. On the above detailed proposition, I don't agree with Per W's summary. No secondary schools are "presumed to be notable". If one is very old and has a richly detailed RS track record, it is notable because of the RS coverage – it is demonstrated not presumed to be notable. I don't think even universities should be presumed to be notable, since various things call themselves universities that are not one. If something with "College" or "University" or "Institute" in its name turns out to be notable it's because we verified the RS coverage of it and demonstrated it to be notable, not because we presumed it was notable. Mountain ranges and heads of state are presumptively notable because of what they are, of their scope in the grand scheme of things. I agree that primary schools are presumptively non-notable, i.e., that it's going to take really strong RS showing to demonstrate that one is. That said, NORG seems to already have all this covered.  — SMcCandlish ¢ 😼  06:53, 12 November 2018 (UTC)
  • Clarification:
  1. Universities and colleges: Presumed to be notable
  2. Secondary schools (including defunct institutions): Presumed to be notable
  3. Primary schools: Some AfD's have been ridiculous and overzealous in squashing notability of some lower level schools that have achieved significant coverage. I am frequently astounded at the serial blindness of a certain class of editors who cannot see a long list of sources, obviously achieving the basics of WP:GNG. Instead they only see the hard gospel of a WP:SCHOOLOUTCOMES, with no room for reason.
Because we have that class of editor roaming the back pages of AfDs (looking to cause trouble), we cannot provide them any further ammunition for their arguments. No wiggle room, no further limitations they can misinterpret as an excuse to censor additional wikipedia content. I will note, on the many school articles I have tried to create or improve, I have not found the same consistent set of sources for school information that are available for other common subjects. Government lists are frequently years out of date and incomplete. Many sources are community generated and don't meet the standard of WP:RS. And the best sources for a specific school ultimately resolve back to WP:PRIMARY where your quality and consistency may vary. I know of probably a dozen or more large schools that have no articles and that have been that way for a decade. Why? The sources to create even the most cursory stub just aren't available to me or anyone else who looks. I've personally written to many schools suggesting they write their own article . . . make it a class project. Tell the world the story of your school and find the local sources to back it up. It has worked a few times, but most of the time it is ignored. With that inconsistency of sources, additional limitations to our criteria are not warranted or useful. Trackinfo (talk) 07:04, 12 November 2018 (UTC)
Please see my comment just above yours. It's highly dubious that any of these things are presumed notable, certainly not below the university level and even that's iffy because not everything with that word in it's name is a legit institution.  — SMcCandlish ¢ 😼  14:26, 14 November 2018 (UTC)
  • No need A key problem with having different rules for different tiers of education is that the institutions within those tiers differ wildly. For instance, while US high schools seem to be huge, Australian ones tend to be relatively small (hence a major issue I have with editors who argue that high schools are automatically notable - maybe they are in the US, but not in Australia). The size of higher education institutions in Australia varies from about 73,000 students at Monash University to dozens at some private sector tertiary education providers, so obviously the same rules can't apply to all. WP:ORG does a good job, and there's no need to treat educational institutions in a special way. Nick-D (talk) 07:17, 12 November 2018 (UTC)
  • Please close this before it becomes a huge mess like the last RfC on this issue some things are just best not talked about in a large RfC and are best found out through practice. Divisive issues where massive RfCs have consistently not reached any consensus are one of them. Also, NORG explicitly does not apply to schools as was part of the consensus adopting the new standards. TonyBallioni (talk) 08:38, 12 November 2018 (UTC)
  • No point. This is a battle that was lost over a decade ago, and the notion that secondary schools of whatever size or importance are exempt from any notability standards or sourcing requirements is about as set in concrete as any COMMONOUTCOME on Wikipedia. Waste of time and breath to hash it out yet again. Ravenswing 08:42, 12 November 2018 (UTC)
  • No. In actual fact, the criteria we usually use cover (a) primary and middle schools, and (b) secondary schools and tertiary institutions. We usually consider (b) to be notable and (a) not to be. -- Necrothesp (talk) 08:46, 12 November 2018 (UTC)
@Necrothesp:, where are the criteria that are used? --Per W (talk) 12:41, 12 November 2018 (UTC)
  • No need - Both types of institution should be covered by WP:ORG. But it should be a good idea to get rid of SCHOOLOUTCOMES as it is too often misused as a policy to keep schools, even when horribly written and unsourced. The Banner talk 09:45, 12 November 2018 (UTC)
  • I agree with TonyBallioni, and I think the specific line he is referring to in WP:ORG is The scope of this guideline covers all groups of people organized together for a purpose with the exception of non-profit educational institutions ... (emphasis mine). Mz7 (talk) 12:34, 12 November 2018 (UTC)
The problem with that highlighted sentence is that the ORG guideline subsequently goes into some detail about schools... in fact it has an entire sub-section devoted to them... so (despite the highlighted sentence) it is obvious that schools ARE considered within the scope of the ORG guideline. I think that sentence will need to be removed, but that is for another discussion. Blueboar (talk) 17:05, 12 November 2018 (UTC)
Yeah, point taken. Mz7 (talk) 03:39, 13 November 2018 (UTC)
  • No per Necrothesp's comments. Over six years ago I perused 100s of high school AfDs which I compiled in an essay and concluded that no matter what anyone ever says and how many RfCs and dramafest discussions we have, verifiable high school articles that aren't just a one-sentence piece of crap are almost ALWAYS kept. --Milowenthasspoken 12:55, 12 November 2018 (UTC)
Good survey! So a well-written article (with enough verifiable content) about a high school should be kept. Couldn't we then state somewhere that high schools are presumed to be notable? Then we can avoid lots of discussions. --Per W (talk) 14:39, 12 November 2018 (UTC)
Note that the phrase "presumed to be notable" does not mean "is inherently notable". A presumption of notability simply means we should give a school article the benefit of the doubt... waiting to delete until we have done due diligence in searching for sources (per WP:BEFORE). Blueboar (talk) 17:05, 12 November 2018 (UTC)
Cordless Larry: See, and that's exactly what I was talking about below, about schools in non-English speaking countries. We delete them because we don't have or can't read the foreign-language sources. But I can guarantee you such schools would have been kept if they were in Anglophone countries. In effect, if we insist on GNG for high schools we are institutionalizing WP:Systemic bias. --MelanieN (talk) 10:07, 13 November 2018 (UTC)
But if we can't read the sources, then I don't see what we can base articles on. I'm also not sure that the issue is about not being able to read the sources, because we have some regular school AfD participants who have the language skills necessary to read local sources, but rather that the sources often don't exist online, so we can't access them. Cordless Larry (talk) 10:10, 13 November 2018 (UTC)
Cordless Larry: The only thing I've seen changing is that more articles are being created these days for high schools in far flung non-English speaking places without available online sourcing. Those have always candidates for deletion. When the "are high schools notable?!?" debate began 15 years ago with the VfD for Union County Magnet High Schools, editors were debating mainstream large American high schools. E.g., Jimbo Wales made the argument in November 2003 that Randolph School could have an article. No one would dream of sending something like that to AfD today. I screenshotted the article deleted via Wikipedia:Articles for deletion/Kishorchak Banamali High School, it was unsourced, there was no option but to delete. If someone wants to spend their time on wikipedia tracking down stubs to Indonesian and Indian high schools without sourcing, they will get them deleted.--Milowenthasspoken 14:01, 13 November 2018 (UTC)
Yes, true enough about Kishorchak Banamali High School, which was pretty much my argument there too, Milowent. Some editors will still argue for keep even in such circumstances, however - including admins, which worries me. Cordless Larry (talk) 14:39, 13 November 2018 (UTC)
  • Keep the current understanding: institutions of higher learning (degree granting) and secondary schools (diploma granting) should be presumed to be notable, if there is confirmation of their existence and status. This practice 1) prevents endless arguments because high schools and colleges, like professional sports figures, virtually always turn out in a search to have enough coverage to qualify, and 2) helps to get around our inherent bias against non-English-speaking countries, since even though coverage likely exists, it can be hard to find in the non-English press. MelanieN (talk) 17:24, 12 November 2018 (UTC)
  • (@MelanieN:, where is the current understanding? --Per W (talk) 18:52, 12 November 2018 (UTC)
  • I sincerely doubt that the "current understanding" is that all high schools and above possess inherent notability. But I could be wrong. -The Gnome (talk) 19:57, 12 November 2018 (UTC)
  • Keep as is. Agree with MelanieN on all issues. In fact I'd like to take her comment above and frame it somewhere. Hobit (talk) 18:08, 12 November 2018 (UTC)
  • Different set (NOT NORG) - Secondary schools and definitely accredited universities should be presumed notable status. Classifying them in with WP:NORG is wildly OTT and also sets them a higher level of standards to meet when the circumstances for those stricter requirements is less likely to occur. I haven't marked this as "Keep" like MelanieN since there is such disagreement as well as partial rollback from this position that "Keep" is itself a level of dispute. Nosebagbear (talk) 18:21, 12 November 2018 (UTC)
  • No – GNG suffices. Nothing should be 'presumed' notable. If it doesn't meet GNG, it doesn't belong on Wikipedia. RGloucester 03:33, 13 November 2018 (UTC)
On the contrary, there are many traditional and accepted special guidelines at enwiki that define notability in ways other than GNG - for example, WP:NACADEMICS. This is not a new or startling concept, it is long-established practice; see WP:SNG. There are many special guidelines for specific categories of article that "presume notability" if certain criteria are met - for example, playing a professional sport at the highest level. The rationale behind this presumption is that such people will virtually always be found to have received coverage that meets GNG, so let's just accept that and not get into thousands of individual arguments about it. The nutshell at WP:NSPORTS spells it out very clearly: "An athlete is presumed to be notable if the person has actively participated in a major amateur or professional competition or won a significant honor, as listed on this page, and so is likely to have received significant coverage in reliable secondary sources that are independent of the subject." That is also the rationale behind presuming notability for high schools and colleges. --MelanieN (talk) 09:59, 13 November 2018 (UTC)
Did you ever consider that perhaps I do not agree with the way such guidelines are used? I'm being asked this question in the context of schools, and in the context of schools, I do not believe anything other than GNG is required. We can discuss sport when someone opens an RfC on that subject. If a school does not meet GNG, it does not need a Wikipedia article. Wikipedia is not a directory. In any case, like others here, I would also be satisfied by bringing schools formally under WP:ORG, if that's preferable. RGloucester 15:30, 13 November 2018 (UTC)
Um... folks... Schools already ARE covered formally under WP:ORG... See WP:NSCHOOLS. Blueboar (talk) 16:04, 13 November 2018 (UTC)
It seems somewhat ambiguous at the moment, given the "exception of non-profit educational institutions" caveat in the lead. What I meant is that I'd be fine with clarifying WP:ORG to the effect above. RGloucester 16:21, 13 November 2018 (UTC)
For the sports-specific notability guideline in particular, it does not define notability in a way other than the general notability guideline. It provides guidance on when it is highly likely that the general notability guideline can be met with a sufficient search for suitable sources. It was discussed last year in this venue, and the closing statement once again affirmed this in the context of WP:NSPORTS (as has been discussed many times since, the closing statement overstepped in its broader conclusions for all subject-specific notability guidelines). isaacl (talk) 17:13, 13 November 2018 (UTC)
  • Yes: Need separate standards to facilitate discussion and consensus - Many of the comments above don't answer the question being posed, namely, whether there should be separate standards for high schools and post-secondary institutions. I think there should because it will facilitate a more focused discussion. Even for those think that WP:NOTABILITY, WP:ORG and other guidelines adequately cover the field, should recognize that others disagree and have reasons for that disagreement. Those reasons (and the objections to them) are, I think, different for high schools and universities, and it would be helpful to discuss them separately, acknowledging (at least) the possibility of different guidelines for each. My (admittedly brief) involvement and review of past attempts to reach consensus makes it clear that the differences make discussing any particular proposal more difficult.Federalist51 (talk) 21:36, 14 November 2018 (UTC)
  • Comment There may be some validity to "schools being an important part of the infastructure". However living in Detroit, Michigan I live in a place where there have been several fly-by-night charter high schools, so I am less convinced than some that all schools that are at the high school level are notable. I also have seen way too many articles that have only been sourced to show a place exists survive on the theory better sources could be found, while no one even tries to find such sources. We need much clearer policies.John Pack Lambert (talk) 05:22, 16 November 2018 (UTC)

General discussion

  • FYI, pings don't go above the count of 50. I'd guess the above ping-o-mat didn't get every one (I wasn't hit). --Izno (talk) 13:53, 9 November 2018 (UTC)
Greetings, Izno. I'd appreciate any help from anyone in fixing this. I should note here that these were not pings per se but mere full-style usernames. Perhaps that helps. Thanks in advance. -The Gnome (talk) 14:02, 9 November 2018 (UTC)
Linking to userpage is a ping, the above did not go through because the count is above 50. Instead of trying to fix that I would advise to just remove the section, it's unnecessary. –Ammarpad (talk) 14:27, 9 November 2018 (UTC)
Would it work to break the list into smaller groups of pings? Blueboar (talk) 15:08, 9 November 2018 (UTC)
Yes, but even then not in one edit. Each smaller group if they'll add up beyond 50 in one edit, it won't work. My rough count shows there's around 120 editors above; so you can ping batch of 40 in 3 separate edits. –Ammarpad (talk) 15:25, 9 November 2018 (UTC)
Thanks, all. I'll get to it. Take care. -The Gnome (talk) 07:03, 10 November 2018 (UTC)
Sad to say, that probably didn't work. Each edit has to be signed - see WP:PING Note that the post containing a link to a user page must be signed; if the mention is not on a completely new line with a new signature, no notification will be sent. (Multiple mentions on the same new line with new sig are fine.) 92.19.25.230 (talk) 22:05, 10 November 2018 (UTC)
Thank you, 92.19.25.230. I did the multiple, signed edits. Take care. -The Gnome (talk) 06:28, 12 November 2018 (UTC)
Ammarpad, IMVHO the issue is quite important and participants in past discussions on it should be informed of this RfC's opening. Take care. -The Gnome (talk) 07:11, 10 November 2018 (UTC)
The Gnome's ping worked that time 8 mins ago. Graeme Bartlett (talk) 06:33, 12 November 2018 (UTC)
Thanks for the confirmation, Graeme Bartlett. -The Gnome (talk) 10:27, 12 November 2018 (UTC)
I don't know if all the pings worked (I was notified) I just think you should have called it pingamajig. Ivanvector (Talk/Edits) 10:33, 12 November 2018 (UTC)
Noted for next time, Ivanvector! Face-smile.svg -The Gnome (talk) 13:13, 12 November 2018 (UTC)
  • An obvious thing, maybe, but if language is changed, we need grandfathering of existing school articles , giving them say, 2-3 years of time before they are treated under NORG/GNG under this potential change. --Masem (t) 17:13, 12 November 2018 (UTC)
Indeed, 24 months is probably the way to go. My heart bleeds at the thought of having a deluge re-enter AfD. Nosebagbear (talk)
  • What is the driver in this discussion? What is the problem if a few less notable schools are included - are the servers running out of space? Policies and uniformity should support and enhance the information in the encyclopaedia, not reduce it. As a final aside; when I see the acres of text devoted to arguing fine (if not irrelevant) points I do wonder if the time could not have been better spent working on articles. Martin of Sheffield (talk) 08:31, 13 November 2018 (UTC)
Greetings, Martin of Sheffield. Wikipedia's policies and guidelines are evidently not driven by web space availability; otherwise, we would have significantly fewer rules and guidelines. The "driver" of this discussion is quite clear, as one could see by diving into past discussions on the issue, linked above. Take care. -The Gnome (talk) 09:44, 13 November 2018 (UTC)
You haven't explained why you feel the need to remove information though. It reads as if you are just trying to establish rules because you believe there need to be rules. Quoting conflicting policies as if they were reasons appears on the surface to indicate a bureaucratic rather than encyclopaedic approach. I would suggest that a better approach is only to disallow that which harms the encyclopaedia, and I have yet to be convinced that a few lines about an otherwise obscure school (which will of course be notable to many thousands of present and former pupils, parents and teachers) harms the encyclopaedia. Verifiability is important as a safeguard of our credibility but notability is a subjective assessment. Martin of Sheffield (talk) 10:02, 13 November 2018 (UTC)
Greetings, Martin of Sheffield. I did not express any kind of "need to remove information." Where do you get that? (If what you say comes from a hard inclusionist perspective I will not entertain it much, thank you. It simply does not pay to argue with editors who insist that all information has a place in Wikipedia, e.g. "Come on, some stub article about a non-notable subject does not harm the encyclopaedia".) But, more importantly, if the policies are indeed "conflicting", as you say, isn't this a reason to resolve the conflicts and get clarity? -The Gnome (talk) 05:51, 16 November 2018 (UTC)
  • This is a perennial subject of discussion, and has been for a decade or more. Looking at the list above I see that it has been discussed at least three times in the last year, and this is a fourth. In one of those discussions, namely this one, the closers decided that even though the opinions for-and-against NSCHOOLOUTCOMES were about equally balanced numerically, the conclusion was to overturn that longstanding practice. Then people seized on that one (out of dozens) discussion and its barely-supported* conclusion to change the wording at various guidelines to say that, hey, secondary schools aren't presumed notable after all. Looking at the discussion here, I see that opinion is still about evenly balanced, and that many/most of us were not even aware that the longstanding guideline had been overturned on the basis of one RfC. This is immensely frustrating. How are those of us who care about this supposed to keep up? If I wouldn't have known about this discussion, either, except for the ping-o-mat kindly sent out above (thank you, The Gnome). --MelanieN (talk) 10:33, 13 November 2018 (UTC)
*Quoting from the closure: "Based on the discussion, we find that the community is leaning towards rejecting the statement posed in the RFC, but this stops short of a rough consensus. Whether or not the community has actually formed a consensus to reject the statement posed in the RFC is a distinction without a difference." --MelanieN (talk) 10:45, 13 November 2018 (UTC)

Partial blocks and bans

Moved to Wikipedia:Village pump (idea lab): More appropriate there, per user suggestion

— Preceding unsigned comment added by Funplussmart (talkcontribs) 20:27, 10 November 2018 (UTC)

Small logos and svg

Sorry to bring this up again, but I never got a good answer the many times I asked:

We upload a logo. It is too big. We reduce it to something like 200x200 so nobody can use it commercially. Then someone tags it for conversion to svg. That format allows it to be any size, high quality, highly reproducible.

Is there a link to the discussion that makes sense of this? Thanks. Anna Frodesiak (talk) 11:45, 12 November 2018 (UTC)

I don't think anything has changed since you asked this question in 2015 at Wikipedia:Village pump (policy)/Archive 119#Non-free image resolution.
A summary, for those seeing this for the first time: Non-free SVGs have long been a point of contention, and I'm not aware of any past conversations that have reached a firm consensus. Some past discussions include:
There are generally three factions in such discussions:
  1. Non-free vector images are ok as long as they don't contain detail that isn't needed to render at appropriate sizes.
  2. Non-free vector images are never ok because simple shapes (such as circles) can be rendered at arbitrary sizes without pixelization artifacts.
  3. Non-free vector images are only ok if they were created by the copyright/trademark holder, even if the editor-created SVG generates an image indistinguishable from the official logo when rendered at appropriate sizes.
I subscribe to the first view, and IMO that's the view that mostly has consensus. HTH, although I suspect it doesn't help all that much. Anomie 14:00, 12 November 2018 (UTC)
The way NFC had treated these is that the only allowable SVG that are non-free are logos in SVG or equivalent form (like EPS) publicly made available by the company/entity that would have appropriate ownership of that label (for example, a parent company with a subsidiary's logo). The rationale for this is that normally non-frees must be of small resolution, so SVG is already an incompatible format with that. But if a entity publishes its logo in an SVG format, we have allowed that to be uploaded and used as logos. We do not allow any other recreations of non-free logos into SVG from a non-SVG format, so anyone asking for a conversion of a logo to SVG should be immediately denied due to this. Recreations can introduce elements that were not a part of the original logo or mis-represent the logo, and that's a problem. (That's why it's okay with those logos that fail to pass the threshold of originality and fall into uncopyrightable, because their reproduction should not introduce any misrepresentation). --Masem (t) 14:40, 12 November 2018 (UTC)
I was trying to head off another round of everyone just repeating what they always say... Sigh. Anomie 03:32, 13 November 2018 (UTC)

Baidu Baike is NOT a Reliable Source

I am a Chinese Wikipedian and I find that in English Wikipedia there are a number of articles about Chinese people and firms citing Baidu Baike as reference. Though many about China can be found on Baidu Baike, which is much "larger" than Wikipedia considering NUMBERS of items included, in fact, Baidu Baike itself are thought to be unreliable in China so that in Chinese Wikipedia it hasn't and will never appear in reference lists. Citing Baidu Baike is no better than citing Wikipedia.

I suggest not using Baidu Baike as a reference anymore. GnolizX (talk) 05:04, 13 November 2018 (UTC)

@GnolizX: Welcome to the English Wikipedia. From my understanding, Baidu Baike is a user generated source, which our reliable sourcing guidelines already recommend not using. That said, the English Wikipedia is too large for anyone to properly monitor, so new users do sometimes add it without knowing about our reliable sourcing guidelines. Ian.thomson (talk) 05:11, 13 November 2018 (UTC)
Then what to do with those articles having already cited Baidu Baike? Will there ever be a robot that can automatically remove the Refs? Just search "百度百科" and we'll get lots of articles with this problem. This is much more terrible because these pages may later be translated to other languages. GnolizX (talk) 05:29, 13 November 2018 (UTC)
If there is a consensus that they are all without exception damaging and useless, you could ask addition to the MediaWiki:Spam-blacklist. Jo-Jo Eumerus (talk, contributions) 07:11, 13 November 2018 (UTC)
But exception exists, for example, Baidu Baike is cited in Baidu Baike to explain its policy. GnolizX (talk) 08:36, 13 November 2018 (UTC)
Exceptions can be made for specific addresses. Citing Baidu on its own article about its own policy would be an acceptable use and would qualify for an exception. Only in death does duty end (talk) 19:15, 13 November 2018 (UTC)
There are currently 2928 pages on English Wikipedia linked http://baike.baidu.com pages and also 643 pages linked http://baike.baidu.com pages according to Special:LinkSearch although a few of them are user pages or talk pages, or as an intermediate source for fair use images source. Someone probably need to check all 3500 of them and remove most of them. Amazingly someone linked it as source on reference desk. C933103 (talk) 07:38, 13 November 2018 (UTC)
Yeah what an amazing number.... So the next step is, that all the 3500+ pages need to be checked... by human beings??? GnolizX (talk) 08:18, 13 November 2018 (UTC)
The number is closer to 1900 in mainspace. You can make a WP:Bot request to remove uses. I think there is at least one bot that will do it.
There are at least 600 other pages which reference baidu.com also which may not be appropriate, as from my review of Baidu the company does not much reliable to say--but that would definitely need human review. I would support blacklisting the domain given the quantity. --Izno (talk) 16:59, 13 November 2018 (UTC)
The links should not just be removed, but instead replaced by other references to support the statements in the articles. If the statement is untrue, then it should be removed along with the bad reference. Graeme Bartlett (talk) 23:29, 13 November 2018 (UTC)
When I have done this previously for what was a patently unreliable source, I simply replaced the offending ref with {{cn}}. --Izno (talk) 23:44, 13 November 2018 (UTC)
We have a page somewhere for listing unreliable sources that are also popular magazines and websites. I think it's also used for generating blacklist entries.  — SMcCandlish ¢ 😼  14:23, 14 November 2018 (UTC)

"Increase" and "Decrease" in rank.

As discussed in Template talk:Infobox website#AlexaRank, currently some Wikipedia use "decrease" to indicate improvement in rank. For instance, If a website was previously ranked #10 in certain ranking, and it now become the #1 site in the world, then editors would put a Positive decrease symbol next to the rank to indicate its ranking have been "decreased" from #10 to #1. However to me it seems like the interpretation doesn't make sense, as the ranking of the website was actually increased from the #10 to #1. Wouldn't it be better to use the Increase symbol to show the website gained places in ranking? C933103 (talk) 07:26, 13 November 2018 (UTC)

Why not simply use “rise” and “fall”? Blueboar (talk) 12:27, 13 November 2018 (UTC)
The OP is saying that it's counter-intuitive to indicate an improvement with a "down" arrow. I would tend to agree. Not sure whether this qualifies as forum shopping, maybe a discussion notice here would have been better? ―Mandruss  13:12, 13 November 2018 (UTC)
Strongly concur with C933103 and Mandruss. Furthermore, this is against MOS:ICONS. We never use icons in ways that can be misleading to readers.  — SMcCandlish ¢ 😼  14:20, 14 November 2018 (UTC)

Transcluding article content into other articles

At Joseph Gordon-Levitt part of the Hitrecord section is transcluded from another article. Something similar happens at Transgender#Scientific studies of transsexuality. I had never come across this before in article space. There is a help page Wikipedia:Transclusion, which mentions the Gordon-Levitt article as an example. There are also templates Template:Transcluded section (links 735 articles [6])and Template:Transcluding article (links 11 articles [7]) so it is used somewhat. Zinc is a featured article and uses it for the common cold section. It seems odd and while I would enjoy using it to keep consistency in articles from areas I edit I think it could have some drawbacks. It makes the assumption that the content should always exactly match the transcluded article and makes editing the target sections difficult. It also means that changes made to another article would affect an article you watchlist without notifying you. There may be others too. I am curious as to whether there are any guidelines or policies to using this technique or if it is just used so little that most editors are, like me until now, unaware that it was viable. AIRcorn (talk) 09:01, 13 November 2018 (UTC)

Transclusion is heavily used in entertainment-related articles. For an example see MOS:TVOVERVIEW in the guidelines for writing about television programs: If a separate List of episodes article exists, the series overview table should be presented at the top of that article below the lead, in a section labeled "Series overview", then transcluded to the episodes section at the main article. This sometimes leads to problems with references, if named references are used but the full reference is not in the transcluded section. StarryGrandma (talk) 20:48, 13 November 2018 (UTC)
In general I don't think it is a good idea due to the problems mentioned above, and the confusion it causes to editors. However I don't think we need a policy to support or preclude it. Using templates transcluded into the two articles seems better than transcluding one into the other. This will prevent edits on one article trashing the other. Graeme Bartlett (talk) 23:33, 13 November 2018 (UTC)

RFC: Should BAG members have an activity requirement?

Please comment at the RFC. Headbomb {t · c · p · b} 17:45, 14 November 2018 (UTC)

MILHIST guidance pages

A discussion is currently underway at Wikiproject Military History concerning guideline status of the MILHIST Content guide and Notability guide. –dlthewave 21:43, 15 November 2018 (UTC)

Single use templates

There is a discussion over at WT:Template namespace § Single use template that would probably benefit from broader input. Anyone here is welcome to contribute or advertise it more broadly. Or you can ping me and let me know where else I should put a notice. Thanks, and happy editing. YBG (talk) 23:05, 15 November 2018 (UTC)

Technical

Support ends for the 2006 wikitext editor

The 2006 wikitext editor will be officially removed next week, on the normal deployment train (i.e., Thursday, 25 October 2018 for the English Wikipedia). This has been discussed since at least 2011, was planned for at least three different months in 2017, and is finally happening.

This toolbar is being removed from MediaWiki.

If you are using this toolbar (and almost none of you are), then you will be given no toolbar at all (the 2003 wikitext editor). This default was chosen so that your editing windows will open even faster, and to avoid cluttering the window with the larger toolbars (a particularly important consideration for Wikisource's PagePreviews). Of course, if you decide that you would prefer the 2010 or 2017 wikitext editors (or a gadget like WikEd), then you are free to change your preferences at any time.

Although it is not a very popular script overall, I know that some editors strongly prefer this particular tool for specific reasons, such as regularly using the <sub> or <sup> buttons. If you are one of its fans, then you might want to know that some long-time editors are talking about re-implementing its best features as a volunteer-supported user script. I believe that any announcements about that project will be made at mw:Contributors/Projects/Removal of the 2006 wikitext editor. Whatamidoing (WMF) (talk) 17:36, 15 October 2018 (UTC)

And if you're thinking "Yeah, she said that three times last year..." – No, really, the fourth time's the charm! This time, they really do think it's not going to completely break the wikis. ;-) Whatamidoing (WMF) (talk) 17:40, 15 October 2018 (UTC)
Best of luck, I'll be sorry to see it go! In case you're interested in some anecdata, it was the codeeditor that really did it for me. I like the shortness and simplicity of the old one, but the linting is just too useful for js/css. ~ Amory (utc) 21:03, 15 October 2018 (UTC)
How does one know which toolbar one is using? DuncanHill (talk) 21:37, 15 October 2018 (UTC)
See Help:Edit toolbar. PrimeHunter (talk) 23:06, 15 October 2018 (UTC)
Or see mw:Editor which has an overview of all different editors that are currently supported. —TheDJ (talkcontribs) 17:59, 16 October 2018 (UTC)
I'm with DuncanHill, i'm afraid; completely non-techclever, i simply found a Preference which says "Show edit toolbar" and i've had it active for years, i think. Is that the toolbar that's going? How do i choose another one? The only other Preference i've seen talks about an enhanced toolbar, which rather frightens me.... Happy days (or possibly not, if i don't understand toolbars), LindsayHello 15:41, 16 October 2018 (UTC)
The editing preferences are unusually confusing, even by Wikipedia standards. Some of the pref items silently override the others, and it's especially difficult to explain to new editors. I've proposed improvements at phab:T202921, but unless that wins the m:Community Wishlist (starts in a few weeks), I don't think it will happen any time soon.
Lindsay, if you're a non-technical person, then you might want to consider trying the visual editor again. It is really vastly better than it was back in the day. If you don't have separate "Edit" and "Edit source" tabs already, then look for a little pencil icon (not the highlighter marker pen) and switch to it. It works mostly like a normal word processing document, and is really the only sensible way to do some things, like adding or removing a column from a large wikitext table.
If you prefer wikitext, then I think you would likely be happy with the light blue "enhanced" toolbar. It has been the default for all users since approximately 2010, and it gets used thousands and thousands of times each day with very few complaints.
Finally, if you don't actually use the buttons in the little toolbar (which is not unusual for experienced editors), then your easiest option is probably doing nothing. In that case, the toolbar, which you're already not using, will just go away all by itself. Whatamidoing (WMF) (talk) 17:22, 16 October 2018 (UTC)
P.S. I fully and wholly expect a lot of editors to turn up here on the day in question, who as always likely missed all the announcements, because they just don't follow fora like these. Please keep in mind, that according to the data, last year 1500 en.wp editors making a single edit in a 1 month period had the toolbar enabled. Note this doesn't equal USED the toolbar, many people simply have it enabled because they always have. —TheDJ (talkcontribs) 17:59, 16 October 2018 (UTC)
Of course they will. It's just impossible to keep up with everything. That's why I appreciate it so much when people ping me for interesting discussions. This will also be announced in m:Tech/News on Monday, as well as the Editing newsletter, which will go out next week (Tuesday?).
Schedule update: There's been a slight delay. But it's finally up on the Beta Cluster. It doesn't seem to have broken anything obvious, so it should reach this wiki next WP:THURSDAY.
Tech folks here might want to take a look at what Arkanosis has been doing about a replacement script, especially that edit about a gadget for Monobook users. (Hmm, I wonder whether the copies of gadgets are up to date on the Beta Cluster? If they're not, that might explain why last week's watchlist problem wasn't visible until it hit production.) Whatamidoing (WMF) (talk) 17:37, 24 October 2018 (UTC)
We have a script! See mw:Contributors/Projects/Removal of the 2006 wikitext editor#Alternatives for most of the details.
Also, based upon the conversation at w:fr:Discussion utilisateur:Arkanosis#Page, we probably have some scripts/gadgets that will break. I think that this search will find the gadgets. Calling all interface admins... Whatamidoing (WMF) (talk) 18:00, 29 October 2018 (UTC)
Reminder: It's almost WP:THURSDAY, and this change is riding the deployment train. Whatamidoing (WMF) (talk) 06:03, 1 November 2018 (UTC)

So, and this is me showing my techability again, did this happen or not happen? I'm sure it's past the date Whatamidoing (WMF) mentioned in the opening statement, and it's also after the next Thursday too, but i still have the same toolbar when i edit which i understood was going away. Am i misunderstanding, even less clever than i thought, or did something change the plans? Happy days, LindsayHello 16:13, 2 November 2018 (UTC)

It looks like http://tools.wmflabs.org/versions/ says that yesterday's deployment (the big weekly update of everything) had a problem on the Wikipedias and was rolled back after 10 minutes. My best guess is that phab:T208549 is the reason they reverted it. This change (and all of the others in the weekly update) has been made to all of the non-Wikipedias already, and it will happen here as soon as they re-deploy, which looks like it will be after 18:00 UTC Monday. So you are correct, and it appears that you have a brief reprieve. ;-) Whatamidoing (WMF) (talk) 19:11, 2 November 2018 (UTC)
Well, unless gadget maintainers figure it out first, with only two days left till deployment it's probably not worth other editors and developers trying to guess what will break when the deployment gets rolled out. Thanks for the heads up. Deryck C. 11:38, 6 November 2018 (UTC)

Update: It happened.

The German Wikipedia appears to have had a problem in a local gadget, and they may not be the only ones. If you encounter complaints, I recommend that your first question be this: Are you talking about the 2006 wikitext editor (picture), or about mw:CharInsert (picture)? Only the blue-gray toolbar at the top of the editing box is supposed to be removed. Access to special characters is meant to remain in place. Whatamidoing (WMF) (talk) 21:20, 6 November 2018 (UTC)

Please let me know if that toolbar gets reconstituted as a user script. I can probably figure out how to do no-wiki tags manually, but the string for hidden comments defeats me, and neither seems to have been included in the "enhanced" toolbar. Numbers using a tool are not a good indication of its usefulness; editors do many different kinds of tasks, using different hardware, and with different technical backgrounds. Yngvadottir (talk) 22:27, 6 November 2018 (UTC)

  • I use monobook with the green on black gadget. The "advanced" toolbar is almost unreadable - white icons on a very pale blue background. It also takes ages to load. Is there an alternative that actually works? Or is this another of those "improvements" that just makes things worse and we are told to be grateful for? DuncanHill (talk) 23:50, 6 November 2018 (UTC)
    • As noted in the comment on 29 October that begins with the words "We have a script!", there is already a replacement user script available. You can follow the directions at mw:Contributors/Projects/Removal of the 2006 wikitext editor#Alternatives to install it in common.js (or your global.js at Meta, if you edit multiple wikis and want it on all projects). It's also possible for any interface admin to turn it into a local gadget. Then you'd only have to open Special:Preferences and tick the box. Whatamidoing (WMF) (talk) 00:09, 7 November 2018 (UTC)
      • The instructions there are almost incomprehensible, and I lack the language skills to translate the French. DuncanHill (talk) 00:13, 7 November 2018 (UTC)
      • Thanks, Whatamidoing (WMF), I actually did look there after posting, and I can read the French. I would have considered asking for help installing something, which would be a first; the warning about damaging my computer by downloading a script has always stopped me, but I really can't do without hidden comments. Nowiki I think I can learn to do manually, and my current laptop allows me to type tildes to sign. But ... guess which button is missing both from the screenshot of the bar and from the script? So the WMF has now forced me to make a wallet card with the code for a hidden comment on it, to carry at all times. Way to go, simply for the sake of making changes. Yngvadottir (talk) 00:37, 7 November 2018 (UTC)
        • Have you looked in the CharInsert/EditTools for the codes you want? It's in between the bottom of the editing window and the top of the Edit summary box. Set the menu to "Wiki markup" if it isn't there already. Whatamidoing (WMF) (talk) 00:53, 7 November 2018 (UTC)
          • This may be the moment to point out I use Monobook. In any event, I doubt such a thing is hidden among chart codes, and I have the alt chars (Latin) chart open all the time in that location for the things where I can't immediately remember the Microsoft ctrl+ code. (My head is actually surprisingly full of codes to get nonstandard things to display, which is why I deeply resent something unique to this site that requires a string of unmemorizable symbols being removed from clickability.) Yngvadottir (talk) 01:08, 7 November 2018 (UTC)
        • Whatamidoing (WMF) Where do I go to make a request for those instructions to be re-written in a way that makes sense , and 2) get the French stuff translated too? It tells me to import things to local media wiki whatever the hell that is, and lots of other stuff that might make sense to you but is meaningless to me. Is there perhaps some kind of "technical" desk where people could get help? DuncanHill (talk) 01:37, 7 November 2018 (UTC)
          • I think the answer to that question depends upon whether you're the only person at this wiki that wants this. If you're not, then it's possible that someone else (i.e., someone with more technical skill than me ;-) would sort it out, and then you could just copy what they did. Whatamidoing (WMF) (talk) 02:47, 7 November 2018 (UTC)
            • WP:ITSNOTTHURSDAYYET. --Izno (talk) 04:12, 7 November 2018 (UTC)
              • 1. ^ this and 2. I asked Amory about this a couple of days ago and she seemed to think that perhaps TheDJ had begun importing it. I also use Monobook and would like to continue doing so. Killiondude (talk) 04:59, 7 November 2018 (UTC)
                Killiondude, I have no intention of bringing that thing back. I'm maintaining more than enough old junk and it's also why I didn't protest the removal from MediaWiki core. If someone prepares all the necessary work, as an iadmin I will of course review and deploy peoples contribution. —TheDJ (talkcontribs) 09:45, 7 November 2018 (UTC)
  • Whatamidoing, DuncanHill is certainly not "the only person at this wiki who wants this", as you're well aware from when you asked a year ago; as you're also well aware, the reason the only people who were using this are people who joined pre-2010 isn't that the 2010 editor is superior, but that the devs forced the slow editor on all new signups and buried the option to change it in preferences so most editors were never even aware that a toolbar existed that didn't take forever to load, and consequently either disabled the new toolbar altogether or put up with waiting for it to load each time. Can you—or someone at the WMF—please explain in a way that doesn't involve my needing to learn French what steps I need to take to re-enable it? ‑ Iridescent 19:42, 7 November 2018 (UTC)
  • DuncanHill, sounds like you have a problem with the green on black gadget. You should ask it's maintainer to improve it. —TheDJ (talkcontribs) 09:46, 7 November 2018 (UTC)
    This should improve the green on black gadget to where it works well enough with WE2010. Seems someone started that work in the past and didn't completely finish it. —TheDJ (talkcontribs) 10:05, 7 November 2018 (UTC)
    TheDJ I don't see any difference - the icons are still almost invisible, white on a pale blue background. I don't have any problems with the green on black gadget until somebody else goes and breaks something else! DuncanHill (talk) 14:29, 7 November 2018 (UTC)
    Now it's changed and I can see the icons. It really is a lot less useful than the old toolbar, especially in the way it hides the cite templates (and then hides parts of them even once you've opened them). DuncanHill (talk) 15:15, 7 November 2018 (UTC)
    And now it's changed back and the icons are invisible again. DuncanHill (talk) 16:30, 7 November 2018 (UTC)
  • Hi all (noting Iridescent and DuncanHill); I've taken the liberty of importing the script that WAID mentioned above into the English Wikipedia and translating it. It's in my userspace right now (I'd need to request interface admin to move it to Mediawiki). Y'all can install it by adding the line: mw.loader.load("/w/index.php?title=User:Writ_Keeper/Scripts/legacyToolbar.js&action=raw&ctype=text/javascript"); to your common.js page. Let me know if there are any issues or concerns, or if I've done something horribly wrong. Writ Keeper  20:15, 7 November 2018 (UTC)
  • Excellent, and thank you. (I suppose there's no way to bring back the "cite" button as well, which IIRC was a separate script? One of my main peeves with the 2010 editor, aside from the slowness to load and the space it took up, was that the citation tools were so much worse than those of the 2006 version.) ‑ Iridescent 20:23, 7 November 2018 (UTC)
  • No worries! If we can dig up the separate script, I can probably convert it over pretty easily. Otherwise, you'll have to describe how the button worked, and I can recreate it. (I always do refs manually, which is probably pretty timewasting.) Writ Keeper  20:26, 7 November 2018 (UTC)
Was the cite button part of Wikipedia:RefToolbar. I too appreciate your work on making the script work, and echo Iridiscent's desire for trhe cite button. DuncanHill (talk) 20:29, 7 November 2018 (UTC)
It looks like it was part of Wikipedia:RefToolbar, but because it auto-detected which toolbar you were using—and the WMF removing "edit toolbar" from preferences has now made us all appear to have toolbars disabled altogether—it's unable to figure out where to display the "cite" button. Seriously, sometimes I wish the WMF would tell us which of their many management consultants told them that "run fast and break things" was the best way to operate, so I can track them down and every Thursday disrupt them trying to go about their work. ‑ Iridescent 20:39, 7 November 2018 (UTC)
@Writ Keeper: Thank you! Does your version include the hidden comment button, or is there any way to add that? Yngvadottir (talk) 20:29, 7 November 2018 (UTC)
Hidden comment should be fairly easy to add. I'll look at both of those. Writ Keeper  20:31, 7 November 2018 (UTC)
@Yngvadottir: You should be good to go for hidden comment. Writ Keeper  20:58, 7 November 2018 (UTC)
Thank you thank you thank you! That appears to have worked. Yngvadottir (talk) 21:04, 7 November 2018 (UTC)
@Writ Keeper: There was a "create redirect" button too, which was very useful. DuncanHill (talk) 21:21, 7 November 2018 (UTC)
Indeed, the "redirect" button was (and is, until now) the one I use most often. Makes it very quick and easy to set up new redirects. Here's the old toolbar, that I really liked:
RefToolbar 1.0.png
It looks like I might have to spend some time playing around with all the various editor options (apart from VE, which I loathe). Haven't bothered to do this so far, since I use an external editor for most of my editing. A big "thank you" to Writ Keeper for his work on this. --NSH001 (talk) 11:44, 8 November 2018 (UTC)
Implemented the redirect button. Still working on the cite button; it's mostly working, but it's a complicated script and there are some apparently old bugs that need ironing out. @Iri: I've disconnected the URL/DOI/etc. lookup buttons; they connect to an offsite script that I don't know about and can't vouch for. Let me know if that was an important feature for y'all. Writ Keeper  15:55, 8 November 2018 (UTC)
Lookup wasn't something I ever used—I found that because it imported the formatting quirks of the source website (curly quotes, allcaps, etc) it took more time to check its output than it did to input the citation manually field-by-field. I know that trainers use the URL/DOI lookup in training courses for new editors as a "see, citing sources aren't as scary as the raw reference markup makes it look" exercise, but I would imagine they're likely using vanilla default settings so as not to confuse people who've just created the account, so this toolbar won't appear. Paging Redrose64, NeilN, SpinningSpark, LindsayH, Keith D and Diego Moya as the people (other than me) who said they were still using it last time the WMF claimed nobody was still using this, who may be able to give a better idea of whether people consider this functionality important. ‑ Iridescent 17:08, 8 November 2018 (UTC)
Thanks, Writ Keeper. I've always been fond of that citation tool, especially for Google books. I like it better than WP:ProveIt, but I've had to make do with since. howcheng {chat} 17:15, 8 November 2018 (UTC)
@Iridescent: I turned off that toolbar when it got too slow to load. Virtually all of its functionality is available in the "⧼MediaWiki:Gadget-charinsert⧽" gadget, which is enabled by default - it amazes me just how many people claim that they can't do something, and all the while it's in that gadget, usually when "Wiki markup" is selected. A few buttons, like the "cite" one, are absent, but I never used that. The interminable whining at Wikipedia talk:Manual of Style/Archive 208#Doesn't MOS:DASH contradict WP:ACCESS? is a similar case of people not knowing that they can use the same gadget to make dashes. --Redrose64 🌹 (talk) 22:20, 8 November 2018 (UTC)
The charinsert box is better than nothing, but it adds an additional layer of complexity with no obvious benefit; as with the 2010 toolbar, the functions are there, but you need to switch to the right page to access them. Yes, it's only one extra click (or two extra clicks if you switch back out of "wiki markup" afterwards), but over time the difference between one click and two adds up. The charinsert tool is particularly user-unfriendly when using a mobile device to edit, which we're always being told is the future, as the buttons are so small and fiddly (and using the 2010 toolbar on a mobile device is also horrible—unless you're in a 4G spot, you can literally watch the buttons load one at a time). ‑ Iridescent 23:50, 8 November 2018 (UTC)
It's no extra clicks if you leave it set to "Wiki markup", which is what I do - I occasionally need the things in Cyrillic or Greek, after which I switch it back to Wiki markup. This set includes all of those in the "Insert" set, which is where it starts if you've never used it, have switched devices, or have zapped your cookies. --Redrose64 🌹 (talk) 00:20, 9 November 2018 (UTC)
  • Hey, allUser:DuncanHillUser:Iridescent, the RefToolbar is ready for trial. Owing to its complexity, it's a separate script from the toolbar itself; you can install it by adding mw.loader.load("/w/index.php?title=User:Writ_Keeper/Scripts/legacyRefToolbar.js&action=raw&ctype=text/javascript"); to your common.js page on a new line, similar to the installation for the rest of the toolbar. Let me know how it works, and if there's anything else missing from it or the toolbar. Thanks! Writ Keeper  19:12, 8 November 2018 (UTC)
  • On some very limited testing, it looks to be working fine. Many, many thanks. ‑ Iridescent 19:17, 8 November 2018 (UTC)
    • Thank you, looking good. Please can you take over from the Foundation? DuncanHill (talk) 19:20, 8 November 2018 (UTC)
    • Thank you so much Writ Keeper. I'm another editor who was still using it and I am eternally grateful :) Pawnkingthree (talk) 20:16, 8 November 2018 (UTC)
      • @Writ Keeper: I've created my common.js page and copied and pasted that code into it. I am using monobook on Chrome and I have the 2010 tab turned off. However it doesn't appear to be showing up for me? The C of E God Save the Queen! (talk) 16:26, 11 November 2018 (UTC)
        • @The C of E: legacyRefToolbar adds a cite button to legacyToolbar which must already be loaded (maybe this should happen automatically). Load both with the below code. PrimeHunter (talk) 16:43, 11 November 2018 (UTC)
mw.loader.load("/w/index.php?title=User:Writ_Keeper/Scripts/legacyToolbar.js&action=raw&ctype=text/javascript");
mw.loader.load("/w/index.php?title=User:Writ_Keeper/Scripts/legacyRefToolbar.js&action=raw&ctype=text/javascript");

MonoBook editing toolbar removed

I haven't had the toolbar visible since last night (the older version, of course), has it been removed from service? I have checked all my browsers and it's gone (no changes to any of my gadgets, enables or beta components). Nate (chatter) 16:38, 8 November 2018 (UTC)

@Mrschimpf: If you mean this toolbar:
RefToolbar 1.0.png
...then it has indeed been removed. See the #Support_ends_for_the_2006_wikitext_editor section above; I'm currently working to re-implement it as a user script for those that prefer it. Writ Keeper  17:25, 8 November 2018 (UTC)
Thank you, Writ Keeper, I liked that toolbar much better! If you are able to set that up, can you make some kind of announcement here, maybe start a new section heading so we will see it in the history - maybe something along the lines of "Rejoice, you can have your old toolbar back!" 0;-D And include simple instructions (preferably not in French) on how to implement it, for us tech-ignorant folks? --MelanieN (talk) 00:15, 14 November 2018 (UTC)
Thanks; sorry I missed it above (I just knew it as 'the older toolbar' and nothing else, so I didn't think of looking up there). I look forward to having it back in some form. Nate (chatter) 17:39, 8 November 2018 (UTC)
ARGH. So, some time back my software on my tablet updated and changed ...something... so that when I try to add bolding the “old fashioned way” it doesn’t work. Example: ‘’’Bold should be here’’’ but apparently whatever software change went on broke that. So, whatever, I adjusted and started using the toolbar instead. And now it’s gone and I am apparently unable to use bolding or italics. Beeblebrox (talk) 17:47, 11 November 2018 (UTC)
@Beeblebrox: You are using curly apostrophes (and indeed curly quotes too). Besides being advised against in text (see MOS:CURLY), they won't produce the desired markup either. You must use straight apostrophes - like this - for them to work. This is basic Wiki markup, see WP:CHEATSHEET. --Redrose64 🌹 (talk) 21:57, 12 November 2018 (UTC)
This is what I see in the editing window, but when I save it it’s ‘’’Bold’’’ and ‘’italics’’
The thing is, when I type them in they look like y always did, but when I save my edit they turn curly and I have no idea why. I’m pressing the same key I always did. Beeblebrox (talk) 21:28, 13 November 2018 (UTC)
I found the issue at some point my settings were changed to include smart punctuation which I have now turned off. Yay. Beeblebrox (talk) 21:42, 13 November 2018 (UTC)

Missing edit shortcuts

I've noticed that over the last couple of days I appear to be missing the edit shortcuts (the line of icons above the edit box for lack of a better description) from the edit space in my Chrome browser. I haven't deactivated anything so I was wondering if there is a technical problem in the wiki syntax. The C of E God Save the Queen! (talk) 22:36, 10 November 2018 (UTC)

Yes, see #Support ends for the 2006 wikitext editor above. Killiondude (talk) 22:58, 10 November 2018 (UTC)

Making links conditional on target status

Some category header templates now include automated links to portals, passing them to {{Portal}}. They only check whether the portals exist; they don't check whether the portals are ready for use, and some are not, e.g. Portal:1910s has been started but is tagged with {{Portal maintenance status|date=October 2018|incomplete=y|subpages=checked|broken=major}}.

Would it be feasible for {{Portal}} to check the status of the portal, and exclude broken ones? – Fayenatic London 13:38, 31 October 2018 (UTC)

Yes. Modify Module:Portal to read the unparsed content of the portal page and look for {{Portal maintenance status}}. You can then have Module:portal take appropriate action whatever that might be.
Trappist the monk (talk) 13:46, 31 October 2018 (UTC)
Thank you very much, Trappist the monk. I did not realise there was a module:Portal. Please could you, or someone else reading this, insert a condition there so that the module will skip linking to a portal with status broken=major ? – Fayenatic London 08:25, 3 November 2018 (UTC)
I could, but I'm not sure that I should. I almost never venture into portal space, but your Portal:1910s example doesn't look all that broken to me; readers going there will find something so I guess that I'm not seeing this as a problem. If, as part of whatever construction is undertaken, the portal page displays huge red error messages, has broken html, or whatever, and if that condition will exist for a while, perhaps the best solution is to do portal development in a sandbox and then publish the sandbox version when it is ready for public consumption. This is, after all, why we have sandboxen. No new code to write, no new code to maintain.
Trappist the monk (talk) 09:38, 3 November 2018 (UTC)
Yeah, if a portal is bad enough (for more a week or so while it is under construction) that it shouldn't be linked, then it shouldn't be in portal space at all but in draftspace. Galobtter (pingó mió) 09:43, 3 November 2018 (UTC)
Sandboxing is nice in theory, but some editors have been mass-producing automated portals with zero curation or maintenance. See recent discussions at WT:WPPORT and WT:PORTG#Notability_Discussion:_Revived. Also, their construction techniques use {{PAGENAME}} which probably wouldn't work in sandboxes.
There are currently 70+ portals tagged as broken (which places them in Category:Portals with errors in need of immediate attention), but no sign of them being actively attended to.
I have asked at Wikipedia_talk:WikiProject_Portals#Portal_linkage_problems whether there is consensus to add the code suggested above. – Fayenatic London 10:13, 7 November 2018 (UTC)
Draftspace isn't set up for portals, and portals don't work in draftspace. That is, their code doesn't work in draftspace, and when moved to draftspace, they become broken.    — The Transhumanist   00:46, 8 November 2018 (UTC)
What would happen to the portal box when it has a single link, and that link is not displayed?    — The Transhumanist   00:46, 8 November 2018 (UTC)
You pinged me into this conversation and then removed the {{ping}} so perhaps you don't want my participation here. Regardless, the answer to the question that you asked me is: I don't know. What happens to the portal box is dependent upon what the community determines to be the appropriate action for Module:Portal to take when it encounters |broken=major.
Trappist the monk (talk) 12:01, 8 November 2018 (UTC)

Portals have features that may acquire regular readers who return to portals or regularly click on portal links for their news, DYKs, automatically updating content, and automatically added content. Having links disappear could be disruptive to those readers. If a portal becomes broken and its link disappears, regular readers may not know how to contact the right people to fix it. With a link to a broken portal in place, they would see the problem, and would have the opportunity to go to the portal's talk page to report it, or even collaborate with others to fix it. On the portal's talk page, they would see our link to the WikiProject, and could go there to report the problem as well. With no link, they lose those options. For veterans like us, that's no big deal. But for new Wikipedians, or readers who have limited editing experience, that could leave them almost helpless, scratching their heads. Having links disappear may also have other ramifications that we are not yet aware of. We don't want to hide the problems, we want to fix them, and we want anybody on the scene to be able to do it. A link to a broken portal should also be a route to the instructions on how to fix it, such as having a link to the portal instruction page on every portal's talk page. We need to enable people who use portals to be able to help maintain them, rather than remove the option to do so.    — The Transhumanist   01:06, 8 November 2018 (UTC)

A portal that becomes slightly broken, may still be helpful to readers, such as if its news feature is still working. Why remove access to that news if the image slideshow all of a sudden becomes empty because images were removed from the root article from where they were displayed? This creates a domino effect. We need to be careful not to fall into an all-or-nothing mindset. A partially functioning portal is still useful, especially to regular visitors of the portal system.    — The Transhumanist   01:15, 8 November 2018 (UTC)
I checked 3 portals at random listed at Category:Portals with errors in need of immediate attention, and they had no problems. That list is is making the problem look bigger than it really is, and introduces the problem of false positives.    — The Transhumanist   01:35, 8 November 2018 (UTC)

VisualFileChange

How difficult would it be to import VisualFileChange over from Commons to en.wiki, so that users who are patrolling images can perform batch actions and avoid spamming user pages with multiple automatically generated Twinkle notifications? GMGtalk 12:37, 2 November 2018 (UTC)

Some of this is prompted by some comments at User_talk:Ritchie333#How_to_go_from_here - which I have restated below (in modifed form) ...ShakespeareFan00 (talk) 12:43, 2 November 2018 (UTC)
Convenience link. The script is stored in commons:MediaWiki:VisualFileChange.js and subpages, so to get it here we'd need a Meta sysop to first import it to Meta wiki and then an enwiki sysop imports it here. The main problems I could see is that the JS would need to be rewritten to accomodate different namespaces, templates etc (for example, on Commons file deletion discussions occur on dedicated subpages). and that there may be dependencies outside of the main JS file. Jo-Jo Eumerus (talk, contributions) 12:48, 2 November 2018 (UTC)
Does that mean we go to phab land I presume? I mean it seems like it could be beneficial to many projects, since it seems like doing this here would facilitate transfers to any other project also (if I understand correctly), and User:ShakespeareFan00 has already started spitballing improvements for our purposes, which if eventually implemented, could also cross pollinate back over to Commons. GMGtalk 12:54, 2 November 2018 (UTC)
Prompted by some comments at User_talk:Ritchie333#How_to_go_from_here - which I will restate (in modifed form below) ...

"Would it be possible to have a multi-image/issue selector tool? That way a "wall" of notications could be be avoided, as the tool would let various issues be selected en-masse, and an image patroller could "batch" up requests, into ONE notifcation, perhaps for some uploaders containing ALL the media with issues that had been identified or flagged.

Alternatively (And possibly combined with the above), perhaps an upload "dashboard" (An extension of Special:ListFiles]] }} for users would be helpful, so that rather than seeing a wall of notifcations on the talk page, you get a 'bell' style notification in the UI, which links to the relevant concern in the image dashboard. This would also allow for the consideration that some people don't read their talk pages often, but do respond to the 'bell' or 'tray icons. (Not all CSD notifications or image tagging operations generate notifications, my custom notifcations)

Importing VisualFileChange from Commons, would be part of the soloution, as VFC can at least do multiple tags per image, or per batch as I understood it..

A more advanced tool than VFC would need to go further though, as VFC works on a 'batch' of images to apply the "same" set of issues. What would also be needed is a tool that can see a batch of images, and if needed apply 'differing' tags (by user selection on a per image basis if needed) in the batch. Some CSD are applied slightly differently if you have different license tags,to give an example. Some Tags need date= tag applied ( or on one of mine placed= tags, and so on. Once a set of images and associated tags are logged, the tool I am describing should generate ONE BIG notification covering all the affected media and issues, rather than a wall of notifcations like TWINKLE does when patrolling a lot of images.

Related Discussion on a "media" dashboard, vs talk page notifcations.

Alternatively (And possibly combined with the above), perhaps an upload "dashboard" (An extension of Special:ListFiles for users would be helpful, so that rather than seeing a wall of notifcations on the talk page, you get a 'bell' style notification in the UI, which links to the relevant concern in the image dashboard. This would also allow for the consideration that some people don't read their talk pages often, but do respond to the 'bell' or 'tray icons. (Not all CSD notifications or image tagging operations generate notifications, my custom notifcations)

Related consideration, When media you uploaded gets tagged for CSD , currently you get a Talk page notification in most instances.. Is there are mechanism for this instead to be a 'notification' instead?

Suggested format " <User X> has edited [[File:]] which you uploaded or restored... The edit is <link to diff> " or " <user X> has tagged [[File: ]] which you uploaded for <CSD criteria>, Please review your upload and take appropriate action.". Moving image issue notifcations from tak pages to a dedicated dshaboard or log, might also increase visibility and response to the notifcations. Other things which are image notifications that could be a 'bell' styule notifcation, might be listing at FFD, pending commons transfer (different from F2, F8 as such) and so on...

Such notifications should ideally be based on what a user has uploaded (without them needing to be explicitly placed in a Watchlist), (and potentially on File: pages contained in a Watchlist for that user.) ShakespeareFan00 (talk) 12:57, 2 November 2018 (UTC)

Umm...I'd say a good first step would be whether we can find a competent victim volunteer to just get the thing over here. GMGtalk 13:22, 2 November 2018 (UTC)
I don't think that you don't need to get the script imported, it's possible to install JavaScript that is hosted on another Wikimedia project. For example, I find User:Anomie/previewtemplatelastmod very useful (thanks Anomie), but it's not set up on Wicipedia Cymraeg, so I import it cross-wiki, see cy:Defnyddiwr:Redrose64/common.js. In this case I think that the required code is
mw.loader.load('//commons.wikimedia.org/w/index.php?title=MediaWiki:VisualFileChange.js&action=raw&ctype=text/javascript');
placed in Special:Mypage/common.js. JavaScript experts, please confirm. --Redrose64 🌹 (talk) 17:56, 8 November 2018 (UTC)

Colors disappeared

Weird. I got used to seeing colors when I edited on Wikipedia. Now I don't see them.— Vchimpanzee • talk • contributions • 20:07, 5 November 2018 (UTC)

What colors you mean? Do you mean colors in the edit box when you are editing wiki pages? Stryn (talk) 20:15, 5 November 2018 (UTC)
And now the colors are back. I wonder what's going on. For example, the equals signs to the left and right of the heading (which is larger than the other text) are blue, and so are the Wikilinks and the colon and four tildes.— Vchimpanzee • talk • contributions • 20:16, 5 November 2018 (UTC)
Colors disappeared again. I also find that if I try to insert text, the text that was there disappears rather than being pushed to the right.— Vchimpanzee • talk • contributions • 20:37, 5 November 2018 (UTC)
@Vchimpanzee: Where are you seeing colors? In the edit box? What editor are you using if so? --Izno (talk) 21:03, 5 November 2018 (UTC)
This sounds like slow servers. Several times today I have failed to receive one or another of the CSS or JS pages that should be served to me when retrieving a Wikipedia page; I suspect that Vchimpanzee is experiencing the same problem. --Redrose64 🌹 (talk) 21:10, 5 November 2018 (UTC)
Per their description Vchimpanzee is talking about mw:CodeMirror syntax highlighting. Galobtter (pingó mió) 21:17, 5 November 2018 (UTC)
Redrose64 that sounds like the problem. Galobtter I never knew what it was called.— Vchimpanzee • talk • contributions • 21:26, 5 November 2018 (UTC)
I haven't seen colors all day. At both libraries I have been using Google Chrome. I have Edge at home.— Vchimpanzee • talk • contributions • 22:02, 8 November 2018 (UTC)

Upside down text

I have fixed it but does anyone know how this was done? Aoziwe (talk) 10:26, 7 November 2018 (UTC)

Most characters have an inverted glyph somewhere in Unicode... it's probably some utility that a vandal was playing with. I suspect that this reverses the order of characters in a string and then replaces each character with it's inverted equivalent:
Some (l, s) map to themselves; some (n/u) are easy mappings because the inverted character is a valid Latin letter. The first step is dead easy, we did it as one of the first programming assignments at school; the second step requires a lookup table. --Redrose64 🌹 (talk) 10:42, 7 November 2018 (UTC)

Thanks Redrose64 - seems like a lot of trouble for a vandal. Aoziwe (talk) 10:59, 7 November 2018 (UTC)

It took seconds to find http://www.upsidedowntext.com with the first tested Google search online invert letters. It's also first for your heading Upside down text.PrimeHunter (talk) 12:50, 7 November 2018 (UTC)
Thanks. Aoziwe (talk) 12:58, 7 November 2018 (UTC)
˙op oʇ ʎsɐǝ ʎɹǝʌ ʇᴉ sǝʞɐɯ ʎllɐnʇɔɐ ǝʇᴉs ʇɐɥ┴ Home Lander (talk) 00:54, 8 November 2018 (UTC)
see User:Plastikspork/flipsummary.js :) Frietjes (talk) 18:42, 8 November 2018 (UTC)
Upside down text is so last year. Iridescent 18:53, 8 November 2018 (UTC)
Jeebus. I almost ordered a new computer. ―Mandruss  18:56, 8 November 2018 (UTC)
What is that mess? I cannot read the diff, nor this edit window (which has slowed to a crawl); even my watchlist is screwed with little squares all over the edit summaries for about twelve lines. Please don't do it again. --Redrose64 🌹 (talk) 19:10, 8 November 2018 (UTC)
How about we edit-filter that shit? Headbomb {t · c · p · b} 19:19, 8 November 2018 (UTC)
I'm not sure it would be possible to edit filter Zalgo text; because it's made of the standard ASCII character set plus combined diacritics as opposed to specialist and obscure unicode, the diacritics used differ each time, and there are many legitimate uses for diacritics, I can't see how you could write a script that wouldn't hit too many false positives. (This is precisely why vandals—on all user-generated sites, not just Wikipedia—like it so much.) On the plus side, because it screws up the formatting and page history so visibly, it's very easy to spot, so it rarely stays live for long. On upside-down text, it probably wouldn't be possible to filter at all, as all the symbols used have legitimate uses. ‑ Iridescent 19:32, 8 November 2018 (UTC)

Updating a tool

Can a user like me update a wmf lab tool? I am talking about Firefly Tools which is helpful in showing the Linter category count.Adithyak1997 (talk) 18:20, 8 November 2018 (UTC)

@Adithyak1997: WMFLabs is just a hosting site for user-created tools. That particular tool is maintained by firefly. I would contact him if you would like to contribute. There is already a thread on his talk page about the tool not updating recently: User talk:Firefly#Firefly Linter page not updating?. --Ahecht (TALK
PAGE
) 22:19, 8 November 2018 (UTC)
The thread in his user page was the reason due to which I thought of contributing to it.Adithyak1997 (talk) 04:22, 9 November 2018 (UTC)

Template comparison tool

As discussed some time ago (HT User:Plastikspork), we could do with a tool to facilitate the comparison of related templates to decide whether or not to merge them.

The tool would do the following, for two (or more?) templates:

  • determine the list of parameters in each (perhaps from raw code; perhaps from TemplateData; perhaps from {{Parameter names example}})
  • sort them
  • remove those that are the same in both cases
  • produce a list of the differing parameters

Can someone make a tool to do this, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:49, 8 November 2018 (UTC)

@Pigsonthewing: This might be a good candidate for the meta:Community Wishlist Survey 2019, if you can get a proposal in in the next couple of days. --Ahecht (TALK
PAGE
) 22:21, 8 November 2018 (UTC)
You could use the TemplateData GUI editor to produce a list of (most) parameters from the code. From there, I think that a quick round of grep -xvf would produce the list of unmatched options, for manual review. Whatamidoing (WMF) (talk) 17:23, 9 November 2018 (UTC)
Here is a module hack that, for the purposes of proof-of-concept compares {{cite book/old}} against {{cite journal/old}} (these are the pre-Lua cs1 templates). The output is merely the raw mw.dumpObject() return value and can be prettified to suit:
{{#invoke:Sandbox/trappist the monk/template compare|compare|Template:Cite book/old|Template:Cite journal/old}}
table#1 {
 ["Embargo"] = "Cite journal/old",
 ["department"] = "Cite journal/old",
 ["issue"] = "Cite journal/old",
 ["journal"] = "Cite journal/old",
 ["magazine"] = "Cite journal/old",
 ["newspaper"] = "Cite journal/old",
 ["number"] = "Cite journal/old",
 ["periodical"] = "Cite journal/old",
 ["section"] = "Cite book/old",
 ["sectionurl"] = "Cite book/old",
 ["trans_chapter"] = "Cite book/old",
 ["work"] = "Cite journal/old",
}
Trappist the monk (talk) 18:15, 9 November 2018 (UTC)
Pigsonthewing, I adapted some javascript that I wrote for "User:Frietjes/addcheckforunknownparameters.js" to create "User:Frietjes/templatecompare.js". once installed, you go to "Special:TemplateCompare" and put in the list of templates to compare. if you see a "Did not finish processing" alert, then let me know, and I will adjust the regular expressions to try to get complete processing for that particular template. I tested it on {{cite book/old}} against {{cite journal/old}} and it looks like it's working there. Frietjes (talk) 21:04, 9 November 2018 (UTC)
Frietjes, a first column for the parameters is missing which is offsetting the columns by one. --Gonnym (talk) 08:21, 11 November 2018 (UTC)
Gonnym, fixed, and I added an html preview for the wikitable. Frietjes (talk) 14:18, 11 November 2018 (UTC)
@Frietjes: Thank you. More often than not, I'm not seeing the list-of-parameters table. It does appear intermittently. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:31, 13 November 2018 (UTC)
@Pigsonthewing:, it could be taking some time to process the templates. I put the pop-up alerts in there to show the progress through the script. if you have particular examples you want me to help debug, let me know. Frietjes (talk) 13:33, 13 November 2018 (UTC)
@Frietjes: I've just tried {{Infobox event}} vs. {{Infobox civilian attack}} and after five minutes nothing had rendered. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:10, 13 November 2018 (UTC)
@Pigsonthewing:, you are correct. it was failing on the expandtemplates for some reason, which is only used to show a preview of the wikitext. I switched this to something else, it is working for me now. Frietjes (talk) 20:28, 13 November 2018 (UTC)
now documented at User:Frietjes/templatecompare. Frietjes (talk) 00:15, 14 November 2018 (UTC)
@Frietjes: That's working well now, and is very useful. Thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:30, 15 November 2018 (UTC)

Issue with my Special:Contributions page?

For some reason, my Special:Contributions page looked like this earlier: (Imgur link). It was the case whether I was logged in, logged out, using Chrome or using Edge. The problem appears to have since been resolved, but still. What happened here? Narutolovehinata5 tccsdnew 20:46, 8 November 2018 (UTC)

It also happened to me for all tested contributions pages, logged in or out in two browsers. It was right after the English Wikipedia got mw:MediaWiki 1.33/wmf.3 today 20:28.[8] It lasted a few minutes. PrimeHunter (talk) 21:02, 8 November 2018 (UTC)
WP:ITSTHURSDAY. --Izno (talk) 21:13, 8 November 2018 (UTC)
@Narutolovehinata5: It did that for me just once; a WP:BYPASS fixed it immediately. BTW, please don't upload screenshots to imgur - the page takes a long time to load, my antivirus software complains, and my PC slows to a crawl necessitating a reboot. Better methods are available. --Redrose64 🌹 (talk) 23:39, 8 November 2018 (UTC)
This is apparently still happening when the page is transcluded (see my sandbox). I have a ticket open because it recently started breaking MathML rendering (see phab:T209446). — AfroThundr (u · t · c) 01:34, 14 November 2018 (UTC)

Edit conflicts: updated beta feature

Today on (8th November), a beta feature on your wiki has changed: The two-column edit conflict view got a new interface to allow you to solve edit conflicts more easily. The feature comes from the German community’s Technical Wishlist. Learn more on the project page. -- Michael Schönitzer (WMDE) (talk) 21:20, 8 November 2018 (UTC)

Transclusion help needed

I have been trying to transclude the contents of Portal:Music/DateOfBirth/November 9 to a page in Portal:Record production. When I use {{Portal:Music/DateOfBirth/November 9}} the contents of {{Portal:Music/DateOfBirth}} transcludes, irrespective of the date used. Having tried to figure out why, I am thoroughly perplexed. Can someone help me understand why it doesn't work (or better, how to make it work)? Thank you.--John Cline (talk) 10:40, 9 November 2018 (UTC)

@John Cline: you don't state what "a page in Portal:Record production" actually is, and I can't tell from your recent edits which page this might be. --Redrose64 🌹 (talk) 10:52, 9 November 2018 (UTC)
I'm sorry Redrose64. I haven't saved any changes because they never worked in preview. The page is Portal:Record production/DateOfBirth. Thank you.--John Cline (talk) 11:01, 9 November 2018 (UTC)
@John Cline: Portal:Music/DateOfBirth/November 9 transcludes Portal:Music/DateOfBirth/November which transcludes {{Calendar}} which has pagename-dependent behaviour to make a calendar with dates and links corresponding to the page it is on. The transclusion should be in <noinclude>...</noinclude> like [9] so the calendar is only made on the page itself. Most other dates already do it.[10] This search looks for dates missing this <noinclude>...</noinclude>. PrimeHunter (talk) 11:30, 9 November 2018 (UTC)
Thank you PrimeHunter, and Redrose64. The insource: search parameters will be quite useful going forward as well. I really appreciate the help.--John Cline (talk) 11:53, 9 November 2018 (UTC)

can't remove username from login page

When i press shift+del in chrome on windows after highlighting the username, chrome only removes the password, and the username is offered the next time one clicks on "log in". --Espoo (talk) 17:58, 9 November 2018 (UTC)

@Espoo: try clearing your cache, forms, and WMF cookies. — xaosflux Talk 22:43, 9 November 2018 (UTC)
Thanks. It would be important to provide a button after logging out that automates that for users, most of whom don't know they have to do that or how to do that. --Espoo (talk) 07:17, 10 November 2018 (UTC)
Those are controls about options in your browser which we don't control. One tip that might be good for your use case, use "private browsing" sessions, Microsoft, Google, and Mozilla browsers support these and won't remember anything from that session. — xaosflux Talk 17:06, 10 November 2018 (UTC)
...assuming that you don't mind logging in repeatedly. I accidentally had a wiki page in "private browsing" mode a few week ago, and it took me a while to figure out why it kept demanding that I log in over and over and over. Whatamidoing (WMF) (talk) 23:31, 12 November 2018 (UTC)

RM discussion for Template:La and others

A WP:RM discussion at Template_talk:Ln#Requested_move_28_October_2018 to move the various "namespace links" templates from short names (i.e. {{la}} or {{lh}}) to more descriptive names (i.e. {{Article links}} or {{Help links}}) is currently open for discussion. The short forms would remain redirects and still work. This naming discussion may be of interest to readers of this noticeboard. power~enwiki (π, ν) 20:38, 9 November 2018 (UTC)

Accessing parent template params from a subtemplate

Resolved

Is a subtemplate able to access the parameters of its parent template without them being included in the subtemplate's call string? For example, suppose I call {{x1|a=1|b=2|c=3|d=4|e=5|...|z=26|aa=101|bb=252|...|zz=26926}} and the code of {{x1}} in turn calls {{x2|1=a|2=aa|3=zz}}. I'd like for {{x2}} to have access to all of the {{x1}}'s parameters, so that, for example, within {{x2}} I could invoke the following:

  1. {{{ {{{1}}}}}} → {{{a}}} → 1
  2. {{{ {{{2}}}}}} → {{{aa}}} → 101
  3. {{{ {{{3}}}}}} → {{{zz}}} → 26926
  4. {{{ {{{1}}}{{{1}}}}}} → {{{aa}}} → 101

The only solutions I can think of are:

  • Append all {{x1}} parameters when invoking {{x2}}: {{x2|1=a|2=aa|3=zz||a=1|b=2|c=3|d=4|e=5|...|z=26|aa=11|bb=22|...|zz=2626}}
  • Expand all of the parameters when invoking {{x2}}: {{x2|1={{{a}}}|2={{{aa}}}|3={{{zz}}}}}

However, for my particular application, neither of these is workable. The first is unworkable because my x1 has about 200 parameters and invokes x1 multiple times, which I'd like to have appear on consecutive lines. The second is unworkable because my x2 mangles its input parameter values something like example 4 above so that each x2 parameter is actually used to select up to five different x1 parameters, and if include them all, then my x2 invocations won't fit on a single line. Any ideas? YBG (talk) 21:23, 9 November 2018 (UTC)

Lua modules can do this using frame:getParent(), but it is impossible to do in Wikitext, so this could be accomplished by luafying {{x2}} (or writing a wrapper in lua. {{3x|p}}ery (talk) 21:38, 9 November 2018 (UTC)
@Pppery: Thanks! YBG (talk) 21:57, 9 November 2018 (UTC)

WP:SPI "Date filed" showing an error for some investigations?

Wikipedia:Sockpuppet investigations/JoshuSasori was filed in July, not October 11; I checked a few others and most of them seemed to be accurate, but Wikipedia:Sockpuppet investigations/Boyhoodjams shows as having been filed on October 13 despite the multiple entries apparently having been filed between August 29 and September 4. I'm fairly certain I know why (both pages were subject to a particular kind of disruptive vandalism), but I was wondering if there was any way to remedy it? Hijiri 88 (やや) 08:07, 10 November 2018 (UTC)

Regarding your second example, the date was changed in this edit after a vandal moved the casepage. That means when a page is moved, the bots probably assumes it's a new filing. May be it should stop. So you can ask Amalthea the botop of the bot that updates Wikipedia:Sockpuppet investigations/Cases/Overview for that, though it looks he has not edited for a while. –Ammarpad (talk) 10:39, 10 November 2018 (UTC)
@Hijiri88: 'Date filed' is actually 'date the page was added to Category:Open SPI cases', because this is cheap and easy to figure out. There's currently no way to change that I'm afraid. Amalthea 08:54, 13 November 2018 (UTC)

Script issues

Following a query (on my talk page), I tried the usual troubleshooting actions, but cannot understand why my Engvar script doesn't work in isolation and in the context of another user's monobook script (meaning the button doesn't dislay in the side bar when supposedly installed). I did find however, that all my scripts become callable from within my monoboook files. My workaround is to advise importing my monobook.js file by pasting the instruction:

importScript("User:Ohconfucius/monobook.js"); while removing importScript("User:Ohconfucius/script/EngvarB.js");

The consequence, however, is that it creates a very busy the sidebar above all for the users who have no utility for my other scripts, but at least it seems like an acceptable work-around for me. What could be the problem? -- Ohc ¡digame! 09:35, 10 November 2018 (UTC)

This sounds like your Engvar script has some dependencies that are resolved by the presence of one or more of the other scripts in your monobook.js - try removing scripts one at a time from monobook.js until EngvarB.js fails. Then examine the last one removed, to see what it does that Engvar might depend upon. --Redrose64 🌹 (talk) 09:53, 10 November 2018 (UTC)
Thanks, @Redrose64: I tried loading a few scripts on my vector page. It seems that there is no dependency on my formatgeneral script. However, it seems to need either my foreigndates script or my MOSNUM script for example. How can I now identify what element in these scripts that ENGVAR requires and then to make the appropriae addition? -- Ohc ¡digame! 16:53, 14 November 2018 (UTC)
These being User:Ohconfucius/test/MOSNUM dates code.js and User:Ohconfucius/script/foreigndates.js. You probably need to add one of these three lines
mw.loader.load('//tools-static.wmflabs.org/meta/scripts/pathoschild.templatescript.js');
importScript("User:Ohconfucius/script/MOSNUM_utils.js"); 
importScriptURI('//meta.wikimedia.org/w/index.php?title=User:Pathoschild/Scripts/Regex_menu_framework.js&action=raw&ctype=text/javascript');
to User:Ohconfucius/script/EngvarB.js. --Redrose64 🌹 (talk) 19:23, 14 November 2018 (UTC)
Thanks for that. FYI, it was the third one. -- Ohc ¡digame! 08:49, 15 November 2018 (UTC)

"Edit your list of watched pages"

PHP fatal error: entire web request took longer than 60 seconds and timed out: Supposedly because of maintenance, but it's been doing this for hours. Any ideas? ——SerialNumber54129 14:22, 10 November 2018 (UTC)

@Serial Number 54129: do you have more than 5000 pages on your watchlist? Are you able to access Special:EditWatchlist/raw? — xaosflux Talk 15:20, 10 November 2018 (UTC)
@Xaosflux: Err: yes, 26,057...I wanted to cut it down a bit you see. Great though, yes I can access the raw list. Is that a little odd? Thanks for your help Xf. ——SerialNumber54129 15:48, 10 November 2018 (UTC)
@Serial Number 54129: sounds a lot like the mostly ignored phab:T41510. Prior discussions seem to be along the lines of "1>When my watchlist is huge it doesn't work. 2>Don't use a huge watchlist". — xaosflux Talk 16:51, 10 November 2018 (UTC)
I've been bothered by the obvious move of the raw link only to where you have to load the pretty edit-watchlist page, so unless you know the raw page is there, you're screwed with super-long watchlists. Tempted to file a phab about it. --Izno (talk) 15:58, 10 November 2018 (UTC)
@Izno: where would you want it to appear? — xaosflux Talk 16:48, 10 November 2018 (UTC)
If anyone wonders what this is about: With the current default preferences, the top of Special:Watchlist has a single large button "Edit your list of watched pages", and no link to the raw list. If "Hide the improved version of the Watchlist" is enabled at Special:Preferences#mw-prefsection-watchlist then you instead get smaller "View and edit watchlist | Edit raw watchlist" next to eachother. PrimeHunter (talk) 18:30, 10 November 2018 (UTC)
@PrimeHunter: when you end up at Special:EditWatchlist are you getting the 'raw' option at the top still? — xaosflux Talk 20:22, 10 November 2018 (UTC)
Yes. I only meant the option is not directly in Special:Watchlist by default. PrimeHunter (talk) 20:27, 10 November 2018 (UTC)
@PrimeHunter: OK, yeah sure why not? Going to require a fight with those OOUI devs though :( The messages on the orinal WL are:
(watchlistfor2: Username, (parentheses: (watchlisttools-view)(pipe-separator)(watchlisttools-edit)(pipe-separator)(watchlisttools-raw)(pipe-separator)(watchlisttools-clear)))
I turned off that horrid "improved" watchlist the second it came out! — xaosflux Talk 20:53, 10 November 2018 (UTC)

iarchive

iarchive:cupola-1983/page/n0

What is this and how does it work? I've never seen iarchive: before (the macro? not the site). Thanks -- GreenC 00:20, 11 November 2018 (UTC)

Technically that magic is due to meta:Interwiki map and the entry for IArchive appears to have been added in November 2013 following a discussion here. Johnuniq (talk) 00:33, 11 November 2018 (UTC)
Interesting, thanks. I had no idea interwiki maps extended beyond the wikis. One more complication for bot writers :) -- GreenC 00:46, 11 November 2018 (UTC)
If you have a bot that's dealing with interwiki links, you should probably be getting the list from action=query&meta=siteinfo&siprop=interwikimap rather than having to know about meta:Interwiki map. Anomie 15:37, 11 November 2018 (UTC)
And Special:Interwiki shows in human-friendly form what MediaWiki currently uses. meta:Interwiki map is where the interwiki prefixes are created and edited but there can be a long delay before changes are imported into MediaWiki. PrimeHunter (talk) 21:41, 11 November 2018 (UTC)

Earwig's Copyvio Detector

I am trying to use Earwig's Copyvio Detector to search a document in draft space for copyright violations, using the search engine. After it connects to wmflabs, it says that no sources were checked, and the probability of a copyright violation is 0%. Well, it should be 0% if there was no searching. What causes it not to search anything, and what do I do to correct this, to get it to search? Robert McClenon (talk) 07:09, 11 November 2018 (UTC)

Robert McClenon, I'm getting the same issue. IIRC, it happens because too many people have already ran it within the last day. Home Lander (talk) 21:45, 11 November 2018 (UTC)
This probably happened because there was discussion about copyright violations on drafts, and the reviewers were checking the drafts. The screen refers to a cache. Maybe the cache becomes full, and the tool doesn't handle that well. Does User:Earwig still maintain the tool? Robert McClenon (talk) 01:12, 12 November 2018 (UTC)
That user hasn't, butThe Earwig would be a better person to ask. :-) Graham87 07:25, 12 November 2018 (UTC)
Thanks. Robert McClenon, I looked, and there doesn't seem to be any systemic problem with the tool right now. In general, you'll see that if every phrase from the article the tool attempted to search for in Google returned no results, and it has nothing else to go off of. The tool picks phrases at random throughout the article, so it could have gotten unlucky, or maybe the draft is truly unique, or maybe Google had some kind of problem. In my experience, if we've reached the daily request quota, you'd see a different error, but that may have changed. There shouldn't be any issues related to caches becoming full. If you give me the name of the draft, I can look more closely, but I can't be much more specific without further details. — Earwig talk 03:05, 13 November 2018 (UTC)
User:The Earwig - Try Draft:How to be a strong personality. Robert McClenon (talk) 05:09, 13 November 2018 (UTC)
Robert McClenon, indeed, every sentence in that article is unique (at least as far as Google is aware). No sources were checked because no potential sources were found. (If you look at the top right, where it says "generated in X seconds using 8 queries", that tells us eight separate searches were made, and none of them turned up any hits.) — Earwig talk 02:23, 14 November 2018 (UTC)

Multiple Short Description

In many of the pages, I was able to see that there are multiple short descriptions occurring for a single article. Both of them are same. For example, consider the page Kondotty. I know there are two short descriptions, one from wikidata and other from wikipedia. But I guess the short description from wikidata was overridden with the one from wikipedia as requested by English wikipedia.Adithyak1997 (talk) 10:54, 11 November 2018 (UTC)

Yes. Kondotty uses {{Infobox settlement}} which automatically creates a Wikipedia:Short description. It can be overridden with short_description, the last parameter at Template:Infobox settlement#Other information. "Page information" in the left pane shows both the local and Wikidata description.[11] See also {{Short description}}. 12:22, 11 November 2018 (UTC)PrimeHunter (talk)
@PrimeHunter:So in such a case, shouldn't there be a condition set to display only one of them? I mean, in cases where there are two short descriptions, shouldn't there be a criteria to display only one of them?Adithyak1997 (talk) 14:25, 11 November 2018 (UTC)
Only if you display the descriptions by CSS are multiple descriptions shown. One description is actually used. Galobtter (pingó mió) 14:30, 11 November 2018 (UTC)
None of them are actually displayed by default in the desktop version of Wikipedia. User:Adithyak1997/common.css and User:Adithyak1997/common.js both have code to display short descriptions. The bottom of Special:Preferences#mw-prefsection-gadgets has "Show page description beneath the page title". It is disabled by default. PrimeHunter (talk) 16:09, 11 November 2018 (UTC)

& n d a s h ; rendering problem

Suddenly I'm seeing &ndash, (with a comma, followed by a blank space) where formerly I saw an actual en-dash. Is it just me or my laptop, or has this suddenly stopped working? There are probably over a million occurrences of this within Wikipedia. Michael Hardy (talk) 19:39, 11 November 2018 (UTC)

Michael Hardy, See this discussion. Ping Trappist the monk because updating the live modules to fix the issue seems quite overdue. Galobtter (pingó mió) 19:51, 11 November 2018 (UTC)

Where are the Mapframe parameters?

Several pages that use a Template:Infobox building show a map; eg. Instituto Técnico Militar and Bacardi Building (Havana)...but where are the mapframe parameters for adjusting or changing the map? It is not embedded. If I copy the whole page to my sandbox, the map disappears. If I print the page, it shows: <mapframe zoom"10' frameless="1"...etc, etc </mapframe> under the image of the infobox...help! ovA_165443 (talk) 21:05, 11 November 2018 (UTC)

@Osvaldo valdes 165443: Template:Infobox building#Mapframe maps shows optional mapframe parameters to adjust the map in the infobox. The coordinates in your examples are taken from the Wikidata item for the article. Click "Wikidata item" under "Tools" in the left pane of the article. I don't think Template:Infobox building can replace the whole mapframe map. PrimeHunter (talk) 21:34, 11 November 2018 (UTC)

Main Page responsive design

A proposal to add responsive design to the main page was briefly implemented, then reverted after problems for certain browsers and gadgets showed up. Before trying to run it live again, it would be beneficial to do some testing with some different browsers and such. Anyone want to take a look at User:Yair rand/MPSandbox and report whether you see any issues? --Yair rand (talk) 21:38, 11 November 2018 (UTC)

Green tickY Looks good here, Windows 10 Home with Google Chrome. Home Lander (talk) 21:43, 11 November 2018 (UTC)
Green tickY Also looks good on Debian Testing with Firefox Nightly. — AfroThundr (u · t · c) 03:53, 13 November 2018 (UTC)
Looks fine to me on several older iOS devices. I'd also highly advise to not rollback on every single bug that is being found when this only effects minute amounts of users. That leads to months long cycles that aren't very productive and actually hurt testing. Rollout and fix where issues are reported. The burden upon people working on this to have tested it against BB10s is unreasonable, there is no problem with such a small user groups NOT being able to use a single page for a couple of days, while others work to fix the problems. —TheDJ (talkcontribs) 09:02, 13 November 2018 (UTC)

Blacklisted IP talk pages

I recall sometime back discussing on here about an IP talk page that could not be created because it was blacklisted. User talk:2600:1700:8680:E900:8C6F:CAC6:D0E0:A9EB just exhibited the same behavior; the message intended to be left there was left at the user page instead, and a sysop had to move the page to the correct location. I recall this issue having something to do with a rule on the title blacklist; can IP talk pages be exempted from whatever it is? Home Lander (talk) 21:42, 11 November 2018 (UTC)

Wikipedia:Village pump (technical)/Archive 167#IP talk page blacklisted? was about a blacklist entry for moves at MediaWiki:Titleblacklist:
.*\p{Lu}(\P{L}*\p{Lu}){9}.* <casesensitive | moveonly>  # Disallows moves with more than nine consecutive capital letters
I don't see anything preventing a normal creation of User talk:2600:1700:8680:E900:8C6F:CAC6:D0E0:A9EB. I guess User:2600:1700:8680:E900:8C6F:CAC6:D0E0:A9EB was created by mistake instead of the talk page and then non-admins couldn't make a page move to the talk page. Moves to any page in the userspace of an IPv6 address with more than nine letters will match the rule but moves to IP userspace should be rare. Requests can be posted to MediaWiki talk:Titleblacklist. I see you already made a declined request about the old case at MediaWiki talk:Titleblacklist#IP talk pages blocked from moves. PrimeHunter (talk) 23:16, 11 November 2018 (UTC)

Populated category redirect

Category:Non-talk pages requesting an edit to a protected page now redirects to Category:Non-talk pages with an edit request template but is populated by Module:Protected edit request/active/sandbox and Module:Protected edit request/sandbox, both of which have some syntax problems that means edits can't be made to them until they're fixed. Can anyone with the tech knowledge sort them out? Timrollpickering 11:55, 12 November 2018 (UTC)

Looks like you took care of it. ~ Amory (utc) 19:30, 12 November 2018 (UTC)

Tech News: 2018-46

19:21, 12 November 2018 (UTC)

Regular expression to add flag icons and country links to country list

Please see these table updates:

Can anyone give me the regular expressions to quickly link all the country names, and to add the same flag icon wikitext that currently exist on the article pages:

I have Notepad++ and NoteTab Light installed. Both text editors allow use of regular expressions, etc.. Their syntax is not the same though.

This is the wikitext I need to add:

{{flagcountry|Country name}}

It adds the flag icon and makes the country name into a link.

Basically I need the regular expression to wrap all the text in the first cell of each line with the flagcountry template.

I will add the instructions to here:

--Timeshifter (talk) 11:59, 13 November 2018 (UTC)

@Timeshifter: I don't know your text editor syntax but our default source editor has regular expressions on "Advanced" followed by the search and replace icon on the right. There it works to search for (\|-.*\n\|\s*)([^\|\n]*) and replace with $1{{flagcountry|$2}}. Select "Treat search string as a regular expression" before clicking "Replace all". PrimeHunter (talk) 17:04, 13 November 2018 (UTC)
@PrimeHunter: Wow, this is going to help a lot of people making tables, and especially in updating tables. Thanks!!! See an example, along with some how-to info:
User:Timeshifter/Sandbox81
--Timeshifter (talk) 02:05, 14 November 2018 (UTC)

Separate buttons for single and double bracket links in the editing toolbar

My current editing toolbar has a single button for links. It is slow to create links this way. The 2 buttons were much faster.

Is there any editing toolbar that has both buttons? --Timeshifter (talk) 11:07, 13 November 2018 (UTC)

Timeshifter can you explain why this is slow ? I do paste, hit enter and I'm done ? —TheDJ (talkcontribs) 11:59, 13 November 2018 (UTC)
I use the wikitext editor. For internal links I select the internal link text, hit the link button, and then hit enter or "insert link". That is 2 steps. In the past it was 1 step. No "insert link" popup box.
For external links. I have to cut the text or the URL from the wikitext editing window, then click the link button, and paste it into the insert link box, and then hunt around for the other part, and then paste it into the insert link box, and then hit enter or "insert link". It's a nightmare compared to before.
It was much easier until very recently with the old toolbar that had separate buttons for single and double bracket links. I could set up right in the wikitext editing window.
I don't use the visual editor since I usually only do quick little edits that are much faster in the wikitext editor versus waiting for the visual editor to load. Which can be a long time in even articles of average length.
The wikitext editor opens a section almost instantly. And until very recently adding an external link was almost instant too. Single click. No "insert link" popup box.
--Timeshifter (talk) 12:18, 13 November 2018 (UTC)
Timeshifter, well you can also just type the brackets. Even faster and you don't need to move your hand to your mouse. And they are of course right beneath the edit area in the Wikitext section of the char inserter as well. —TheDJ (talkcontribs) 12:20, 13 November 2018 (UTC)
For an [[internal link]] that's 6 clicks versus 1 click. You have to place the cursor on each end. Gotta do that with a mouse if the link is buried in a paragraph. --Timeshifter (talk) 12:28, 13 November 2018 (UTC)
6 ? No... ah. Don't click the [ characters. Choose the drop-down "Wiki markup" and use the [[]] inserter. One click (well two the first time you switch the menu). —TheDJ (talkcontribs) 12:37, 13 November 2018 (UTC)
I am not seeing a drop-down "Wiki markup" in my wikitext editing toolbar. I only see the link button icon consisting of intertwined chain links. --Timeshifter (talk) 12:54, 13 November 2018 (UTC)
Wikitext editing toolbar.jpg
I uploaded a screenshot of the wikitext editing toolbar I am seeing now. I could not find anything that was exactly what I was seeing in this category:
commons:Category:MediaWiki edit toolbar screenshots
I think this below is close to the wikitext editing toolbar I was using until recently:
MediaWiki edit toolbar.png
--Timeshifter (talk) 13:30, 13 November 2018 (UTC)
@Timeshifter: No, I mean this CharInsert-it.PNG (italian version, but it looks similar), which is positioned directly underneath the textarea and is a gadget enabled by default for all users. —TheDJ (talkcontribs) 13:51, 13 November 2018 (UTC)
Let me try it here and [here]. OK, thanks a lot. That will work. Would be nice though to have those 2 buttons at the top too, instead of the popup "insert link" box from the top toolbar button which is for newbs, but only slows down experienced editors. I often have to scroll to get to the toolbar. Having my favorite buttons at both the top and bottom would speed things up and allow me and others to make more edits. That adds up. Maybe there could be a way to have custom toolbars. Where I could pick and choose buttons. Kind of like how one can customize Firefox with button placement in various locations of one's choice. I just had to scroll to find the signature button I prefer. The one that puts 2 dashes in front. :) --Timeshifter (talk) 14:28, 13 November 2018 (UTC)

(unindent). @TheDJ: No joy! After a day of use, I find this to be no help. I am usually editing at the top of the textarea in the editing window. But the single-bracket link is at the bottom of the textarea window. So I have select at the top, scroll to the bottom, be careful not to click wrongly in the interim, and then click the [] icon at the bottom. Then scroll back up to do more work. And often the wiki markup dropdown is back to being closed. So many steps, clicks, and scrolls involved just to add a couple brackets.

I am baffled as to how this could get past the MediaWiki developers. I mean it is absolutely basic to wiki editing by wiki editors across many different type of wikis. Experienced editors often use the wikitext editor. And I believe we were promised long ago that the wikitext editor would never be phased out without approval by users. Single-brackets are used all the time in wikis outside Wikimedia. Because external links are often more common than internal links.

I believe there used to be a way in preferences to turn off these popup "aids" such as the insert link popup box.

There is an easy fix. Just add an option in preferences to add those 2 wiki markup buttons to the toolbar: [] and [[]] --Timeshifter (talk) 02:20, 14 November 2018 (UTC)

Well then you should file a ticket in phabricator. —TheDJ (talkcontribs) 08:18, 14 November 2018 (UTC)
OK. See T209487 --Timeshifter (talk) 13:33, 14 November 2018 (UTC)

(unindent). Part of the problem is I no longer see a way to permanently adjust the size of the wikitext editing box. So that I don't have to scroll as much, or at all, to get to the bracket buttons. Dragging the corner adjusts the height of the editing window, but it is not remembered. It seems that wikitext editing is being limited bit by bit. --Timeshifter (talk) 14:26, 15 November 2018 (UTC)

@Timeshifter: The size of the wikitext editing box can permanently be made larger by setting the CSS declarations for width and height (the removal of the user preference for this was a long long time ago). --Izno (talk) 17:39, 15 November 2018 (UTC)
@Timeshifter: This was covered at Wikipedia:Village pump (technical)/Archive 153#Edit box size and, to a lesser extent, at Wikipedia:Village pump (technical)/Archive 169#Hard to scroll down in lower right corner of edit window. In brief: you can use this CSS rule
textarea#wpTextbox1 {
  height: 15em;
  width: 60em;
}
to set a smaller edit box size. It goes in Special:MyPage/common.css. You may need to play with the dimensions, some browsers measure an "em" according to the font size outside the edit box, so a height of 15em will not necessarily give 15 rows within the edit box. In my browser (Opera 36), those dimensions give 12 rows of 94 characters, YMMV. Omit the width: declaration if you want to stick with the default width. --Redrose64 🌹 (talk) 23:48, 15 November 2018 (UTC)

Problem with Parsoid gadget

Are there any users who use the gadget Parsoid which is used for Linter purpose? If yes, please check [this] link for my problem statement.Adithyak1997 (talk) 15:55, 13 November 2018 (UTC)

revision deletion limitations?

Are there limitations on the number of versions that can be revision deleted in one action? I'm trying to respond to the RD one request at Mohamed Naguib, which involves more than 250 versions. I tried twice, and each time the browser tab crashed. I'm happy to do it in chunks, but thought I'd check here first in case there's something I need to know.--S Philbrick(Talk) 15:58, 13 November 2018 (UTC)

@Sphilbrick: you should not have issue with under 1000 (but also see phab:T207530 for slow enwiki deletions going on). — xaosflux Talk 16:05, 13 November 2018 (UTC)
I find attempting anything over 200 in one go and the operation usually fails, so I just go in chunks. Nthep (talk) 16:13, 13 November 2018 (UTC)
Nthep, Thanks for the report. Needing to do more than 200 is rare enough that it is hardly worth investigating. I'll just remember to do chunks of <200. S Philbrick(Talk) 16:17, 13 November 2018 (UTC)
Xaosflux, FTR, I tried a third time, it crashed.
Then I tried in chunks, one of about 100, one of 150, and one more for the rest, and that worked.
I'll treat this as a one-off, but if it happens again, I'll file a report. S Philbrick(Talk) 16:15, 13 November 2018 (UTC)

Searching my contributions with a filter on a previous namespace?

I'm trying to find, in my contributions list, an edit I made to a draft. I don't remember the title of the draft, or specifically what I put in the comment field, but I'll recognize it when I see it. The edit was made sometime in the past few days.

If I filter on Draft namespace, I don't see it. I think the problem is that the draft was accepted and now lives in mainspace, so the filter on draft space no longer works. Is there some way to filter on, "It was in draft space when I made the edit"? -- RoySmith (talk) 19:10, 14 November 2018 (UTC)

If you can't find it in your contributions, perhaps you would see it by reviewing the moving log; Ctrl+F "page draft:" and skim through those. It may be possible to find the edit you made using a database query at WP:Quarry. --Izno (talk) 20:52, 14 November 2018 (UTC)
Does this list help? Drafts were introduced in 2013-ish, so your accepted draft must be one of the first 17 listed. MusikAnimal talk 22:39, 14 November 2018 (UTC)
If you used WP:AFCH then you can make a browser search (Ctrl+F in many browsers) on "AFCH" in your mainspace contributions. C3orf67 is the only hit in the last five days. PrimeHunter (talk) 23:23, 14 November 2018 (UTC)
Yeah, C3orf67 was it. Thanks. -- RoySmith (talk) 00:37, 15 November 2018 (UTC)

Two different people moved the same page???

I recently moved a page from a user sandbox to draft space. My User contributions shows the move:

(change visibility) 19:10, 14 November 2018 diffhist  (0)‎  m Draft:Highschoolers to Run Under Four Minutes in the Mile ‎ (RoySmith moved page User:Herg-derg-editor/sandbox to Draft:Highschoolers to Run Under Four Minutes in the Mile: Preferred location for AfC submissions) (current) [rollback: 1 edit]

But, if I look at the draft history, it claims that User:Legacypac is the one who did the move, one minute earlier:

(cur | prev)  19:09, 14 November 2018‎ Legacypac (talk | contribs | block)‎ m . . (2,895 bytes) (0)‎ . . (Legacypac moved page User:Herg-derg-editor/sandbox to Draft:Highschoolers to Run the Four Minute Mile: Preferred location for AfC submissions) (undo | thank)

Legacypac's contributions shows a confusing double-entry for this:

(change visibility) 19:09, 14 November 2018 diffhist  (0)‎  m Draft:Highschoolers to Run the Four Minute Mile ‎ (Legacypac moved page User:Herg-derg-editor/sandbox to Draft:Highschoolers to Run the Four Minute Mile: Preferred location for AfC submissions)
(change visibility) 19:09, 14 November 2018 diffhist  (+78)‎  N Draft:Highschoolers to Run Under Four Minutes in the Mile ‎ (Legacypac moved page User:Herg-derg-editor/sandbox to Draft:Highschoolers to Run the Four Minute Mile: Preferred location for AfC submissions) (Tag: New redirect)


Huh? Some kind of race condition in the logging? -- RoySmith (talk) 00:43, 15 November 2018 (UTC)

You moved the redirect left behind by his move. See Draft:Highschoolers to Run Under Four Minutes in the Mile. Nihlus 00:50, 15 November 2018 (UTC)
Doh! Of course, thanks for figuring that out. There was indeed a race condition, but it was between when I decided to move the page and when I actually clicked the button. I'll move the redirect back -- RoySmith (talk) 00:57, 15 November 2018 (UTC)

One computer can't load Wikipedia while another can

Hello, I've got two Windows computers, and yet one's able to access Wikipedia while the other's not. One's in Windows 7 with IE 11.0.9600.19155 and the other's in Windows 10 with IE 11.345.17134.0. I'm logged into the latter, and using my normal Monobook, while the other isn't logged in at all. This computer (obviously) can access the site, while the other is consistently returning a 404 error for Wikipedia. At the same time, the problem appears to be restricted to en:wp — using Windows 7, I can access other random sites fine (I run a Google search, find a website I've never seen before, and it loads fine), and I'm able to navigate to de:wp, fr:wp, Commons, and every other WMF wiki that I've tried. Any ideas? — Preceding unsigned comment added by Nyttend (talkcontribs) 17:54, 15 November 2018 (UTC)

Have you tried using different browsers on the Win 7 machine?Nigel Ish (talk) 17:58, 15 November 2018 (UTC)
Sometimes when the system clock is off by enough it prevents https from working correctly. And try clearing cookies and browser cache. -- GreenC 18:38, 15 November 2018 (UTC)
Can't load it in Firefox 60.2.2esr or Chrome 70.0.3538.102; I get results identical to IE. I virtually never use Chrome or Firefox (except for loading sites that don't work in IE), so I doubt that there's anything problematic in the cookies or the cache. I've cleared both in Firefox and gotten the same results; I'm not immediately clear how to clear them in Chrome, so I've not (yet) done that. The computer I'm using has a system time of 15:40 on 2018-11-15, and the other one has a time of 3:40 PM on 11/15/2018 — can't see how this would be a problem in my specific situation. Nyttend (talk) 20:39, 15 November 2018 (UTC)
And now, somehow, I'm able to access en:wp on Windows 7. Nothing's different, as far as I can tell, while before I wouldn't have even had the chance to log in. Nyttend backup (talk) 20:54, 15 November 2018 (UTC)
In Chrome (at least on Mac; I'm assuming the same on Windows), you can open the Developer Tools window (Command-Option-I), select the network tab, and then reload your page. It'll show you the details of every network access your browser makes. Sometimes you can discover interesting things, like javascript files failing to load. You can also look in the javascript console for error messages. Even if you don't know how to interpret these messages yourself, you can copy-paste them and other people may be able make use of them. My hunch is that some javascript file fetch is timing out, but that's just a hunch. The network trace would help verify or disprove that. -- RoySmith (talk) 22:57, 15 November 2018 (UTC)

Job opening for product manager

Whereas Deskana has decided to reclaim his volunteer status, there's a job opening that may interest some of you: http://boards.greenhouse.io/wikimedia/jobs/1436077 The team is currently focusing on mw:Visual-based mobile editing, and is responsible for about a quarter of the known universe, including "All issues relating to the edit screen, edit conflicts, and saving edits". Please think about applying or encouraging good people to apply. Whatamidoing (WMF) (talk) 21:32, 15 November 2018 (UTC)

Template:Infobox album creating garbage

Is there a reason that the invocation of {{infobox album}} on Masterpiece (Thompson Square album) is spewing garbage all over the page? I have included a screenshot here. Ten Pound Hammer(What did I screw up now?) 23:53, 15 November 2018 (UTC)

It's displaying the wikitext exactly as expected for me. You can try editing the page in safe mode [17] or whilst logged out to see if it's a malfunctioning script you have, or try a different browser to see if it's your browser. --Deskana (talk) 00:12, 16 November 2018 (UTC)
Ah, looks like I was along the right lines. An edit you made using ProveIt was what introduced all the weird stuff. I guess ProveIt is malfunctioning somehow. --Deskana (talk) 00:13, 16 November 2018 (UTC)

Proposals

RFC:Close MedCom?

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

  • Summary --> There is a strong consensus to ☑Y disband the Mediation Committee in entirety. And, all processes and components thereof, shall be marked as historical.
  • Details -->
    • The broader theme of the comprehensive analysis by the OP, (Beeblebrox) has been heavily supported by numerous participants.
      • There is a broad consensus that MEDCOM is akin to a toothless process that hasn't served any practical purpose in the recent spans and that the process of RFCs are far superior and useful, in the locus of resolving content-disputes.
    • The opposition camp contains some interesting take(s) on the issue but I am afraid that they have failed to turn the tide in their favor, by a count of heads as well as by a weighing of arguments (and corresponding rebuttals).
      • RMClenon, TransporterMan, Coffman et al have argued for MedCom to be sustained in light of the potential of the process to resolve complicated content disputes (without delving into conduct) but the rebuttals are good-enough.(vide RGloucester, Swarm, Boing et al) That the inner-machinery of the project is heavily non-transparent and the working is overtly bureaucratic compounds the dismal scenario.
    • A few folks (Blackmane, AGK, Steven Crossin et al) have supported ideas of a reform to increase it's effectiveness but they consist of a diverse bunch of proposals, which has failed to progress anywhere past the brainstorming session(s) and there is accordingly, an absence of consensus on that locus.There is also a lack of consensus as to merging this to DRN, (despite no rebuttal).
      • Interested people may pursue such ideas separately and present to the community, for an evaluation.
    • Isaacl's comment at the end of the Extended Discussion section, might be a worthy read:-)

Respectfully, WBGconverse 19:10, 12 November 2018 (UTC)


Should the Mediation Committee be closed and marked as historical? 18:11, 10 October 2018 (UTC)

This RFC stems from a previous discussion, now viewable here. The discusion was not overly long and did not result in any real conclusions, so it seems a formal RFC is advisable to determine consensus on the subject.

I would like to be clear from the outset that this is not intended to attack or disparage the users who have dedicated their time and effort to this project, but rather to ask if the project itself is actually accomplishing anything of real value to Wikipedia overall or if it has become redundant to the point where it should be closed.

Rationale:

  • Medcom accepts very few cases. The last case accepted was just over a year ago.
  • This is mainly because “lower” forms of dispute resolution are required first, similar to ArbCom proceedings.
  • The other reason cases may not be accepted is that unlike Arbitration cases, Medcom cases require that all parties agree to participate and the decisions reached are not binding.
  • Of the few cases that are accepted, very few succeed at resolving the issue, the last case marked successful was over two years ago.
  • The process, instead of complementing other dispute resolution procedures, appears to have become redundant to them.
    • Content disputes, which are all that Medcom handles (as opposed to behavioral issues) are mostly handled by talk page discussions, content RFCs, or WP:DRN
  • Interest in being on the committee is very low. For the last few years its chairperson has been doing pretty much all the work, which consists almost entirely of rejecting cases as premature. While other, nearly inactive users have indicated their willingness to return to help if a case were to be accepted, it is essentially a one-man project and has been for some time.
    • It is worth noting that the chairperson’s term expired some eight months ago but there apparently been no inclination whatsoever to either re-elect or replace them. In fact, it looks like the chair is the only member who has commented on the project’s main talk page in the last three years.
  • Given the previous points, it seems undesirable to have a process where, in the rare case that it actually takes on a case that case is decided either by the same person every time or by users who are mostly inactive on Wikipedia.

So, we’ve got a process that by it’s own records, hasn’t resolved any issues in a few years, hasn’t been used at all so far this year, and whose internal processes are stagnated and handled almost exclusively by one user.

For all of these reasons, and again with the upmost respect for those that have striven to keep this project alive, I believe that it is time to admit that this process is almost entirely unused and redundant and to mark it as historical and shut down its mailing list. Beeblebrox (talk) 17:50, 10 October 2018 (UTC)

MedCom discussion

  • Support Doesn't appear to be active, other dispute resolution noticeboards seem to work better. SemiHypercube 00:38, 11 October 2018 (UTC)
  • Support Per above. – BrandonXLF ([email protected]) 00:41, 11 October 2018 (UTC)
  • Support pet project of a small number of users that doesn't really do anything anymore. It gets a fair amount of requests, but they are never heard, and the community has pretty much moved past centralized content dispute resolution in this manner, preferring talk page RfCs and if need be, an RfC on a policy page or noticeboard. TonyBallioni (talk) 00:44, 11 October 2018 (UTC)
  • Support – No longer a useful process...much like WP:RFC/U was, back when it was abolished. Other forms of dispute resolution have been used in its place for years, with greater effect. No reason to retain the air of community bureaucracy at a process that is largely maintained by one person. In the end, people have voted with their feet. Abolish it. RGloucester 00:45, 11 October 2018 (UTC)
  • Support - seems to have no purpose at all these days. Home Lander (talk) 01:08, 11 October 2018 (UTC)
  • Support Inactive, useless. TonyBalloni sums it up nicely. ThePlatypusofDoom (talk) 01:46, 11 October 2018 (UTC)
  • Support per above. --Rschen7754 02:17, 11 October 2018 (UTC)
  • Oppose the abolishment of all the forums for editor review (apart from RfA) was not a benefit to the encyclopedia-building project, and I don't think abolishing MedCom will be either. It will be far more work to resurrect this in the future than to let it linger idle for now. Some forum that is the clear forum-of-last-resort for content disputes is needed; I don't see DRN or ARBCOM as filling that role. MedCom should have some type of reform to be more relevant, but doing it at the barrel of a gun won't work. power~enwiki (π, ν) 03:11, 11 October 2018 (UTC)
    MedCom isn’t a forum of last resort. We have no such thing for content disputes and never have. TonyBallioni (talk) 03:29, 11 October 2018 (UTC)
    It actually has no authority whatsoever, being entirely voluntary and non-binding. I also object to the characterization of this being the “barrel of a gun” as what it really is is just admitting that medcom doesn’t do anyhting anymore so there’s no point in directing users to it. There already isn’t an actual committee. Beeblebrox (talk) 06:14, 11 October 2018 (UTC)
    Well, it certainly needs to either be more willing to do *something*, or actually be a forum of last resort. I plan to stay an oppose !vote, but without some viable reform proposal this will certainly be marked historical. There's a good chance it won't do anything for the next year+ even if it isn't marked historical. power~enwiki (π, ν) 15:29, 11 October 2018 (UTC)
    If it gets to the point that the talk page, RFCs, RSN, DRN, &c., cannot solve a content dispute, that almost certainly means that there are conduct issues. That's the essential problem with the structure of this thing...it isn't fit for purpose, and so it doesn't do anything. In the end, though, its excessively bureaucratic proceedings are a relic of another era, and I personally am happy to condemn them to history. RGloucester 15:39, 11 October 2018 (UTC)
    @Power~enwiki: Which other now-abolished forums for editor review are you referring to? 142.160.89.97 (talk) 07:21, 16 October 2018 (UTC)
  • Support It is already dead, so may as well save the time of all the people requesting resolution through it. They are better off starting a WP:RFC to determine consensus which is how content is settled per policy. If lower forms of resolution have not resolved the dispute, it is extremely unlikely that a completely voluntary non-binding and toothless process will do either, and this is reflected in the reality of the situation. Galobtter (pingó mió) 07:17, 11 October 2018 (UTC)
  • Support per above rationale. Inactive, and preference for talk pages and RfCs. Better to redirect attention of volunteers elsewhere than have a semi-morubund venue. --Tom (LT) (talk) 07:37, 11 October 2018 (UTC)
  • Oppose I do not see any clear benefits of closing MedCom down now. At least the proposers have not specified any. In addition, {{historical}} template is used to mark pages or processes that have become completely inactive and for a long time. These is not true in the case of MedCom - there is still some activity. So, this is not an appropriate proposal. If somebody wants to simply close it down, there should be a wider RFC, not a small discussion on this board. Ruslik_Zero 09:44, 11 October 2018 (UTC)
    Uhh, where would a wider RFC be than a discussion at the pump advertised at WP:CENT as this discussion is? Galobtter (pingó mió) 09:47, 11 October 2018 (UTC)
    Yeah, I find this comment very bizarre. You can disagree with the reasoning I presented but there is nothing inappropriate about it, it is widley advertised, and if somebody just shut this discussion down now that would be wildly inappropriate. Beeblebrox (talk) 18:35, 11 October 2018 (UTC)
  • Neutral - I don't think the Mediation Committee has ever really played a very important role. It's non-binding, and it adds a layer of bureaucracy to dispute resolution that most editors don't want to deal with. Nevertheless, a part of me wants to see it reformed and modernized so that it can serve some sort of purpose. But at this point, it may not be feasible. Kurtis (talk) 09:50, 11 October 2018 (UTC)
  • Oppose — If MedCom is closed WP will have no DR mechanism to mediate complex disputes. DRN is specifically designed to handle disputes which can be resolved within 14 days and has an automated case-closing mechanisms for cases which do not fit that mold. Moreover, anyone can be a DRN volunteer. Current volunteers generally discourage newcomers to Wikipedia from volunteering, but they can do so if they care to. (Third Opinion is the best training ground for newcomer volunteers.) Cases which are accepted at MedCom, and there have not been any recently, it is true, often take weeks to months to resolve with multiple different specific issues being considered. MedCom has never taken many cases and DRN has, as it should, taken away the simple cases that might have previously been handled at MedCom, but MedCom still plays a necessary part, if only rarely. — TransporterMan (TALK) 12:17, 11 October 2018 (UTC) (Chairperson, Mediation Committee)
    Counterproposal. Retain but improve MedCom by making it the actual last resort. Make it mandatory to participate at MedCom by making a good faith effort to resolve a dispute if the case is accepted for mediation by the Committee. The requirement would not require a party to actually resolve the dispute, but only to participate in mediation and make a bona fide good effort to do so. Parties who refuse to participate, or who participate and fail to make a good faith effort, should be barred from continuing to participate in the dispute and from editing the article in question in a manner related to the dispute (this is equivalent to the same requirement in real world court-ordered pre-trial mediation: you've got to show up and make an effort to resolve the case). The mechanics of this will need to be worked out, members of the Committee who are administrators could impose the limited topic ban or the Committee could, in the alternative, make a recommendation to ANI. Either way, the community would have to trust the Committee to prevent this from becoming a means of gaming disputes. Cases should be required to at least file the case for consideration at Third Opinion or DRN or RFC before coming to MedCom, so as to weed out the simple cases. Respectfully submitted, TransporterMan (TALK) 12:17, 11 October 2018 (UTC)
    I would recommend starting a separate RFC for a replacement venue of any sort, if you think Wikipedia should have one. --Izno (talk) 14:09, 11 October 2018 (UTC)
    Sorry to break this to you, but Wikipedia currently has no dispute resolution mechanisms to mediate complex disputes. MedCom doesn’t exist already. Beeblebrox is just asking we admit that and stop wasting people’s time by sending them through a process that doesn’t actually exist. TonyBallioni (talk) 12:21, 11 October 2018 (UTC)
    I cold not be more opposed to yor counter proposal. No way no day can we give Medcom “teeth”. Currently it’s basically you, but in theory there are three other mediators. None of you were elected or appointed by the community so there is basis for any sort of real authority. (for those of you who are unaware, Medcom selects it’s own members, and has it’s own mailing list where they discuss their inner workings. It’s very much a closed shop) Beeblebrox (talk) 18:50, 11 October 2018 (UTC)
    What if a precondition of the counter-proposal getting acceptance was all current (and future) members have to stand for election in the same manner as ArbCom members do? Additionally, how about actually giving MedCom a couple of dentures to make binding content-related decisions (ie: "Source X cannot be used in this context unless wider community consensus agrees to it" or "The reliability of that source is currently disputed so cannot be used until {condition}") Dax Bane 10:09, 18 October 2018 (UTC)
  • Support - There are too many backstage venues as it stands. This one has atrophied. Carrite (talk) 12:26, 11 October 2018 (UTC)
  • Support Pretty much dead. MoonyTheDwarf (Braden N.) (talk) 12:44, 11 October 2018 (UTC)
  • Support per the proposer. It seems fairly clear that the WP:RFC process is superior for content disputes; where it is inhibited is when conduct becomes an issue, but that's a separate set of processes anyway. --Izno (talk) 14:09, 11 October 2018 (UTC)
  • Support As it appears largely redundant, and has pretty much shut down on its own already, it seems smart to officially 'close' the venue. — Insertcleverphrasehere (or here) 14:14, 11 October 2018 (UTC)
  • Zaphod sums it up well, and honestly Power~enwiki lays it out well enough. I've always liked MedCom — it aims to fill a much-needed space for content disputes — and in my starrier-eyed days of the very late aughts, once thought it'd be nice to serve. Still, it's not filling that space because nobody uses it. I think the project would be better if MedCom were a productive place of dispute resolution, but it's not. As such, keeping it "active" and as an "option" is probably doing more harm than good, interrupting other resolution methods and drawing out disputes needlessly. There are good things nobody uses, and after trying and trying, there's no shame or harm in admitting it's not working. ~ Amory (utc) 15:45, 11 October 2018 (UTC)
  • This proposal is a remarkable coincidence. I began discussing the underuse of mediation with a couple of my committee colleagues last week.

    As noted by the other commenters (both supporting and opposing), the notion of mediation is a good one. We would all like for it to be working and achieving results. However, it just isn't functioning as a process. In the end, accepted requests and successful cases – ie frequency of resolving disputes – is what matters.

    I would propose that we provide an opportunity at this stage to propose updates to the process for 2018 and onwards. As I say, some early work has already been done on this question so it should not be too long in the works. I hesitate to call those updates a 'reform', because as a community we tend to prefer incremental improvements. Nevertheless, some of the proposals under development could quite easily turn the process into an effective one. I suppose they are reformatory in nature.

    For what it's worth, the crux of the proposals is to bring mediation into the dispute resolution process as an effective, functioning noticeboard or process. At the moment, it sits apart from the other dispute resolution venues – ignored and ignorable. I propose reform to this discussion – that we give updating the process a try. We strip back some of the vestigial bureaucracy. We make it an actual, go-to process that actively solves advanced content disputes. In my view, there is a gap in our community for such a thing. And in the existing mediation process, we have a solid base (nearly 2 decades of precedent and experience) and existing material to work with (the process is recognised in the ratified Arbitration policy etc.). If the consensus here is to reform and it does not work, I would propose closing it myself. AGK ■ 17:31, 11 October 2018 (UTC)

    Actual practice suggests we do not need this form of mediation to resolve disputes. If such a process were needed, MedCom would not've fallen away as it did. There are better venues for content dispute resolution, and behavioural problems are dealt with in the usual channels. I simply do not see the benefit of continuing to emphasise a process that has died a natural death...it 'died' for a reason, and for those reasons I am opposed to reform. If such proposals were to create an entirely new body, from the ground up, and then seek community consensus for establishment, that'd be another thing. But I do not see the benefit in launching such a proposal under the auspices of the existing 'MedCom' mandate, which has clearly run its course. RGloucester 17:42, 11 October 2018 (UTC)
    That is a rather brazen – and, in my view, incorrect – view of dispute resolution. All around the community there are content disputes that do not get solved until one editor grows frustrated enough to lash out. At that stage, they are blocked or receive a sanction in enforcement of general sanctions. We then call that consensus by default, regard the dispute resolved, and carry on with a deficient article. I do not see the "actual practice" that led us here as right, and I am proposing we update the process to tackle the wider problem of a serious dearth in effective solutions for protracted disputes. Or perhaps we could just redirect the whole thing to some essay and continue decentralising the facilities for editors in dispute to receive guidance from experienced editors; certainly that is the way things more generally are heading.

    Disputes on the project today, as the encyclopedia matures and its expansion plateaus, are increasingly about obscure or intractable issues. Closing down processes that we, as a community, have designed to steer those disputes back on track will do nothing to stop the car driving off the cliff. Creating a mediation process is one case where the project elders probably had it right. We just need to update it. AGK ■ 18:00, 11 October 2018 (UTC)

    The biggest problem with what you're proposing is that it really has nothing to do with MedCom...it's a proposal for an entirely new process, replacing the existing MedCom with something different. In as much as this is what you propose, I cannot accept the use of the existing MedCom policy to create an entirely new process. I'd rather this be marked historical, as it is indeed historical, and defunct, and something new prepared for review by the community. What you propose, I think, is a circumvention of community consensus. RGloucester 18:23, 11 October 2018 (UTC)
  • Support purely on grounds of inactivity, I think it's entirely possible for a process like MedCom to play a role in our dispute resolution processes. Activity has consisted of the chairperson rejecting requests for some time and it doesn't seem to be actually resolving disputes. Given that we are basically misleading people into thinking it's a working process if we don't tag it as inactive/historical. If a significant number of active editors are willing to commit to reviving the project then I'd be happy to change this. Hut 8.5 18:17, 11 October 2018 (UTC)
  • Neutral Like AGK, I wish this were more active. I say this as someone who has not participated, primarily because I believe that good mediation requires a certain skill level which typically require some training and I haven't had formal training. There are many people who have had such training and frankly surprised we haven't attracted more of them. If I were a mediation professional, I might see Wikipedia as a great place to practice skills. While that hasn't happened, perhaps it will. We've got a small national conversation about civility in progress, and, ever the optimist, perhaps that will spark more interest in mediation and some of those people will show up here and offer to help. There might be some value in having an existing structure rather than having to reinvent from scratch. Arguably, if this is marked as historical, it doesn't mean it goes away so that goal could be accomplished even if this is marked as historical, but I prefer something a little softer. Perhaps a message at the top of the page that says this projectprocess is currently inactive but could be reinvigorated if enough participants show interest.--S Philbrick(Talk) 18:27, 11 October 2018 (UTC)
    To note, MedCom is not a project...it is actually a policy-based process specified by Wikipedia:Mediation Committee/Policy. The remaining one active member of the Committee has not even been able to follow this policy, in that he has continued serving despite the end of his term. I really find it hard to accept that we have a policy that literally no one follows or uses...is this not contradicting the very nature of Wikipedia policy itself? RGloucester 18:31, 11 October 2018 (UTC)
    I thought this point was insignificant to the discussion, but as it keeps coming up – the coordinator/chair would be reconfirmed by email. They just do not announce it or make a song and dance. AGK ■ 18:57, 11 October 2018 (UTC)
    I didn’t mention the internal processes used because as you say it has no bearing on the core reasons for this proposal, but if we were to do that I think the community would be rather surprised. I’m not aware of any other group who determine their own membership devoid of community input and decide who their chair is in an off-wiki discussion on their own privileged mailing list. Beeblebrox (talk) 19:06, 11 October 2018 (UTC)
  • Oppose This is a truly silly proposal. This proposal does not benefit Wikipedia in the least, and is a waste. Just because something is not that active right now, does not mean it won't reactivate in the future. We just saw that with the Signpost, and the needlessness of this RfC is plain - you don't like that someone is over there fielding complaints, etc., find something useful to do with your time, and focus on writing articles, not complaining about other people offering to mediate disputes and respond to complaints in a slightly structured forum. Alanscottwalker (talk) 18:39, 11 October 2018 (UTC) As it is now argued below that oppose comments are not supportive, there must be some confusion, being supportive of editors who want to provide mediation for others who want it is being supportive of MEDCOM, and it is the right thing to do. -- Alanscottwalker (talk) 12:35, 12 October 2018 (UTC)
    Keeping MEDCOM open misleads people into thinking it actually resolves disputes and wastes their time filing out a request for mediation only to get it rejected. Galobtter (pingó mió) 18:52, 11 October 2018 (UTC)
    What nonsense. Never in the history of problem solving has having to state the problem to someone else formally, and the parties involved, ever been a hindrance to problem solving, the opposite is the case. Alanscottwalker (talk) 19:56, 11 October 2018 (UTC)
    A straw man if I’ve ever seen one. Unless you can point out where anyone is “complaining about people other people offering to mediate disputes“ as that is not anywhere in the rationale at the top. This is only about admitting the obvious, this process may have had a place once but it has been rendered obsolete and redundant by a cultural shift towards other forms of dispute resolution. This isn’t personal, so I don’t appreciate you trying to make it so. Beeblebrox (talk) 18:59, 11 October 2018 (UTC)
    What? Personal? I said nothing personal. And you don't need to repeat your already rejected argument that there are too many ways for people to go about solving problems. Alanscottwalker (talk) 20:13, 11 October 2018 (UTC)
    WP:BAG. I think it is time we step back and let other community members independently assess the original proposal, the counter-proposals, and the limited further discussion. Badgering is causing the signal-to-noise ratio of this thread to plummet. AGK ■ 19:13, 11 October 2018 (UTC)
    I hear you, but when some people are suggesting this be closed as innapropriate and others are trying to personalize the dispute instead of responding to the actual issues under discussion it can be hard to restrain oneself. Beeblebrox (talk) 20:12, 11 October 2018 (UTC)
    Well, this proposal is complaining about people offering to mediate disputes, so calling a spade, a spade is just appropriate. The proposal's reason is, 'we don't like the way you mediate.' Alanscottwalker (talk) 20:46, 11 October 2018 (UTC)
    Every word of what you wrote is wrong. Beeblebrox (talk) 21:16, 11 October 2018 (UTC)
    Every word is not only right, it's evident. Alanscottwalker (talk) 22:01, 11 October 2018 (UTC)
    (edit conflict) @Alanscottwalker: I agree with what Galobtter said. That, and the problem with comparing it with the Signpost is that on the Signpost, there was just an issue of activity of the participants, (though it has been brought up that only one of the members of MedCom is still active) whereas with MedCom it has pretty much been superseded by other dispute resolution pages, such as Wikipedia:Dispute resolution noticeboard, Wikipedia:Administrators' noticeboard/Edit warring, Wikipedia:Third opinion, and the like. SemiHypercube 19:02, 11 October 2018 (UTC)
    Again, senseless, 'there are too many ways to go about addressing issues in somewhat different formats' is not even a coherent critique. Alanscottwalker (talk) 20:06, 11 October 2018 (UTC)
    At the time of the last discussion about this at VP Policy, about a month ago, at least 3-4 other current active members of the Committee either indicated in that discussion or on the Commitee's mailing list that they are, indeed, still active. It's not correct that I'm the sole surviving member. Moreover, past members who are inactive are still members and I wouldn't hesitate to poll them should our active member list be depleted and a mediator needed. - TransporterMan (TALK) 19:27, 11 October 2018 (UTC)
  • Support as per everyone above, No point keeping and sending editors to something that's pretty much inactive, There are other venues which are quicker and simpler. –Davey2010Talk 20:08, 11 October 2018 (UTC)
  • Neutral Would be nice to see it given a place but without a significant review into how Dispute Resolution works and the Mediation Policy it is not sustainable. In its current state, it's not worth keeping. RhinosF1 (talk) 20:17, 11 October 2018 (UTC)
  • I would merge with the Wikipedia:Dispute resolution noticeboard, since it can be arbitrary in dividing lines between "small" and "large" disputes. Also the fewer "go-to" places the better. Cas Liber (talk · contribs) 20:19, 11 October 2018 (UTC)
    Seems like that would be the best way actually. RhinosF1 (talk) 20:25, 11 October 2018 (UTC)
  • support, largely as stated: redundant to other forums that produce better results. Guy (Help!) 21:10, 11 October 2018 (UTC)
  • Support per nom. Effectively defunct. There should be prominent pointers to other dispute resolution forums like DRN though. ---- Patar knight - chat/contributions 00:15, 12 October 2018 (UTC)
  • Support per nomination and Carrite (too many backstage venues), and largely redundant. . Kudpung กุดผึ้ง (talk) 02:47, 12 October 2018 (UTC)
  • Oppose: I'm not sure if I knew about the Committee existence. It sounds like it could be something useful for mediating complex disputes. Even if the case log is not very active now, it does not mean that it may not pick up in the future. K.e.coffman (talk) 05:32, 12 October 2018 (UTC)
  • Support Largely ineffective, generally redundant to many other binding processes that we have. Closure is overdue. –Ammarpad (talk) 05:54, 12 October 2018 (UTC)
  • Oppose per TransporterMan. Process is important, especially when it comes to complicated disputes. Having an outlet for such that is less looming than the arbitration committee benefits the community, even if it is not used very often. As long as their are volunteers willing to run it, we should allow it to stand.— Godsy (TALKCONT) 08:43, 12 October 2018 (UTC)
  • Support per the nominator's rationale; I find the oppose reasoning unconvincing. Enterprisey (talk!) 09:05, 12 October 2018 (UTC)
  • Support also per nom: the project has clearly become moribund, and, with respect, to the oppose comments, they mostly consist of IDLI arguments. Which, of course, are not supportive arguments.——SerialNumber54129 09:51, 12 October 2018 (UTC)
  • Support I cannot find fault with anything in the nomination statement (content or form :), and as mentioned above, there are actual downsides to stringing along a factually dead component of the mediation meta-process. Pruning deprecated components is not structural deletionism, it's necessary basic housework. --Elmidae (talk · contribs) 12:41, 12 October 2018 (UTC)
  • Oppose closing it down wholesale. Better to reform it into something useful than to shut it down entirely. feminist (talk) 13:27, 12 October 2018 (UTC)
  • Support: Medcom is unnecessary bureaucracy, an obscure and confusing part of a complex set of intricately linked dispute resolution processes. It's barely active and it doesn't seem to work. Certainly most users would not know when to turn to it. Dispute resolution reform is necessary and cutting out processes that have died a natural death should be part of that reform. Bilorv(c)(talk) 18:13, 12 October 2018 (UTC)
  • The simple answer to the neutral question asked in this request is no; the Mediation Committee should not be closed and marked as historical. Unfortunately both concepts, simple and neutral, end with that.--John Cline (talk) 20:05, 12 October 2018 (UTC)
  • Support this is mostly just acknowledging the current state of things. If people want some kind of binding arbitration/mediation that is actually useful, they should start an RfC proposing that rather than keeping this on life support or standing by while another inch of dust accumulates. {{u|zchrykng}} {T|C} 00:39, 13 October 2018 (UTC)
  • Support per above. Opposes are unconvincing. -FASTILY 02:41, 14 October 2018 (UTC)
  • Support Thank all involved for their work and close it. Only in death does duty end (talk) 14:22, 14 October 2018 (UTC)
  • Weakish support - I opened the previous VPP thread, but still haven't come to a solid conclusion about the best way forward. I get the point some people have made there are opportunities for reform, and that it would be best to work towards making it useful rather than shutting it down. However, I'm not convinced that those reform efforts wouldn't be better suited for DRN, incorporating some flexibility to make it cover the cases that would otherwise go to RFM. I also appreciate the idea that some aspects of RFM seem a bit anachronistic in wikiculture (like the committee selected by themselves). There is indeed a value in doing it that way, but I think that arbcom has shown that we can have decent results with community-appointed members. Robert McClenon made some good points in the previous discussion about the relationship between DRN and RFM and what characterizes each of them, so I wouldn't want to immediately say that DRN should absorb RFM, but I do think that if RFM is closed, the very next step should be a thorough evaluation of DRN to see how it could, as the sole forum of its kind, be made most useful (whether by framing it as an eventual expansion to include RFM-type cases or just as an analysis and reform process in its own right. Also, pinging Robert McClenon and TenOfAllTrades, both active in the previous discussion but haven't commented here yet. — Rhododendrites talk \\ 15:06, 14 October 2018 (UTC)
  • Oppose – I opposed the idea of shutting down the MedCom the last time it was suggested, even though the MedCom has not had a case in more than a year. As both I and User:TransporterMan have said, DRN is a lightweight process for disputes that can be resolved by discussion in one to two weeks, or at most three to four weeks. DRN has never been meant to be a heavyweight process for disputes that may drag on for months. I understand that the proponent is proposing in good faith to shut down a process that hasn’t been used recently, but it is a process (not a project) that doesn’t have a substitute. There are two problems currently with MedCom, but the two problems tend to offset each other. First, there is a shortage of mediators, but, second, there are very few cases for which formal mediation is in order. My own guess is that if, while this RFC is still running, a case is accepted by MedCom, MedCom will find a volunteer mediator to handle the case.
It now appears inevitable that MedCom will be shut down. The reasoned Oppose !votes are being shouted down. This raises the question is what will happen the next time there is a long complicated content dispute. What will probably happen is that we will lose two respected editors. It isn’t just a matter of taking the acronym RFM out of a list and the procedure MedCom out of a list of processes. It would be like disbanding the volunteer fire department because there hasn’t been a fire recently. Not every content dispute can be contained by DRN and specialty noticeboards. If we have a case that needs real mediation, at present, we can find a mediator. If we cross that entry out of the list, then we just throw it to WP:ANI, which is at best a damage-containment effort, or to ArbCom. What will happen the next time that there is a content dispute for which formal mediation is appropriate is that, first, it will go to DRN. Handling the dispute will burn out the DRN volunteer moderator who tries to handle the case without actual experience in conflict resolution, and they will likely not only leave DRN but leave Wikipedia. The conduct issues that had been contained while the content was being addressed will then re-emerge, and there will be multiple trips to WP:ANI and possibly a trip to ArbCom, and eventually topic-bans will be imposed, and in all likelihood one of the two editors, probably a respected content contributor, will be sufficiently embittered by the inability of the community to resolve the content dispute that they will likely leave Wikipedia.
The Support side has not considered the future adverse consequences of doing away with MedCom as the fall-back last resort for content disputes. Just because it hasn’t been used recently doesn’t mean that it isn’t needed. There hasn’t been a fire. That doesn’t mean that there won’t be a fire.
Since we are now almost certain to mark the MedCom as historical, the best way to recover from this mistake will be to create something having a similar function and mission. What we ought to be doing, rather than looking for a procedure to take out of a list of procedures, is trying to improve our dispute resolution procedures. Just getting rid of one that hasn’t been used recently is very much the wrong answer. It would have been better to propose improvements to DRN ‘’before’’ proposing to get rid of MedCom, but I don’t see any real hope now. Robert McClenon (talk) 01:59, 15 October 2018 (UTC)
I'm sorry, Mr McClenon, and if you perceive this as 'shouting down', I can certainly apologise further, but having read through various MedCom cases, I find it hard to accept this position...I see a combination of 1) dislocation of discussion that should have taken place on the article talk pages to a backroom space 2) dancing around obvious behavioural issues for the sake of reaching the illusion of a compromise. A comment made by Geometry guy in 2007 sums up, I think, the problems with the so-called mediation process. It applies an overbearing bureaucracy to disputes that could be resolved through talk page discussion or other normal channels, trying to force some kind of 'compromise' to appease warring parties, with the ultimate result of either failing completely because of an inability to deal with underlying behavioural problems, or comprising the content of the encylopaedia for the sake of appeasing editors participating in advocacy for a certain position. The reality is that we have better tools to deal with disputes on Wikipedia now...the false dichotomy between the so-called 'content' and 'conduct' disputes has been cast aside, and systems like discretionary sanctions have been brought in to encourage more moderate conduct in areas prone to discord. MedCom, I think, is truly a relic of a more idealistic era in Wikipedia's development. It no longer serves a practical purpose. All this proposal intends to do is recognise the status quo, nothing more. RGloucester 03:33, 15 October 2018 (UTC)
  • False. Every single Wikipedia dispute resolution mechanism divides conduct and content, its why we have Wikipedia:CONTENTDISPUTE. Similarly, you can't argue content disputes at AN/I, nor can Arbitration decide content issues. And whatever the elaboration of mediation, as Wikipedian's do like to write long explanations, Mediation's process is simple: someone shows up, states a problem and notices others, and a volunteer shows up and responds. Alanscottwalker (talk) 19:18, 15 October 2018 (UTC)
    You misunderstood me. My point was, if a so-called content dispute cannot be resolved by talk page discussion, various noticeboards, RfCs, &c., it usually means that there is a conduct issue, not a true content issue, and it should be dealt with as such. The 'black and white' distinction between content and conduct disputes is no longer relevant...hence the development of things like community and ArbCom discretionary sanctions, which force a 'drop the stick'-style approach on the part of editors in dispute-laden topic areas, lest they be sanctioned. RGloucester 19:31, 15 October 2018 (UTC)
    The content/conduct distinction is always relevant on every one of our boards. Every one -- that is our policy -- repeatedly. Your odd argument amounts to, 'oh, we can just tell people to shut-up, instead of mediating', which actually makes no sense because of the arbitrariness and strange value of it. RfC's are often weirdly sprung, poorly constructed, and poorly researched, so it is bizarre to hold them up as models for deliberation. (e/c) As for talk pages, the reason the 'shut up' method is employed there, at all, is because talk pages are without other boundaries. Alanscottwalker (talk) 19:46, 15 October 2018 (UTC)
    I've said my bit...my time is up. I still think the comment by Geometry guy is very relevant...but, I too must 'drop the stick'... RGloucester 19:56, 15 October 2018 (UTC)
    It is true that many disputes have both a content aspect and a conduct aspect. There are very few disputes that are purely conduct disputes. If the problem is simply the conduct of an editor who is a vandal, troll, or flamer, the offending editor normally gets indeffed quickly, without a real dispute. Content dispute resolution mechanisms, such as DRN and MedCom, operate on the optimistic assumption that the parties will set aside their conduct concerns long enough to resolve the content issue, and then the conduct issue is resolved as a side benefit. Conduct dispute resolution mechanisms, such as WP:ANI and Arbitration Enforcement, operate on the recognition that the offending editor who is preventing the content issue from being resolved can be sanctioned long enough to resolve the content dispute. There never was a black-and-white distinction, except for vandals, trolls, and flamers. It is still true that throwing away a content dispute resolution process is unwise. Robert McClenon (talk) 02:32, 16 October 2018 (UTC)
    The only comment I want to add here (and responding to actual points made is not "shouting down") regards seeing "MedCom as the fall-back last resort for content disputes". It is not, never has been, and can not possibly be the fall-back last resort for content disputes - not if it can make no binding decisions. Boing! said Zebedee (talk) 09:09, 16 October 2018 (UTC)
  • Strong support - Wow, it's definitely time to put this thing out of its misery. MedCom is inaccessible, redundant, ineffective, archaic relic, particularly in the context of modern dispute resolution, which is heavily streamlined in favor of formal, community-based consensus building, which easily handles both routine and complex disputes with binding decisions. At this point, it's more of a distraction from measures which actually resolve disputes. It's less useful than the long-defunct WP:RFCU or WP:WQA, and frankly it's amazing that it still exists. This concept, where you have some very "complex" dispute and the only viable solution is for a mediator to walk both parties through it ad infinitum until they reach an understanding is, quite simply, unrealistic, and to present it as some sort of "last resort" DR measure that we might need someday is a joke. Editors are expected to competently pursue DR and seek and abide by consensuses. The community no longer tolerates editors who are obstinate and obtuse, who can't or won't communicate effectively to resolve disputes, who won't listen, or who won't let it go when they can't secure a consensus, and who will drag out disputes past a reasonable point. When these situations arise, we're not relying on this bureaucratic dinosaur to walk them through their dispute and hope everyone will be agreeable, even though they're spending weeks and weeks of their life trying to come to an understanding in an online argument. We're investigating the underlying behavior and sanctioning or warning users, or implementing page restrictions, or going to ArbCom for binding solutions, so that actual collaborative, good faith editors do not get burned out and can continue contributing. That's why MedCom is an obsolete relic, not because we haven't had any "complex disputes" lately. Also, this whole thing is just out of touch with the community. It's purported to be this formal, serious thing, the be-all and end-all of dispute resolution, with legitimacy stemming from Jimbo himself, but in reality it's the pet project of this closed club of a small handful of users (or more realistically, one user), who decide from within what their membership is, and what their rules are, and when to take a case (read: never) and really don't contribute anything to DR. It's totally out of whack. The "chair" of MedCom's comments above just goes to show how out of touch with DR and the community this whole thing has become. Rather than actually demonstrating how and why MedCom has done and can still do good for the community, his case for keeping it is that we somehow 'need' his committee, because they don't accept newcomers into their ranks, or because they will accept disputes that drag on for months while DRN won't (I wonder why), or because they "mediate". I've been involved in DR pretty much since I became active here, and this kind of mediation-based approach to DR has never been particularly effective anyway, and keeping around a self-important group of 'mediators' who have long-since outlived their usefulness to the project is just silly. I thank those who have invested time in this project, but it's time to pull the plug.  Swarm  talk  00:26, 16 October 2018 (UTC)
  • Strong support: I was pretty convinced of MedCom's uselessness when I was on (and chaired) the committee--and that was 2007. I've toyed with the idea of proposing its closure off and on over the years, but never got around to writing something up. FACE WITH TEARS OF JOY [u+1F602] 03:01, 16 October 2018 (UTC)
  • Support. At Wikipedia:Mediation Committee it says "The Mediation Committee ... is the last stage of content dispute resolution on the English Wikipedia. Mediation is entered into voluntarily by the parties to the dispute and does not result in binding resolutions." But that is self-contradictory - a voluntary venue that does not result in binding resolutions can not possibly be the last stage in resolving anything. In practice, consensus arrived at by community discussion is the ultimate stage in content dispute resolution, and that is binding - and if editors refuse to follow it, sanctions can be applied directly from that. And as content dispute resolution often requires a good understanding of a subject and the sources supporting it, and with the way Wikipedia has massively developed since 2003, a small number of chosen editors really can not be up to that job. The Mediation Committee is one of those things that I think was a good idea and had its value in the early days, but the community has moved on and has bypassed it as a means of content dispute resolution. I thank all those who have served on it or contributed to it in other ways, but I think it's time to let it go. Boing! said Zebedee (talk) 08:57, 16 October 2018 (UTC)
    But Consensus is not binding. On Wikipedia, there are only a very, very few things that that are binding, so the fact that mediation recognizes that is the only choice mediation has. -- Alanscottwalker (talk) 09:24, 16 October 2018 (UTC)
    That link to WP:CCC simply says that consensus can change. At the time a consensus is reached, it is binding until a new consensus some time later replaces it - and in the meantime, editors are bound to abide by it and can be (and regularly are) sanctioned for failing to follow it. In fact, with the few exceptions at WP:CONEXCEPT, consensus is ultimately the only binding process the community has at its disposal. Oh, and I'll add that the inability of MedCom to make binding decisions is nothing to do with WP:CONEXCEPT. Boing! said Zebedee (talk) 09:37, 16 October 2018 (UTC)
    There are millions of things that have no consensus, and regularly result in no consensus. And how is consensus reached, even in the things where it can be found, by discussion, even mediated discussion. And even then consensus is provisional by policy. Alanscottwalker (talk) 09:44, 16 October 2018 (UTC)
    And in cases where there is no consensus, MedCom is powerless to act, so it can not be what it claims to be. Once you take away the obviously incorrect claim that MedCom is the last stage of content dispute resolution, I simply don't see what it offers that WP:DRN doesn't. Boing! said Zebedee (talk) 10:04, 16 October 2018 (UTC)
    Act? If discussion is an act, it certainly can discuss (act on) things with no consensus, that's what all content dispute resolution forums do, there is no guarantee of consensus. A stage is just a forum, after all. Binding is only used once in Consensus policy and it is in CONEXCEPT, not in the rest of the policy.-- Alanscottwalker (talk) 10:38, 16 October 2018 (UTC)
    I honestly don't understand the point you are trying to pursue here, and this seems to be going in circles. If there is any way MedCom can actually be the last stage of content dispute resolution or can achieve anything that WP:DRN can't, I'm really not getting it from what you are saying. Anyway, I've explained my reasoning as best I can, and I'm happy to leave it to whoever judges the consensus now. Boing! said Zebedee (talk) 10:59, 16 October 2018 (UTC)
    (E/C) There is no other stage, it is the last on the list, per policy. MEDCOM has a slightly different structure, where experienced mediators are willing to discuss sources, analyse research, and policy, at length among willing participants. Anyone, who has been involved in complex content disputes knows they last months and months, through many stages Alanscottwalker (talk) 11:05, 16 October 2018 (UTC)
    Oh, you take the last stage of content dispute resolution to simply mean it's the last item included on a arbitrary list? That's meaningless, and if we simply take it off the list it won't be. To be of any value, the last stage of content dispute resolution must mean more than that. And yes, I know that disputes can be long and complex (we have plenty that have been going on for years, on and off), but merely stating that says nothing about MedCom's ability to solve them any better than current processes. Let's face it, MedCom already doesn't actually exist - it's just User:TransporterMan, who has overstayed his term in the chair. Anyway, thanks for answering those two specific points, but I remain in disagreement and still see no value in MedCom. Boing! said Zebedee (talk) 11:30, 16 October 2018 (UTC)
    Well, just to add on your earlier strain of thought, no, many of us involved in complex content disputes do not want admins (who can hardly claim to be the font of all knowledge) striking their heavy (sometimes incompetent) hand against the people we disagree with. As for the rest, it's just bizarre, because MEDCOM is set-up by CONSENSUS policy, to not be used much. You just contented consensus is arbitrary in its listing, so by that, consensus is arbitrary, is your argument. Alanscottwalker (talk) 11:50, 16 October 2018 (UTC)
    Nobody is suggesting that admins should decide content disputes (and we are forbidden from doing so anyway), so that strikes me as a false dichotomy. If a list of processes can be decided by consensus, then it can be changed by consensus too - which is what we are considering here.

    My point about "the last stage of content dispute resolution" meaning no more than "the last on a list", if that is all it actually means, is that it reduces arguments that it should be kept because it is "the last stage of content dispute resolution" to nothing more than "It should be kept as the last on the list because it is the last on the list." That argument can only have any value if "the last stage of content dispute resolution" means more than just "the last on the list". Can you see what I'm getting at? Boing! said Zebedee (talk) 12:22, 16 October 2018 (UTC)

    Well, you may not, but than others are suggesting that Admin action needs to replace MEDCOM - that is an argument being made, here. (It's also been suggested that complex disputes end quickly, when we know not true). And, it is your argument that raised it should be gotten rid of, for saying it is last, when that is exactly how consensus has wanted it, consensus wanted it to be last on the list, so that's not MEDCOM's fault. And the reason it is last is plain, because it is not meant, nor structured by consensus to be used much (and then the argument is that it's not much used, when that is its consensus design - to not be used much.) Alanscottwalker (talk) 13:15, 16 October 2018 (UTC)
    Can you show me where anyone is suggesting that content disputes should be decided by admins, or that admins should take over the function of MedCom? I accept that I might have missed any such suggestions, but it is definitely not part of the proposal. And yes, I *know* what the consensus currently is! And I am *not* blaming MedCom for it - I am simply saying that consensus can change (wasn't it you who first raised WP:CCC?) and remove it from the list, and that is what we are trying to decide here. And the "keep it because it is last on the list" argument is still empty. Boing! said Zebedee (talk) 13:51, 16 October 2018 (UTC)
    Several times in this discussion admin action has been mentioned as alterantive to MedCom, both Swarm's argument and RGlosters argument most clearly suggest that, and below and above, it's suggested that Arbcom is the alternative to Medcom, and Arbcom is all and only about admin action, so it can't be an alternative to Medcom because Arbcom can't handle content, or if it is made the alternative, Arbcom has to be changed. Your very first post here was in support of admin sanctions in your oppose to MedCom. I never made the 'keep it because its last on the list' argument, so your statement on that is not responding to me, or it is misdirection. You said MedCom should be gotten rid of because it says it is last, but is last on the list because that is what policy says, that's why it says that, WP:CONSENSUS would not allow it to say anything else, just as CONSENSUS would not allow MedCom to be binding. At least we now appear to have agreement that consensus is not binding because it changes, or is still being worked on (and CONSENSUS does not allow it to be binding). -- Alanscottwalker (talk) 15:47, 16 October 2018 (UTC)
    Why are you misrepresenting what I said? Nowhere did I say or imply that "Arbcom is the alternative to Medcom". I was clearly saying that the kind of extreme disputes that would normally be under the purview of Medcom are no longer "mediated" (read: tolerated), and are now dealt with via more effective measures, Arbcom being one of them. When you say "Arbcom is all and only about admin action", and "Arbcom can't handle content", you're quite simply wrong. You're objectively wrong on this. See WP:ARBPOL#Scope and responsibilities, or the Arbitration archives, or Wikipedia:General sanctions#Arbitration Committee-authorised sanctions, or the Wikipedia:Arbitration enforcement log. Arbcom actions and Arbcom-empowered admin actions resolve disputes exceedingly effectively, long before they're ripe for Medcom, which has between a 2% and 0% success rate even as a formal DR body. Medcom already doesn't fit into the DR process. Also, you're claiming that it's not Medcom's fault that they claim to be the "last line of DR", and it's just a matter of policy. Not even getting into the fact that Medcom policy isn't determined by the community, but Medcom themselves (who the community, stunningly, does not have jurisdiction over), nowhere in Medcom policy does it say or imply that it is the last stage of dispute resolution.  Swarm  talk  04:16, 18 October 2018 (UTC)
    @Swarm: If you read back through this discussion, you'll see he's been misrepresenting just about everything everyone says - you, me, Beeblebrox at least. I don't know why he does it, as it's quite clear to anyone else reading it all (and surely will be to whoever judges the consensus), but it's why I've stopped responding to him - there's no point talking to someone who continually does what he's doing. Boing! said Zebedee (talk) 04:31, 18 October 2018 (UTC)
    Well, no, that is not what I am doing. I am just disagreeing with you. Alanscottwalker (talk) 17:48, 18 October 2018 (UTC)
    Swarm, I was not referring to you about Arbcom, the only thing I was referring to your comment about is admin action, the "and" Arbcom was a different thought. And yes, I do think it is CONSENSUS ("ArbCom does not settle content disputes or change policy") that arbitration is about admin action, not content. Arbcom does not handle content (is I think universally agreed) and Arbcom's SCOPE certainly does not say it should handle content, rather it says it regulates Administrative action, prescribes Administrative action, and takes Administrative action (generally, by reversal of administrative action but also imposing bans and the like, removing Admin permissions, etc) - that is all that is meant by "all and only about admin action." So, no, it's not me, being objectively wrong. As for the rest, MedCom is approved Content DR process (the last) by WP:CONSENSUS policy ("For disputes involving many parties or complicated issues or which otherwise need more time for resolution than is allowed at DRN, the Mediation Committee (MedCom) is staffed by members with proven mediation ability."). Alanscottwalker (talk) 18:55, 18 October 2018 (UTC)
    "Arbitrary" was the wrong word, apologies for that - I've struck it, and I now think my comment does not need any further adjective. Boing! said Zebedee (talk) 12:29, 16 October 2018 (UTC)
    I also want to add that the way MedCom is managed, by appointing its own mediators without any community selection process, and conducting its business by internal mailing list, is anathema to the open way the Wikipedia community is supposed to work. Boing! said Zebedee (talk) 10:09, 16 October 2018 (UTC)
    Oh, and I've only just spotted the following at Wikipedia:Mediation_Committee#Policy... "The Mediation Committee policy documents how the Mediation Committee, its mediators, and the formal mediation process operates. This policy is maintained by the Committee and is considered an authoritative codification of how Committee matters should be conducted" (my emphasis). So the committee selects its own members and sets the policy that governs it, making it totally self-governed and not answerable to the community! I'm not suggesting there's anything wrong with the policy page itself, but self-governing fiefdoms like this are simply not compatible with the Wikipedia of 2018, no matter how well-meaning. Boing! said Zebedee (talk) 13:23, 16 October 2018 (UTC)
    In all these years, have you or someone else ever suggested a modification there, if not it has CONSENSUS (and has had for years) - besides, they are not the only small group that elects and selects itself on the pedia, several corners do. Volunteers band together to do things, its how volunteerism often works. And in particular with a matter like mediation, ground rules for mediation in the real world are standard. Alanscottwalker (talk) 13:35, 16 October 2018 (UTC)
    The question of whether anyone has suggested any modifications misses the point - I thought I made it clear that I have no complaints with the policy as it currently exists, and I certainly agree that it currently has consensus simply through the lack of any challenge. The point is that MedCom itself should not get to judge its own policy, regardless of whether it follows consensus - a benign dictator is still a dictator. If there are other groups which are self-selecting and which actually get to set their own governing policy rather than being subject to community consensus, I'd like to know what they are - I know there are projects which set their own guidelines, but they are all subordinate to community consensus and can be overruled. As for the condescending "Volunteers band together to do things, its how volunteerism often works", there's really no need for it and I think it is beneath you. I know how volunteering works, and you know that I know how volunteering works! What is not inherent in the concept of volunteering is a right for volunteer groups to set their own rules independently of whatever organization or group they volunteer under - but now I'm telling you something that you already know. Boing! said Zebedee (talk) 14:17, 16 October 2018 (UTC)
    Please, no one condescended to you. Although, I do find your discovery of public documents that you can go there right now and change those documents/get-those-documents-changed using community processes, an unfair criticism against other editors of Medcom. And noting there are other projects, which ban together on Wikipedia to do things (see eg Milhist and FAC, and those guidelines you mention) is just noting that it is not at all suprisng or unusual. Alanscottwalker (talk) 15:47, 16 October 2018 (UTC)
    I am not criticizing "other editors of Medcom", I am criticizing the concept of a body which decides its own policy rather than being subordinate to community consensus to set it. I asked you about "groups which are self-selecting and which actually get to set their own governing policy" as you appeared to claim there are others, and I specifically made the point that projects which set their own guidelines (which are subordinate to community-decided policy) are not in that category. You responded with a comment about "projects which band together on Wikipedia to do things". I'm not saying there's anything surprising or unusual about "projects which band together on Wikipedia to do things", I'm saying there very much is something unusual and surprising about groups which can set their own governing policy. How am I not making that clear? I've tried hard to hold a meaningful discussion with you, but I see no point in continuing if every response I get from you completely misses or misrepresents my point, and instead argues against a point I have not made or throws up yet another non sequitur. Anyway, I mean no unfriendliness, but I'm done with my discussion with you. Boing! said Zebedee (talk) 16:40, 16 October 2018 (UTC)
    How is it not clear? The community can go there and change those MEDCOM documents (and could in the past - it's an open wiki), right now (just as it can go change FAC process and selection of FAC people and Milhist process and selection of Mihist people, just as in any change of guidelines, policies, etc. etc.). So, whatever you're criticizing, if it's in the Wiki's documents, it can be changed right now by the community and is subject to the community (so it is not true to claim it is not subject to the community, if that is your criticism). But if you are not criticizing what is in the documents (the documents that can be changed by the community right now) then you would have to be criticizing people who drew-up the documents. But that the community would leave it to the people who want to mediate to make-up mediation, would actually make much sense and be very understandable. Alanscottwalker (talk) 19:20, 16 October 2018 (UTC)
  • Support closure We provide mediation through other channels. The Wikipedia community does not have the administrative capacity to oversee and support the Mediation Committee as everyone imagined it when that organization was established. In the past few years we have gotten new automated tools for surfacing community discussions and improving the dispute resolution process. I would like to think that now, as compared to 5 years ago, ArbCom is divesting more power and the community boards are stronger, and both are getting more support from the wiki community and WMF community tech development. While I would like to endorse more infrastructure to support community health, the mediation committee takes a lot of labor and does not give a good return for what goes into it. I prefer to focus on our other offerings until those are stronger and even better defined. For last resorts see arbcom and for general issues use the boards. Blue Rasberry (talk) 14:39, 16 October 2018 (UTC)
  • Weakish oppose As many have stated, MedCom as it is doesn't really provide much of a service, largely because it is voluntary and non bonding. However, IMO I do think we need to have somewhere for editors to go for a binding resolution on content, but absolutely does not touch conduct, which is what we have ArbCom for. Of course, this would entail the management of MedCom to be quite different to how it is now. Members would have to be elected, policies would need the power of community consensus behind it and a charter drawn up. Blackmane (talk) 01:25, 18 October 2018 (UTC)
  • Oppose Its fairly poor in its current state. But I would like to see it improved rather than abolished. Make it binding on those involved so people can know that their time in going through the process will not be wasted. Still should be voluntary by those starting the process. -Obsidi (talk) 01:38, 19 October 2018 (UTC)
  • Support - we already have other methods of mediation that aren't as dead as this one, so archiving it is inconsequential. Kirbanzo (talk) 17:23, 19 October 2018 (UTC)
  • Oppose - I don't see last case 2017 as that inactive, and some users are willing to use and maintain the process. Also, I can agree with the concept that more disputes should be solved via "content" rather than "conduct". GreyGreenWhy (talk) 18:40, 20 October 2018 (UTC)
  • Support; regardless of inactivity, the process seems to be fairly unsuccessful at best per Ammarpad's comments in the section below. Jc86035 (talk) 09:13, 24 October 2018 (UTC)
  • Merge into WP:DRN, as per Casliber. As someone who has twice participated in mediation (once productively and once to no resolution), it makes me very sad to see this proposal, but it also makes me sad that the process is used as little as it is. I want to say strongly that TransporterMan and the other members of the committee have been doing excellent work and deserve the appreciation of the community, something that strikes me as disappointingly lacking in this discussion. That said, I think that the idea of merging into DR is a very good idea. DRN often amounts to "we can't really deal with that here", and although such a merge won't fix all of the problems that DRN has, it would add a level of dealing with the most complicated content disputes. I find it noteworthy that the first sentence of DRN is "This is an informal place to resolve small content disputes as part of dispute resolution." Note the word "small". We need a way to address large content disputes, too. --Tryptofish (talk) 20:27, 26 October 2018 (UTC)
  • Support - Doesn't really serve any useful function. Beyond My Ken (talk) 03:36, 28 October 2018 (UTC)
  • Support. Any concerns as to how to improve current dispute resolution process should be put forward in a future proposal.   —  Hei Liebrecht 04:39, 29 October 2018 (UTC)
  • Support being able to focus on large scale content issues without resorting to removing editors for conduct issues is desirable, but MedCom has failed to effectively do this, and I think it is due to the nature of the process. I support the idea of mediators, but this needs some WP:TNT. — xaosflux Talk 04:53, 29 October 2018 (UTC)
  • Oppose. We don't close projects unless either (1) no active participant wants to carry on; or (2) there is demonstrable harm in carrying on the project. Given User:TransporterMan's comment, and the fact that mediation isn't compulsory at the moment, we have no grounds to abolish the mediation committee. Deryck C. 10:45, 29 October 2018 (UTC)
    • @Deryck Chan: There are no grounds to close, because one of those two requirements need to be satisfied? Interesting. What policy or consensus are you getting that from? I've never heard of that principle. A substantial rationale has been made in the proposal. Some are disagreeing, but you're going so far as to say that the rationales provided go out the window by default, due to the existence of two specific prerequisites to closing parts of the project. A very bold and authoritative statement coming from an administrator, for which I sincerely hope you have something concrete to back it up.  Swarm  talk  20:48, 29 October 2018 (UTC)
      • Actually that is what happens with wikiprojects 99% of the time. If it goes inactive/no longer serves a purpose, its just left alone or sometimes marked inactive - but its almost never 'closed' as such. See here for a quick answer. So Deryck is correct in thats the general consensus to deal with Wikiprojects. The core difference however is that almost all wikiprojects that go inactive/defunct are based around article editing and not administrative (small a) functions. There is no downside to letting a wikiproject devoted to articles going inactive and not being marked as such/closed, because someone might take it up again in the future. With projects based on admin functions/problems between editors, there does need to be 'closure' so editors understand its no longer a valid route to seek assistance - the 'harm' in this situation being wasting editors time thinking MEDCOM is actually a functioning process. To Deryck: See the precedent at WP:WQA and the associated discussion here. Only in death does duty end (talk) 21:15, 29 October 2018 (UTC)
And “abolish” really isn’t correct either. This is just about marking what is obviously an outdated and unused process as inactive. If it were to be kept open, then yeah, it’s probably overdue for some serious reform, but it seems clear we don’t use it and don’t need it anymore, whatever it’s past role may have been. Beeblebrox (talk) 22:18, 2 November 2018 (UTC)
  • Support, no successfully closed cases in years? C'mon, folks, what's dead is dead. If anyone truly appreciates what Medcom did and believes it served a valuable niche, the solution isn't to prop up the corpse with wires and duct tape, the solution is to replace it with something better and more efficient that will actually survive. Andrew Lenahan - Starblind 19:45, 30 October 2018 (UTC)

Arbitrary Page Break

  • Reform (weak oppose) - I was aroused from my grave by a Signpost email regarding this thread and have thought carefully about my thoughts here. Many of those that I've worked with in dispute resolution over the years have commented here. @AGK:'s thoughts (Hi there!) stands out for me (I agree with some aspects of those that are supporting closure, noting that in most cases, MedCom is underused, somewhat bureaucratic and outdated. The concept of binding content dispute resolution has been discussed ad nauseaum over the years (WP:BCD being an example), but I think it's unlikely to ever have traction except in limited circumstances (think [[Wikipedia:WikiProject_Ireland_Collaboration/Poll_on_Ireland_article_names|Ireland Article Names), so discussion about making MedCom binding I think is not worth pursuing.
DRN was proposed by me way back when to deal with lightweight, simplex disputes in a rapid manner. The motivating ideas behind it were:
1. Have more eyes on a dispute, by creating a many-to-many relationship between DR volunteers and participants, possibly reducing burnout of volunteers
2. Resolve most disputes quickly, as trends over time showed that the longer a dispute went on for, the less likely it was to be resolved successfully (this wasn't universal, however). The data is quite old, but there's a survey done in 2012 with some data too (WP:DRSURVEY).
Historically, there was a conversation between those that ran DRN and those on MedCom about a conversation on referring disputes to MedCom that would benefit from mediation, to MedCom. I do believe that in some instances, mediation may be merited. I've mediated some disputes in the past which had several issues to work through, and sometimes they need to be worked through methodically. I would argue that the universal agreement to mediation is a rule that should be abolished however - if there is a case where there are 6 participants, the case has been brought in good faith and one person opposes, then the case should proceed in my belief - as one presently can just oppose and game the process. Perhaps a conversation on what happens to that person if they oppose should be had, but I think it's a necessary conversation.
The other factor in my argument to keeping MedCom open (but reform) is that MedCom is the only content dispute resolution process where discussions are privileged. This is designed to facilitate open discussion, because good faith conversations (even if at times, heated) cannot be used in ArbCom proceedings. No other forum affords this.
I think MedCom also needs new blood. Maybe the criteria for membership should be altered to make it less of a vote of existing members, and more based on dispute resolution experience. I'm not sure, but the nomination process seems a little antiquated. Lastly, a prerequisite to mediation should also be other proper DR forums should be used first. Open to the idea of MedCom only accepting cases referred by a DR volunteer, but aware that this is more bureaucracy, not less. Overall, I do agree that MedCom needs reform, but I think that it should be explored. Keen to work on this with the community - am glad there's been a reason for me to return from the grave!. Steven Crossin 01:52, 31 October 2018 (UTC)
  • Support closure, without prejudice to re-opening it in future, per Amory. I too like the idea of the Mediation Committee, and agree it has done great work in the past. However it simply isn't active enough now to be a viable form of dispute resolution. Our dispute resolution systems are confusing enough as it is, and it does a disservice to users to point them at this process which at the moment will most likely either reject their request or leave them in limbo. the wub "?!" 19:28, 2 November 2018 (UTC)
  • Support closure. Redundant. All the important dispute resolution discussion happens way before it ever reaches MedCom, and by the time we should be at the MedCom level of the DR process the dispute is either already resolved or requires ArbCom intervention anyway. -- œ 19:51, 3 November 2018 (UTC)
  • Support the closure, as it is nearly fully inactive. Dreamy Jazz 🎷 talk to me | my contributions 12:14, 5 November 2018 (UTC)
  • Support closure. It is apparent that this process has withered on the vine and no longer serves any useful purpose, if it ever did. - Nick Thorne talk 23:45, 9 November 2018 (UTC)

Extended discussion

  • The overall success rate over the last five years seems to be around 1-2% of the total number of cases filed, while the overall success rate for the last two years is 0% by any measure.
  • There is a similar situation at arbcom, accepted case numbers are down, extraneous subcommittees such as WP:BASC have been shut down, and the committee itself is shrinking.
  • This is actually a good thing in that it would seem to indicate that many problems are being adequately addressed before things get to the point of needing an entire committee to resolve them.
  • I completely belive what Tranporter Man says about the willingness of largely inactive mediators to return if needed. The fact that they haven’t been needed in years is the whole point. Beeblebrox (talk) 18:53, 12 October 2018 (UTC)
  • Evaluating this RFC: Medcom is not "just any" process created by a user on a whim. It is one of the first two content DR processes created at Wikipedia (the other, and first, being RFC) and, if my memory serves, was created by or in cooperation with Jimbo Wales himself, who also appointed the first mediators. Just as Arbcom would not be shut down without a consensus involving both a very large number of participants and a strong number of !votes in favor of termination, neither should Medcom. While this RFC has a couple of weeks to go, the response here so far would seem to me to be entirely inadequate to take any decisive action to terminate Medcom or mark it as historical, even if the "support" !votes were unanimous, which they are not. Regards, TransporterMan (TALK) 16:15, 15 October 2018 (UTC)
  • Comment 1 - Deprecating MedCom is being inaccurately compared to deprecating User conduct RFCs. The difference is that no one has cited any actual harm done by having MedCom available. RFC/U was doing real harm, because the procedure was both rigid and confrontational. Because of its rigidity, it was hard to use it correctly, so that the most common result was an incomplete RFC/U, which didn't even start a comment process, but did further offend the subject editor. Its original purpose, which was to serve as input to User:Jimbo Wales for a request to ban a user before there was an ArbCom, had long become obsolete. MedCom doesn't do any harm, and still may serve a purpose when DRN and other options have fallen through. Robert McClenon (talk) 18:45, 15 October 2018 (UTC)
More to the point, RfC/U had no dedicated volunteers, it was just a roving, changing band exercising mobocracy, and was just a board where people pilloried, and often bullied one another (we certainly don't need another page for that). On the other hand, Wikipedia is based on volunteerism, and these MedCom people are volunteers, who volunteer to mediate. Alanscottwalker (talk) 18:56, 15 October 2018 (UTC)
  • Comment 2 - I am deeply unimpressed by the good-faith comments by some Support !voters that DRN should be strengthened and reformed, because I don't see those who are advocating deprecating MedCom as doing anything to improve DRN. They don't want MedCom, and they are hoping that someone else will step in and do something to improve DRN. Robert McClenon (talk) 18:45, 15 October 2018 (UTC)
  • Comment 3 - As noted above, when an issue comes along for which formal mediation is appropriate, we will probably lose two productive editors from Wikipedia, the DRN volunteer who burns out trying to mediate a case that needs formal mediation, and the more collaborative of the two editors, who learns that the remaining content processes are stacked against a collaborative editor in favor of an aggressive editor. I know that isn't what anyone wants to have happen, but that is what will happen when a case comes along that requires formal mediation. Robert McClenon (talk) 18:45, 15 October 2018 (UTC)
  • Comment 4 - You should have asked what are the next steps before just going ahead with crossing a process off a list. Robert McClenon (talk) 18:45, 15 October 2018 (UTC)
  • Regarding the statements made by some supporters that talk page discussions and RFCs are generally successful in resolving content disputes if there are no conduct issues: there are many discussions that fade out and fail to reach a conclusion due to a lack of sustained participation, and many RFCs that do not achieve a consensus, in many cases because there are equally valid opposing views that are just based on different underlying assumptions or interpretations, which English Wikipedia's decision-making model is not well equipped to resolving. This is a gap in content dispute resolution that needs to be filled. (Unfortunately, the mediation process as it is currently implemented by the mediation committee doesn't strike me as being a particularly effective way to deal with these types of disagreements in English Wikipedia: its voluntary nature doesn't help with the problem of sustained participation, and unless the community agrees to have representatives of major viewpoints enter in mediation on its behalf, it's too hard to have formal mediation with large disputes.) It is demotivating for editors to know that any edit they make could get challenged and trying to resolve it can mean long, protracted discussions, with possibly no definitive resolution ever arriving. isaacl (talk) 16:30, 28 October 2018 (UTC)
  • On another note, I'm a bit uncomfortable telling a group of volunteers that they should not pursue an initiative that is optional and hasn't affected other community processes. I realize in theory it might divert editors into a long process with an uncertain ending that fails to adapt quickly enough to new editors entering the dispute on article pages, but in practice (due to the paucity of accepted cases) there's no evidence of this happening, so it's hard to evaluate if the process can adequately deal with this. (For instance, the mediation process could be placed on hold or discontinued if there were signs of new editors entering that could resolve the dispute through continued public discussion.) isaacl (talk) 17:33, 9 November 2018 (UTC)

The Real Problem

WP:Request for comment is the second-last stage in content disputes. It usually involves tens to hundreds of users. Every "no consensus" result should result in meditation(last stage) But.. good luck meditating this amount of users... The solution? I see none, which makes me sad.2001:A61:492:BC00:2507:E75C:1C33:57AA (talk) 23:17, 3 November 2018 (UTC)

Look to how the real world resolves this: representatives are chosen to present the major opposing viewpoints, and mediation is held amongst them. This would require that the community be willing to delegate discussion to a small group of people. As in the real world, the result could be presented back to the community for ratification, or it could be deemed binding (the option just needs to be selected beforehand). isaacl (talk) 16:47, 5 November 2018 (UTC)
Don't be so sad. The process of content consensus is never ending through generations of users (and multiple forums) and it will always be so, until the great Editorial Board is adopted (which is no time soon). We actually have had very useful mediations in developing sourced/policy based content but there you go, we don't do that anymore (down the road, how often RfC's are useless, or malformed, or misinformed, or not informed, at all. Then again, some of the most useful content RfC's have been developed in, perhaps you guest it . . . mediation). Alanscottwalker (talk) 19:32, 9 November 2018 (UTC)

Closure

  • I've been looking through this RfC and plan on closing it at some point in the next couple days. It looks, at a glance, that some participants may feel more confident in the result if a three-admin panel closes this RfC. Is that the preference of the participants, or will a single closer suffice? Kevin (aka L235 · t · c) 07:40, 9 November 2018 (UTC)
    If you need 3 people to judge the consensus above something is wrong. A blind hamster could do it. Only in death does duty end (talk) 08:44, 9 November 2018 (UTC)
    I think the consensus is obvious too and do not think three people need to close here. But there is a significant volume of comments and people get bent out of shape when they don't feel their (side's) comments were accurately reflected. Three people closing can help avoid that. --Izno (talk) 12:50, 9 November 2018 (UTC)
    I agree. I think the consensus is clear, but there are some pretty strong opinions, and I think a 3-member panel would help generate a better sense of fairness. Boing! said Zebedee (talk) 13:31, 9 November 2018 (UTC)
    I don't see any specific indications that some participants will feel more confident if a panel of editors (admins or non-admins) closes the RfC. However if the closers would feel more confident with a panel, they should feel free to proceed with this approach. isaacl (talk) 17:23, 9 November 2018 (UTC)
    L235, the consensus is too obvious. I was planning to do it by myself but would probably temporally restrain. WBGconverse 17:31, 9 November 2018 (UTC)
  • Come on, now. The consensus above maybe idiotic, but we all know votes matter. The only hiccup will be addressing the amendments to the multiple policies or guidelines and templates, including Arbcom templates that say, in a content dispute, if nothing else works go to Med Com. Good luck. Alanscottwalker (talk) 18:52, 9 November 2018 (UTC)
  • I don’t see any need for a panel of admins, as others have stated the consensus is fairly obvious. As the person who initiated this I am willing to help with the necessary adjustments mentioned above if needed. Beeblebrox (talk) 21:13, 9 November 2018 (UTC)
  • I have no objections to a one-person closure, to be clear. Please be careful with the closure, though. Best, Kevin (aka L235 · t · c) 21:26, 10 November 2018 (UTC)
  • I think it's easy enough to establish whether or not a consensus has been reached. The closer would not even need to provide an analysis beyond 'consensus/no consensus' but it is traditional to say a few words. It's due for closure, and It does not need a panel of of people to come up with the result. FWIW, if I hadn't voted, I'd close it now and that would be the end of it. Kudpung กุดผึ้ง (talk) 02:35, 11 November 2018 (UTC)

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

RfC: should we automatically pending-changes protect Today's Featured Articles?

Recently, TFAs have been the target for severe vandalism, and the enormous majority of them end up being semi-protected at the end of the day. More particularly, they have been the target for an IP-hopper who adds obscene images at 550px on the top of the TFA, with some of his vandalism staying for several minutes even being removed by IP readers. I myself have loaded a TFA once with a vagina image on it, and I suppose I'm not the only reader to have done so. I have received the opinion of several editors that we should semi-protect TFAs automatically, but I have also seem valid objections that TFAs are supposed to illustrate the principle of Wikipedia, and indeed, there are occasional constructive edit from IPs on TFAs. I therefore propose that we pending-changes protect TFAs automatically (via TFA Protector Bot) so that we will still be able to have constructive edits from time to time, but high-resolution obscene images will not be publicly viewable. With PCP, TFAs will still be part of the encyclopedia anyone can edit, but although typos might stay for a couple minutes more, they will be free from vandalism. L293D ( • ) 23:46, 13 October 2018 (UTC)

Note: I thought it was obvious, but since some people don't seem to get it, my proposal also includes unprotecting the FA when it is no longer on the Main Page. L293D ( • ) 13:57, 15 October 2018 (UTC)
  • Support a fair compromise that prevents vandalism but still allows constructive edits. TeraTIX 00:05, 14 October 2018 (UTC)
  • (edit conflict) Support Even though this is (probably) based on a perennial proposal, this sounds like a reasonable compromise (though this might put extra work on pending changes reviewers. SemiHypercube 00:07, 14 October 2018 (UTC)
  • Support. TFA is a big target for vandalism. Considering it's the very first thing that shows up on Wikipedia's main page, a ton of people could see that vandalism, and some times it can be extreme. However, this is the encyclopedia that anyone can edit, so I don't necessarily like the idea of always locking the first thing that appears on the main page so that only certain users can edit it. PCP seems like a good idea to me.--SkyGazer 512 Oh no, what did I do this time? 00:11, 14 October 2018 (UTC)
  • Support, at least until we have a working filter, or a better way to stop this kind of vandalism. Suffusion of Yellow (talk) 00:14, 14 October 2018 (UTC)
  • Support per everyone else. The advantage of pending changes is it allows IPs and new users to make their change, without it being instantly visible to all and sundry. I get the objections about Pending Changes reviewers not being as active as they should be and articles sitting in the queue for entirely too long. I also get the objections about things getting confusing when there are a bunch of edits that are a mix of constructive and unconstructive edits. However, I would not describe pending changes as "useless". Today's Featured Article and other main-page featured content serve several purposes for Wikipedia - (1) showcasing our work, and (2) inviting people to get involved. Semi or full protection circumvents (2). Allowing people to vandalize and have it be visible circumvents (1). Pending changes protection allows people to get involved without showcasing the destructive efforts of vandals. ~ ONUnicorn(Talk|Contribs)problem solving 00:21, 14 October 2018 (UTC)
  • Comment. During the pending changes trial, trialled pages that had high amounts of edits per day (such as Barack Obama and George W. Bush) had to have PC removed from them because the volume of edits overwhelmed the ability of CRASH to approve edits. This needs to be kept in mind - if a TFA is controversial or popular enough, PC becomes limited in use. (I am not !voting on this as everybody who gives a damn already knows my views on Flagged Revisions and its bastard understudies.) —Jeremy v^_^v Bori! 00:22, 14 October 2018 (UTC)
  • Comment the TFA we've had for less than an hour has already been vandalized five six ten times with obscene images, and it's continuing. L293D ( • ) 01:35, 14 October 2018 (UTC)
    I added it to the bad image list. --Redrose64 🌹 (talk) 08:02, 14 October 2018 (UTC)
  • Support, but perhaps an edit filter that prevents non-autoconfirmed editors from adding or changing images on TFAs would be better given Jéské Couriano's comments above. --Ahecht (TALK
    PAGE
    ) 02:40, 14 October 2018 (UTC)
  • Support It makes sense, and doesn't block anonymous contributions completely. — AfroThundr (u · t · c) 03:06, 14 October 2018 (UTC)
  • Support As other editors have stated, this seems to be the best compromise while maintaining the project. ProgrammingGeek talktome 03:27, 14 October 2018 (UTC)
  • Support Seams reasonable. – BrandonXLF ([email protected]) 04:41, 14 October 2018 (UTC)
  • Oppose per the protection policy and Jéské Couriano. "Pending changes protection should not be used as a preemptive measure against violations that have not yet occurred." If a given TFA is having vandalism problems, an admin should use their discretion to apply whatever remedy is best, whether that be (range) blocking or a higher level of protection. I believe the status quo is a better state of affairs than significantly increasing the workload of reviewers. Yes, TFAs get vandalized, but they have far more eyes on them and get reverted almost immediately, whereas it's not unusual for me to see pages in the reviewer queue for over an hour. I would oppose any default protection of a page, even (especially) TFA, per the protection policy and knowing how slow pending changes reviewing can be am even less in favor of this proposal. Wugapodes [thɑk] [ˈkan.ˌʧɹɪbz] 05:54, 14 October 2018 (UTC)
  • Support Why should we have to deal with all this vandalism when it is so easily prevented. Pending changes won't stop good faith changes. It will prevent readers from looking at vandalised articles. Hawkeye7 (discuss) 06:10, 14 October 2018 (UTC)
  • Strong oppose on principle. This is the encyclopedia that anyone can edit, no permission or approval required. If we don't hold to that principle on the most-viewed article on the site, what do we have? We can use existing anti-vandalism measures, including the BIL and rangeblocking, without violating this principle. I don't suppose there's a way to have one of the anti-vandalism bots "pay more attention" to the featured article, so that obvious vandalism could be reverted instantaneously? --Yair rand (talk) 14:03, 14 October 2018 (UTC)
  • Oppose If we are not going to allow pending changes to be pre-emptively applied to all the BLP's out there (where constant vandalism can have a real world effect and distress on the subject) then really the Battle of Hochkirch can just deal with it like any other article. This RFC is also functionally pointless, as it cannot over-rule the existing policy WP:PCPP and any admin applying protection in such a manner against policy is at risk of being accused of abusing their tools. Want to alter the policy? Start an RFC for that. Only in death does duty end (talk) 14:13, 14 October 2018 (UTC)
There's a difference between protecting a ~millionish articles and one article a day. If this RfC is in favour of preemptive protection, then certainly the policy would be amended to reflect that consensus; policies are merely written down consensuses, and just because the RfC doesn't explicitly mention amending the policy doesn't mean there has to be a separate RfC per WP:NOTBURO. Galobtter (pingó mió) 14:27, 14 October 2018 (UTC)
Well yes, I would rather protect a millionish articles to prevent potential actual harm than hurting the feelings of a 18th century Prussian battlefield. And I am Prussian... But really, if as a result of this someone attempts to amend the protection policy to remove the 'do not pre-emptively use PC' (which is what you appear to be suggesting) it will be reverted within seconds. Only in death does duty end (talk) 14:43, 14 October 2018 (UTC)
The amendment would not be to remove "do not pre-emptively use PC" but to add that "An exception is TFAs, which are pre-emptively PC protected by a bot." or something along that lines Galobtter (pingó mió) 15:09, 14 October 2018 (UTC)
  • Support: @Only in death: While I understand the oppose rationale, it misses the spirit of the policy; protection policy says "Pending changes protection should not be used as a preemptive measure against violations that have not yet occurred.". Since all TFA articles are being routinely targeted (while they are TFA), it can safely be assumed that future TFAs will also be targeted unless protected (just the same as if a single article has been recently repeatedly targeted, it can be assumed that it will be targeted again unless protected). In other words, IP vandalism to all TFAs is occurring, therefore TFAs should be routinely protected to stop this vandalism (at the lowest level needed, and for the duration only of the TFA), and I don't see this as contrary to WP:NO-PREEMPT. — Insertcleverphrasehere (or here) 14:53, 14 October 2018 (UTC)
  • Support: Common sense application of capabilities to block routine vandalism in an efficient way. MB 15:44, 14 October 2018 (UTC)
  • Support - Per nominator L293D's experience. Much as I like having busy beavers on TFAs, we should probably do something about the more disruptive ones. Kurtis (talk) 18:24, 14 October 2018 (UTC)
  • Support. I'd prefer semi-protection, but this would be better than the current situation. SarahSV (talk) 18:39, 14 October 2018 (UTC)
  • Support this *is* an RFC to change the protection policy, the argument that this is not permitted by the current protection policy is circular. This is a reasonable measure to prevent vandalism while still allowing good-faith new contributors to edit. power~enwiki (π, ν) 20:11, 14 October 2018 (UTC)
  • Oppose as pending changes is useless at the best of times and creates more work than it's worth on active articles. I could get behind semi-protection, but I'm a hard no on expanding pending changes to anything: it really is the most useless technical feature in MediaWiki. Also, note to the closer, this should not be read as "Oh, he might be fine with semi-protection, so split the baby with pending changes." I think nothing is better than pending changes because it doesn't require all the extra work and allows good faith people to edit. Semi would be better, despite the loses, but PC would be terrible and result in mangled histories. TonyBallioni (talk) 20:45, 14 October 2018 (UTC)
    • @TonyBallioni: Could you clarify your vote a bit? Are you saying that PCP would be more work? There are dozens of editors who patrol the TFA for vandalism, and PC would save them all that work. If we have a vandal who vandalizes the TFA ten times (as it happened yesterday) with obscene images and the vandalism stays for one minute average, the average of 40,000 pageviews TFAs get would mean 278 people load the TFA with a glaring vagina image on top of it. L293D ( • ) 13:57, 15 October 2018 (UTC)
      • No, it would increase their work substantially: pending changes does absolutely nothing to reduce workload. It increases it on busy article (TFA being one of the most busy) because it requires reviewing of edits, deciding whether or not to affirmatively approve them, and causes good changes by even those with +sysop to get stuck in a technical nightmare of pending approvals that no one really understands how it works, instead forcing people to do mass reverts of up to 10+ edits and then make the good changes again because no one can figure out how the approval process works. Pending changes is a technical nightmare and should rarely if ever be used for pure practical reasons: there aren't circumstances where it is justified where semi-protection isn't better, and if it's "minor but recurring vandalism" just let it go through: it's much easier to just revert. No work is ever saved with pending changes. It's only ever increased. TonyBallioni (talk) 14:12, 15 October 2018 (UTC)
  • Oppose I prefer a standard 24 hour full protection. The Banner talk 20:49, 14 October 2018 (UTC)
  • Oppose - I'd prefer semi-protection over pending-changes because the latter requires continued monitoring and accepting/reverting whereas the former doesn't, We should get rid of IP editing altogether and be made into a register-to-edit site but ofcourse I know I'm the minority on that. –Davey2010Talk 20:53, 14 October 2018 (UTC)
  • Support: it settles the concern of the perennial proposal; it doesn't lock out editing completely, thereby not leaving a poor impression on readers/editors. Regards, User:TheDragonFire300. (Contact me | Contributions). This message was left at 23:24, 14 October 2018 (UTC)
  • Oppose - frustrates IPs with good contributions, and does not diminish work for patrollers. And there are many eyes on main page. Cas Liber (talk · contribs) 01:41, 15 October 2018 (UTC)
  • oppose IPs should be able to directly edit TFAs. — BillHPike (talk, contribs) 03:05, 15 October 2018 (UTC)
  • oppose Wikipedia is the "Encyclopedia that anyone can edit" so having the TFA protected would give a bad impression on new editors Abote2 (talk) 10:04, 15 October 2018 (UTC)
    @Abote2: This proposal refers to having pending changes protection, not semi-protection, so new users can still edit. SemiHypercube 11:21, 15 October 2018 (UTC)
    No, they can not. They can submit changes for approval. It is not the same thing. --Yair rand (talk) 13:53, 15 October 2018 (UTC)
  • Support: pending changes doesn’t stop anyone from editing. There’s need for protection and in fact, if most TFAs are getting semi-protected midway through, pre-emotive PC is actually a decrease in protection as it means all people will be able to edit at any point in the day (barring extreme spam of vandalism which would require an increase in protection). Bilorv(c)(talk) 10:55, 15 October 2018 (UTC)
  • Oppose in favor of different solution. I think it was MusikAnimal's original suggestion, but why not do something closer to tagging TFA with an invisible template and creating an edit filter specifically to disallow changes within a File name for any unconfirmed editor on that tagged page, as well as disallow additions of new files. It's a bit less harsh than either of the proposed options and should alleviate the worst of the problem behind the LTA. (If you are an EFM, please feel free to tell me this isn't feasible.) --Izno (talk) 14:02, 15 October 2018 (UTC)
  • Oppose After vandalism has happened, I'm OK with protecting. Pre-emptive protection is not useful, IMHO. --Jayron32 15:18, 15 October 2018 (UTC)
  • Oppose I'm a bit on the fence for this one, as I recognize the issues that persistent vandalism on one of the most public pages of the day. However, I would lean in favor of not protecting TFA. Even though it doesn't say it in the top left corner, this is still the "encyclopedia that anyone can edit." Semi-protection would be out of the question as a preemptive measure. Pending changes might work, but only if edits were reviewed quickly. It is not unusual for me to look at my dashboard and see the pending changes backlog rated as "High" or "Critical", and I have no doubt that the backlog would extend to TFA. Pending changes would then not be workable. I would be supportive to targeted measures (edit filters) for specific types of vandalism. --AntiCompositeNumber (talk) 17:04, 15 October 2018 (UTC)
  • Oppose as a permanent solution. Full disclosure: I've PC-protected today's TFA, and yesterday's TFA, and tomorrow's TFA preemptively. I may well continue doing this for a while and encourage others to do the same. I'm perfectly happy with that - though I would prefer no protection it's obviously a sensible precaution at this time. However I don't think this should be a permanent state of affairs, as this proposal suggests. There's been very few times in the last many years that preemptive protection has been an appropriate response. The vandals in any case also target other articles on the main page, and have been known to also use accounts. Autoconfirmed is an easy bar. Ultimately I'd prefer to see an edit filter implementation targeting image edits, like the one being discussed at WP:AN. -- zzuuzz (talk) 18:31, 15 October 2018 (UTC)
  • Suppose see what I did there? per the above comment by zzuuzz. This is perhaps a workable stopgap measure but I don’t see it as good permanent solution. So, do it for now, but don’t consider the problem permanantly resolved. Alternatives like the edit filter proposed below should be considered. Beeblebrox (talk) 19:07, 15 October 2018 (UTC)
  • Weak support Thanks for starting this. I brought this up (permalink) at AN, under the safe assumption the community wouldn't agree to preemptively PC protect long-term, but that it would be a wise short-term solution. But frankly, I do think we should PC-protect the TFA, for the full 24 hours, unconditionally. This is not just about the image vandalism. I can't count how many times I was reading the TFA, and noticed something was off (entire sections missing, broken wikitext, dubious claims, etc.), before finally figuring out it had been vandalized. I am a strong believer in the no-preemptive protection philosophy, but you don't need to wait for the TFA to be vandalized. It will happen, with absolutely certainty, and it may linger there for minutes. This is normally fine and typical of the wiki, except this article we're advertising to millions of readers as being of utmost quality. PC seems like a great solution because everyone still gets to edit. And remember, most people don't edit, they just read. Ideally they will be reading the version we intended for them to see. Worry of clogging up the PC backlog is what makes me unsure. On one hand, almost all of it (for TFA) would be vandalism, which will get reverted by patrollers no slower than it is now, and then the pending changes will no longer be in the queue. But there are good edits in there too, and overall the high edit rate may make the reviewing process more cumbersome. This is why we usually reserve PC for articles that have a low-ish edit rate. I'd like to first see how our "PC trial" (so to speak) goes over the next few days, as I know we're going to be adding it again. We can review the data, good vs bad edits, get an idea of how the PC backlog is affected, and go from there. One other thing I might suggest is to not show the PC lock icon at the top-right on TFA. MusikAnimal talk 20:06, 15 October 2018 (UTC)
  • Support per TheDragonFire300. Double sharp (talk) 23:57, 15 October 2018 (UTC)
  • Support Wikipedia is the encyclopedia anyone can edit, not the encyclopedia anyone can vandalize. Pending changes is not going to stop constructive editors from contributing. --Joshualouie711talk 01:21, 16 October 2018 (UTC)
  • Support semi-protection, a better option than pending changes. --K.e.coffman (talk) 03:16, 16 October 2018 (UTC)
  • Support: This is a no brainer. There is significantly less damage to a) our reputation, and b) our articles if we automatically semi-protect TFA's for the 24 hours that the article is on the main page, then there is from readers opening up those articles to be confronted with vandalism. Readers can live with having to use the talk page to propose fixes for a day. Mr rnddude (talk) 03:23, 16 October 2018 (UTC)
  • Support TFA is meant to show the very best of our efforts. Protecting a page for one day to stop an IP free for all can't be a bad thing. Any well-meaning anon. editors can raise an edit request on the article's talkpage. Lugnuts Fire Walk with Me 11:17, 16 October 2018 (UTC)
  • Oppose - PC on TFA generates a significant level of work for PC patrollers which gets harder to handle at a non-geometric rate. This would cause knock-on effects on other PC work. TFAs always have lots of watchlisters and thus a fairly quick return of edits in any case. Nosebagbear (talk) 18:19, 15 October 2018 (UTC)
  • Oppose per AntiCompositeNumber, zzuuzz, and Beeblebrox. The supports are quite right, this is an issue, a problem, but preventing certain people from editing the very first article they're likely to come across doesn't strike me as the correct solution. Happy days, LindsayHello 14:38, 16 October 2018 (UTC)
  • Strong Oppose. PC protection is only useful for articles that are not edited very often - so that there is time for a pending edit to be approved or disapproved. PC is worse than worthless for heavily edited articles, since one pending edit creates a logjam that blocks subsequent edits. I could possibly go along with automatically semi-protecting the TFA, but I absolutely oppose pending change protection. --MelanieN (talk) 19:52, 16 October 2018 (UTC)
  • Support - Net positive. shoy (reactions) 20:14, 16 October 2018 (UTC)
  • Oppose per MelanieN and TonyBallioni. PC is a badly designed feature that increases workload for watchlisters and page patrollers, and on a frequently edited page (which TFA is on that day) it results in a quagmire of issues. I'm in favor of the alternative proposal, as it addresses the most pressing aspect of vandalism. No such user (talk) 15:10, 17 October 2018 (UTC)
  • Support I support locking down all of Wikipedia. This is a step in the right direction. Our best, most-advertised works are obviously the targets of vandals. Chris Troutman (talk) 00:02, 18 October 2018 (UTC)
  • Support. TFA is the first article many readers see when they visit Wikipedia through the main page or the mobile app. Wikipedia's reputation depends on its ability to make good first impressions. Pending changes protection still allows IP editors to propose changes to TFA, and there is no shortage of articles that can be edited by any user with their changes immediately applied. — Newslinger talk 15:14, 18 October 2018 (UTC)
  • Oppose due to the backlog of changes that can build up with a popular article, and because we have a less disruptive solution suggested below. Boing! said Zebedee (talk) 15:25, 18 October 2018 (UTC)
Leave to admin discretion, per zzuuzz. There isn't always much vandalism on TFAs, and PCP is counterindicated when there is a large volume of constructive edits but I support discretionary preemptive protection (starting at PC or semi depending on relative volume) for high profile pages if vandalism is judged to be likely. Alpha3031 (tc) 12:52, 19 October 2018 (UTC)
  • Support per User:Insertcleverphrasehere. This deals with the problem of TFA being used as an attack vector, without breaching the principle that anyone can edit. I am unimpressed with the argument against pre-emption, because as others have noted it is near certain that TFA will be vandalised. Leaving PCP to applied after the first spasm of vandalism will only create manual work. --BrownHairedGirl (talk) • (contribs) 14:35, 19 October 2018 (UTC)
  • Oppose pending changes simply does not work for articles that receive frequent edits. feminist (talk) 18:06, 19 October 2018 (UTC)
  • Oppose as phrased. There are very few decisions we should make automatically. Some TFAs, like my own on Greek mythology, didn't actually need PC; others, like Barack Obama, need to be semi-protected or protected. I am here because I was quoted far below on that subject, so I won't repeat myself. Can we try "By default, TFA should be at least subject to pending changes protection"? Septentrionalis PMAnderson 00:44, 20 October 2018 (UTC)
  • Support Prevents vandalism while allowing constructive IPs/non-autoconfirmed users to make changes. Philroc (c) 12:26, 24 October 2018 (UTC)
  • Oppose per above. Some people seem to have forgotten that this is Wikipedia, the encyclopedia anyone can edit. I'm opposed to *any* sort of preemptive protection. -FASTILY 07:49, 25 October 2018 (UTC)
  • Oppose per Cas Libre, Yair Rand and Fastily. --Nemo 11:51, 26 October 2018 (UTC)
  • Support although pending changes can get clogged, it would be only 1 article extra to deal with. Although pending changes protection is not supposed to be used for preemptive protection, the long term vandalism on TFAs, almost guarantees that vandalism will occur. Making TFAs semi-protected stops IP or unconfirmed editors from editing the article constructively, which will hinder the improvement of the article (at least for that day). Just having a edit filter for images seems silly, as the IP editor in question may just turn to other vandalism. Dreamy Jazz 🎷 talk to me | my contributions 19:37, 28 October 2018 (UTC)
  • Support. The fact that today's featured articles have been vandalised in the recent past means that there is enough disruption to justify pending-changes protecting forthcoming today's featured articles for the duration they're on the front page. Since this is very short temporary protection, and we have the unapproved-edit log to assess how much vandalism we're getting, I think PC is proportionate here. Deryck C. 17:38, 6 November 2018 (UTC)
  • Support. I'm surprised that this wasn't the norm already. TFAs are too high-traffic to avoid being a primary target for vandals, and there's clear evidence that temporary protection is the only way to completely stop it. In regards to the primary oppose reasoning (it's an encyclopedia anyone can edit, and this is preventing that), it's not blocking edits entirely, just hiding them from view of unregistered users until someone can verify them. I've been a big supporter of pending changes for a while, and this is the perfect use case for it. Nathan2055talk - contribs 23:17, 10 November 2018 (UTC)
  • Support. The "anyone can edit" philosophy should of course be upheld wherever possible, but pragmatism trumps upholding unrealistic ideals. Darylgolden(talk) Ping when replying 12:27, 14 November 2018 (UTC)

Alternative proposal: disallow non-autoconfirmed users adding images on TFAs

Most of the opposes above are oppositions to PCP in general, so maybe we should just disallow non-autoconfirmed editors from adding images to TFAs. This would be achieved via an edit filter. L293D ( • ) 14:35, 15 October 2018 (UTC)

  • Weak support If something needs to be done, I would not be opposed to this solution, if it is workable. --Jayron32 15:18, 15 October 2018 (UTC)
  • Support - this sounds a reasonable thing to do - TFA shouldn't be having any photo altered without major discussion and thus there'd always be someone who could handle the actual edit, giving relatively little in the way of negative for a partial plus. Nosebagbear (talk) 18:19, 15 October 2018 (UTC)
  • Support Seems like a good idea regardless of the outcome of the broader discussion. Beeblebrox (talk) 19:04, 15 October 2018 (UTC)
  • Support as above. TonyBallioni (talk) 19:12, 15 October 2018 (UTC)
  • Support (as I commented above). In principle adding or changing an image on TFA seems as straightforward as move protection - one of those things that is rarely appropriate. -- zzuuzz (talk) 19:18, 15 October 2018 (UTC)
  • Support per above. Aoi (青い) (talk) 19:20, 15 October 2018 (UTC)
  • Support If this would be the only thing that works (but how would it be implemented? Edit filter?) SemiHypercube 19:24, 15 October 2018 (UTC)
  • Oppose as permanent solution This would be easily achieved via an edit filter This not yet true. See this AN discussion (permalink). Anyway, the image vandalism is a temporary problem. It will go away, and there will (very occasionally) be constructive edits of adding images to the TFA. We should not outright disallow this indefinitely. Don't worry about the short-term; if and when we are able to use an edit filter we will. MusikAnimal talk 19:38, 15 October 2018 (UTC)
    @MusikAnimal: the image vandalism is a temporary problem: no, its not; this image vandalism has been present for seven months. As to the technical implementation, a bot would add some invisible template such as {{TFA filter}} and remove it at the end of the day. The edit filter should be fairly simple: If the article contains the template and !"autoconfirmed" in USER_RIGHTS and added_lines contain [[File:, then disallow. L293D ( • ) 21:36, 15 October 2018 (UTC)
    The edit filter is simple if the bot automation exists, which it does not. Once that's done, we have means to target this specific image vandalism to TFA. We don't necessarily need to ban all imagery. Yes the image vandalism has been going on for a while but seven months is not that long if we're talking about an indefinite ban. And please, don't discuss private filter implementation on public venues (albeit yours was rather straightforward and guessable) MusikAnimal talk 22:11, 15 October 2018 (UTC)
  • Oppose Not in favour of the use of edit filters. Hawkeye7 (discuss) 21:55, 15 October 2018 (UTC)
  • Support It is very unlikely that an image added to a TFA would benefit the article as the imagery will have been considered and discussed in the FA review, and the risk of image vandalism is high. Hrodvarsson (talk) 00:17, 16 October 2018 (UTC)
  • Support: I'm not sure that most valdalism is adding images, but would not hurt. --K.e.coffman (talk) 03:16, 16 October 2018 (UTC)
  • Support if PC-protection of TFA does not succeed: I'd prefer PC protection, but this would also eliminate some of the most egregious vandalism on TFAs. Regards, User:TheDragonFire300. (Contact me | Contributions). This message was left at 10:49, 16 October 2018 (UTC)
  • Support provided the same edit filter also disallows removing images as well. Alternatively, as mentioned above more judicious use of the bad image list can help. —Jeremy v^_^v Bori! 17:50, 16 October 2018 (UTC)
  • Support. It's true that IPs sometimes make constructive edits to the text of TFAs, and I understand people's desire to keep that open as a possibility. But I can't imagine any acceptable image being uploaded by an IP or brand new user. It would either be inappropriate for the article, or it would have improper licensing, or both. If we can find a way to technically block changes or uploads to images, I'm all for it. --MelanieN (talk) 20:00, 16 October 2018 (UTC)
  • Support this proposal. No such user (talk) 15:10, 17 October 2018 (UTC)
  • Support as a compromise. — Insertcleverphrasehere (or here) 15:14, 17 October 2018 (UTC)
  • Support. Sounds like it should be effective without compromising the "anyone can edit" ideal and without clogging up articles with pending changes. Boing! said Zebedee (talk) 15:31, 17 October 2018 (UTC)
  • Support It should work Elitemagikarp (talk) 15:49, 17 October 2018 (UTC)
  • Support I support locking down all of Wikipedia. This is a step in the right direction. Our best, most-advertised works are obviously the targets of vandals. Chris Troutman (talk) 00:02, 18 October 2018 (UTC)
  • Support Johnbod (talk) 00:13, 18 October 2018 (UTC)
  • Support, seems like a good compromise. Kaldari (talk) 20:12, 18 October 2018 (UTC)
  • Support if PC-protection of TFA does not succeed: I'd prefer PC protection, but if there is not a consensus for PCP, then this is a good compromise. --BrownHairedGirl (talk) • (contribs) 14:37, 19 October 2018 (UTC)
  • Support per B!sZ. Mathglot (talk) 22:22, 21 October 2018 (UTC)
  • Support, assuming it's both technically possible and the PCP proposal fails. Bilorv(c)(talk) 01:52, 22 October 2018 (UTC)
  • Strong oppose per User:Jimbo Wales/Statement of principles 2 and 3 and WP:AGF. Image vandalism of TFAs is a recent problem and should be resolved if and when it occurs with blocks, range blocks, page protection, and/or adding the image to the image blacklist as suitable to the individual case, not a blanket and convoluted edit filter that will confound and bite good faith newcomers. IPs should be just as allowed to engage in WP:BRD of images on TFA as any other editor, and the idea that newcomers will understand Wikipedia well enough to make a talk page request for the addition of an image is not compelling. Wugapodes [thɑk] [ˈkan.ˌʧɹɪbz] 08:02, 22 October 2018 (UTC)
  • Oppose per MusikAnimal. Philroc (c) 12:57, 24 October 2018 (UTC)
  • Oppose technically infeasible and would result in poor experience for anons making legitimate edits. -FASTILY 07:49, 25 October 2018 (UTC)
    • Fastily, why would it technically infeasible? Filters are able to detect lots of stuff; surely they could detect when an IP or new account performs an edit that adds a new file-display link to a page? No comment on your experience argument. Nyttend (talk) 01:59, 5 November 2018 (UTC)
      • There's no way to make a TFA-specific edit filter; see MusikAnimal's !vote above. -FASTILY 07:55, 5 November 2018 (UTC)
  • Erm How do you enforce this in a way that doesn't increase human workload? Deryck C. 17:38, 6 November 2018 (UTC)
    By setting it to "disallow". L293D ( • ) 14:33, 9 November 2018 (UTC)
  • Only temporarily, in response to an actual vandalism wave or PoV-war. I.e., this really isn't any different from any other WP:RFPP case. Just go there and report the problem and let the protection-focused admins deal with it as they normally do.  — SMcCandlish ¢ 😼  06:19, 13 November 2018 (UTC)
  • Support - too much potential for damage by adding an unsuitable image. Darylgolden(talk) Ping when replying 12:23, 14 November 2018 (UTC)

Alternative proposal: semi-protect TFAs

I'm going to close this section per WP:SNOW as it's clearly not going anywhere. Mz7 (talk) 05:59, 21 October 2018 (UTC)
The following discussion has been closed. Please do not modify it.

In the RfC above several editors have expressed their opinion that TFAs should be semi-protected instead. L293D ( • ) 23:19, 14 October 2018 (UTC)

  • Oppose as a perennial proposal. SemiHypercube 23:22, 14 October 2018 (UTC)
  • Weak oppose - frustrates IPs with good contributions, though does reduce work for patrollers. Ultimately there are many eyes on main page, so vandalism will not be missed Cas Liber (talk · contribs) 01:41, 15 October 2018 (UTC)
  • Oppose. The fact that it's a perennial proposal is not a reason to oppose in itself. However, this is the encyclopedia that anyone can edit it, and I think taking away the ability for everyone to edit the current featured article at all would be contrary to that purpose.--SkyGazer 512 Oh no, what did I do this time? 14:01, 15 October 2018 (UTC)
  • Oppose for the reasons I explained above. --Jayron32 15:18, 15 October 2018 (UTC)
  • Oppose The ability to edit the featured article is part of how we invite people to get involved. ~ ONUnicorn(Talk|Contribs)problem solving 15:30, 15 October 2018 (UTC)
  • Oppose, for the reasons I mentioned above, which echoes the points of the other opposes here. --AntiCompositeNumber (talk) 17:07, 15 October 2018 (UTC)
  • Oppose It would contradict the "anyone can edit" motto if the first article on the main page is always unable to be edited by anons or new users. An edit filter preventing addition of images, as discussed above, is about the limit of autoprotection that should be considered in my opinion. Hrodvarsson (talk) 00:21, 16 October 2018 (UTC)
  • Insanity: Suggesting/trying something multiple times and expecting a different answer each time. Oppose.Jeremy v^_^v Bori! 17:51, 16 October 2018 (UTC)
  • Support I support locking down all of Wikipedia. This is a step in the right direction. Our best, most-advertised works are obviously the targets of vandals. Chris Troutman (talk) 00:02, 18 October 2018 (UTC)
    Chris troutman, finally. Someone with the guts to say what we've all been thinking. All articles should be fully-protected. Let's shut down RfA, as well, just to make sure none of those pesky vandals are handed the mop. ProgrammingGeek talktome 00:20, 18 October 2018 (UTC)
    @ProgrammingGeek: Bryan Caplan has shown that voting does not result in Pareto-optimal solutions. Either we want to solve the problem or we don't. Chris Troutman (talk) 03:14, 18 October 2018 (UTC)
    So? Pareto-optimal solutions are both very difficult to reach, and a very weak condition. How many rules changes do we have that are literally unanimous? Septentrionalis PMAnderson 00:54, 20 October 2018 (UTC)
    Pmanderson, This kind of situation is easily avoided by the absolutist government advocated for in Leviathan. A good first step for this is this proposal. ProgrammingGeek talktome 01:41, 20 October 2018 (UTC)
  • Oppose as there's a better solution above. Boing! said Zebedee (talk) 15:26, 18 October 2018 (UTC)
  • Neutral, prefer pending changes so new editors can still submit changes via the normal edit button. Deryck C. 17:38, 6 November 2018 (UTC)
  • Support semi-protection: the amount of penis pictures bombing onto TFA today is just too much. StraussInTheHouse (talk) 16:03, 10 November 2018 (UTC)
  • While I'm sympathetic to the view that anonymous IP contributions to Wikipedia have, over the years, statistically become less and and less likely to be constructive (especially at "big target painted on them" pages), the constructiveness of them hasn't fallen precipitously, so general consensus has not shifted toward locking anons out of any more editing, even temporarily. It could go that way some day, but I don't see any signs of such a WP:CCC shift yet. For this sort of thing in particular, it would require an analysis proving that anon contribs to TFAs (and perhaps other main-page content) are almost always revert-worthy, and even then you'd have to surmount the argument that deciding to edit a main-page-featured item could be many new editors' first forays into participating as more than readers. (Personally, I doubt that's really true very often, but people will argue it.)  — SMcCandlish ¢ 😼  06:19, 13 November 2018 (UTC)

General Discussion

  • Workload issues - There only seem two reasons to oppose, either a strong "no pre-emption" POV or an issue with the resolution. Placing PC on high activity articles like this would have a massive increase. PC already is ruled out in favour of standard semi-protect if used on a traditionally active article. Additionally, resolving PCs becomes increasingly problematic the more of them are "stored-up" since accepting just the good ones becomes trickier much more quickly. Normally PC does as a happy medium between protection and censorship, but enacting it here I think would be a significant increase in workload, reducing speeds on other articles as well. Nosebagbear (talk) 18:26, 14 October 2018 (UTC)
    The amount of workload remains the same; you still have to check the TFA as often as possible, usually at least once every half hour. The difference is that the readers would not be not subjected to vandalism. It's only one day, whereas high traffic articles are every day. Hawkeye7 (discuss) 23:57, 14 October 2018 (UTC)
    pretty sure your remark misses the point Nosebagbear was trying to make, which is more about the pending changes workload than the TFA workload. PC can get very convoluted when used on busy articles, that’s not really what it’s for and adding TFA could cause less attention to be paid to other articles under PC. Beeblebrox (talk) 19:10, 15 October 2018 (UTC)
    The request appears on the watchlist and you approve it. That's how it is supposed to work. Hawkeye7 (discuss) 22:08, 15 October 2018 (UTC)
Optimally yes, but when there are multiple edits awaiting review it can get difficult to untangle. Beeblebrox (talk) 22:14, 15 October 2018 (UTC)
This is essentially the crux of my comment and no-vote. I'm not talking out of my ass; the situation with PC on high-volume articles has been discussed ad nauseam, especially in the various RfCs on its retention/expansion. It's generally accepted that if an article is being heavily edited, PC is not helpful because of the fact that it belays edits until CRASH can be arsed to go through the queue, and in more technical articles this is another strike against it because, during the time you're trying to understand a source, more edits are being shoved into the queue which will also need approval. Throwing more men at it won't help - again, Barack Obama is an article that did not want for eyes (as he was President during the PC trial) and they came to the conclusion that PC was an active detriment compared to the semi-protection that was on it before (and reapplied when PC was removed from it). —Jeremy v^_^v Bori! 17:57, 16 October 2018 (UTC)
  • Question: I see that while this is under discussion, the current TFA is PC-protected. Zzuuzz PC-protected it for four days, the 15th through the 19th, with the edit summary "upcoming TFA". Was this a test, or a BOLD change, or what? Is the actual proposal here to PC protect the page for four days? --MelanieN (talk) 23:23, 16 October 2018 (UTC)
    I've mentioned this above. I think MusikAnimal might have even referred to it as a 'trial'. I'd describe it as a temporary measure in response to the current vandalism, and I've picked three/four days, because that's how long TFAs actually remain linked on the main page. The protection (four articles to date) has prevented anus/vagina images being displayed on two of the articles. I have also PC-protected a couple of articles 'in the news' in response to the vandalism. There is no long term strategy implied. -- zzuuzz (talk) 23:30, 16 October 2018 (UTC)
    For now, it has worked great and not even one of the "problems" the opposers raised have happened. No logjam, no "trouble sorting edits" or anything similar. L293D ( • ) 23:45, 16 October 2018 (UTC)
    I would argue that's more because of the obscurity of the TFAs in question. —Jeremy v^_^v Bori! 05:39, 17 October 2018 (UTC)
  • Comment: The points made by Jéské Couriano (Jeremy) and TonyBallioni need to be understood by anyone considering this proposal who isn't a Pending Changes reviewer: Reviewing changes on active pages is, due to the current PC review workflow, an extremely daunting task. I'm sure there are ways it could be improved, but as things currently stand single-edit reviews are relatively easy, and relatively quick, but when an article in the queue consists of several changes by multiple editors, it can sometimes sit there for many hours before one of us finds the energy to tackle it. (Accumulating more edits, and as a result becoming an even more daunting task.) That may be a state we wish to avoid the TFA ending up in.
Perhaps the PC review queue listing could be updated to display certain articles, including TFA, as "immediate review" candidates, with a request that those reviews be performed before the rest of the queue. That might help alleviate the buildup a bit, though it still doesn't change the fact tha the review system is designed in a way that makes the effort required to perform a review grow exponentially with the number of editors and edits pending. -- FeRDNYC (talk) 02:58, 18 October 2018 (UTC)
I should note that I am not a member of CRASH (and in fact gave up adminship because it includes reviewer); that said I have participated in the lion's share of RfCs on the subject, including the RfCs and straw polls that took place around the tail end of the "trial". Workload on very busy pages was indeed brought up quite a bit, and I will quote Pmanderson (talk · contribs) with regards to the situation I've mainly been using as my counterpoint to this:

"No, this is a problem for which PC is demonstrably not a solution. Barack Obama was moved back to semi-protection while the trial was still underway; the backlog became unmanageable - and his election is two years off. Other elected officials will have the same problem when elections roll around (there may be fewer vandals - or there may not; but there will also be fewer watchers and confident reviewers.(sic)


The reason that the issue has not manifested on the present TFAs that have been PC-protected is that their subjects are fairly obscure and do not attract interest enough to see the volume of edits that something even reasonably popular would see as a matter of course. —Jeremy v^_^v Bori! 10:06, 18 October 2018 (UTC)
Thanks. Why the sic? A pending-changes reviewer who's not confident on the subject of the article is not much better than no review. Septentrionalis PMAnderson 00:46, 20 October 2018 (UTC)
Because you forgot a closing parenthesis. —Jeremy v^_^v Bori! 01:29, 22 October 2018 (UTC)

As an alternative, how about applying preemptive PC ECP only to those articles where ArbCom has authorised the use of discretionary sanctions. Today's article isn't likely to be hit with the vandalism, but the same would not be said of pretty much any US, or even UK, politician, for example. It would be worth considering applying preemptive PC on BLP's at least, the rest can be dealt with on an "as they happen" basis. Blackmane (talk) 05:07, 25 October 2018 (UTC)

Pretty much any national-level politician is a bad choice for PC, especially as election time approaches. See above. —Jeremy v^_^v Bori! 10:34, 25 October 2018 (UTC)
Actually meant ECP, corrected myself. Blackmane (talk) 01:54, 26 October 2018 (UTC)

Proposal - Allow non-admins to close deletion discussions as "delete" at Wikipedia:Redirects for discussion

Today, I am going to propose that non-admins should have the right to close deletion discussions as "delete" at Wikipedia:Redirects for discussion. This is because it is one of those deletion noticeboards that have a huge backlog and can stretch for up to two week or even more. I am sure that with the help of non-admins, this backlog will always reduce significantly. XFDCloser should allow non-admins to close a WP:RFD discussion as "delete" and then tag the corresponding page for speedy deletion with {{db-xfd}} so that an admin can delete soon after. Pkbwcgs (talk) 12:33, 20 October 2018 (UTC)

  • It seems like this will only create duplicate work... Before using the Delete button Admins will still have to re-assess the consensus of the discussion. — Insertcleverphrasehere (or here) 12:40, 20 October 2018 (UTC)
    • @Insertcleverphrasehere: That's a good point. However, we could restrict this so that users who have more than 10,000 edits can only close these discussions. However, right now there is a backlog of two weeks at WP:RFD and non-admins can currently close any discussion as anything other than keep. Also, if that is the case then what if a non-admin closes a discussion as keep just because they created that redirect when there are five delete votes? Then, they got the consensus wrong! So, if non-admins can't be trusted to close a deletion discussion as "delete", the why should they be trusted to close a deletion discussion as "keep". However, non-admin can close discussions as anything other than "delete" on all noticeboards (except WP:TfD where non-admins can close discussions as "delete" as well) so what is wrong in letting non-admins close WP:RFD discussions as "delete" to clear the backlog? There is no problem in letting non-admins close WP:RFD discussions as "delete" and if there is any problem, it can always go back to admins only closing WP:RFD as "delete". Pkbwcgs (talk) 12:53, 20 October 2018 (UTC)
"Clearing the backlog" does nothing if admins still have to go and read all those discussions to ensure that the consensus was right (they have to do this as it is ultimately their responsibility to use the delete button appropriately). We don't need a knee-jerk response here. Just go ask at WP:AN if some admins can come over and clear the backlog. — Insertcleverphrasehere (or here) 13:00, 20 October 2018 (UTC)
I've already done two non-admin delete closures. This is possible when an admin has come along and deleted while the xfD is ongoing. Hawkeye7 (discuss) 08:43, 21 October 2018 (UTC)
  • WP:RFD does not have any backlog, much less one that's over two weeks. Occasionally a single discussion hangs out in the backlog for some time (eg: Stephni meyer), but that is different from RfD actually being backlogged. I can't think of any sizable backlog there since early 2016 and even then, it wasn't to the point where I would call it problematic. -- Tavix (talk) 15:07, 22 October 2018 (UTC)
  • Agree with @Insertcleverphrasehere. No matter what, the admin doing the "actual deletion" must reassess the situation and be personally assured that the deletion is OK and this is plainly duplication of work. Just what is needed is to draw the attention of willing admins to the area, through the usual ways.–Ammarpad (talk) 13:50, 20 October 2018 (UTC)
  • Strong oppose: What's the point of closing as delete if the closer cannot delete anyway? Regards, User:TheDragonFire300. (Contact me | Contributions). This message was left at 04:39, 21 October 2018 (UTC)
  • I supported this the last time it was proposed (Wikipedia talk:Redirects for discussion/Archive 9), and I'm still somewhat sympathetic towards it. It is true that an admin still needs to do the final review, but the main advantage comes from the fact that there are more active administrators at CAT:CSD than WP:RFD. As long as the non-admin closure is performed on clear outcomes only, time is saved by the fact that the deleting admin probably wouldn't have deleted the redirect had the non-admin not drawn attention to it. Close calls and controversial decisions should still be left to administrators. Something similar has already been implemented at WP:TFD with some success. With that being said, the previous discussion was held when, if I recall correctly, the backlog at RfD was pretty severe. I can't confess to being familiar with the RfD backlog today, so perhaps this extension on non-admin closures is simply not necessary (e.g. admins already clear out the easy delete closes quickly). Mz7 (talk) 05:07, 22 October 2018 (UTC)
  • Strong Support a great way to tackle backlogs. Yes an Admin will need to check the RfD before deleting but they will not need to fill out the fields to close the discussion. It will be very clear very fast which non-Admins are trustworthy to close RfDs where the Admin can just handle the deletions. This will reduce silly relistings as well. Legacypac (talk) 09:34, 22 October 2018 (UTC)
  • Support. Even though admins will need to check the RfD, most are unlikely to be contentious so that's likely to be little more than a rubber stamp. And in cases that might not be obvious, I generally find it significantly easier to review someone else's judgment of consensus than to judge it myself from scratch. As Legacypac says, it means the admin just has to do a quick CSD delete rather than the formal closing steps of the RfD, so it's one step of bureaucracy taken care of. Mz7 makes the point that CSD has more active admins than RfD - I've personally done lots of CSD work but I don't think I've ever even looked at RfD. On an ideological front I also think it's good to get judgment calls like this devolved away from admin-only wherever practical. Boing! said Zebedee (talk) 10:21, 22 October 2018 (UTC)
  • Procedural note. The same thing was propsed, and rejected, at an RfC in 2016, see Wikipedia talk:Redirects for discussion/Archive 9#Allow non-admin delete closures?. Of course, things can change, but if there is any obvious change since then, it is that for the past year or so we've had more admins regularly closing discussions, so the backlogs have almost disappeared now. – Uanfala (talk) 12:39, 22 October 2018 (UTC)
    It was a close call back then, and two years is a very long time in Wikipedia ;-) Boing! said Zebedee (talk) 13:31, 22 October 2018 (UTC)
  • Oppose Per above, I don't see the point. As one of the main sysops active at RfD, I don't think lack of sysop activity is a major issue, but rather lack of overall participation. Having a few more sysops swing by would be helpful, but I'd much rather have folks take part in the discussions. Best case scenario there's a half dozen or so participants, and excepting Thryduulf, there's very little actual discussion amongst participants; mostly by the seventh day there have been no comments for five or six days. ~ Amory (utc) 13:40, 22 October 2018 (UTC)
  • Hypothetical support, practical oppose. I appreciate the intent here; non-admins are perfectly capable of assessing consensus. However, since an admin still has to come along and delete the article, it just creates double work. --Jayron32 13:45, 22 October 2018 (UTC)
  • Question how would this work mechanically? Maybe a CSD-like tag indicating an RfD was closed by a non-admin as Delete with a link to the closing diff? zchrykng (talk) 13:47, 22 October 2018 (UTC)
@Zchrykng: Yes a template like {{db-xfd}}. — Insertcleverphrasehere (or here) 13:52, 22 October 2018 (UTC)
  • Oppose. It's rare that there is actually a significant backlog of discussions that are simple closures (with any outcome). user:Feminist does good work with easy keep and retarget closures and there are 6 active RfD admins (in no particular order) myself, Tavix, Patar knight, Amorymeltzer, Deryck Chan and BDD. The discussions that get left are the ones that are more complicated and need careful assessing of the arguments - NACs would not help these. The one really extended backlog we had recently was Wikipedia:Redirects for discussion/Log/2018 September 17#Stephni meyer which went unanswered for several days at WP:ANRFC but was closed by Ivanvector (an occasional RFD participant and former regular) when I left a message on their talk page. What is needed at RfD is more people (admins and non-admins) participating in discussions and admins patrolling backlogs at WP:ANRFC. Thryduulf (talk) 14:30, 22 October 2018 (UTC)
  • Strong oppose. This comes up frequently enough that I have listed out my reasons at User:Tavix/non-admin closes. -- Tavix (talk) 14:43, 22 October 2018 (UTC)
  • TBH I think what this shows is that having something like an "eliminator" user right would be useful. Galobtter (pingó mió) 14:48, 22 October 2018 (UTC)
  • Support - I did make this same proposal some time ago. I don't think this would help address any backlogs and I agree that in the more recent past this process hasn't really been plagued with backlogs anyway. I pretty much agree entirely with Thryduulf's comment, but this is more of a "why not?" support. I don't think the sky is going to fall if we let non-admins conclude that a discussion closed as "delete" just because they can't push the buttons: we let non-admins close every other kind of result anyway. Personally I think it's silly that we trust experienced editors like feminist to neutrally assess the result of a discussion but only if the result fits in a certain box. If such a user can determine the consensus of a "keep" discussion they are just as capable of determining the consensus of a "delete" discussion. Ivanvector (Talk/Edits) 15:29, 22 October 2018 (UTC)
  • Oppose per the sound reasoning at User:Tavix/non-admin closes. -DJSasso (talk) 16:31, 22 October 2018 (UTC)
  • Neutral. I have previously argued against NAC deletion, though the marginal cases of all admin-regulars having already chipped in, and the faffiness of RfA are softening me up to the idea of non-admins closing discussions to mandate admin action. As one of the RfD admin-regulars I am probably expected to leave a comment here, so I'm writing this to say why I don't feel strongly either way. Deryck C. 17:23, 22 October 2018 (UTC)
  • I'd like to find some way to make this work. Before I was an admin, I did good work (I'd like to think) with non-admin closures, including deletion results in venues that allowed it. I mostly agree that the RfD backlog hasn't been bad enough recently to really need this, but that has not always been true and likely will not be true again sometime in the future. So I don't want to argue against planting seeds just because I currently have enough food, proverbially speaking. The first thing that comes to mind is a system in which one or more admins indicate "hey, a non-admin delete close could work here". I don't know how to design a clean mechanism like that, though. I imagine it'd be invoked most when admins are involved. We wouldn't want it to just be a way for admins to try to cut short discussion on something they want to see deleted. (Please ping me if a response is requested; I won't be watching this page.) --BDD (talk) 19:22, 22 October 2018 (UTC)
  • Comment the mechanics are very simple. Close as Delete and tag the redirect G6 housekeeping noting "deleted at RfD" or similar. An admin working CSDs can just press the button. If some non-Admins closed the non-comtroversal ones the Admins woukd be freed up to close the tougb ones, though there are not a lot of tough RfD discussions. I favor letting non-Admins do everything possible to demonstrate a good trackrecord and this is a good place for someone to show their judgement. Legacypac (talk) 19:33, 22 October 2018 (UTC)
  • Oppose per the excellent essay at User:Tavix/non-admin_closes. All this does is create duplicate work. The scripts that we have make adding all the templates trivial, so a non admin doing that isn't really helping. The best that can be said for this proposal is that it might give qualified individuals the chance to better demonstrate that they are qualified for RfA, but they can do that in other ways. — Insertcleverphrasehere (or here) 19:56, 22 October 2018 (UTC)
  • Oppose. I don't understand the reasoning here at all; there's no backlog to speak of at RFD and hasn't been since the disruptive editor who used to fill it with spurious and time-consuming comments (all of which needed to be reviewed by the closing admin just in case it was one of the rare occasions when he was making a sensible point) has been sitebanned, and needing to have two closers for each discussion would increase the workload, not decrease it. ‑ Iridescent 20:02, 22 October 2018 (UTC)
  • Oppose, noting that (I think) I supported a similar proposal a while ago. It makes sense for TfD and CfD to allow non-admin "delete" closures because templates and categories need to be orphaned/emptied/replaced before they are deleted, and this extra work can be done quicker if non-admins are involved in the process. RfD has no similar issue. feminist (talk) 10:32, 23 October 2018 (UTC)
@Feminist: I have not seen non-admins close CfD discussions as "delete" and XFDCloser doesn't let me close CfD discussions as "delete". Pkbwcgs (talk) 11:38, 25 October 2018 (UTC)
Also, Wikipedia:Categories for discussion/Working is fully protected which makes it impossible for non-admins to close CfD discussions as "delete". Pkbwcgs (talk) 11:47, 25 October 2018 (UTC)
See Wikipedia_talk:Categories_for_discussion/Working#Protection_of_WP:CFD.2FW.2C_take_3. feminist (talk) 13:04, 25 October 2018 (UTC)
@Feminist: Okay. However, XFDCloser doesn't let non-admins close a CfD discussion as "delete". Pkbwcgs (talk) 14:06, 25 October 2018 (UTC)
  • Oppose Unless there is a user right that allows non admins to delete pages it makes no sense to allow non admins to close as delete unless the article is already deleted and the admin forgot or could not close it. Abote2 (talk) 10:29, 25 October 2018 (UTC)
  • Oppose per basically hwat Tavix has already summarized at User:Tavix/non-admin closes. There is already a process to determine whether someone is clueful enough to assess consensus and it's called WP:RFA. In fact, proposals like this carry the risk of deterring people from running for adminship by removing incentives (such as the ability to close XFDs as delete). Regards SoWhy 10:37, 25 October 2018 (UTC)
  • Support per Ivanvector. Also, it's great, actually, to have two users (the closer and the deleter) who believe delete is the policy compliant consensus, further evidencing that is the reasoned course. In addition, it's said that the process suffers from lack of participation, a likely side benefit to this proposal is more policy compliant participation and more experienced participation across the board. (As lack of participation in deletion, often results in a potential closer, not closing, but instead participating). -- Alanscottwalker (talk) 13:22, 25 October 2018 (UTC)
  • Oppose, per Iridescent. Unnecessary, as there is no significant backlog at RFD. Will not decrease the workload on admins but will increase the overall workload for the project and will make things bureaucratically more complicated without a completing need for it. Also will create a mess at DRV if such deletion decisions are ever appealed there since there will be more things to haggle about (the NAC closure itself and the subsequent deletion by an admin). Nsk92 (talk) 14:30, 25 October 2018 (UTC)
  • Oppose as meaningless. Admins are responsible for any use of the tools, so they would still have to reevaluate the discussion to determine if the determination of a "delete" consensus was correct. "But _______ told me to!" isn't an excuse for tool misuse. If a non-admin agrees that something should be deleted, they can of course add a "Delete" argument to the discussion, and realistically, greater participation in deletion discussions would be of far more value. Seraphimblade Talk to me 19:35, 25 October 2018 (UTC)
  • Support - if this proposal was implemented, admins should not be the ones responsible for that deletion - the non-admin closer would be. Admins would only be responsible for preventing clerical errors - establishing that an RfD was closed as delete for the correct redirect. This is easily handled by an automated tool. Hell, we could make it so an automated tool compiled the NAC deletes onto one page, waiting for an admin to drive-by d-batch all of them. Admins will likely know the closer in the vast majority of deletions that would occur under this rule. In response to the argument that anyone who is trustworthy enough to close RFD discussions as delete should simply pick up the mop at RfA, I have only one thing to say: RfA is buh-roken. Tazerdadog (talk) 06:11, 28 October 2018 (UTC)
  • Consensus has determined that only trusted users (aka those who succeeded in RfA) should have access to deletion tools, as with great power comes great responsibility. Therefore, letting non-Admins close as delete and having them delete the pages would be large break of consensus. Kirbanzo (talk) 18:54, 28 October 2018 (UTC)
  • Snow oppose - deletion should always only be carried out by administrators - besides, if it's deleted before the XfD (in this case, RfD) is finished, let some user use the custom close rationale to close it. Kirbanzo (talk) 18:54, 28 October 2018 (UTC)
  • Oppose. Doubles the work as admins are ultimately responsible for their deletions. The problem with RFD and most non-XFD AFD processes is not a lack of willing administrators, but a lack of participation. ---- Patar knight - chat/contributions 07:52, 4 November 2018 (UTC)
  • Oppose deletion is best left to admins and if they have to double-check anyway this is a waste of time Atlantic306 (talk) 16:52, 4 November 2018 (UTC)
  • Support in principle - this discussion is a close parallel to the similar one at TfD awhile back, and contains a lot of the same misunderstandings. NACs at TfD worked well, and IMO the sole condition that would limit using them in a similar way at RfD is the opposition of admins who are regulars there. We had back then the same problem with people who had no idea how the process might work showing up at the RfC to announce that it wouldn't help and would "double the work", never mind that the people actually doing the work at the time knew perfectly well where the pain points were and why this procedural change would reduce them. The difference between the TfD proposal and this one, though, is that it seems that (some of?) the admins involved aren't persuaded (see Amorymeltzer's post above) and they're the ones who actually know what they're talking about when it comes to workload. Opabinia externa (talk) 21:54, 4 November 2018 (UTC)
  • Oppose (1) the is not a huge backlog in AfD and (2) As a reviewer, I have seen many times pages have been checked reviewed and accepted on the main space even the articles have 0 source/homepage or sources associate with the subjects, let alone the articles pass the notability, reliable secondary source with WP:SIGCOV requirements. If reviewer would accept such articles, other editors might not know/might not have the knowledge of what constitute a page to be deleted. To say that, there are some editors and reviewers do have the understand to carry out the task if a non-admin "delete" closures right is provided/permitted. CASSIOPEIA(talk) 04:27, 13 November 2018 (UTC)
    • @CASSIOPEIA: Read the topic before commenting. We are talking about WP:RfD, not WP:AfD so please don't talk about articles for deletion. Pkbwcgs (talk) 16:15, 13 November 2018 (UTC)

Proposal/RFC: Redesigning page-protection padlock icons to be more accessible

Hello everyone. The template doesn't seem to like tables inside of it, but I'm leaving this table here just to clarify the conclusions reached. Thanks, ProgrammingGeek talktome 14:35, 13 November 2018 (UTC)

Type of protection Former design Implemented design
Full protection
Fully protected
A symbolic representation of a padlock, gold in color with a grey shackle. On the body is a white capital letter F.
Template protection
Template-protected
A symbolic representation of a padlock, magenta in color with a grey shackle. On the body is a white capital letter T.
Semi-protection
Silver padlock
A symbolic representation of a padlock, dark grey in color with a grey shackle.
Creation protection
Blue padlock
A symbolic representation of a padlock, light blue in color with a grey shackle. On the body is a white plus sign.
Move protection
Green padlock
A symbolic representation of a padlock, green in color with a grey shackle. On the body is a black right arrow.
Upload protection
Purple padlock
A symbolic representation of a padlock, purple in color with a grey shackle. On the body is a white up arrow above a horizontal line.
Pending changes protection
White padlock
A symbolic representation of a padlock, blue-grey in color with a grey shackle. On the body is a white check mark.
Extended confirmed protection
Dark blue padlock
A symbolic representation of a padlock, medium blue in color with a grey shackle. On the body is a white capital letter E.
Protection by office action
Black padlock
A symbolic representation of a padlock, black in color with a grey shackle. On the body is a white circle.
Cascading protection
Turquoise padlock
A symbolic representation of a padlock, turquoise in color with a grey shackle. On the body is a white symbol representing a chain link.

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Most discussion seems to have stopped, and I think this RfC has reached its natural conclusion.
  • Summary: there is consensus to ☑Y Update the padlocks with grey shackles, without bias towards other discussions as to design specifics
  • Extended rationale:
    • There is an overwhelming majority of editors in favour of the new padlock designs. While sheer force of numbers alone does not determine consensus, this proposal is in a somewhat unique position of "I like this side more" to be a pretty valid rationale.
    • There were a total of 3 editors opposing this proposal.
      • Two stated that they had a preference for the old design.
      • One stated that they would support if the icons were removed. I weighted this opposition less because I felt it was more of an "implementation" issue, which I considered separately.
    • Most people who had an opinion either way stated that they preferred the version with the grey shackles, although I don't really buy (get it?) the assertion that Wikipedia could be mistaken for an ecommerce website without the grey shackles.
    • The question as to whether or not the padlocks improved accessibility was never really settled. As most editors supported the change anyway, this didn't seem to matter too much. As implementation wouldn't have decreased accessibility, the argument itself wasn't too important in the decision to close.
    • Much discussion was had over the specifics over the contents of the icons themselves.
      • Some editors preferred letters over symbols and vice versa. Boing! said Zebedee's suggestion that symbols were easier to learn than colours seemed to be generally agreed upon
      • Feedback was incorporated into the padlocks (viz. the symbols)
      • The discussion did not start with the padlocks that were finally agreed upon. While I think that most editors who supported would be generally happy with the final result, I believe that there should be no bias towards further discussion of specifics
        • Note that this doesn't mean that there should be another discussion - Zebedee's point that requiring another discussion would be needlessly bureaucratic is correct.

Many thanks to all who participated. Kindest regards, ProgrammingGeek talktome 01:23, 13 November 2018 (UTC)


EXAMPLES: Full Protection (Redesign).svg Template Protection (Redesign).svg Semi Protection (Redesign).svg Creation Protection (Redesign).svg Move Protection (Redesign).svg Upload Protection (Redesign).svg Pending Protection (Redesign).svg Extended Confirmed Protection (Redesign).svg Office Protection (Redesign).svg Cascade Protection (Redesign).svg

Should the page protection padlock icons be redesigned? XYZt (talk  |  contribs) – 07:00, 25 October 2018 (UTC)

Screenshot of Wikipedia semi-protected padlock (Sep 2018).png

Background (padlock redesign)

Page-protection padlocks are icons at the top right corner of protected pages. However, the current padlock designs have several flaws, many of which harm people who have visual impairments.

1. The padlocks were not designed for viewing at such a small size.
  • The edges on the icons have a white glow, which makes them appear to blend into the backgruond.
  • The shackle is thin and light, contrasting poorly with the background.
2. Many of the padlocks do not have adequate color contrast.
  • Per WP:COLOR, the contrast of text (or in this case, small icons) with its background should reach at least Web Content Accessibility Guidelines (WCAG) 2.0's AA level. This is because some readers of Wikipedia have visual impairments such as partial or full color blindness.
  • However, current lock icons like pending changes protection (light grey) and create protection (cyan) fails to meet the AA standards.
3. Most users cannot tell the type of protection each lock represents from a glance.
  • There are no visual aids that help people understand what the different padlocks mean.

Proposal (padlock redesign)

Type of protection Current Redesign Grey shackle Dark mode
Full protection
Fully protected
A symbolic representation of a padlock, gold in color. On the body is a white capital letter F.
A symbolic representation of a padlock, gold in color with a grey shackle. On the body is a white capital letter F.
A symbolic representation of a padlock, pink in color. On the body is a black capital letter T.
Template protection
Template-protected
A symbolic representation of a padlock, magenta in color. On the body is a white capital letter T.
A symbolic representation of a padlock, magenta in color with a grey shackle. On the body is a white capital letter T.
A symbolic representation of a padlock, pink in color. On the body is a black capital letter T.
Semi-protection
Silver padlock
A symbolic representation of a padlock, dark grey in color.
A symbolic representation of a padlock, dark grey in color with a grey shackle.
A symbolic representation of a padlock, grey in color.
Creation protection
Blue padlock
A symbolic representation of a padlock, light blue in color. On the body is a white plus sign.
A symbolic representation of a padlock, light blue in color with a grey shackle. On the body is a white plus sign.
A symbolic representation of a padlock, light blue in color. On the body is a black plus sign.
Move protection
Green padlock
A symbolic representation of a padlock, green in color. On the body is a white right arrow.
A symbolic representation of a padlock, green in color with a grey shackle. On the body is a black right arrow.
A symbolic representation of a padlock, green in color. On the body is a black right arrow.
Upload protection
Purple padlock
A symbolic representation of a padlock, purple in color. On the body is a white up arrow above a horizontal line.
A symbolic representation of a padlock, purple in color with a grey shackle. On the body is a white up arrow above a horizontal line.
A symbolic representation of a padlock, light purple in color. On the body is a white up arrow above a horizontal line.
Pending changes protection
White padlock
A symbolic representation of a padlock, blue-grey in color. On the body is a white check mark.
A symbolic representation of a padlock, blue-grey in color with a grey shackle. On the body is a white check mark.
A symbolic representation of a padlock, blue-grey in color. On the body is a black check mark.
Extended confirmed protection
Dark blue padlock
A symbolic representation of a padlock, medium blue in color. On the body is a white capital letter E.
A symbolic representation of a padlock, medium blue in color with a grey shackle. On the body is a white capital letter E.
A symbolic representation of a padlock, medium blue in color. On the body is a black capital letter E.
Protection by office action
Black padlock
A symbolic representation of a padlock, black in color. On the body is a white circle.
A symbolic representation of a padlock, black in color with a grey shackle. On the body is a white circle.
A symbolic representation of a padlock, black in color. On the body is a black circle.
Cascading protection
Turquoise padlock
A symbolic representation of a padlock, turquoise in color. On the body is a white symbol representing a chain link.
A symbolic representation of a padlock, turquoise in color with a grey shackle. On the body is a white symbol representing a chain link.
A symbolic representation of a padlock, turquoise in color. On the body is a black symbol representing a chain link.

This proposal redesigns the current padlock icons with more accessibility and minimalism in mind. Unnecessary elements such as textures and shadows are removed, and all of these redesigned icons have AA-level contrast.

Symbols are embedded in the padlocks to further help in identifying different locks. For example, upload protection now has an upload icon inside the purple padlock, and cascade protection, where pages transcluded onto the protected page are also protected, now has a link icon.

People have noted that these padlocks are similar to the ones used at Wikidata. I wasn't aware of that, but it would be great if the folks there implement the embedded icons too.

Alternative designs (padlock redesign)

@Ahecht: has suggested changing the shackles to grey to make them look more realistic.


Posted by XYZt (talk) 07:00, 25 October 2018 (UTC)

Support (padlock icons)

Support, neutral/unspoken on shackle color (padlock icons)

  1. I like the proposed new icons. They are crisp and mainly easy on the eye, plus it solves the problem that colors alone are no longer helpful since so many new forms of protection have been created. Minor change requests aside, I think generally we can support updating the look based on this proposal and discuss individual icons if needed. Regards SoWhy 10:41, 25 October 2018 (UTC)
  2. I agree; nice work XYZtSpace.--John Cline (talk) 10:53, 25 October 2018 (UTC)
  3. Pending whatever minor tweaks might be needed (and based on my comments in the discussion below), I'm happy to support this as a significant improvement. Boing! said Zebedee (talk) 10:55, 25 October 2018 (UTC)
    Just to add that I don't really have a preference between grey shackles and coloured shackles. Boing! said Zebedee (talk) 16:55, 29 October 2018 (UTC)
  4. Minor tweaks aside, LGTM! ~ Amory (utc) 10:57, 25 October 2018 (UTC)
  5. Strong support, I don't make a big deal of it but this is one of the many Wikipedia things which don't work for me. The symbols mean the fact I don't see the colors is less of a problem. — Frayæ (Talk/Spjall) 11:17, 25 October 2018 (UTC)
  6. Support. They are non-invasive and simple. It also solves the problem of being dependant on colour (i.e. black/white prints/screenshots, colour blindness, etc). Rehman 11:21, 25 October 2018 (UTC)
  7. Support in principle. Colors alone re no longer useful with so many different levels of protection. Some design tweaks based on discussion below may still be warranted though. MarginalCost (talk) 11:27, 25 October 2018 (UTC)
  8. Support per above. SemiHypercube 11:29, 25 October 2018 (UTC)
  9. Good work; support in principle subject to whatever adjustments are deemed necessary. Sandstein 11:32, 25 October 2018 (UTC)
  10. Support. Great effort here. Minor tweaks can be done, but updating these old icons to solve the outlined issues is a solid idea that refreshes an older outdated icon set. -- ferret (talk) 11:33, 25 October 2018 (UTC)
  11. I am strongly supporting this proposal as they are more accessible and more colourful to make it obvious what the level of protection is. Pkbwcgs (talk) 11:57, 25 October 2018 (UTC)
  12. I was uncertain about this at first, but now I think that this is much better than what we currently have. funplussmart (talk) 12:14, 25 October 2018 (UTC)
  13. Support as currently designed, strong support with the changes below made. zchrykng (talk) 14:39, 25 October 2018 (UTC)
  14. No brainer. Clear improvement from what we have now. –Ammarpad (talk) 14:51, 25 October 2018 (UTC)
  15. Clear snowed support. Unanimous so far. Discussion proceeds on tweaks. Alsee (talk) 15:20, 25 October 2018 (UTC)
  16. SUpport Big improvement! --Jayron32 15:59, 25 October 2018 (UTC)
  17. Well thought design change. Best, Barkeep49 (talk) 16:10, 25 October 2018 (UTC)
  18. Support looks nice. feminist (talk) 18:07, 25 October 2018 (UTC)
  19. Support easier on the eyes, less confusion and a good fix for something that needs updating. JC7V-talk 18:12, 25 October 2018 (UTC)
  20. (edit conflict) Strong support on principle. I like Ahect's design below better, but would like to see more options as well. Wugapodes [thɑk] [ˈkan.ˌʧɹɪbz] 19:05, 25 October 2018 (UTC)
  21. Support but there may exist some non-obvious problems with their design. It is impossible to say without a full scale trial. Ruslik_Zero 20:14, 25 October 2018 (UTC)
  22. Support I love the new locks. However I would suggest that semi-protection has 'IP' in the lock (or similar, perhaps S for semi), because a plain gray lock is unclear in meaning on its own. Headbomb {t · c · p · b} 21:07, 25 October 2018 (UTC)
  23. Support - including the meaning of the lock in the image seems obvious. Reywas92Talk 00:05, 26 October 2018 (UTC)
  24. Support minor tweaks notwuthstanding, these are a large improvement. Tazerdadog (talk) 00:23, 26 October 2018 (UTC)
  25. Support - 1. Neutral/apathetic on grey shackles.
    2. Prefer letters on the lock bodies. (For cascade protection, which I have never actually seen in the wild, use the chain link to avoid conflict with create protection.) For the most part, people will determine the type of protection by means other than what appears on the lock body: by the tooltip; by clicking on the icon which should take them to a full description of the protection type (as happens today); and to a lesser extent by color after some experience with the new icons. But, if we must put something on the lock bodies, let it be something that is more readily associated with the protection type. I think the letter M (for example) would be more likely to make people think of move protection than would a right-arrow.
    We're used to using graphic symbols I guess because of the widespread use of that on signs of all kinds. That's done so the signs can be understood by speakers of different languages. This is the English Wikipedia, all users are expected to have a certain level of competence in English, so language independence is not a consideration here and we should think outside that box. ―Mandruss  04:03, 26 October 2018 (UTC)
    As newly created pages are marked with an "N" in edit histories, I think an N could be used for the creation protection icon if desired.--John Cline (talk) 04:25, 26 October 2018 (UTC)
  26. Looks like it improves accessibility for some of our users. Mz7 (talk) 06:47, 26 October 2018 (UTC)
  27. Support - as a small but clear improvement to the encyclopedia. I'm agnostic on the grey shackles. Thanks for your work on this! Ajpolino (talk) 06:49, 26 October 2018 (UTC)
  28. Strong support - I deal with protected pages all the time since I work on edit requests and review pending changes. I am also moderately colorblind. With all of the locks together like in this proposal, I can tell them apart fairly well (though the semi and PC1 locks still look the same color no matter where I see them). With a lock alone at the top of a page, I have no chance. It's habit anytime I see a lock to mouse over it and check the popup. The more accessible versions would be much nicer. I agree that neither set of icons means anything if you don't already know what they mean, but I do know what they mean, and the existing color-coding might as well not exist. Make the shackles any color you want, put any symbol or letter you want on any of the locks - any of the proposals I see here would be a vast improvement for me. ‑‑ElHef (Meep?) 15:21, 26 October 2018 (UTC)
  29. Support I often have to look twice (or hover over it) to be sure about a specific protection icon, especially when just quickly skimming over articles. I am sure GUI experts will be able to fine-tune minor details and tweaks. GermanJoe (talk) 17:48, 26 October 2018 (UTC)
  30. Support - more clarity than the current version. Cabayi (talk) 19:13, 26 October 2018 (UTC)
  31. Support Like the new versions, much more clear and noticeable. Personally I prefer the colored shackles, as I don't really think we need "realism" when the real point is to be as clear as possible. Keeping the shackle color the same as the body would mean we might be able to enlarge the letters/symbols to make them more readable while still having enough color to be identifiable. Gray shackles are merely aesthetic and add no informative value. However, either proposal is an improvement over the original. CThomas3 (talk) 19:28, 26 October 2018 (UTC)
  32. Support these icons make it much more obvious what type of protection is being applied. They are also stand out slightly more, are easier and clearer to look at. --Tom (LT) (talk) 22:38, 26 October 2018 (UTC)
  33. Support These newer icons are an improvement upon accessibility as far as meaning of the different lock-levels, although I too would prefer the person icon to be changed to an "S" as the extended protection and full protection already contains an E and an F. This is English Wikipedia, so having the letters makes sense.  Spintendo  23:33, 26 October 2018 (UTC)
  34. Support. May need some minor changes before implementation, but these are a big step up from the old ones in terms of design and accessibility. TeraTIX 01:27, 27 October 2018 (UTC)
  35. I wish they were 3D... Abelmoschus Esculentus 03:49, 28 October 2018 (UTC)
  36. Excellent job here! This is a good idea. I don't buy the idea that if you don't know what the current ones mean, you won't understand what the redesigned ones mean. I didn't know what the colors meant for years, and I'm quite sure the symbols would have been more distinctive to me long before I finally started to internalize what the colors mean. It probably won't help new users much, but those who've been around for a month or two will have a much better shot of getting this collection of new locks. Kevin (aka L235 · t · c) 09:10, 28 October 2018 (UTC)
  37. I support this but I also think that if the padlocks are redesigned the other topicons like the featured and good article icons should be changed too. 🌸 WeegaweeK^ 🌸 10:49, 28 October 2018 (UTC)
  38. Support These single 2D colour padlocks, with extra information included, are much more clearer. I find the current set of padlocks quite confusing. talk to !dave 15:15, 28 October 2018 (UTC)
  39. Support. Much clearer for all users, not just those with visual impairments. MichaelMaggs (talk) 15:42, 28 October 2018 (UTC)
  40. Support - these redesigned padlocks will make it clearer what protections are in place, due to the fact it would have a symbol that can clarify that. Kirbanzo (talk) 18:42, 28 October 2018 (UTC)
  41. Support - The new padlocks are easier to tell apart and discern, and their iconography is more consistent with other parts of Wikipedia. User:Axisixa [t] [c] 07:16, 29 October 2018 (UTC)
  42. Fine Among other things, the current colors seem to want to signify something (except, who knows what) the new ones are marginally better in that regard (even if it were, 'yes, we really are trying to tell you something with this, not just dress up in colors') -- Alanscottwalker (talk) 12:27, 29 October 2018 (UTC)
  43. Support New icons look way better (current design styles trend toward flatter, cleaner looks, as opposed to the early 2000s gradients on the current protection icons). The colors also are not accessible to people without full color vision, so the icons inside the locks are really helpful. – FenixFeather (talk)(Contribs) 21:21, 29 October 2018 (UTC)
  44. Support I can barely tell the difference between the current pending changes and cascading protection icons. The new icons clearly delineate what they are for. spryde | talk 00:48, 31 October 2018 (UTC)
  45. Support. This improves accessibility without impeding those who don't currently have an issue with the current set, so there are no downsides that I can see. Thryduulf (talk) 13:56, 1 November 2018 (UTC)
  46. Support Nice job, either version; the internal icons are most helpful. Slight preference for grey shackles. --Elmidae (talk · contribs) 10:37, 2 November 2018 (UTC)
  47. Support, with the proviso that Mandruss mentions above that letters are used, not symbols. As is said several times in the oppose section, the whole thing is non-intuitive or non-informative and requires exploration/explanation the first time one comes across it, but letters are slightly easier to remember or work out and, for example, i'm finding it quite difficult right now to tell the difference between the arrow for move protection, that for upload protection, and the plus sign for creation protection. Happy days, LindsayHello 09:36, 4 November 2018 (UTC)
  48. Support. I have the majority human level of color vision, but I've long found the current ones to not be clear enough. I find it impossible to remember what each color means, because I don't see them every day, so I always have to check the tooltip—the current color-coding provides no benefit to me. A little symbol or letter in the lock would make it much easier to remember what icon corresponds to what protection level, so I could tell at a glance. Also, the old ones just look excessively 3-dimensional and skeuomorphic to me. I have no preference for colored or gray shackles—I find that they look equally like shopping bags (or not), and that they look equally distinct from the other colors. I like the symbols on some of the proposed icons, but I'd also be OK with them all being letters. PointyOintment · 03:58, 8 November 2018 (UTC)
  49. Support: These seem more understandable than the old ones. This would improve accessibility, and not just for colour-blind people. Like, I looked at the current ones, and I didn't remember what white was, and then there's all those shades of blue. I don't really like the person icon for semi-protection though. Maybe a padlock slash two would be better. Or a padlock with a slash in the middle. The "semilock" that someone suggested (half dark-grey, half light-grey) might also work. Coloured shackles or grey? Maybe that could depend on the size? – Pretended leer {talk} 21:04, 9 November 2018 (UTC)
  50. Support They look very nice! Easier on the eyes MusikAnimal talk 17:15, 10 November 2018 (UTC)
  51. Support . Kudpung กุดผึ้ง (talk) 03:02, 11 November 2018 (UTC)
  52. Support proposal as a whole but oppose proposed redesigns for some. I don't like how some padlocks are based on the first letter and some others are based on the kind of protection. Either way, it's pretty good and personally if the semi-protection was not just a person placeholder icon. Imo, it should be more contextual or the letter. I'd prefer keeping it like the standard protections (full/semi/PC) being first-letter basis and the other kinds being contextual. The current designs look pretty but lack uniformity. --QEDK () 07:52, 11 November 2018 (UTC)

Support with colored shackles (padlock icons)

Note: This is only the people who explicitly stated their preference to the version with colored shackles.

  1. These look great, and should be easier for all readers to understand. 28bytes (talk) 14:03, 25 October 2018 (UTC) (Adding: I prefer the single-color redesign to the version with the grey shackles, but either one is an improvement.) 28bytes (talk) 01:51, 26 October 2018 (UTC)
  2. I prefer the single-color design over the ones with grey shackles to maximize the colored area. Single-color icons are clearer. feminist (talk) 16:19, 26 October 2018 (UTC)
  3. Support, preferably without grey shackles William Avery (talk) 16:04, 29 October 2018 (UTC)
  4. Absolutely. I prefer the one without gray shackles, since single-colored looks better in my opinion (and probably because I'm used to flat designs), but I'll accept it either way, gray shackles or not. theinstantmatrix (talk) 20:54, 26 October 2018 (UTC)
  5. Support - Although the symbols aren't all intuitive, the colors certainly aren't either, and it may increase accessibility for people with colorblindness or visual impairments. I don't see much value in the grey shackles, as they can hardly be distinguished at the size they will be used, and it's more important for an icon to be recognizable than realistic. Jonathunder (talk) 21:36, 29 October 2018 (UTC)
  6. Absolutely. I prefer the one without gray shackles, since single-colored looks better in my opinion (and probably because I'm used to flat designs), but I'll accept it either way, gray shackles or not. theinstantmatrix (talk) 20:54, 26 October 2018 (UTC)
  7. Support I also support colored shackles, but I also will accept either. CThomas3 (talk) 05:38, 4 November 2018 (UTC)

Support with grey shackles (padlock icons)

Note: This is only the people who explicitly stated their preference to the version with grey shackles.

  1. Minor tweaks notwithstanding, this is a big improvement over the current symbols. Support Grey Shackles as they look better and are just as accessible. — Insertcleverphrasehere (or here) 10:45, 25 October 2018 (UTC)
  2. Conditional support with the gray shackes (as per File:Protection redesign - ahecht.png). They look more like locks and less like shopping bags. Shopping bags are often seen as icons on webpages selling things, and I'd hate to give the impression that Wikipedia is an ecommerce site. --Ahecht (TALK
    PAGE
    ) 18:59, 25 October 2018 (UTC)
  3. Support with grey shackles. The protection padlocks have been long overdue for a clarity upgrade. This fits that bill. —Jeremy v^_^v Bori! 19:30, 25 October 2018 (UTC)
  4. Support with grey shackles. This is a lighter theme that still delivers the basic messages. De728631 (talk) 19:33, 25 October 2018 (UTC)
  5. Support the basic change. The addition of grey shackles would also be good. -sche (talk) 19:47, 25 October 2018 (UTC)
  6. Support' grey version above, which are clearer. There also needs to be an S for semi-protection, and maybe the others should be converted to letters as well since there's only one overlap? ---- Patar knight - chat/contributions 21:00, 25 October 2018 (UTC)
  7. Support with grey shackles. Renata (talk) 00:19, 26 October 2018 (UTC)
  8. Support for grey shackles versions. KCVelaga (talk) 01:16, 26 October 2018 (UTC)
  9. Support with preference for grey shackle versions: if it means that colourblind people will be able to use Wikipedia a bit better, although updating the templates may be a problem. Regards, User:TheDragonFire300. (Contact me | Contributions). This message was left at 02:46, 26 October 2018 (UTC)
  10. Support with grey shackle While the letters won't allow people with no idea of protection to know it instantly, it'll still allow people learning which is which to do it easier (I at-least remember forgetting that the "gold" (actually really brown) padlock was full protection) Galobtter (pingó mió) 08:34, 26 October 2018 (UTC)
  11. I oppose my comment being refactored in this way without any discussion and without having been notified. My original comment in support of redesigning the graphics can be found here. Ivanvector (Talk/Edits) 16:56, 30 October 2018 (UTC)
  12. Support, with some preference for the grey shackle. I very much like the idea of both (a) improving accessibility, and (b) conveying which kind of protection it is. But I also have an alternative suggestion: we really don't need a different color for each one. The identifier inside each padlock accomplishes the distinction between one padlock and another, and many of the colors are not intuitively related to the kind of protection they represent. And personally, I feel like some of the colors look too candy-colored for a serious encyclopedia. I think it would be fine to make all of the new icons black on a white background (as in the office action example, and with a black shackle), and white in dark mode. --Tryptofish (talk) 20:47, 26 October 2018 (UTC)
  13. Support, provided the shackles are grey per others' concerns that the original proposal looked too similar to shopping bags.

    However, I would prefer dropping the letters from the full, template, and extended confirmed protection symbols and the protection by office action symbol. The letters are only understandable by those who would already know what the colour denotes and, with the exception of the office action one, they are all very common types of protection. Additionally, I would have never guessed the O to have been an O; it looks like a combination lock.

    I would also be inclined to drop the person icon from the semi-protection symbol. The icon is also understandable only by those who would already know what the colour denotes. This is in contrast to, e.g., the move protection symbol. Its arrow icon's meaning might not be readily apparent to the average reader, but it would still be most useful to reminding an editor of its meaning given that one doesn't come across move protection too often. The other issue with the semi-protection symbol is that the person icon representing registered users really doesn't help the very common issue of people forgetting that IPs are human too. 142.160.89.97 (talk) 21:44, 26 October 2018 (UTC)

  14. Support with grey shackles Much better, simpler and cleaner than the current ones, the letters seam like they could be helpful to some editors. – BrandonXLF ([email protected]) 02:08, 27 October 2018 (UTC)
  15. Support great improvement. support for grey shackles versions with "O, E , T" same size/height and new "semi-protect of half diagonal light vs dark grey padlock icon. CASSIOPEIA(talk) 09:33, 27 October 2018 (UTC)
  16. Support the grey shackles - the grey handles better convey that the picture represents a lock. Dreamy Jazz 🎷 talk to me | my contributions 19:51, 28 October 2018 (UTC)
  17. Support version with grey shackles Much simpler and more accessible. --Joshualouie711talk 22:01, 28 October 2018 (UTC)
  18. First choice These look great. I've been excited about these ever since I saw the proposed redesign. shoy (reactions) 13:44, 30 October 2018 (UTC)
  19. Support as per my previous comment on the idea lab page. This proposal will be accepted easily since there are only three oppose comments out of the tons of support comments here. Grey shackles would look a lot better in my opinion. 344917661X (talk) 02:00, 26 October 2018 (UTC)
  20. Support the new design makes the locks' function clearer and they don't look like shopping bags. — pythoncoder  (talk | contribs) 18:46, 30 October 2018 (UTC)
  21. I support the icons' implementation, although I would prefer for minor changes to be made first (as below). Jc86035 (talk) 14:04, 25 October 2018 (UTC) Moved to section supporting grey shackles. Jc86035 (talk) 11:26, 2 November 2018 (UTC)
  22. Support - good improvement, thanks for creating them! The gray shackles are clearer that they are padlocks Nosebagbear (talk) 23:08, 2 November 2018 (UTC)
  23. Support with grey shackles. Love the new design, especially with regards to making the protection level clear in a way that isn't just color. (Accessibility is important!) The grey shackles make it more clear that these are padlocks to everyone except those with achromatopsia so we're good on that front. To be honest, I had a knee-jerk dislike of them at first, but I realized it was just because I've been used to the old ones being around for.... what, a decade now? After I read the comments here and really thought about it, I got pretty excited about this! It's a nice, clean, modern redesign. cymru.lass (talkcontribs) 18:36, 5 November 2018 (UTC)

Oppose (padlock icons)

  1. I prefer the current ones and think they look nicer, so I guess I’m opposing, but I also don’t see this as a big deal either way. Also, just as a note, I find both sets of icons equally uninformative unless you already know what they mean, so I’m really not getting the arguments for this on those grounds. Again, don’t think this is a big deal, but this is just a graphic redesign, and it’s not particularly informative to the non-insider reader. TonyBallioni (talk) 19:21, 25 October 2018 (UTC)
    @TonyBallioni: The redesign is more informative because it doesn't solely rely on color. A colorblind user would be able to eventually learn the different icons with the redesign, whereas they might never be able to do so with the older design. – FenixFeather (talk)(Contribs) 21:25, 29 October 2018 (UTC)
    That’s not more informative: they’re equally indecipherable without knowing the key. It is more accessible, but the colourblind person still has to lookup the key. If it was more informative someone who knows nothing about Wikipedia would be able to look at them and tell you what they mean, and that’s still impossible. TonyBallioni (talk) 21:30, 29 October 2018 (UTC)
    It is more informative to a color impaired user, is what I'm saying, in the sense that there is more information where there was none before. It can be more informative to a non-color impaired user as well. For example, I don't always remember what the blue, gold, and gray locks mean and get them mixed up, but the new icons are extremely helpful with reminding me what they are. Therefore, there is actually additional information. Obviously an icon is not going to magically tell you what the icons mean, though I think the non-letter icons are well chosen and generally do line up with usage outside of Wikipedia. – FenixFeather (talk)(Contribs) 21:41, 29 October 2018 (UTC)
    I disagree. I still view them as significantly more ugly with no added value, but I also don’t want to continue arguing over something that I don’t care that much about and that is going to pass, so this will be my final reply in this RfC. TonyBallioni (talk) 21:57, 29 October 2018 (UTC)
  2. I prefer the current ones and think they look nicer - Yeah, me too. I just didn't want to be the first to say it. If you just put the icons in front of me and asked mt to tell you what they meant, assuming I hadn't seen them previously, I'd have no more clue with the new set than the old set. For example, this is my first time encountering the "office protection" padlocks. Never seen them before. The "o" on the new padlock gave me no more information to work out what it meant, than the blank black padlock did. I had to go work out what it was myself – note; I saw this yesterday before the links were placed. Mr rnddude (talk) 05:39, 26 October 2018 (UTC)
  3. The symbols on the padlock make them look... juvenile. Remove them and I would support. Nihlus 15:27, 28 October 2018 (UTC)
    @Nihlus: Juvenile, possibly, but the symbols make it easier to figure out what each is. SemiHypercube 01:19, 29 October 2018 (UTC)
    No. It isn’t. They’re equally as indecipherable unless you already know what they mean: so it’s the exact same as the current situation. This is obviously going to pass, but it’s not an improvement for anyone but admins who are trying to figure out if they need to change the protection level, and only then if they have trouble remembering that gold=full, grey=semi, and blue=ECP. The others are rare enough or obvious enough through the page history (PC), that it doesn’t matter what the design is as no one will remember it anyway. TonyBallioni (talk) 01:26, 29 October 2018 (UTC)
    Isn't the point that the new ones are meant to be easier to see for those with vision impairments? What we personally like or dislike or what admins might prefer is presumably irrelevant, isn't it? Boing! said Zebedee (talk) 07:46, 29 October 2018 (UTC)
    @TonyBallioni:
    Proposed redesign of protection locks under red-green colour blindness.
    8% of males are colour blind, we should be using something other than colour to differentiate the lock symbols. While true that "They’re equally as indecipherable unless you already know what they mean"; once you know what they mean, the new symbols ARE decipherable, while the old symbols may just be indistinguishable from each other due to colour blindness issues. See the comparison image at right which indicates what the padlocks look like to somebody who has red-green colour blindness, the symbols give a way of distinguishing that is independent of colour. — Insertcleverphrasehere (or here) 08:10, 29 October 2018 (UTC)
    I was referencing point 3 of the proposal, which is what I took the “easier to understand” supports to be referencing, not the accessibility issue. I’m still not personally sure it’s worth moving to significantly uglier graphics over, and think there is likely a better way to handle this from an accessibility standpoint (mouseover providing a description or something like that or even just a better design.) TonyBallioni (talk) 12:06, 29 October 2018 (UTC)
    Well, mouseover doesn't work on tablets and phones (I'm reliably told by folks who use such infernal devices). Boing! said Zebedee (talk) 12:19, 29 October 2018 (UTC)
    Another point that's just struck me, while looking at some tiny icons on my Mac, is that computer interface technology in general seems to be moving away from 3D appearances and fuzzy/shaded borders for very small graphics, because it is harder on visual impairments, and is using more symbols that might immediately look cryptic but which can be relatively easily learned. Boing! said Zebedee (talk) 12:27, 29 October 2018 (UTC)
    That's true. Of course, even though I supported I quiet agree with Nihlus' point. And of course, I would prefer the minimalist style that get rid of the symbols and any shading like the ones used on Wikidata. Clear boundaries and distinctive colors.–Ammarpad (talk) 12:41, 29 October 2018 (UTC)
    Yeah, those are fair points. I suppose my (Quixotic) view here is that while you could make a case for a redesign this particular redesign isn’t the one. I’d prefer something with colours that don’t look like a candy shop and where the icons don’t look so bleh. Clearly in the minority on this though, and it’s not that big a deal. TonyBallioni (talk) 12:50, 29 October 2018 (UTC)
    @TonyBallioni: I guess that is a reasonable gripe with the current icons. Given the support section is completely full of various suggestions of different opinions on what the symbols should be (and in the discussion below), I would consider that there is support that the padlocks should change to be more accessible (differentiation other than by colour), but not necessarily that this specific set of lock images is the final draft). Indeed the locks have changed substantially while this conversation has been ongoing. I suggest that the overall !voting be closed as a SNOW support for changing the locks to be more accessible, but that we have a new discussion on what exactly the locks should look like. As is I think that the various designs look very disjointed, some with letters, some with rather arbitrary symbols, etc., and a more focused discussion on various options for what they might look like is advised. — Insertcleverphrasehere (or here) 16:44, 29 October 2018 (UTC)
    Do we really need that much bureaucracy? The various tweaks suggested during the course of the discussion are relatively minor, and there's a strong consensus for something close to what has been suggested. I think there's sufficient consensus to just change them to the most recently tweaked proposed versions, whether that's the grey shackle or the coloured shackle versions - whoever closes can decide where the consensus most closely lies. Then minor tweaks can just be made via the usual editing process, and a new discussion would surely only be needed if there's significant disagreement or if someone wants to suggest a radically different set of icons. Boing! said Zebedee (talk) 16:53, 29 October 2018 (UTC)
    I think a reasonable closer will conclude that we do need that much bureaucracy. ―Mandruss  17:03, 29 October 2018 (UTC)
    I mean, I don’t like these designs and even I agree with Boing! here: just change them and make tweaks as needed. TonyBallioni (talk) 17:06, 29 October 2018 (UTC)
    Presumably making tweaks as needed would require further discussion and consensus. Why not do that now rather than later? The effort is the same, the difference is in the amount of disruption. One change to the icons is better than two. Further, I prefer letters for all, I think my case for that is strong, and I don't think it has received a full hearing because of all the other discussion going on. That's the problem with doing !voting and development concurrently, which is what WP:VPI tries to address with little cooperation from the community. ―Mandruss  17:11, 29 October 2018 (UTC)
    I'm also a fan of letters for all (with the pesky issue that we have two 'C's). While I like the Upload Arrow, and the Move arrow as natural symbology, letters make for the best cohesiveness and identifiability. But trying to discuss in the middle of all this is pretty difficult if not impossible. — Insertcleverphrasehere (or here) 17:56, 29 October 2018 (UTC)

General discussion (padlock icons)

  • @XYZtSpace: Minor nitpicks:
    • The E, T and O letters should have the same height.
    • The arrow of the upload protection icon should be a little taller since it's currently a little difficult to see what it is.
    • I think you should make the images squares (like the originals), since this would make the images easier to resize. You might also want to fit some of the objects to the 20×20 "grid".
    Otherwise, I like the icons and would favour their use. Jc86035 (talk) 08:18, 25 October 2018 (UTC)
    • I'm definitely with you that the character height should be standardized. MarginalCost (talk) 11:38, 25 October 2018 (UTC)
    • Jc86035 Will be changing the viewbox to 20x20. XYZt (talk  |  contribs) – 16:10, 25 October 2018 (UTC)
    • E, F and T now have the same height. I made O slightly larger to compensate for its aliasing. XYZt (talk  |  contribs) – 21:03, 25 October 2018 (UTC)
      • @XYZtSpace: Thanks. I think there are still some issues with the letters, though. The letters should probably have the same stroke width (i.e. the four bars making up the E should be the same width as the two bars forming the T); and the letters probably should be a little narrower – the E and F look a bit stretched out right now. Maybe you could try [width-to-height ratios] 3:4 or 1:1.618. Jc86035 (talk) 18:19, 26 October 2018 (UTC)
  • For the Upload protection one, just have a vertical arrow rather than the line at the bottom (At first glance I thought this was a ± sign). What is the Icon on the cascade protection lock supposed to be? Would it be better to have a 'C' here instead? — Insertcleverphrasehere (or here) 09:02, 25 October 2018 (UTC)
    @Insertcleverphrasehere: It's probably supposed to be a chain (in reference to the protection chain). I agree that it might be clearer to use a "C", or maybe a downward arrow. Jc86035 (talk) 09:17, 25 October 2018 (UTC)
    As it says above, "cascade protection, where pages transcluded onto the protected page are also protected, now has a link icon". Boing! said Zebedee (talk) 09:21, 25 October 2018 (UTC)
    • The chain was clear to me; I like it. MarginalCost (talk) 11:38, 25 October 2018 (UTC)
  • Do the colors meet accessibility requirements when readers invert their displays? (light text on black background)? Why is semi-protection different from all of the rest? Why are there no tool tips? —Trappist the monk (talk) 09:21, 25 October 2018 (UTC)
    I think this is a great idea, with a little refinement as suggested in this discussion. I have added tooltips to the Old/New table. Alt text is still needed. – Jonesey95 (talk) 10:15, 25 October 2018 (UTC)
    I took a shot at alt text.[19]Mandruss  10:54, 25 October 2018 (UTC)
    Judging by my eyes I think the icons should be fine with inverted colors. I left Semi without an embedded symbol because it is the most common protection [citation needed] and most people should be familiar with it. XYZt (talk  |  contribs) – 15:10, 25 October 2018 (UTC)
    Really? I added an inverted background column to the examples table. —Trappist the monk (talk) 15:50, 25 October 2018 (UTC)
    Oh. Thought by "inverted colors" you meant high contrast mode. With black bg only, I think a different set of images will be needed. Either that or implement a white outline that is invisible normally but shows up in dark mode. XYZt (talk  |  contribs) – 17:01, 25 October 2018 (UTC)
  • My first thoughts are that they look a lot clearer and crisper than the old ones. Even without any visual impairment other than age-related long-sightedness, I find them significantly easier to see. Most of symbols on them were not immediately obvious to me, but it's much easier to learn and remember what symbols mean than what colours mean, so I see that as a positive step forward too. Boing! said Zebedee (talk) 09:26, 25 October 2018 (UTC)
  • I agree with Boing! said Zebedee's assessment that learning symbols is easier than colors. This would seem to follow MOS:COLOR's suggestion that color not be the only method used to convey important information. The use of a colored lock symbol seems to pass that requirement—in that the lock is a symbol itself—but because there are different lock levels, the use of a third symbol matched to a legend would be an improvement.  Spintendo  10:15, 25 October 2018 (UTC)
    • Maybe the third symbol (semi-protection) could be a half-filled padlock (indicating the "semi" status)? Regards SoWhy 10:54, 25 October 2018 (UTC)
      • How about the letter "S" to go with the extended comfirmed and template editor symbols? IffyChat -- 11:01, 25 October 2018 (UTC)
      • (edit conflict)Just add an "S". It's already a little odd that the semi is the only one without an icon. I'd actually probably just prefer letters for all of them rather than symbols. We have the added benefit that (if you use O for office), each starts with a unique letter other than Create and Cascade. GMGtalk 11:04, 25 October 2018 (UTC)
        • I also support adding an "S" to semi-protection. MarginalCost (talk) 11:38, 25 October 2018 (UTC)
          • It looks like there is consensus for adding "S". Will add it later. XYZt (talk  |  contribs) – 17:04, 25 October 2018 (UTC)
            • Alternatively, it could be 'IP', which would be a lot clearer to non-insiders. Headbomb {t · c · p · b} 21:12, 25 October 2018 (UTC)
              • Added an account icon. I don't think non-techies will know what an IP is. Semi Protection (Redesign).svg XYZt (talk  |  contribs) – 22:20, 25 October 2018 (UTC)
                • @XYZtSpace: At the small resolution I think the "person" icon looks a bit deceptive – I thought it was a normal keyhole at first. I don't know what would be better, though. Jc86035 (talk) 18:57, 26 October 2018 (UTC)
      • Further along that path, change the slashed circle in the fully protected icon to an 'F'. Similarly, change the move protection arrow to an U+003E > GREATER-THAN SIGN (HTML &#62; · &gt;) or U+232A RIGHT-POINTING ANGLE BRACKET (HTML &#9002; · &rang;) and rotate the selected character 90° ccw for upload protection. Small detail at small rendering size is too hard to decipher. —Trappist the monk (talk) 11:13, 25 October 2018 (UTC)
        • Done for Full Protection though I still think that icons should be used over letters, we just have to find the right ones; will replace arrows with chevrons & rmv upload dash tomorrow. XYZt (talk  |  contribs) – 06:50, 26 October 2018 (UTC)
  • However, the current padlock designs have several flaws, many of which harm people who have visual impairments. Harm? Really? Are you really claiming that those of us who are visually impaired will suffer further degradation should we chance to look upon the old icons? Hyperbole has its uses, I suppose, but not here. —Trappist the monk (talk) 11:05, 25 October 2018 (UTC)
  • I suggest that each symbol should also be accompanied by a mouse-over text explaining what it does. E.g., the "cascade protected icon" should make text appear that explains in one sentence what cascade protection is, and provide a hyperlink to the policy page that explains it. Sandstein 11:34, 25 October 2018 (UTC)
  • Should we consider changing some of these colors while we're at it? Taking a look at a basic color-blind filter, full protection and move protection end up with basically the same color, as do template, pending changes, and cascading protection. Fixing the first set would be higher priority, since those are used more commonly. MarginalCost (talk) 11:38, 25 October 2018 (UTC)
  • This was at WP:VPI for one month before it came here. Where were all these great ideas for improvement then? ―Mandruss  11:44, 25 October 2018 (UTC)
    Some of the suggestions have to do with that the icons have changed a bit from presented at VPI (e.g crossed out circle for full protection padlock, addition of E to extended confirmed padlock). Also VPI has the third the watchers that VPR has. Galobtter (pingó mió)
    Also VPI has the third the watchers that VPR has. Precisely. If the community is not going to use VPI as intended to a much larger degree, we should get rid of it as unjustifiable complexity in the environment. Way off topic, of course. ―Mandruss  11:51, 25 October 2018 (UTC)
    I think the larger influx is probably coming from the page listing at WP:CENT, beyond just VPR watchers. MarginalCost (talk) 13:28, 25 October 2018 (UTC)
    I found this discussion only because I watch Template:Centralized discussion, FWIW. Thanks to Ammarpad for adding it there. – Jonesey95 (talk) 14:21, 25 October 2018 (UTC)
  • XYZtSpace, would you be making the minor design changes, or should others reupload the files if changes are requested? Jc86035 (talk) 14:10, 25 October 2018 (UTC)
    • Jc86035 Others should feel free to make minor tweaks. For major changes please upload them separately so we can easily compare them. XYZt (talk  |  contribs) – 14:49, 25 October 2018 (UTC)
  • Not sure if this is the correct place for this, but would it be possible to add some CSS or JS to make the icon enlarge when hovered over? Just to make it even easier to see what the icon is? zchrykng (talk) 14:40, 25 October 2018 (UTC)
    If you want to know the type of protection, that's the purpose of the tooltip. But if you really want a better look at what's on the front of the padlock, click on it for a larger version. I would oppose adding any size and complexity just to save you that click. ―Mandruss  15:34, 25 October 2018 (UTC)
    If you go to Preferences → Gadgets and check "Navigation popups" under the Browsing header, you will get a considerably larger preview of the icon when you hover on it. I recommend you give that a try.--John Cline (talk) 15:55, 25 October 2018 (UTC)
    John Cline, good to know! Thanks. zchrykng (talk) 17:15, 25 October 2018 (UTC)
  • While I have no specific suggestion for changing colors, a complete overhaul of color scheme would be good if it helps create a more clear and understandable structure.
    It might be good to go with all letters or all symbols, instead of a mix.
    Perhaps make semi-protect / extended-protect / full-protect into a clear and visible sequence of some sort.
    The full protect symbol makes sense, but the color feels particularly confusing.
    T was clear for Template, but I imagine { instead.
    For semi I imagine thin diagonal white lines, making it more transparent or "semi".
    Create and Move were easy to guess.
    The upload symbol was confusing. A plain up arrow would be better.
    The pending symbol makes sense, although I was stumped when I tried to guess.
    If we want a symbol for office, maybe an ! or big X.
    Cascade wasn't clear at first. It makes sense when explained. Down arrow was an interesting suggestion and it extends the pattern of arrow symbols. Alsee (talk) 16:28, 25 October 2018 (UTC)
    • I've tried the T -> {{ idea before in VPI. The gist of it is that it is too small to be distinguishable on the padlock XYZt (talk  |  contribs) – 02:33, 26 October 2018 (UTC)
      • Right, I suggested a single { for exactly that reason. I think(?) that would fit. Alsee (talk) 08:20, 26 October 2018 (UTC)
        • The problem is with the limited height, not width. Curly brackets are thin enough that the width of three of them combined can fit in the padlock width. However, the limited height of the padlock and the tallness of the brackets means the brackets have to be squashed down, which makes them resemble less like brackets. XYZt (talk  |  contribs) – 18:22, 26 October 2018 (UTC)
    • Color: I kinda miss the red fully protected icon. That red color was declarative; the fuzzy brass colored lock, meh, not so much. I have suggested elsewhere in this discussion that move and upload protection might be marked with '›' or '>' (perhaps also consider U+3009 RIGHT ANGLE BRACKET (HTML &#12297;)). We could extend that idea to the cascade lock by doing pairs of those characters: '››', '>>', or '〉〉'. Alternately, there are these: U+300B RIGHT DOUBLE ANGLE BRACKET (HTML &#12299;) and U+00BB » RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK (HTML &#187; · &raquo;).—Trappist the monk (talk) 11:29, 26 October 2018 (UTC)
  • Thanks for the work. I do think @Michael J:'s suggested alteration for Semi-Protect (on right) is a good one - what do people think Nosebagbear (talk) 16:43, 25 October 2018 (UTC)
    Semilock
  • imo its style is too different from the other icons to be implemented alongside them. XYZt (talk  |  contribs) – 18:15, 26 October 2018 (UTC)
Locks with gray shackles look less like shopping bags
  • It was mentioned briefly above, but I vastly prefer the versions with grey shackles, as they look more like locks and less like shopping bags. Shopping bags are often seen as icons on webpages selling things, and I'd hate to give the impression that Wikipedia is an ecommerce site. --Ahecht (TALK
    PAGE
    ) 16:47, 25 October 2018 (UTC)
  • File:Protection redesign - ahecht.png is an improvement per above. — Godsy (TALKCONT) 17:53, 25 October 2018 (UTC)
    The new version has a problem in that the top padlock and the third padlock down now look exactly the same. Why does the top padlock no longer have a symbol? — Frayæ (Talk/Spjall) 17:58, 25 October 2018 (UTC)
    @Frayae: Ahecht made the grey shackle designs before I added the Full Protection symbol. XYZt (talk  |  contribs) – 18:40, 25 October 2018 (UTC)
    As XYZt said, those were based on an older version. They should be updated now. --Ahecht (TALK
    PAGE
    ) 18:57, 25 October 2018 (UTC)
    Gray bars look great! ~ Amory (utc) 18:54, 25 October 2018 (UTC)
  • Looking at the proposed icons, they do not appear to render uniformly; Full, Pending, Office, and Cascade look bigger than the others, I tweaked the sizes in the table marked "Alt1", and believe they are a bit better there.--John Cline (talk) 19:02, 25 October 2018 (UTC)
    • @John Cline: I was changing the size of the padlocks based on a suggestion above, which is temporarily making the sizes inconsistent. they are fixed now and I removed your table.
  • As green symbolizes an action is possible, and the point of a protection icon is to restrict actions, should the green move-protection padlock be changed to orange? XYZt (talk  |  contribs) – 23:41, 25 October 2018 (UTC)
    Support as pending changes protection level 2 is depracated (it used the orange lock. For more info read the link) SemiHypercube 01:15, 26 October 2018 (UTC)
    Oppose I don't think it matters. Green has always been the color of move protection. funplussmart (talk) 11:55, 26 October 2018 (UTC)
    @SemiHypercube:, I added the orangelock to the pc2 section of WP:PP, for those curious about what icon it used. Did WP:SUPERPROTECT have a padlock when it was thing? funplussmart (talk) 02:47, 28 October 2018 (UTC)
    @Funplussmart: Superprotect did not use a padlock, since it was only used on one page (not on the English Wikipedia, it was on the German Wikipedia in this edit) and that was the common.js page, which transcluding templates (like a protection template) would either be impossible or probably a very bad idea. SemiHypercube 01:15, 29 October 2018 (UTC)
  • @XYZtSpace: I think the no symbol looked better than the "F". I think the no symbol would at least be a bit clearer to a new user who happens upon it, since "F" on its own doesn't really impart the same "no entry" meaning. Jc86035 (talk) 17:19, 26 October 2018 (UTC)
  • The point of the symbols is to differentiate the protection levels when the colors can't. Though I think I might change it back to the 🚫 icon, but that doesn't look very clear when scaled down. XYZt (talk  |  contribs) – 18:15, 26 October 2018 (UTC)
  • @XYZtSpace: You probably have so many pings right now, but do you think you could also upload an SVG version of my suggestion for the office-protected padlock with the WMF logo on it? SemiHypercube 17:33, 26 October 2018 (UTC)
Semi tesseract suggestion.png
  • For others reading my suggestion, see the picture at right for an example what it might look like. SemiHypercube 23:27, 26 October 2018 (UTC)
  • Nitpick - the O padlock looks like it's a combination dial. Perhaps a more elongated O would work better? Cabayi (talk) 19:11, 26 October 2018 (UTC)
    • Or possibly put the "no" symbol on the office lock, since office protection tends to be the "thou shalt not touch" variety. ‑‑ElHef (Meep?) 20:52, 26 October 2018 (UTC)
  • How about the cascading one being a couple of white horizontal lines, as in e.g. "cascading blinds"? wumbolo ^^^ 13:29, 27 October 2018 (UTC)
  • The extended-confirmed padlock is too similar to Israel's flag to be a neutral representation of PI 30/500. w