This page uses content from Wikipedia and is licensed under CC BY-SA.

Wikipedia:Village pump (all)

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

Readers first?

WP:5P1 used to read Wikipedia is an encyclopedia written for the benefit of its readers [1] and I've continued to believe that but now note that it currently doesn't mention written for the benefit of its readers.

Was this an intentional change of policy?

I raise it here because it seems to me to be a major change to policy. Happy to take it to another page if that is more appropriate. But I'd like us to consider putting it back somewhere, perhaps not at 5P but somewhere! Or is it still there and I'm missing it?

I've done a little research, see here, following a post at an RM which asked whether readers or editors were our primary focus, and which caught me a bit by surprise.

It's been discussed before I see, again there are several links in my sandbox, but I can't see evidence of consensus to change this principle. Again, am I missing it? TIA Andrewa (talk) 20:43, 25 August 2018 (UTC)

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

  • Support restoring this text. Might seem obvious but then again, sometimes I wonder. It does seem like a reasonable thing to say out loud instead of imply. NewsAndEventsGuy (talk) 21:17, 25 August 2018 (UTC)
  • Oppose - Is there evidence that a significant number of editors think the encyclopedia's mission is to serve editors? If not, these would be more wasted words added to the ever-growing heap of wasted words.
    Editor1: "Per WP:5P1, Wikipedia's mission is to serve readers."
    Editor2: "I'm serving readers."
    Editor1: "No you're not, because [...]"
    Editor2: "Yes I am, because [...]"
    Repeat until one editor is tired. The preceding was not a productive discussion.
    Except for rank vandals, I've never seen an editor who didn't believe they were benefiting readers. Rank vandals don't read the pillars, and we don't need pillar language to deal with them. ―Mandruss  23:49, 25 August 2018 (UTC)
Good point, asking "how will it make a difference in practice?" Guess I don't have a good answer to that. How about you, @Andrewa:? Can you explain how it would make a difference in practice? NewsAndEventsGuy (talk) 23:55, 25 August 2018 (UTC)
I do so below. Andrewa (talk) 06:28, 27 August 2018 (UTC)
  • Oppose - 5P1 is about what Wikipedia is, or more specifically how the community understands what it means to be an encyclopedia. It's not a mission statement; it's a description of content/genre. That it's supposed to be for readers can be tacked on to any of the pillars ("if rules prevent you from improving Wikipedia for its readers, ignore all rules"; "we strive to serve readers by writing in an impartial tone"...). I also don't necessarily agree. Wikipedia is for everybody, regardless of whether they read it. It's also for people who want to reuse its content, for example. What's important for 5P1 is that it's an encyclopedia. That doesn't mean it's not for readers -- just that that adds a different dimension that's both unnecessary and potentially distracting. — Rhododendrites talk \\ 01:47, 26 August 2018 (UTC)
  • Oppose - While I agree it sounds like some nice, grandiose sentiment, it's really pretty meaningless. Like, it doesn't need to be said that Wikipedia was made "to benefit its readers". That's kind of implied with any encyclopedia, any educational material, or arguably any written work. There's nothing special about the fact that it's there to benefit readers. Is there a conceivable reality in which volunteers from all over the world collaborate to create a vast, free compendium of human knowledge without the intention of "benefiting readers"? It's kind of silly if you think about it. Spelling it out in 5P1 just sounds self-congratulatory and arrogant. Swarm 07:41, 26 August 2018 (UTC)
  • Support and yet, just to say Wikipedia is an encyclopedia written for the benefit of its readers does have the markings of "WTF? over". Maybe we should consider something like, Our encyclopedia combines many features of general and specialized encyclopedias, almanacs, and gazetteers. It is written by readers for the benefit of readers. Wikipedia is not a... (in order to express its primary distinction)?  Paine Ellsworth  put'r there  16:13, 26 August 2018 (UTC)
  • Just to clarify, what I support is the need to be "up front" about readers writing for readers. And I've adjusted 5P1 in the following manner:
Encyclopedia icon.svg
Wikipedia is an encyclopedia
This encyclopedia was created and designed to be written by readers for the benefit of readers. It combines many features of general and specialized encyclopedias, almanacs, and gazetteers. There are several things that Wikipedia is not. Wikipedia is constructed so that future generations can also benefit from the ever-increasing sum of all knowledge found on these pages.
Thank you! for your time.  Paine Ellsworth  put'r there  13:28, 28 August 2018 (UTC)
@Paine Ellsworth: Why did you remove the list of things that Wikipedia is not? I think that is an equally important feature of this pillar (even since the 2008 revision that the original proposer cites) that your revision is deprioritizing. Mz7 (talk) 20:00, 29 August 2018 (UTC)
To Mz7: because it's pillar one, and I can't see starting out so negatively, "WP is not this and WP is not that" not not not. It's still there in the link to What WP is not. Guess I think the first pillar should begin on a more positive note.  Paine Ellsworth  put'r there  04:42, 30 August 2018 (UTC)
  • Support I think this needs to be forefront, as there are editors that, while not necessarily OWNing articles, tend to put how they feel a topic should be presented over clarity of the readers. The infobox wars are one area that I think suffers from, where the omission of infoboxes from articles are to make the article pleasing to editors but without considering readership. --Masem (t) 16:23, 26 August 2018 (UTC)
  • Supplemental In followup to my "support" notvote above I just ran across a good quote in The "Elements of Editing: A Modern Guide for Editors and Journalists" by Athur Plotnik (1982 ed) ... An editor edits above all to communicate to readers, and least of all to address the sensibilities of editorial colleagues. (pg 2) I often think a lot of the drama at Wikipedia is for recreational drama over what are frequently arbitrary issues. I wish that didn't happen. On the other hand, I still don't see how adding the text (which I support for feel-good reasons) will really make a difference in practice. NewsAndEventsGuy (talk) 19:55, 26 August 2018 (UTC)
  • Support if only from conservatism - we ought not to be messing with this fundamental page without a very clear consensus and wide discussion. This is also an important principle which should be upfront somewhere. Johnbod (talk) 01:31, 27 August 2018 (UTC)
  • Support (disclosure: I of course started this section and suggested restoring the clause, this is just to make it explicit). This section was started specifically because a contributor asked Does Wikipedia exist for the benefit of its readers or for the benefit of its editors? [2] which took me by surprise, and then I found out that they were right, our policies didn't say either way. The answer to me is commonsense, and some seem to agree, and think that it's unnecessary to spell it out. But it would obviously help at least one editor if we did spell it out, and I cannot see any downside to spelling it out, nor any previous consensus to make this change to the first pillar, and it seems unlikely that any such consensus could be achieved now. So the clause should be restored, for several reasons. Andrewa (talk) 06:28, 27 August 2018 (UTC)
  • ? That discussion is about disambiguation pages. The most relevant guideline is MOS:DAB, which starts with: "Disambiguation pages (abbreviated often as dab pages or simply DAB or DABs) are non-article pages designed to help a reader find the right Wikipedia article when different topics could be referred to by the same search term, as described in the guidelines on the Wikipedia:Disambiguation project page. In other words, disambiguation pages help readers find the particular article they want when there is topic ambiguity." -- In its first two sentences, that dab pages are for readers is stated twice. — Rhododendrites talk \\ 14:22, 27 August 2018 (UTC)
Heh, speaking purely from wholesome naïveté, the ideal answer to that question is that Wikipedia's editors are its readers. In other words, all readers of Wikipedia are nominally also its editors, because all readers have the technical ability to edit most articles. This is the core principle of Wikipedia really: an encyclopedia written by the people who use it. This is somewhat codified in that third pillar. Obviously, there are many more distinctions made in practice: between active editors, once-a-month editors, blocked editors, readers that don't know how to edit, readers that know how to edit but aren't interested. In short: ideally, Wikipedia exists for everyone. Mz7 (talk) 06:21, 28 August 2018 (UTC)
That discussion is about disambiguation pages. Agree. But the question raised there applies to all of Wikipedia. The main namespace, containing the articles, DABs and some redirects, is the encyclopedia proper. But all other pages, including project pages, talk pages, even use pages and the other weirder namespaces, exist to support the presentation and development of the main namespace. In this sense, all of Wikipedia exists for its readers. Andrewa (talk) 06:29, 28 August 2018 (UTC)
  • Oppose I'm not saying it shouldn't be written for its readers, just that it is of too little value to say in a very valuable space giving the major principles for editing Wikipedia. The case needs to be made that this is a principle that if new editors are not made aware of they may edit in way that is significantly worse. Dmcq (talk) 19:50, 27 August 2018 (UTC)
  • Support in part, oppose in part. I wouldn't be opposed to including something to this effect in the description below the header "Wikipedia is an encyclopedia", but I don't think it should be added to the header itself. Back in 2008, it wasn't bolded either. I fear that if it's added to the header it may distract a little from highlighting the importance of the WP:NOT policy, which is also what the first pillar is about. Mz7 (talk) 05:51, 28 August 2018 (UTC)
    • My original suggestion was in fact that it mightn't be added to WP:5P at all, just somewhere. Andrewa (talk) 06:32, 28 August 2018 (UTC)
  • Support. WP:5P1 Wikipedia is an encyclopedia. What is an encyclopedia?

"Indeed, the purpose of an encyclopedia is to collect knowledge disseminated around the globe; to set forth its general system to the men with whom we live, and transmit it to those who will come after us, so that the work of preceding centuries will not become useless to the centuries to come; and so that our offspring, becoming better instructed, will at the same time become more virtuous and happy, and that we should not die without having rendered a service to the human race in the future years to come."
Diderot Reference: Denis Diderot and Jean le Rond d'Alembert Encyclopédie. University of Michigan Library:Scholarly Publishing Office and DLXS. Retrieved on: November 17, 2007

An inherent part of purpose of an encyclopedia is to transmit the knowledge widely, to all people, including to people suffering from systematic bias. Merely to mention systematic biases causes people to think on it, and it leads to better decisions on helping the product being available to the widest audience. Wikipedia is not a repository, it is a living, growing document with purpose. Imagine a world in which every single person on the planet is given free access to the sum of all human knowledge. That's what we're doing.
Three essays that immediately come to mind on belonging in WP:5P1 are Wikipedia:Reader, Wikipedia:Readers first, & Wikipedia:Product, process, policy. The third does not include mention of "readers", but it does expound on "improving our encyclopedia", which begs the question "for who". --SmokeyJoe (talk) 06:17, 28 August 2018 (UTC)
Is it worth mentioning that re: the Encyclopedie quote, that encyclopedia was a for-profit venture, with constant tensions about changing text to please the church, the state, publishers, editors, writers, etc. with all sorts of financial, philosophical, religious, anti-religious, political, radical, professional, and personal interests wrapped up in its production? :) (this isn't a real attempt at rebuttal btw, but here is a fun example of Diderot writing about his resentment about having to include material his publishers insisted readers wanted). — Rhododendrites talk \\ 15:28, 28 August 2018 (UTC)
Yes, it's always worth mentioning such things; might even be therapeutic both for the mentioner and the mentionees. There were a lot of things that I don't think anybody could have predicted. This was a crazy new endeavor after all, with surprises all around. And here we are, still trying to improve even our pillars. Seems to me that the phrase, "just keeps gettin' better and better" sounds less and less sarcastic over time. Wikipedia rocks!  Paine Ellsworth  put'r there  18:07, 28 August 2018 (UTC)
  • Support Everything should circle back to readers. Sometimes it seems like we blindly follow a policy or guideline, or edit based on writers' needs.—Bagumba (talk) 09:37, 30 August 2018 (UTC)
  • Support restoring. It helps to set the tone and focus, even if not strictly necessary. Peter coxhead (talk) 10:35, 30 August 2018 (UTC)
  • Oppose, out of fear that someone will point to that clause to justify something that would arguably help readers but isn't encyclopedic. Also doesn't really communicate anything, so it just adds text. One of the things that's great about the pillars as they are is that they are concise and easily readable. Compassionate727 (T·C) 13:35, 31 August 2018 (UTC)
  • Oppose because the language can be used to argue that every other policy should be ignored if the material in dispute is "beneficial to the reader". Indeed, the argument made by the IP editor, below, may at least imply this very argument. That is, of course, a specious argument, but we don't need to fuel it. - TransporterMan (TALK) 02:53, 14 September 2018 (UTC)
  • Support Some editors seem to forget entirely about the audience. I would use this phrase instead: "primarily for the benefit of laypeople." When I look at some of the articles on math and physics, I feel like some of our articles are either written for Ph.D. students or for the author to show off their skill at writing something only experts can decipher and appreciate. It reminds me of some incomprehensible user manuals. --David Tornheim (talk) 03:26, 5 October 2018 (UTC)
  • Support I do wikiwork because I got annoyed at the lack of a good description for a few things i'm interested in (Not much, by the way). Besides, I don't see a reason not to. MoonyTheDwarf (BN) (talk) 19:02, 10 October 2018 (UTC)
  • Oppose This page isn't really that useful. It's not public facing as far as I can tell, and is pretty much something you'll read if you're already interested in editing. We don't really poll our readers on anything (not that I think polls would be a great idea in the vast majority of cases), but already "reader first" mentality is leading to flawed arguments of "I'm an average reader and this is my opinion" on this RFC. People who edit Wikipedia are already a very small slice of the population and not a representative sample, so it's inaccurate to claim that one is an "average reader". So, saying Wikipedia is for the readers on a page directed at editors is functionally useless but only serves to fuel arguments that are aimed at avoiding policy and instead appealing to some imagined generic reader. Maybe if this were a primarily reader facing page it would make sense to make readers feel appreciated but as it is, it's not useful. – FenixFeather (talk)(Contribs) 00:13, 11 October 2018 (UTC)
  • Strong support. Anything that reminds editors that readers are important is good. If anyone wants to get into tiny wording details, it gets even better: despite the title of this discussion, the proposed wording doesn't say "readers first", but "for the benefit of readers". It is legitimate, correct, and not redundant. --Amir E. Aharoni (talk) 07:10, 16 October 2018 (UTC)

I would like to hear more

There are two early oppose !votes above.

Both seem to agree that the principle is sound and important, but think it unnecessary or even inappropriate to spell it out, and that in practice it makes no difference to do so. I hope I have answered that.

We seem agreed that the change was made without consensus support.

But I have been in consensus-based decision making processes where the motion was put and there were literally hundreds against a handful, so the chairperson said let's just hear from the handful and they convinced us. In that spirit, Mandruss and Rhododendrites, I'd like to hear more.

And the other person who might contribute something relevant is Robkelk, who (rightly as it turned out) asked the question that so startled me. So pinging him too. Andrewa (talk) 06:54, 27 August 2018 (UTC)

Yikes.
It looks like you're trying to spin the opposition in a way that seems to support this proposal... and you're doing it at multiple venues (that one of them is Talk:Fan (machine) makes me think this is more about that argument than 5P). I explicitly said that Wikipedia is for everybody. It's for people reading it, listening to it, writing it, looking at its pictures and graphs, republishing it, referencing it, analyzing it, etc. I suppose that can all be boiled down to "readers" but let's not turn this into a self-evident question of "are readers important?" Bringing it back to that discussion this seems to be about, at the fan article, "think of the readers" shouldn't be a trump card in an argument, but it's relevant to the disambiguation process. The way to propose a change that would make dab pages more useful to all users is to start a discussion about our disambiguation process, not to add something to 5P to use as basis for that dab argument (apologies if I'm misreading that thread).
I hope I have answered that. - Where?
We seem agreed that the change was made without consensus support. - ??? No. Someone added the text, legitimately, based on a very small discussion on the talk page. Someone else removed it a year later, legitimately. Nobody contested it. Then it sat there on one of the most visible projectspace pages for ten years. WP:IMPLICITCONSENSUS. I.e. the evidence that there was consensus for it is that it sat uncontested for ten years. — Rhododendrites talk \\ 13:53, 27 August 2018 (UTC)
The regrettable shortcut "WP:IMPLICITCONSENSUS" carries an unfortunate vibe of weight that runs contrary to the spirit of consensus. This shortcut is only a few months old and I objected at the time (but with very little input from others and I didn't feel like fighting). So here we have an authoritative table-pounding using this shortcut as the gavel. Well, look deeper. The shortcut points to a section in our WP:CONSENSUS policy. In that section is another link which points to our explanatory supplement WP:Silence and consensus. There we see a section titled "Silence is the weakest form of consensus". In the same vein, since Aug 2011 our essay WP:Arguments to avoid in discussions (rated mid-importance) rejects WP:CONTENTAGE as a reason for much of anything. Finally, assuming there were ever any consensus about any of this, we come full circle to our consensus policy, which provides WP:Consensus can change. In short, the mere passage of time can not turn "I just don't like" reasoning into slam-dunk reasoning. In even fewer words maybe we need a shortcut that says WP:Time means squat. NewsAndEventsGuy (talk) 14:22, 27 August 2018 (UTC)
Sidestepping your opinions about implicit consensus, which we can talk about elsewhere if you want, the point is that Andrewa argued the small discussion that led to the text being added in the first place should carry such a forceful consensus that when someone changed it a year later it was (a) illegitimate and (b) doesn't matter that nobody contested the change -- not then, despite having hundreds of people watching it, and not in the ten years since then. Consensus can change, absolutely, so I wouldn't argue that what has stood for ten years can't be changed, either, but the idea that what has been there for ten years should be undone because a handful of people had a talk page discussion the year before but didn't contest the change is absurd. — Rhododendrites talk \\ 14:32, 27 August 2018 (UTC)
I don't mean to twist your words but I think I agree. To be specific, I think that what happened in the long ago means squat and the important thing is what people think today. If that's what you said, then yes I agree. If that's not what you said please elaborate a little where I got it wrong. NewsAndEventsGuy (talk) 14:40, 27 August 2018 (UTC)
Close enough. :) I would personally grant a bit more weight to what managed to stick on a highly watched page for a decade, but neither of them need to dictate what happens now (i.e. it's less that I want to preserve some action from ten years ago and more that I disagree with Andrewa's notion that a change "made without consensus support" ten years ago is relevant to this discussion). — Rhododendrites talk \\ 14:57, 27 August 2018 (UTC)
Agree that neither of them need to dictate what happens now and the important thing is what people think today.
The lack of consensus support at the time of the change would be relevant only if we cannot come to a consensus decision on the wording now. Far better not to go there. But in that unfortunate scenario, it becomes relevant, unfortunately. Andrewa (talk) 20:10, 27 August 2018 (UTC)
I knew that question was going to kick off debate, even when I asked it. I've seen cases at other wikis where the act of creating and naming and filling in pages in just the right way, even when particular requirements would never be noticed by most people who use the wiki, got in the way of collecting and sharing information. The former is what I was thinking about when I asked whether the wiki existed for the editors, and the latter is what I was thinking about when I asked whether the wiki was for the benefit of the readers. That said and out of the way, we come to this proposal. If it needs to be said so that we focus on everybody who uses Wikipedia instead of focusing on those of us who edit here, then let's say it... but I hope that it wouldn't need to be said. Thus, I'll abstain on voting here. --Rob Kelk 00:09, 28 August 2018 (UTC)
As it turns out, you were probably wiser than I. Apologies. Andrewa (talk) 06:15, 28 August 2018 (UTC)

The principle

We seem to have answered part of the question. Nobody seems to doubt the truth or validity of the point that Wikipedia is... written for the benefit of its readers (my emphasis). Some see it as good to say so explicitly, while others object strongly to doing so, but nobody questions the principle itself.

So getting back to the original question, is this a fair comment? Andrewa (talk) 11:18, 27 August 2018 (UTC)

See above. — Rhododendrites talk \\ 14:14, 27 August 2018 (UTC)
OK... but what exactly is wrong with it? Andrewa (talk) 20:04, 27 August 2018 (UTC)
The supports and opposes are to restoring the text, following the first respondent’s lead. If you are not proposing the text be restored, and are simply trying to clarify whether “Wikipedia is written for its readers”, then it would be fair to say both the supporters and opposers agree that it, of course, is. It would be completely inappropriate to change the wording based on this though, because you cannot override the opposers just because you want to. You would need to make this an RfC with wide community advertisement to make changes to the text, given the fact that this is a controversial proposal. Swarm 20:10, 27 August 2018 (UTC)
Yes, there is a poll above (not initiated by me) into restoring the text.
Initially I was certainly asking whether we should restore the text, but also whether this had been a deliberate policy decision. And that seems to have been answered in the negative, there was no intention to change the policy, just to remove unnecessary clarification, and there is still no intention to change it. The only disagreement is as to how the policy should be expressed.
So far, several editors have supported the proposed change, and two have opposed. But both of these appear to me to support the principle. I really do not see what the fuss is all about.
I'm certainly not trying to fork any discussion. I'm trying to centralise discussion here on these matters, on which a heads-up was posted (again not by me but I think it was a good thing and said so) at WT:5P#Wikipedia is an encyclopedia written for the benefit of its readers. Both issues are obviously of relevance to that talk page. I have replied there to comments made there, but if anything, others are forking the discussion, not me.
A formal close to the poll would be good IMO. Where we go from there depends largely on the close. Andrewa (talk) 20:49, 27 August 2018 (UTC)
The repeated misrepresentation of this thread is getting concerning. ... and two (yourself included) have opposed -- at the time you wrote that four users had opposed, and five (yourself included) had supported. — Rhododendrites talk \\ 20:51, 27 August 2018 (UTC)
An honest mistake which I tried to correct but have had several ECs... one of which at least was probably one of the oppose !votes.
Please read WP:AGF and consider adopting it. Andrewa (talk) 20:56, 27 August 2018 (UTC)
Fair enough. I suppose that was a bit harsh. Struck the first part with apologies. — Rhododendrites talk \\ 21:26, 27 August 2018 (UTC)

───────────────────────── Rock in pond.... I might switch to "oppose". Here's why.... let us assume for sake of argument that everyone agrees (at least on paper) that Wikipedia is for the reader's benefit. Now suppose we say that on paper. What would be the impact of such a decision? Mandruss (talk · contribs) has already contemplated a new (sad) line of argument in the ephemeral debates we have to deal with. The only reason I first voiced support is the wishful hope that saying this would magically reduce some of the questionable behaviors from longtime users. But the discussion and further reflection leaves me thinking that there isn't really anything constructive to be gained here. The question arose at a great example where two options were being considered for an article title, "Mechanical fan" versus "Fan (Mechanical)" and somehow the differing views in the talk thread were boiled down to two supposedly conflicting policty statements, and supposedly the determining factor would be whether Wikipedia is (or is not) "For the benefit of readers" (Same diff that Andrew posted above) I am not qualified to offer an opinion if the logic is sound, because I am an involved editor championing a third option ("Fan (air circulation)"). But I'm not impressed that the partipants arrived at a point of trying to reconcile their reading of policy on this question. This is the sort of unexpected thing that could happen if this text is restored. "First do no harm". Before we risk inviting new lines of possibly lame argument by restoring/adding this text, what exactly do we gain? How will it be used to make the project better ? In my mind, this is how the question should be decided. Before I bother with the clerical task of switching to oppose, I thought I'd float the qustion a second time, since your first attempted answer "it would help at least one editor" wasn't really an explanation . NewsAndEventsGuy (talk) 23:13, 27 August 2018 (UTC) PS At the source venue, if the two policies being debated are indeed in conflict (on which I'm dubious but neutral) then the answer is not messing with a third policy. Instead the two supposedly conflicitng ones should be refined so they are in harmony. NewsAndEventsGuy (talk) 23:25, 27 August 2018 (UTC)

It would help at least one editor was my whole reason for making the suggestion that we consider putting it back somewhere, perhaps not at 5P but somewhere (please note that someone else then decided to make it a poll). Actually it's two editors... I used to refer to this policy a great deal. Now I guess I'll need to appeal to commonsense instead, which doesn't seem an improvement. But for every user who says they have the problem, nine others know they have it and don't say. For every user who knows they have it, nine others have it and don't know. On the other hand, there seems no harm in making it explicit. It's agreed that Wikipedia is for readers, the policy used to say that, and the case for removing it seems incomprehensible to me... mere speculation as to what damage it might cause, with no evidence that it did cause any damage at all in the years it was policy, but strong feelings that the damage would be there.
But really, it's not worth this angst. I still support making it explicit (again), but if commonsense it must be, commonsense it will be. I fear that will lead to more fruitless discussion not less, but nothing we can't deal with. Maybe we just need to do so. Eh bien, continuons. Andrewa (talk) 06:07, 28 August 2018 (UTC)
A valiant effort to make a change for good, but IMHO I think "fruitless discussion" would be unchanged either way. Some folks just like to argue about nothing. And to emphasize the #1 thing I got out of this, in the source issue at Talk:Mechanical fan if the two policies claimed to be in conflict are really in conflict, the answer lays in refining those policies so they march in harmony. NewsAndEventsGuy (talk) 11:50, 28 August 2018 (UTC)
I used to refer to this policy a great deal. Good, some actual practical experience, something real, empirical evidence. The question is: When you referred to this policy, did that affect the outcomes?
if commonsense it must be, commonsense it will be. No, "common sense" is equally useless, as it varies widely between individuals. It's been clearly established that the number of editors who don't understand that this encyclopedia, like all encyclopedias, exists to serve readers is zero or insignificant. That means you don't need a pillar to refer to to make that argument in a discussion. Whether the argument succeeds or not is a matter of consensus like everything else. ―Mandruss  22:42, 28 August 2018 (UTC)
Strongly disagree that it has been clearly established that the number of editors who don't understand that this encyclopedia, like all encyclopedias, exists to serve readers is zero or insignificant. On two grounds. I don't think that has been demonstrated at all, but respect your opinion that it has been, and again I'd like to hear more. But more important, no editor or group of editors is insignificant. Take care of the pennies and the pounds will take care of themselves.
At the risk of linking to my own essay, perhaps we might address the underlying concerns by promoting and/or developing User:Andrewa/creed? This concentrates on the positives rather than the negatives, as did the for readers clause of course. Andrewa (talk) 18:01, 29 August 2018 (UTC)

I think this concept is something that probably gets overlooked more than people realize. I won't get into specifics to avoid any drama, but recently there was a portal that made a decision about the templates of their articles, in favor of removing information. The community of readers voiced their opposition to it pretty clearly and loudly, but were ignored in favor of "policy" (no specific WP was cited), and even the compromise (removing bullet lists, and rewriting the info as prose) was ignored in favor of simply removing the information. As a result, READERS were negatively impacted. While people may feel this is a "common sense" thing, having it stated officially would go a long way to resolving issues regarding content that may not fall in line 100% with all guidelines, but is beneficial to readers nonetheless. 64.222.174.146 (talk) 14:53, 10 September 2018 (UTC)

  • A proper month long RFC after which uninvolved admins made a policy based decision to remove the section from pro wrestling articles. Misrepresenting the process shows that some people will never be happy with a process that does not support their POV.  MPJ-DK  02:11, 11 September 2018 (UTC)
Feel free to correct whatever was misrepresented. I pointed out it ws a policy based decision, and also that no specific policy was cited. I even went back and double checked to make sure my memory wasn't biased. Nothing I said in my comment was misleading, at least not intentionally. I specifically support this because of the fact that policy decisions can be made without factoring this bit of "common sense" into account, as its not officially stated anywhere. I intentionally didn't mention specifics so as to avoid dealing with people biased for/against the previous topic, as the topic itself is mostly irrelevant. My point was it would be nice to have this somewhere so policy based decisions can weigh it accordingly. 64.222.174.146 (talk) 16:20, 13 September 2018 (UTC)
So if I am reading this right your argument is that no policy was cited in the closure? There were plenty of policy based arguments made by participants and the closer agreed that the policy based arguments of one of the sides is what decided the outcome. Or am I misreading your comments? Not sure what "for the readers" would have invalidated there, it is not Wikipedia-Kryptonite that trumps all else. MPJ-DK (talk) 22:52, 13 September 2018 (UTC)
Not trying to argue for/against that specific subject any more, that point is moot. The point I am making is that when a decision is being made based around policies, having a policy in place that factors in stuff like a large contingent of readers being against a change. The arguments to make a change may be based around policy, and may be valid, but when a majority of the people actually reading the content are against the change, this policy prevents the outright dismissals of "Just because you like it doesn't mean it should stay." 64.222.174.146 (talk) 16:18, 14 September 2018 (UTC)


Heads-up at the project talk page

A heads-up has been posted at WT:5P. Andrewa (talk) 11:29, 27 August 2018 (UTC)

  • Support WP is the rebellious child of encyclopedias - unquestionably descendant, but irreverent of it stodgy fore-bearers. You can read in the subtext in many of our policies that we do it like so to avoid the failure we see in our predecessors. This notion of benefiting our readers contrasts with those that were more invested in promoting their own politics or allowed clearly biased primary sources to rewrite their own history. ghost 14:28, 28 September 2018 (UTC)

Year range for two consecutive years

Recently a single user moved 497 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)


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 et 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)

Request for an update of size calculations for splitting an article

The "rule of thumb" listed in Wikipedia:Article size for splitting an article has not changed since 2008 (at least). Is it possible to update these values? because I feel that some good articles (therefore long) are unnecessarily split by following this rule, thus reducing Wikipedia's readability. Nowadays, articles are significantly lengthened by the increased use of citations (many articles have hundreds of citations, often with external links). Browsers have made significant progress in ten years and can display such large pages; I think it is time for a change. Values in the scale should be at least doubled imo. Another way to improve this rule would be to exclude citations/references from the calculation. T8612 19:06, 17 September 2018 (UTC)

The size guidelines are for readable prose size, so citations/references are indeed excluded. Galobtter (pingó mió) 19:10, 17 September 2018 (UTC)
  • (edit conflict) Generally speaking, I'd say we can probably just toss out the article size suggestions that are based in the page's database size. Text is easy to load, it's all our fancy images that lag slow connections, and there's CSS and scripts and stuff that lag fast connections on slow computers too. On the other hand the guideline does deal largely with readable prose, and that's not a matter of technical limitation. Maybe we should update the WP:SIZERULE portion to be in terms of word count, rather than kilobytes. Ivanvector (Talk/Edits) 19:12, 17 September 2018 (UTC)
If the issue behind this guideline is loading time, why not placing the limitation on this, instead of text length?T8612 19:45, 17 September 2018 (UTC)
How would a normal editor determine that? People have different experiences with load time. WhatamIdoing (talk) 18:51, 25 September 2018 (UTC)
  • Yup, those figures are way too large and need to be shrunk. I'd recommend 30KiB as an upper limit. Jdforrester (WMF) (talk) 19:20, 17 September 2018 (UTC)
  • As noted it does not include citations notes etc, only readable prose size. Also, 'make it shorter' just sounds like good writing advice. So, not in favor (perhaps, if you proposed, 'make it shorter? :)). Alanscottwalker (talk) 19:30, 17 September 2018 (UTC)
  • The real problem is that they are not being enforced. Every time I point out an article is over 100kb rps ("Almost certainly should be divided") the response is that it's such an important and big topic... People simply ignore Wikipedia:Summary style, although that's one of our most important writing guidelines. – Finnusertop (talkcontribs) 02:13, 20 September 2018 (UTC)
@Finnusertop: Then perhaps articles that are listed as vital articles could get an upper limit, as they would really be considered important? T8612 14:06, 25 September 2018 (UTC)
  • Yes how about we increase the readable text size upper limit to 200,000 characters
  • No, let's not recommend larger pages. In fact, let's see about encouraging articles (not including all lists) to be shorter than the currently contemplated upper limits. I see three unrelated problems with large pages:
    1. Most people won't read long pages. A typical reader expects less than 1,000 words. Why? Because most of the other content they encounter is less than 500 words. A traditional "full-length" newspaper article was around 800 words. Even in-depth investigative articles rarely exceed a couple thousand words. Most native English speakers can sustain a reading speed of about 200 words per minute. That means that if you write "just" 2,000 words, you're expecting people to spend 10 minutes reading it. If you write 10,000 words (the longest SIZE contemplates), you're expecting them to dedicate nearly an hour to reading your article. This is already exceedingly unlikely. I've written a 6,000+ word article; I have no illusions that people will spend half an hour reading it. It was interesting to write, but I sometimes look at it and think that I should find a way to condense it, partly because more people would read it if it were at least 20% shorter, and partly because:
    2. Encyclopedias are supposed to be concise. Concision is one of the key characteristics of an encyclopedia. Articles in the famous 1911 Encyclopædia Britannica ran around 1,000 words each. Sure, we might not be constrained by the cost of paper, and maybe our ideal article might average double that, but making articles be an entire orders of magnitude longer than a traditional encyclopedia article, or even 30 times that length as suggested by the person who forgot to sign the above comment, suggests that we've stopped writing encyclopedia articles, and started writing some other sort of reference work. If you think back to when you wrote "long" papers for school – typed on paper, double-spaced – it should be pretty obvious why these numbers are well beyond generous for an encyclopedia article. That "10,000 words" is a 40-page-long paper (yes, forty pages). That's the length of a very long academic article (many prestigious academic journals limit authors to a maximum of half that length) or the length of a short novella, not an encyclopedia article. Also, encouraging length inevitably results in needless filler, so we'll get needless length, unencyclopedic verbosity, and bad writing to boot. We're not getting much educational value out of increasing length, especially when you understand that:
    3. Some people cannot load long pages. You can't give everyone access to the sum of all human knowledge if the page is too long for them to read on their devices. Sure, my relatively modern Mac can handle long pages just fine – but not everybody has my internet connection, and not everybody has a laptop. Desktop browsers have made significant strides, but half(!) of our traffic comes from mobile devices, and mobile devices today, especially if you are using a cheap one, are worse than laptops were when this rule was updated.
  • So, no, I don't think we should be increasing our page sizes. Let's stick with the goal of being an encyclopedia. WhatamIdoing (talk) 19:53, 25 September 2018 (UTC)
  • No need to change. The guidelines already exclude references and anything other than article prose, so the initial proposal is already effectively satisfied. On the other hand, I want to specifically oppose suggestions of reduction to "30KiB", or to impose a hard cap. We have a guideline on when an article is probably getting to big. I will note United States as an example case. The Page Information lists the length as 411,566 including refs and wikitext. However for guideline purposes the prose is around 125k. Every section and subsection has already been condensed to summary form with a hatnote to at least one article, and on average three hatnote links each. If someone is looking for something specific, the Table Of Contents will jump them to a condensed summary of what they want. I'd also like to address the comparison to 1911 Encyclopædia Britannica. I just checked the 1911 Britannica article for United States. It appears in Volume 27, and runs from page 612 to 735. That's over one hundred and twenty pages. Assuming I didn't botch my quicky math, it appears to be over 1,000k long. We would have to expand the United States article eight times longer to be comparable to 1911 Britannica. Our page for United States is ridiculously short by Encyclopedia standards, because we can and do spin off pages for subtopics as appropriate. Reducing the guideline or enforcing a firm number would be damaging for inherently large topics. Alsee (talk) 07:41, 27 September 2018 (UTC)
    • s:1911_Encyclopædia Britannica/United States, The has the contents. "The article", as you are presumably counting it, is two paragraphs followed by ten sections (written by different people) that contain about 180,000 words. The shortest section, at 378 words, is on the Military of the United States, and the longest section is about 100,000 words on the History of the United States. Since we structure these "sections" by putting them in separate articles, I'm not convinced that we have to expand anything at all: we have already bested them.
      However, it still remains the case that the average "finished" article in EB1911 is around 1,000 words – considerably smaller than what we encourage. WhatamIdoing (talk) 06:07, 28 September 2018 (UTC)
  •  Question: Is there any warning displayed during editing when the target value is exceeded? Samsara 18:10, 1 October 2018 (UTC)
  • There is absolutely no reason, to give you an example, why we are able to keep World War II under 100 kB but World War I is "too big and important" a topic, other than misguided WP:OWNership. Every time WP:TOOBIG is invoked, "Almost certainly should be divided" gets turned on its head and the status-quo that "Almost certainly" shouldn't prevail, almost certainly prevails. – Finnusertop (talkcontribs) 22:01, 6 October 2018 (UTC)
    • Outside of lists/tables, there's nearly always ways to split articles as outline in WP:SS, and I agree that it often comes to ownership that "Too big" pages don't get split. Given that we are literally not paper, there is almost never a need for a monolithic article (and that's where we have things like WP:BOOKS to actually create large groups of articles that encompass a topic for that need all that information in one place). The current SIZE requirements meet the balance of all users quite well. --Masem (t) 22:06, 6 October 2018 (UTC)
  • One thought to add to what has been written: should our articles attempt to be comprehensive, if not authoritative, in how they cover the subject, or serve as an introduction to the subject? If they are intended to be comprehensive/authoritative, I can't see how this is possible: even experts would find it a challenge to write Featured Articles on their subjects; any well-educated & curious person can write introductory essays, even if she/he is not an expert. And I've found introductory essays tend to age better & are much easier to keep up to date than lengthy, in-depth monographs. Which leads to this point: articles that serve as introductions aim to be short & concise. -- llywrch (talk) 21:47, 9 October 2018 (UTC)
    • Well, we are, by definition an encyclopedia written in summary style: "A Wikipedia article should not be a complete exposition of all possible details, but a summary of accepted knowledge regarding its subject" (WP:NOTEVERYTHING). Even the FA criteria, that begin with comprehensiveness, end with "Length. It stays focused on the main topic without going into unnecessary detail and uses summary style" (WP:FACR#4), so there is clearly no contradiction. – Finnusertop (talkcontribs) 11:27, 12 October 2018 (UTC)
  • No need to change WP:TOOBIG has been around for a long time, and has served us well as a rule of thumb. With regard to the usual arguments:
    • Most people won't read long pages. For which we have the summary in the lead. It isn't true either.
    • Encyclopaedias are supposed to be concise That was true 100 years ago, but we are WP:NOTPAPER, and our mission is "to collect and develop educational content" That's why we have orders of magnitude more material than any paper encyclopaedia.
    • Some people cannot load long pages Was true when people had 300 baud modems and 64K computers, but not today. In fact, the Wikipedia logo is 15K, so this is a concern, turn off the images!
  • In practice, we attempt to write articles that are comprehensive and authoritative. Some articles are more easily forked than others. We can split Dwight Eisenhower's military and political careers into separate articles, but is more difficult for John Glenn, whose three careers as aviator, astronaut and legislator overlapped. World War II is typical of many high profile articles: everyone wants it smaller, and everyone wants text on some favourite subject added. Hawkeye7 (discuss) 06:30, 13 October 2018 (UTC)

RfC: Proposed deletion policy

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)

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)

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)

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

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)

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)
  • 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)

Redirects from specific examples to lists that don't mention the examples

It occurs to me that I may not be clear about proper procedure concerning redirects (or concerning RfD).

My assumption is that a band not mentioned anywhere on Wikipedia should not point to a list of bands simply because it is a band, that we should not have redirects from websites to lists of websites that don't include that website, and that we shouldn't have a pile of redirects to a list of software from specific examples of that software that aren't mentioned in our list (or anywhere on Wikipedia).

If I'm right, could someone highlight exactly where it says that? If I'm not right, what am I missing? — Rhododendrites talk \\ 16:40, 30 September 2018 (UTC)

The problem you raise may be due to the dynamic nature of Wikipedia... ie the fact that articles are edited and change over time. It may be that the list being pointed to in the redirect did (at one time) mention the band/website/software... but was subsequently edited and the mention of band/website/software removed. In other words, the redirect may have made sense at the time it was created, but NOW no longer does. Blueboar (talk) 17:13, 30 September 2018 (UTC)
@Blueboar: Indeed the list did include them. I'll give the specific context here, since I don't think this comes close to convassing. List of video game emulators was, at one point, kind of a link farm/all-inclusive directory. It's not anymore, but it retains about 60 redirects from the names (and variations of names) of specific software no longer mentioned there or, generally, anywhere on Wikipedia. Some of those articles were deleted at AfD, some were redirected while the list was still all-inclusive, some never existed. When I tagged the redirects for RfD, I was surprised to see two experienced editors !vote keep. Since it seemed like such an obvious case for deletion to me, for the reasons above, I was then surprised that I could not find a clearly articulated policy that says what I thought it said (other than #10, which is sorta kinda). So here I am. — Rhododendrites talk \\ 17:32, 30 September 2018 (UTC)
I suppose you are referring to the practice of "redirect term which is not mentioned at its target" as a deletion criterion, yet which does not appear at WP:R#DELETE? --Izno (talk) 17:30, 30 September 2018 (UTC)
That's the one. — Rhododendrites talk \\ 17:32, 30 September 2018 (UTC)
It can be found reasonably in the intent of RD2, which is The redirect might cause confusion. (never mind the example). I think when a redirect term is not mentioned at its target, it's going to be confusing to the reader who follows the redirect. --Izno (talk) 17:42, 30 September 2018 (UTC)
There is also WP:Astonish. I believe a reader would be astonished/confused if redirected to an article that does not even mention the term. MB 19:14, 30 September 2018 (UTC)
I think it would be helpful if this were made explicit. It happens too often as it is, and it's too hard to get rid of them. The Drover's Wife (talk) 22:14, 30 September 2018 (UTC)
Actually, I think this is overall a bad idea. I looked at RFD just now, and half a dozen people are invoking this non-rationale to delete things like the redirects from music albums, on the grounds that the music album doesn't happen to be mentioned in the current(!) version of the article. In most cases, the harm seems to be hypothetical (Do we really think that some reader who typed in the name of a music album would actually be confused upon being redirected to the article about the band? I'll buy "disappointed", but not "confused" in such cases), and the imagined benefit appears to be, well, imaginary (in most cases). WhatamIdoing (talk) 20:51, 1 October 2018 (UTC)
A lot of names of music albums are not obviously names of music albums, so I think this could indeed be confusing. CapitalSasha ~ talk 21:05, 1 October 2018 (UTC)
Actually confusing for someone who already knows the name of the album? (Because how else are you going to type it into the search box?)
And wouldn't this be the sort of thing that gets fixed by editing the article rather than deleting things? I'm pretty sure that Wikipedia:Deletion is not cleanup even at RFD. WhatamIdoing (talk) 03:14, 2 October 2018 (UTC)
An album is very different. It is standard for an article about a band/musician to include a discography of major works. In that case, if not currently mentioned, it would be easy to just add it. It's a rare case of a fairly standard list in an article. That is the exception, though. Many lists, like the one this section concerns, are lists of examples, not exhaustive lists that one could expect to find. It is not the case that just because we have a list of examples of X that any instance of X that exists in the world would make sense to redirect to that list. In the list of redirects to the list of video game emulators, it is not the case that it would be appropriate to add any of them to the list. I don't think this is really about those cases when it's obvious that the [album, etc.] could be added but hasn't yet. — Rhododendrites talk \\ 05:21, 2 October 2018 (UTC)
Dab page equivalent MOS:DABRL discourages entries where the blue link does not mention the term. Whatever we decide, I would think the guidelines for redirects and dab entries should be consistent.—Bagumba (talk) 03:59, 2 October 2018 (UTC)
I disagree. Dab entries are visibly displayed, and deserve a stricter criterion for inclusion than what a redirect needs for existence. Dicklyon (talk) 04:10, 2 October 2018 (UTC)
A reader should not end up at a page that does not readily give them information on the term that they entered. It's equally annoying if they get to the "wrong" page whether it is via a redirect or a dab page.—Bagumba (talk) 04:49, 2 October 2018 (UTC)
Sure, but where you end up and what's displayed on a disambig page are non-equivalent things. Displaying on a disambig page invites one to go there, while a redirect is only invoked if one types it (or links it) explicitly. So the bar is at a different level, imho. Dicklyon (talk) 06:01, 2 October 2018 (UTC)
  • It is true that there is no policy that explicitly addresses what this concerns, and it is possible to interpret others in ways that conflict, clearly. I remain rather convinced that it is not standard practice to keep redirects from specific examples to general topics/lists of examples when the latter makes no mention whatsoever of the former, and I'm surprised to see people arguing against doing just that. It seems we may need an RfC to add that language to RFD... — Rhododendrites talk \\ 00:25, 10 October 2018 (UTC)

Proposal to Adopt Wikipedia:Blocking IP addresses as Policy

I'm thinking about proposing that we adopt Wikipedia:Blocking IP addresses as policy. Currently it is only an WP:INFOPAGE, but really it describes what I think should be binding policy. Before I do this, does anyone have any reason I should reconsider proposing this? -Obsidi (talk) 02:57, 5 October 2018 (UTC)

Looks more like a Guideline. Dicklyon (talk) 03:17, 5 October 2018 (UTC)
I wen't back and forth on that. I guess it could be a guidelines of the blocking policy, maybe that is more appropriate. -Obsidi (talk) 15:55, 5 October 2018 (UTC)
The policy is the blocking policy, where most of the important details are already written. We don't need another policy page on the subject, IMO. -- zzuuzz (talk) 17:34, 5 October 2018 (UTC)
Agreed with zzuuzz. This is an informational page but anything that should be codified as policy is already in the blocking policy. TonyBallioni (talk) 17:44, 5 October 2018 (UTC)
Before even considering making it a policy, the obvious problems in it should be fixed.
One example: it says "If you block an IP address in any of the following ranges, you are required to immediately notify the Wikimedia Foundation Communications Committee" but never tells you when and where either the WMF or the Wikipedia community made that a requirement.
Another example: The top of the page has the usual "This is an information page... It is not one of Wikipedia's policies or guidelines" language, but two of the section titles are "Policies" and "Guidelines" --Guy Macon (talk) 19:14, 6 October 2018 (UTC)
  • No, per zzuuzz. This is a solution looking for a problem. Dennis Brown - 16:51, 12 October 2018 (UTC)

What it takes to write an encyclopedia article

If you are interested in the nature of notability – why some potential subjects can be developed into separate articles, while some equivalent subjects are better presented as part of a larger article – then you might be interested in watching Wikipedia:Articles for deletion/Chitty (cricketer). I think there are a couple of thoughtful comments there. WhatamIdoing (talk) 18:18, 5 October 2018 (UTC)

bureaucrat access to manage copyviobot group

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.
☑Y Unanimous consensus in favor.WBGconverse 06:22, 14 October 2018 (UTC)

Hello all, a new access group was implemented by the Growth Team (copyviobot) which can be used by bots to add a special tag to the new pages feed for suspected copyright violations. See prior discussion regarding the group's creation here: Wikipedia:Bots/Noticeboard#New_bot-like_access_group and an active BRFA that would like to trial this feature here: Wikipedia:Bots/Requests for approval/EranBot 3. I propose the following updates in support of this:

  1. Amending Wikipedia:Bureaucrats#Bot_flags to allow bureaucrats to issue and revoke this flag in the same manner as the bot flag
    1. Approve execution of phab:T206731 to enable access for (Bureaucrats) to Add group and Remove group of the copyviobot group.
       Done The developer team has done this already in phab:T206731 - so barring a failure below this part is actually live and we are just looking at updating our internal policies. — xaosflux Talk 18:36, 11 October 2018 (UTC)
  2. Amending the Wikipedia:Bot_policy#The_"bot"_flag to include this as an available bot access, with such bots subject to the same requirements of other bots

Discuss

  • Support as proposer. — xaosflux Talk 02:10, 11 October 2018 (UTC)
  • Support per WP:SNOW. TonyBallioni (talk) 02:14, 11 October 2018 (UTC)
  • Support per above. --Rschen7754 02:15, 11 October 2018 (UTC)
  • Support this type of change needs community consensus but shouldn't be controversial. power~enwiki (π, ν) 02:18, 11 October 2018 (UTC)
  • Support, per WP:SNOW. Headbomb {t · c · p · b} 02:35, 11 October 2018 (UTC)
  • Support per common sense. Natureium (talk) 02:43, 11 October 2018 (UTC)
  • Seems reasonable. SQLQuery me! 03:19, 11 October 2018 (UTC)
  • Seems ridiculous that we need another group to do this. But yeah sure, let 'crats hand it out once it's here. -- Ajraddatz (talk) 05:05, 11 October 2018 (UTC)
  • Um. Do we actually need a separate group here? The permission does not sound very critical to me. Jo-Jo Eumerus (talk, contributions) 06:04, 11 October 2018 (UTC)
    @Ajraddatz: / @Jo-Jo Eumerus: I mostly understand why a new 'permission' was built, not sure why the developers didn't want to just use an existing 'group' though (such as 'bot') - I think they are just being very cautious. — xaosflux Talk 13:54, 11 October 2018 (UTC)
  • Support per common sense. I'm glad "copyviobot" is starting to be clarified. SemiHypercube 12:02, 11 October 2018 (UTC)
  • Obviously ~ Amory (utc) 14:27, 11 October 2018 (UTC)
  • Echoing what my fellow editors said: Don't know why that's needed but obvious that it should be bundled with crat permissions. Regards SoWhy 17:35, 11 October 2018 (UTC)
  • Support  — fr+ 09:24, 12 October 2018 (UTC)
  • Support - sure, bots are approved by 'crats, that's par for the course. But why do we need a separate class of bots to detect copyvios and flag articles? Aren't there already bots that do this? Ivanvector (Talk/Edits) 17:42, 12 October 2018 (UTC)
    @Ivanvector: there are some that make 'reports' (mostly off-wiki) - this new access will inject metadata to the wikidatabase, so that it can be used by components such as the new pages feed. I think the devs split this out since it is not being rolled out WMF wide at this time; I think if there is going to be a widespread rollout adding this new "permission" to the existing bot "group" may be the best. — xaosflux Talk 18:25, 12 October 2018 (UTC)
  • Support. Thryduulf (talk) 22:31, 12 October 2018 (UTC)

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

User accounts

Hi, is it allowed for a group of people to contribute to Wikipedia using only one account? Basically, is a shared account allowed? I’m not talking about one people controlling a group of accounts, that would be sockpuppetery.--▸ ‎épine talk 16:52, 12 October 2018 (UTC)

WP:NOSHARING. DonIago (talk) 16:59, 12 October 2018 (UTC)
No, that's not allowed; see WP:NOSHARING or WP:ROLE. Ivanvector (Talk/Edits) 16:59, 12 October 2018 (UTC)
Such an account would be blocked as being compromised. TonyBallioni (talk) 17:02, 12 October 2018 (UTC)
Thanks @TonyBallioni: and @Ivanvector: can a CheckUser detect if an account is used by a group of people?--▸ ‎épine talk 17:15, 12 October 2018 (UTC)
Theoretically, yes, a checkuser could detect activity that would suggest one account is being used by several people. Ivanvector (Talk/Edits) 17:40, 12 October 2018 (UTC)
Well, not exactly. They can see whether it's multiple devices/web browsers, but they can't see who's typing. One person logged in at school and again at home looks exactly like one person logged in at school and a different person logged in at home. Evidence that it's different people is usually behavioral (like saying that you never saw a message that your account replied to). WhatamIdoing (talk) 19:34, 12 October 2018 (UTC)
Or, for example, using the pronoun "we" a lot. Most role accounts admit it because they don't know it's wrong. It's very rare to have a role account which is deliberately being shared deceptively. It is hard to envision a situation where to do so is useful for the user. --Jayron32 14:22, 16 October 2018 (UTC)

Proposed new naming convention Wikipedia:Naming conventions (Irish stations)

I've started a proposed new naming conventions for articles on railway stations in Ireland at Wikipedia:Naming conventions (Irish stations). It's modeled after the other former conventions already established for Canada (WP:CANSTATION, Poland (WP:PLSTATION), the UK (WP:UKSTATION), and the U.S. (WP:USSTATION). It was written to follow the unwritten practice already in place as closely as possible. Comments and suggestions are welcome.--Cúchullain t/c 18:36, 15 October 2018 (UTC)

What do Ted Kaczinski, Aldous Huxley, and Francis of Asissi have in common?

Yup ... they're all being spammaged by the same infobox. Allegedly because they are all part of anti-consumerism.

Infoboxes have gotten out of control before, and I know somehow they were reigned in, but recently I've started to see more junk hits (e.g. from anatomical regions) somehow coming up from Google searches again, and more outrages like the long, long, long, long trailer by the side of the Kaczinksi article that makes it sound like he wrote Walden. (Admittedly I suppose people who enable scripts more often might see something different, but all that spam is still dumped in the article whether it is read or not. I mean, would I rather see articles get 32K more text apiece or 32K more spam apiece?)

I'm thinking some random policy applications like:

  • This is a giant coatrack that would make Goatse quail at the sight of it. I mean, was Pope Gregory I an anti-consumerist? Pencil him in!
  • I laugh to think of the secondary source that would list these three together. Maybe we should write a grievance studies article?
  • I shudder to think of the reaction I would get from some editors if I manually typed a tenth of that list of terms into the See Also section. Probably end up under a topic ban...

But is there anything else I'm missing? What can be done here? Wnt (talk) 13:44, 16 October 2018 (UTC)

Small nitpick - that isn't an infobox. --Gonnym (talk) 13:47, 16 October 2018 (UTC)
It's not the size of the sidebar that matters; it's how you use it. There's always "Navigation templates are particularly useful for a small, well-defined group of articles; templates with a large number of links are not forbidden, but can appear overly busy and be hard to read and use." from WP:SIDEBAR. This seems kind of like an unhelpful one. At worst, it could always be converted to a (horizontal) navbox and dumped at the bottom of the article, which is where these things usually go to be ignored. –Deacon Vorbis (carbon • videos) 13:58, 16 October 2018 (UTC)
The reason this is happening is that we are having the discussion here instead of at the article talk pages OR at the template talk page. I would recommend the following steps for dealing with these problems 1) WP:BEBOLD and remove the offending template yourself. If it stays away forever, congratulations. If it comes back 2) Start a discussion at the article talk page where it was put back and see what WP:CONSENSUS is or 3) Start a discussion at the template talk page, post a notice on every article talk page where it currently appears, and reach a consensus as to which articles should and should not have it. Once you have consensus, you can enforce it. --Jayron32 14:21, 16 October 2018 (UTC)
  • If it is demonstrably WP:OR/WP:SYNTH to group these together, you could try WP:TFD to delete the template (and remove the transclusions. power~enwiki (π, ν) 02:40, 17 October 2018 (UTC)
  • Is this something we even need to track? I would just get rid of it entirely. CThomas3 (talk) 03:59, 17 October 2018 (UTC)

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)
  • 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)
  • 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)

Multiple stub messages

Some articles have two or even more messages saying that they are stubs and specifying that the stub is related to something. Just one of these specialised stub messages is okay but when theres multiple of them it could be confusing for readers. I think a policy or a style guideline needs to be made to prevent this. 🌸 WeegaweeK^ 🌸 22:55, 16 October 2018 (UTC)

  • The purpose of the stub notices is to bring the article-needing-expansion to the attention of people who are interested in expanding articles in particular topic areas. I was involved several years ago in the massive stub sorting project which led to the current stub topics structure. Why not just use categories? The distinction is in the definition of stub: A stub is an article deemed too short to provide encyclopedic coverage of a subject. (WP:Stub). There are, of course, other ways of dealing with this, such as only using {{stub}} and making all topic stubs hidden but enabling of special stub sub-categories within standard categories = one of many alternatives. --User:Ceyockey (talk to me) 01:05, 17 October 2018 (UTC)
    • Yet another alternative is to use the project tagging on the talk page to see if it is a stub. Graeme Bartlett (talk) 09:41, 17 October 2018 (UTC)

RfC notice: DIFFCAPS

Comments are requested for a discussion of article naming policy (DIFFCAPS) at Wikipedia talk:Article titles. Thank you. —Sangdeboeuf (talk) 01:03, 17 October 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)

Mass renaming of election articles, bypassing WP:Requested moves

At Wikipedia:Bots/Requests for approval/TheSandBot, discussions are underway about a request from User:TheSandDoctor to run a bot to rename 35,226 articles on elections. Many consequent edits will be required on templates etc.

This follows an RFC on anamendment to WP:Naming conventions (government and legislation) (WP:NCGAL), at WT:Naming conventions (government and legislation)#RFC_inadequate,_bot_not_justified.

That RFC was closed as a consensus to change the naming format from "Foo election, YYYY" to "YYYY Foo election". However, only 16 editors !voted, by a margin of 11:5 in favour. (so only 3 or 5 more opposes would have pushed it into no consensus territory).

That seems an inadequate basis for such a big change.

And I don't see any sign of a consensus anywhere to use a bot to bypass WP:Requested moves for these 35,226 articles. I am not aware of any precedent for using a bot in this way, especially without a clear consensus to bypass WP:RM.

The discussion at Wikipedia:Bots/Requests for approval/TheSandBot is even considering how to handle exceptional cases such as Polish presidential election, 1922 (special) and Polish presidential election, 9 December 1922. Discussions such as that belong at WP:RM; they should not be buried on a technical page.

I do not suggest that any of those involved are acting in bad faith. But I do think that in their enthusiasm, they are acting in excessive haste with inadequate consensus-formation.

So is there any way to persuade WP:BAG to hold off such a huge exercise until it is clear that there is

  1. a broad consensus that the limited-participation RFC adequately reflects the view of the community?
  2. an RFC to support using a bot to bypass WP:RM on such a huge scale

--BrownHairedGirl (talk) • (contribs) 03:33, 19 October 2018 (UTC)

Links from mainspace to draft?

I know you're not supposed to link from mainspace to draft, but I can't find any policy which actually says that. Where is it? -- RoySmith (talk) 14:32, 19 October 2018 (UTC)

Are you talking about cross-namespace redirects? ~ ONUnicorn(Talk|Contribs)problem solving 14:34, 19 October 2018 (UTC)
Well, there's WP:MOSLINKSTYLE "Do not create links to user, WikiProject, essay or draft pages in articles, except in articles about Wikipedia itself (see Self-references to avoid)." Natureium (talk) 14:37, 19 October 2018 (UTC)
Ah, MOS:LINKSTYLE is what I wanted, thanks. The specific issue was a user had linked to a draft from a WP:DAB page. -- RoySmith (talk) 14:46, 19 October 2018 (UTC)

Technical

PDF file cited as source downloading onto computer

I'm wondering why clicking on the url for the source cited in Business network#cite_note-:0-2 is downloading onto my computer instead of opening in a web browser. I've clicked on PDF files cited as sources before and they usually open up in the browser. If it's my computer then no biggie; if, however, it's the formatting of the citation or something about the website, then maybe the citation syntax can be tweaked to stop the automatic download. There's another PDF file cited in the same article as Business network#cite_note-SS_1995-6 which does open in the web browser, and doesn't download. -- Marchjuly (talk) 06:44, 5 October 2018 (UTC)

Marchjuly, this depends on what the server of that file tells the browser to do. Some browsers provide options in their settings to allow you to override this. —TheDJ (talkcontribs) 07:17, 5 October 2018 (UTC)
OK. It seemed a bit weird that it was doing it for one and not the other, but I'll sort it out since it's on my end. Thanks for taking a look. -- Marchjuly (talk) 07:19, 5 October 2018 (UTC)
I followed the instructions in the link you provided, but my settings were set to not download PDFs. Kinda weird. Can a website set things up to override a user's individual settings? -- Marchjuly (talk) 07:24, 5 October 2018 (UTC)
@Marchjuly: a quick look at that site indicates it is not really serving "a file" but a data stream of the file - and browsers wouldn't normally be configured to deal with that type of data in-browser. — xaosflux Talk 20:23, 5 October 2018 (UTC)
@Xaosflux: Thanks for taking a look. Ah...that’s sounds a bit diabolical, but I expect it’s fairly common. The question then is whether such a thing is OK for Wikipedia’s purposes; it seems like it would be better to cite a site Smiley emoticons doh.gif which actually hosts the desired content than downloads it to your computer when clicked. Is there a way to tweak the citation template syntax which tells whatever/whoever needs to know that clicking on the link will download it onto your computer? — Marchjuly (talk) 21:38, 5 October 2018 (UTC)
I would think that if you can point to one page "up" where a link to the PDF is obvious, generally in such cases where that page is describing what the user will see in the document, then that's an ideal solution. But the "stream" link is not bad if that's only way to provide the PDF. --Masem (t) 21:44, 5 October 2018 (UTC)
@Masem: It took going back a couple of pages to ec.europa.eu/docsroom/documents/5563/attachments/1/translations to find a link which wouldn't download or which wasn't listed as an error, but I'm not sure that helps anything since it still seems to require that the source be downloaded if you want to verify it. Is there a way to mark the citation, so that readers are alerted to the fact that clicking on the link may cause the file to be downloaded to their computers? -- Marchjuly (talk) 07:39, 12 October 2018 (UTC)
That's really annoying. I tried to find a better "landing" page (something aking to [4] where there's information about the report and a clear link to download). Best I can tell there's no way to stop the download without severe CSS/JS intervention on the client side. (you can force a PDF to download through simple HTML5, but not vice versa). And best as I can tell from the cite templates there's no way to throw an indicator to a user. I definitely don't want someone to insert a ref thta ends up downloading a 10 gig document without warning, for example. --Masem (t) 14:17, 12 October 2018 (UTC)
@Marchjuly: "downloading" occurs including any such large file sizes @Masem: mentions regardless if the file is opened in a browser tab or with another application. — xaosflux Talk 14:47, 12 October 2018 (UTC)
Yes, as other examples consider these three pages of the same document: sheet 1 of 3; sheet 2 of 3; sheet 3 of 3. Those links take you to the file description pages, but if you click the image or the "Original file" link, it downloads instead of displaying. The smallest of these three is 1.28 MB. --Redrose64 🌹 (talk) 15:11, 12 October 2018 (UTC)
@Masem, Xaosflux, and Redrose64: Appreciate all of the input and info. FWIW, the citation isn't formatted using a template (sorry for not noticing this before); so, I think a "warning" about the link can just be added manually. However, perhaps the best thing to do in a case such as this would be to reformat the citation in a way that deactivates the url; for example, {{Cite web}} requires an active url to work properly, but there are some citation templates which don't. So, maybe treat this as a type of WP:SAYWHERE source, providing as much information about it as possible. If a citation template is used, then using |via= to treat the landing page as WP:CONVENIENCE and |others= or |quote= to either (1) quote the specific information being referenced, (2) add a "warning" to the reader that the file will download on to their computer if clicked, or (3) some combination of those two things. Maybe the person who added the citation or someone else who has been contributing to the article would be willing to do that, so I'll add {{Please see}} for this discussion to the article's talk page. -- Marchjuly (talk) 23:00, 12 October 2018 (UTC)
Do make sure that |format=PDF is used. They know that clicking the link in that case will bring them a file - whether that is viewed in the browser or being downloaded to view outside the browser, its still being downloaded. --Masem (t) 23:11, 12 October 2018 (UTC)
Thanks for the reminder. That's a good point since there'll be no PDF icon displayed after the url if it's deactivated. -- Marchjuly (talk) 23:28, 12 October 2018 (UTC)
Except for the cases of a link to another point in the same page, and a "link" that actually fires some JavaScript, clicking any link - PDF or otherwise, external link or internal - will bring back at least one file. For example, clicking this link - User:Masem - will bring back the file [en.wikipedia.org] plus several others (stylesheets, images, JavaScript etc.)
I see two potential causes here. First, the size of the file - it's 1,082,824 bytes. Second, the file has the somewhat unusual name [ec.europa.eu] which shows the the file is named simply "pdf". --Redrose64 🌹 (talk) 10:09, 13 October 2018 (UTC)

Managing TemplateData: does not write my edits

When I edit a template documentation page to add or change WP:TEMPLATEDATA, the edits do not materialise. I use the "Manage TemplateData" edit helper (button). After editing in theat screen, I press "Apply" then no edits are made to the /doc page edit box (and so saving would be a null-edit). Any ideas? -DePiep (talk) 16:38, 7 October 2018 (UTC)

Which template did you try to edit? Ruslik_Zero 19:41, 7 October 2018 (UTC)
{{Currency}} (/doc that is), tried to add new TemplateData list; {{See also}}, tried to add parameters to TD. Tried more templates so in recent weeks/months. -DePiep (talk) 20:02, 7 October 2018 (UTC)
DePiep, does this happen if you edit in ?safemode=1? (See mw:Help:Locating broken scripts#Test if you have problems related to user scripts or gadgets.) What's your browser and OS? Whatamidoing (WMF) (talk) 05:09, 10 October 2018 (UTC)
reproduce with/without safemode=1 (=success/fail)
I did this:
  1. Clear cache
  2. Open Template:See_also/doc (read)
  3. add ?safemode=1 to end of URL
  4. open for Edit (with me, traditional edit mode, not VE). The appendix ?safemode=1 did not return, so:
  5. add &safemode=1 to action=edit URL(needs &) and reload, opens:
  6. [en.wikipedia.org] (edit screen, looks OK)
  7. Open Manage TemplateData (button)
  8. Add paramter, paramter "Test"; Apply;
  9. Done, parameter added [5] (success).
  10. Same for Template:Currency/doc (success when using &safemode=1).
  11. After both successes, tried again without safemode: failed in both pages.
re OS and browser: last July I switched from Linux to Windows 10, on 'new' hardware. Browser is Chrome v69 64-bit.
fyi, last April I lost my TE permission, did not ask it back yet. -DePiep (talk) 15:52, 10 October 2018 (UTC)
Extra test: installed Firefox v62 on Windows10 desktop. Same process. Using safemode=1: success, without safemode=1: fail. -DePiep (talk) 16:01, 10 October 2018 (UTC)
ping @Whatamidoing (WMF): -DePiep (talk) 15:53, 10 October 2018 (UTC)
Running with debug=true, webconsole message in Chrome: "Uncaught TypeError: Cannot read property 'accessKey' jquery.js[...]" (in Firefox: "jQuery.Deferred exception: element is undefined [...]"). Need more? -DePiep (talk) 16:17, 10 October 2018 (UTC)
I can confirm this: the error message appears in the debug mode after {{Currency/doc}} is opened for editing. It only appears after Manage TemplateData button appears on the screen. Also tried to edit the template data but without success. Ruslik_Zero 09:29, 11 October 2018 (UTC)
I can't reproduce this (on my Mac). I'll file a bug report.
User:DePiep, does this happen always, or only on protected templates? Whatamidoing (WMF) (talk) 19:40, 11 October 2018 (UTC)
Since ?safemode=1 seems to resolve the problem, the problem is probably in a user script or gadget. This could be anything from WikEd to something that only the two of you are running, but it's probably not something that I'm running (which is pretty much the defaults plus NAVPOPS, and whatever you can see in my common.js/global.js files). Do you have any guesses about what scripts you two might have in common? Whatamidoing (WMF) (talk) 19:50, 11 October 2018 (UTC)
(edit conflict) @Whatamidoing (WMF): Tried in unprotected {{Other antibacterials}}, both main template page and /doc page (I freshly added). Both failed.
I also tested this {{Other antibacterials/doc}} page when logged out: success (I did not save). -DePiep (talk) 19:53, 11 October 2018 (UTC)
My scripts afaik: 'User:Js/ajaxPreview.js'; 'MediaWiki:Gadget-HotCat.js'; 'User:Cameltrader/Advisor.js'; WikEd, JS WikiBrowser = Wikipedia:AutoWikiBrowser/Script, also WP:AWB. Don't know if this is the complete list.
@DePiep: Can you get and copy-paste a backtrace from the browser console for this error (either browser)? There should be a little arrow/triangle next to the error message, clicking it will display the backtrace below. It's impossible to identify what is causing the error from just this message (I am guessing that the error is generated within the 'jquery.accessKeyLabel' module, but the real problem is probably in whatever code is using jquery.accessKeyLabel here). Matma Rex talk 18:34, 12 October 2018 (UTC)
───────────────────────── re @Matma Rex:. ok, will make a screenprint etc. To be sure: does any of this exposes me? -DePiep (talk) 23:05, 12 October 2018 (UTC)
@DePiep: The stack trace could allow someone to deduce which browser extensions you are using or which gadgets you have enabled (in this case, the latter is kind of the point). It should not expose any other private information (although it technically could, it would take very weird code to do it). If you're concerned, you can email it to my WMF account [email protected] instead of posting it publicly, or review it yourself (I'm looking for a function name or a file name that would reveal which script is causing your problem). Matma Rex talk 01:55, 13 October 2018 (UTC)
I've put the stack in phab. -DePiep (talk) 08:17, 14 October 2018 (UTC)

I looked into this: the issue is caused by the wikEd gadget. If anyone still maintains wikEd, I documented some details of the problem and ideas on how to fix it in a comment at phab:T206795#4668857. I guess for now you'll need to turn it off before using the TemplateData editor. Matma Rex talk 23:32, 15 October 2018 (UTC)

Thanks Matma Rex. Any follow-up through WidEd maintainer [who], &or in phab. Close here I'd say.-DePiep (talk) 20:08, 19 October 2018 (UTC)

Image layout artifact

Image-display-artifacts.png

This is a screencap of bicycle brake. The thumb image has a vertical line of black and gray dots. It doesn't look this way on the actual commons:File:Bicycle brakes - animated.gif image page. Seems like it's at the boundary of the transparent background? I tried changing the |upright=1.35 parameter, and any other value does not have this artifact. I tried various purging of the file page and the enwiki article page, with no change. Another user says they do not see it. Any ideas what's happening? DMacks (talk) 12:30, 11 October 2018 (UTC)

It works for me. The viewed thumb depends on user settings. What is your "Thumbnail size" at Special:Preferences#mw-prefsection-rendering? I have 220px and see [upload.wikimedia.org] on Bicycle brake. Can you right-click the image on the article and select something like "View image" to get a similar url? Do you see the problem there? What is your browser? It's an animated gif. Does it animate for you? It does for me. PrimeHunter (talk) 13:13, 11 October 2018 (UTC)
220px in that preference for me also. The direct link from right-click is [6], where I also see the dots and it does animate (in both cases). I'm using Firefox 62.0.3 on OS X. DMacks (talk) 13:20, 11 October 2018 (UTC)
Okay, now I don't (neither direct-view of that URL nor in the aricle). Glad I kept a screenshot so neither y'all nor I think I'm crazy. DMacks (talk) 13:21, 11 October 2018 (UTC)
DMacks, You'll need more than that screenshot :) S Philbrick(Talk) 19:35, 11 October 2018 (UTC)
You're lucky {{glare}} is red or I'd template the hell out of ya:) DMacks (talk) 07:45, 12 October 2018 (UTC)

Unable to publish a very specific change (an AfD page) at any namespace as an unregistered contributor

Please try to insert the wikitext of Special:Diff/863443818/863448552 to any page (preferably Wikipedia:Sandbox or an userpage sandbox). This should fail when all the following conditions are true:

  • The text of the page to be published only has the wikitext of Special:Diff/863443818/863448552.
  • The page doesn't have to be empty (blanked) first, but the previous point must still be true.
  • An attempt to publish changes must be done by a non-administrator (unregistered IP address contributor)?

If point #1 is false, the edit succeeds: Special:Diff/863621545.

My attempts to publish fail silently for me (as an unregistered user) at the following locations:

Despite all this, it works for @PrimeHunter (who's an administrator) at Wikipedia:Articles for deletion/Anti-Jewish violence in Eastern Galicia involving soldiers of the Blue Army: Special:Diff/863619579?!

The most mysterious part about this is that it's not Special:AbuseFilter related, as it seems. There are no logged events at Special:AbuseLog. There are no special editnotices. Attempting to publish the changes repeatedly does nothing. I didn't get a CAPTCHA for the external link.

While trying to write this VP/T post, I got the red "Incorrect or missing CAPTCHA" box at top but CAPTCHA security check at bottom. The issue started around ~22:30 UTC; was there a MediaWiki update behind this? (I've never seen the CAPTCHA box be at the bottom before.)

Please, I'm very curious for someone else to attempt to reproduce this as an unregistered contributor. For the curious, this is on Firefox 62.0.2 on GNU/Linux. I feel like to have encountered the weirdest bug of my years here. 84.250.17.211 (talk) 23:58, 11 October 2018 (UTC)

  • I have so far reproduced the missing CAPTCHA issue by reducing the issue to these two lines:
    <div class="infobox" style="width:33%">AfDs for this article:<ul class="listify">{{Special:Prefixindex/Wikipedia:Articles for deletion/Anti-Jewish violence in Eastern Galicia involving soldiers of the Blue Army}}</ul></div>
    :({{Find sources AFD|Anti-Jewish violence in Eastern Galicia involving soldiers of the Blue Army}})
    In combination, the CAPTCHA goes missing. Perhaps I should blame the nominator here? But I'm still curious. (I got the incorrect or missing CAPTCHA while writing this, with CAPTCHA below the edit summary again and red box at top.) 84.250.17.211 (talk) 00:32, 12 October 2018 (UTC)
    • This is the smallest test case I could make for CAPTCHAs to go missing:
      {{Special:Prefixindex}}
      :{{Find sources AFD}}
      84.250.17.211 (talk) 00:39, 12 October 2018 (UTC)
      • Even smaller:
        {{Special:Prefixindex}}
        https://example.com/
        It must have an external link for CAPTCHA trigger. In example, {{Cite web}} alone won't do it but {{Cite web|url=<url>}} will (with a proper URL), but any bare link will also work. 84.250.17.211 (talk) 00:53, 12 October 2018 (UTC)
  • To be clear: This issue is experienced with Template:Afd2 (in example), with a caveat that one must be signed in to nominate an article for deletion. I must be one weird person to handle AfDs and cleanup while refusing to have/be signed into an account. 😏 84.250.17.211 (talk) 00:58, 12 October 2018 (UTC)
I can reproduce this. It happens if you try to save an edit when these three are all satisfied:
  1. You are unregistered or not autoconfirmed at the wiki. It also happens at other wikis.
  2. The edit transcludes a special page, either directly in the source or via a template like {{Afd2}}. It can both be an existing special page like {{Special:Prefixindex}} and a non-existing page like {{Special:NoSuchPage}}
  3. The edit adds an external link which would normally have caused a CAPTCHA.
The expected behaviour is getting an edit page with a CAPTCHA. The actual behaviour is getting an edit page with no CAPTCHA. There is no apparent way to complete the edit. If users want to experiment without logging out then try a wiki where you are not autoconfirmed. The default requirement in Wikimedia wikis is four days and zero edits but some wikis require edits with wgAutoConfirmCount in [noc.wikimedia.org], e.g. 20 edits at no:. Special:CentralAuth can show where your account is already registered. PrimeHunter (talk) 10:05, 12 October 2018 (UTC)
  • It looks like you found a bug in the CAPTCHA code, please report the bug so it can get looked in to. This is not limited to the English Wikipedia, so it will need to be looked at by developers. — xaosflux Talk 22:44, 12 October 2018 (UTC)
    • I would appreciate if someone could do this on my behalf and add {{Tracked}}. 84.250.17.211 (talk) 21:55, 13 October 2018 (UTC)
      •  Done phab:T207065 is for you. You will, unfortunately, need to create an account if you want to add information to the ticket. Whatamidoing (WMF) (talk) 17:32, 15 October 2018 (UTC)

Ref Toolbar not showing up

For some reason, Wikipedia:RefToolbar isn't showing up at all in my edit windows. I've tried refreshing and clearing the cache; I've tried turning it off in preferences and back on again. Any idea what's going on? Ten Pound Hammer(What did I screw up now?) 02:39, 12 October 2018 (UTC)

TenPoundHammer, any browser errors? See WP:JSERROR for reporting info. Enterprisey (talk!) 03:30, 12 October 2018 (UTC)
@Enterprisey: I don't understand a word of that. Ten Pound Hammer(What did I screw up now?) 03:54, 12 October 2018 (UTC)
Which browser and operating system are you using, so that I can try and reproduce it? Enterprisey (talk!) 04:33, 12 October 2018 (UTC)
mw:Help:Locating broken scripts#Test if you have problems related to user scripts or gadgets might be helpful. But the easy step first: would you please click on this link and tell us if that produces the expected results? Whatamidoing (WMF) (talk) 19:28, 12 October 2018 (UTC)
@Enterprisey: Windows 10 and Google Chrome. @Whatamidoing (WMF): No, nothing. Ten Pound Hammer(What did I screw up now?) 00:03, 13 October 2018 (UTC)
@Enterprisey: I can't seem to pull up debug mode following the instructions. I am way over my head here. Just tell me the quickest way to unfuck this. Ten Pound Hammer(What did I screw up now?) 01:40, 13 October 2018 (UTC)r
@Enterprisey: I get "Use of "mw.toolbar" is deprecated" and "title=User:Apoc2400/refToolbarPlus.js&action=raw&ctype=text/javascript:1 You installed the userscript User:Apoc2400/refToolbarPlus.js

It is no longer working and you should uninstall it." Any idea what's causing that? Ten Pound Hammer(What did I screw up now?) 01:44, 13 October 2018 (UTC)

TenPoundHammer remove importScript('User:Mr.Z-man/refToolbar.js'); from the bottom of User:TenPoundHammer/monobook.js Galobtter (pingó mió) 16:23, 13 October 2018 (UTC)
TenPoundHammer, is everything better now? Whatamidoing (WMF) (talk) 18:23, 18 October 2018 (UTC)

Non-backlog category with template

CAT:CSD transcludes {{Adminbacklog}} with a 50-item threshold, i.e. it automatically detects the number of contents and displays as a backlog only if there are 50+ items. Can anyone imagine why it's displaying now? There are only twelve pages and sixteen files in the category; there's no way this should be showing up. I've purged it repeatedly (first time was over an hour ago; second was maybe half an hour or more ago) using the (recount) link in the template, so the item counts shouldn't be old information. Nyttend (talk) 04:22, 12 October 2018 (UTC)

@Nyttend: We've been seeing multiple reports of categories having problems recently. Wikipedia:Village pump (technical)/Archive 169#Category count wrong is the most recent thread. --Izno (talk) 04:37, 12 October 2018 (UTC)

Scrotum infobox image not working

See Talk:Scrotum#Image_not_showing_in_article--♦IanMacM♦ (talk to me) 06:25, 12 October 2018 (UTC)

I've added an exception to the image blacklist. -- zzuuzz (talk) 06:34, 12 October 2018 (UTC)
Thanks, it helps if these images have {{Restricted use}} otherwise it may not be obvious why the problem is occurring.--♦IanMacM♦ (talk to me) 06:52, 12 October 2018 (UTC)
There used to be a bot which did this. I believe the task was inherited by Cyberbot I. It might be time for another look at it. -- zzuuzz (talk) 07:05, 12 October 2018 (UTC)
The previous bot got sacked? DMacks (talk) 07:33, 12 October 2018 (UTC)
Sox'd -- zzuuzz (talk) 07:43, 12 October 2018 (UTC)
I wasn’t aware it had stopped.—CYBERPOWER (Message) 10:28, 12 October 2018 (UTC)
Cyberpower678, looks like it's not removing the restricted tag from images either; File:An image of Klaus Heissler in a water bowl.png had the restricted tag even though it's not on the list (was about to start a new thread, then saw this related thread). Weird image to have ever been on the list in the first place. Home Lander (talk) 01:32, 16 October 2018 (UTC)

Log deletion

Is it possible for an ordinary admin to delete a block log? L293D ( • ) 22:10, 12 October 2018 (UTC)

Redact not delete. However it would be against policy to do so. — Martin (MSGJ · talk) 22:22, 12 October 2018 (UTC)
@L293D: see Wikipedia:Revision_deletion#Log_redaction. — xaosflux Talk 22:35, 12 October 2018 (UTC)
Deleted log events will still appear in the logs, but parts of their content will be inaccessible to the public. Other administrators will still be able to access the hidden content and to undelete it, unless additional restrictions are set.
When changing the visibility of a log entry, there are three items that may be redacted individually or together: delete action and target; delete edit summary; delete performer's username/IP address. In theory, I could redact a block log entry on behalf of somebody else, this would then create a further entry in the deletion log, showing that I had changed the visibility of another log entry; I could then redact my own username on that new entry, which would then create a further entry ...
There's always a trail for those who need to know, and those who abuse the tools can be traced.
In summary: don't do anything that will get you blocked. --Redrose64 🌹 (talk) 22:49, 12 October 2018 (UTC)

Wanted Templates not updating

In Malayalam wikipedia, in the Special page Wanted Templates, what could be the reason for a certain range of templates to appear again and again even after purging happens a number of times?Adithyak1997 (talk) 05:27, 13 October 2018 (UTC)

Please give a link and example when you report an issue. ml:Special:WantedTemplates is generated periodically and says in English: "The following data is cached, and was last updated 09:46, 10 October 2018." You didn't say what or when you purged, and some things require a null edit and not a purge to update link tables. Nothing done after 09:46, 10 October 2018 will affect the list until next time the list is generated by the software. PrimeHunter (talk) 09:43, 13 October 2018 (UTC)

@PrimeHunter, Sorry for not providing links. Please do check [|this] link for a detailed problem description.Adithyak1997 (talk) 09:59, 13 October 2018 (UTC)

I don't know Malayalam but there appears to be an issue with automatic conversion between two similar characters. The third link at ml:Special:WantedTemplates says ml:ഫലകം:തടയപ്പെട്ടവര്‍‏‎ where "ഫലകം" means "Template". The link is red in the list but works. However, it automatically changes the last character and goes to the page ml:ഫലകം:തടയപ്പെട്ടവർ from 2007. The last characters ര്‍‏‎ and ർ look different to me, and my browsers find function says they are different. They also produce url's with different ends but both url's automatically redirect to the same third url. Maybe the software generating ml:Special:WantedTemplates doesn't know about the automatic conversion and produces an entry if a non-canonical form of the name is used in a page. According to [r12a.github.io], ര് is ‎"0D30 MALAYALAM LETTER RA" followed by "0D4D MALAYALAM SIGN VIRAMA", while ർ is "0D7C MALAYALAM LETTER CHILLU RR" and not followed by something else. PrimeHunter (talk) 10:58, 13 October 2018 (UTC)
@PrimeHunter, If you think like that, then what about the next link starting with ഫലകം:User?Adithyak1997 (talk) 11:29, 13 October 2018 (UTC)
The link says ml:ഫലകം:User ഈമെയില്‍‏‎ but clicking it leads to ml:ഫലകം:User ഈമെയിൽ. These also have different last characters, this time ല്‍‏‎ and ൽ where [r12a.github.io] says the first is a letter followed by "0D4D MALAYALAM SIGN VIRAMA". I don't know Malayalam or the code used to generate WantedTemplates so I'm only guessing this conversion is related to the WantedTemplates entry. PrimeHunter (talk) 16:04, 13 October 2018 (UTC)

Line break leaves lone quotation mark at end of line

Can we do something to make edits like this one unnecessary? It seems likely that we would in general want to suppress a line break after an opening quotation mark; is there some reason that's not easy? Or is this more of a browser bug? Dicklyon (talk) 06:05, 13 October 2018 (UTC)

Line breaks without nowrap are decided by the browser. My Opera and Chrome versions will break between "( but not Firefox, IE and Edge. In theory our software could be changed to automatically add nowrap in certain places where breaks are probably unwanted but some browsers are known to make them anyway. I don't support actually bloating our html with extra code like that. Example without nowrap if people want to test their browser by changing window width:
"(musician)" "(musician)" "(musician)" "(musician)" "(musician)" "(musician)" "(musician)" "(musician)" "(musician)" "(musician)" "(musician)" "(musician)" "(musician)" "(musician)" "(musician)" "(musician)" "(musician)" "(musician)" "(musician)" "(musician)" "(musician)" "(musician)" "(musician)"
With the html produced by {{nowrap}}:
"(musician)" "(musician)" "(musician)" "(musician)" "(musician)" "(musician)" "(musician)" "(musician)" "(musician)" "(musician)" "(musician)" "(musician)" "(musician)" "(musician)" "(musician)" "(musician)" "(musician)" "(musician)" "(musician)" "(musician)" "(musician)" "(musician)" "(musician)"
PrimeHunter (talk) 09:32, 13 October 2018 (UTC)
dont use nowraps around that. That’s insane. The world wide web is no typesetting software. It is supposed to look different for different people. It’s supposed to have browsers make decisions for you so that overtime it can improve doing so. By adding these nowraps you reduce the legibility of the wikicode, for a minor rendering issue that will confuse absolutey no-one. It also messes with the wordbreaking algorithm of browsers (for instance when i have a stylesheet to hyphenate words before linebreaking, then this nowrap would mess with that). If the parent element is narrower than the word, then it will either overflow or be forced down the page to where there is space (especially problematic on mobile. Nowrap is evil and should be avoided to where it is absolutely necessary. The templates description doesn't say ‘use sparingly’ for nothing. —TheDJ (talkcontribs) 10:28, 13 October 2018 (UTC)
Changing {{nowrap|"(musician)"}} to {{nowrap|"(}}musician)" would avoid interference with browser hyphenation of words but further reduce the legibility of the wikicode and still bloat the html so I don't support it either. If there are browsers breaking between )" then should we also write {{nowrap|"(}}musician{{nowrap|)"}}? No thanks. PrimeHunter (talk) 11:12, 13 October 2018 (UTC)

“Math extension cannot connect to Restbase”

Hi, am I the only one getting the following error on G-test?

Failed to parse (MathML with SVG or PNG fallback (recommended for modern browsers and accessibility tools): Invalid response ("Math extension cannot connect to Restbase.") from server "/mathoid/local/v1/":): {\textstyle \hat{\theta}}

--78.54.45.5 (talk) 08:54, 14 October 2018 (UTC)

I made a null edit to the page and the error has gone away for now. Jc86035's alternate account (talk) 10:50, 14 October 2018 (UTC)

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)

Question about a block

I helped a reader create an account. They wanted to edit but they were unable to edit as an unregistered editor because of a range block. they now have an account, but even after logging him they get a message that they are not permitted to edit because of a block.

I must be missing something — I thought if one had a registered account, the good edit while logged in even if their IP happen to be part of a range block.

If anyone reading this happens to be an OTRS agent, they provided a screenshot of the message.

ticket:2018101510004415 --S Philbrick(Talk) 17:44, 15 October 2018 (UTC)

If the block is a hard one, it will prevent editing even by registered accounts. Ruslik_Zero 19:00, 15 October 2018 (UTC)
Ruslik0, I can imagine applying a hard block to a static IP, but I wouldn't have expected such a block to be applicable to a range.
The range is 94.197.120.0/23 and the block message is (anon. only, account creation blocked, cannot edit own talk page). S Philbrick(Talk) 19:48, 15 October 2018 (UTC)
What is the exact text of the message? Ruslik_Zero 20:00, 15 October 2018 (UTC)
It appears to be anon-only, and while it is globally blocked as well, Just Chilling disabled the global block. Should be able to edit thru the block, I would think. SQLQuery me! 20:05, 15 October 2018 (UTC)
Just Chilling, That's what I would expect, but they shared a screenshot which look like they are logged in but blocked S Philbrick(Talk) 20:15, 15 October 2018 (UTC)
What I did (or at least think I did!) was to locally disable the global block and then install an anon-only en block. When this problem arose with schools, the advice that we gave that seemed to work, was to make a few edits on a clear IP, to establish the account, before going back to the blocked IP. I don't have the technical knowledge to speculate why this worked but it is worth a try. Just Chilling (talk) 00:43, 16 October 2018 (UTC)
I had a similar thing happen a few weeks ago. I was using a VPN (proXPN, Toronto server IIRC) and was logged in, but got a message that the IP address was blocked when I tried to edit a page. (I could try to find the IP address of that VPN server if needed, but it has been dropping my connection frequently in the time since then, so I haven't been using it.) Just Chilling, the advice to make a few edits from elsewhere doesn't seem like it would have been helpful for me—I've been editing with this account once in a while for many years. PointyOintment · 20:37, 17 October 2018 (UTC)

Tech News: 2018-42

22:40, 15 October 2018 (UTC)

veaction=editsource

Hi. I'm wondering why do I keep getting "&veaction=editsource" in the URL address when I try to edit a page. I'm guessing this is something that has to do with Visual Editor/wysiwyg (which is something I'm not interested in using, at the moment) and I made sure to de-select the option "Temporarily disable the visual editor while it is in beta" in my Editing Preference. Any help or guidance here will be greatly appreciated. Thank you. --Ciphers (talk) 04:04, 16 October 2018 (UTC)

@Ciphers: veaction=editsource is in an edit url giving mw:2017 wikitext editor when you have enabled "New wikitext mode" or "Automatically enable all new beta features" at Special:Preferences#mw-prefsection-betafeatures. If you don't want it then disable both. "de-select" means to not select so I'm unsure what you want. If you don't want VisualEditor then select "Temporarily disable the visual editor while it is in beta" at Special:Preferences#mw-prefsection-editing. 2017 wikitext editor and VisualEditor are not the same. PrimeHunter (talk) 09:41, 16 October 2018 (UTC)
Thanks a lot @PrimeHunter:. That seems to have solved the issue, for sure. Thanks again. --Ciphers (talk) 12:15, 16 October 2018 (UTC)
Pedantic detail: The 2017 wikitext editor (aka "new wikitext mode" or "VisualEditor's wikitext mode) is part of VisualEditor (the extension). It is not, however, the visual editor (aka "VisualEditor's visual mode"), which is the thing (currently, the only thing) you use for editing that looks like a word processor.
If anyone knows where I can get a refund for the hours of my life that were consumed by the meetings about naming this, please tell me. Whatamidoing (WMF) (talk) 17:34, 16 October 2018 (UTC)
(said with love:) A refund, as in you want us to take back the money that the WMF paid you to attend those meetings? We volunteers will have to have a meeting about that.Jonesey95 (talk) 04:51, 17 October 2018 (UTC)

Reverse curve in pageviews graph

Pageviews martin hellinger.PNG

Has anybody come across a reverse curve and loop in a pageviews graph before? This is in the {{annual readership}} at Talk:Martin Hellinger, but please discuss at mw:Template talk:Graph:PageViews#Reverse curve. --Redrose64 🌹 (talk) 08:12, 17 October 2018 (UTC)

Redrose64, no idea, but the actual numbers show a lot of 0 in the data. It seems that this graph uses quite a bit of easing and i suspect that those two combined are the cause of this. Not sure if that an error in the module or the graph lib.—TheDJ (talkcontribs) 20:20, 17 October 2018 (UTC)
Yeah, the problems might be from the fact that the article was created very recently (October 10) and the graph shows days before that. SemiHypercube 20:39, 17 October 2018 (UTC)

Template:NJT links

Hi there, I was doing some edits to Millington station, and came across Template:NJT links. The template doesn't seem to be working. Thanks. Magnolia677 (talk) 22:36, 17 October 2018 (UTC)

I read the documentation at Template:NJT links and made the required updates [11][12] to match a 2016 move from Millington (NJT station) to Millington station. {{NJT links}} now produces two working links at Millington station#External links. PrimeHunter (talk) 23:17, 17 October 2018 (UTC)
@PrimeHunter: Thank you! Magnolia677 (talk) 16:10, 18 October 2018 (UTC)

Khan squash family#Family tree

I'm not sure where to really ask this, so I figured this might be a good place. Was wondering if someone who is familiar with the formatting of family trees could take a look at the one in the this article. It could just be my computer, but the tree is seems to be too wide to fit on the page. It's probably just in need of a tweak or something. -- Marchjuly (talk) 00:59, 18 October 2018 (UTC)

Repeatedly logged out

Hi, Over the past hour or 2 I've been repeatedly logged out and ticking the "keep me logged in for 365 days" doesn't seem to achieve anything, Never had the problem before and as far as I know everything my end is sound so didn't know if there was some sort of bug here,
I'm about to go to bed so if anyone replies I'll respond in the next 8-9 hours,
Many thanks, –Davey2010Talk 03:33, 18 October 2018 (UTC)

I was having this issue briefly. It's usually related to a corrupted cookie. My issues cleared up after 5-10 minutes. Let us know when you're back from the dream lands if it is still happening. --Izno (talk) 03:52, 18 October 2018 (UTC)
Hi Izno, Oh okay I had no idea corrupted cookies could cause it - Learn something new everyday! :), All seems fine now so maybe it was a corrupted cookie, Many thanks for your help, Thanks, –Davey2010Talk 12:42, 18 October 2018 (UTC)
@Davey2010: If you experience problems with your login, one thing to try is to deliberately log out. This action might not destroy a corrupt login cookie, but it will invalidate all login cookies bearing your login ID, on all machines, no matter how old (or how recent). Then when you next log in, you get served a fresh clean cookie, and any corrupt cookies that you may still have will not be recognised should they be sent back to the Wikimedia servers. --Redrose64 🌹 (talk) 22:45, 18 October 2018 (UTC)
Hi Redrose64, Ah okay brilliant thank you I'll try that if it happens again, Thanks for the handy tip :), Thanks, –Davey2010Talk 23:38, 18 October 2018 (UTC)

Annoying message on top

Can the following message be disabled? This is the current revision of this page, as edited by Nizil Shah (talk | contribs) at 09:57, 18 October 2018 (ce1). The present address (URL) is a permanent link to this version. (diff) ← Previous revision | Latest revision (diff) | Newer revision → (diff)

It's pretty annoying... Capankajsmilyo(Talk | Infobox assistance) 04:31, 18 October 2018 (UTC)

In common.css, add this:
div.mw-revision { display: none; }

HTH Dax Bane 05:20, 18 October 2018 (UTC)
If you only want it removed for the current revision and not a similar message for older revisions then use:
div#mw-revision-info-current { display: none; }
PrimeHunter (talk) 09:42, 18 October 2018 (UTC)

border color of 1px wikitable borders

Hi! How can I get a 1px-border of red, if class="wikitable"? Doc Taxon (talk) —Preceding undated comment added 13:36, 18 October 2018 (UTC)

red border color missing
red borders of 2px are too thick
@Doc Taxon: there is a lot of oddity with precedence of 1px borders, a hack is to use style 'double', as a double border has higher precedence, but the same appearance like this:
hacked 1px red border color
xaosflux Talk 14:21, 18 October 2018 (UTC)
thx a lot indeed Doc Taxon (talk) —Preceding undated comment added 14:27, 18 October 2018 (UTC)

How can I permanently hide the page curation rightside toolbar

When I open new pages from the Special:NewPagesFeed, I now get on those pages on the right side a (to me) annoying large page curation toolbar overlapping the text. With the uppermost button I can minimize it, and then with "X" I can hide it completely, but I have no interest in doing this on every page again and again. I have looked in preferences, and I can't find a way to get rid of this new thing I don't need or want (I have an unobtrusive Twinkle dropdown at the top of the page for the thngs I need, and I don't need things like "go to next page in the queue"). Fram (talk) 09:20, 19 October 2018 (UTC)

@Fram: once you close it it should stay closed unless you click on 'curate this article' on the side pane. If you want to hide it, you can put the following in Special:Mypage/common.css
/* Hide the page triage toolbar */
#mwe-pt-toolbar{display: none !important;}
xaosflux Talk 12:02, 19 October 2018 (UTC)
It stays closed on that article, but it reopens on every new article I open from the new pages. Thanks for the css code but I don't use or want special css, these kind of changes shouldn't be made in general without an opt-out function as they are rather intrusive and not wanted by everyone. I can't find this change announced here at all, but it's not always easy to find these things. Fram (talk) 12:13, 19 October 2018 (UTC)
Hello @Fram:, can you please check if ?showcurationtoolbar=1 is in the URL? If it's there, then the curation toolbar will always shows up maximized. If you minimize or close the toolbar and navigate to another page that's in the Special:NewPagesFeed queue and don't have ?showcurationtoolbar=1 in the URL, then you should see see the toolbar minimized (if you minimized before) or "Curate this article" in the tools section (if you closed it). KHarlan (WMF) (talk) 13:37, 19 October 2018 (UTC)
Hi @Fram: I'm not seeing any change that should be causing this, the page curation bar has been around for a long time, and it should only activate if you load it on purpose with "curate" command, and should go away once you minimize it, then close with the x. If you have multiple tabs, close all but one, refresh the page, then try minimize/x closing it, then restart your browser and see if it stays away. — xaosflux Talk 12:34, 19 October 2018 (UTC)
Looking at Wikipedia talk:New pages patrol/Reviewers#NPP Browser broken, there clearly were problems with this last week (when too many people didn't see the curation toolbar, so I guess someone from the devs made a change which now shows it too often... Fram (talk) 12:43, 19 October 2018 (UTC)
See Wikipedia_talk:Page_Curation#New_Issue?, some changes have been made this WP:THURSDAY as per phab:T206580 Galobtter (pingó mió) 12:44, 19 October 2018 (UTC)
Thanks, hadn't seen that, I'll post my concern there. Fram (talk) 13:22, 19 October 2018 (UTC)

Importing an image from one wikipedia to other

I would like to know the reason why I am not able to use the file Allauddinum Albhutha Vilakkum.jpg([link]) on Malayalam wikipedia.Adithyak1997 (talk) 10:57, 19 October 2018 (UTC)

File:Allauddinum Albhutha Vilakkum.jpg was uploaded to the English Wikipedia as a non-free image for use in a specific article with a fair use claim. Files can only be used if they are uploaded to the same wiki or to Wikimedia Commons. Commons does not accept non-free images so you would have to upload a copy to the Malayalam Wikipedia, assuming non-free images are allowed for the purpose by the wiki. Wikis have different rules and I don't know anything about Malayalam. PrimeHunter (talk) 11:08, 19 October 2018 (UTC)
@PrimeHunter By downloading that image(or copying)and reproducing it in Malayalam Wikipedia, do create any violation of rights in English Wikipedia?Adithyak1997 (talk) 11:17, 19 October 2018 (UTC)
The English Wikipedia has no rights which can be violated here. It is the rights of the copyright holders which must be respected. I don't know which procedures the Malayalam Wikipedia has for this but it may involve ml:Template:ScreenshotU. PrimeHunter (talk) 11:42, 19 October 2018 (UTC)

Watchlist problem?

Were the radio buttons used to be.

I've noticed today that my watchlist is no longer differentiating between changes I've seen and changes I haven't. Each entry now just starts with the same period/full stop. Using Firefox on Mac, and no relevant preference options that I can see. Tried Chrome on Mac too, and the differentiation between seen and unseen changes also does not show. Anyone else seen this, and any idea what the problem is? Boing! said Zebedee (talk) 12:54, 19 October 2018 (UTC)

Same here, using Firefox 62.0.3 under Windows 7, 32-bit. The bullet points are now much smaller (are the size of periods) and undifferentiated. Dhtwiki (talk) 13:09, 19 October 2018 (UTC)
I've got the same problem. Chrome Version 69.0.3497.81 (Official Build) (64-bit) on a Windows 7 terminal. Simonm223 (talk) 13:19, 19 October 2018 (UTC)
  • What options do have enabled under "Watchlist" at Special:Preferences#mw-prefsection-gadgets ? — xaosflux Talk 13:31, 19 October 2018 (UTC)
    I have the following three enabled...
    Geonotice: display notices on your watchlist about events in your region
    Display watchlist notices
    (This loads the base style for the watchlist. Please do not disable this option.)
    The other three are disabled. If I enable the "Display pages on your watchlist that have changed since your last visit in bold" it marks the new changes in bold so I can at least see what's new, but it doesn't effect the bullet points - instead of solid and hollow? bullet points, they're still just periods. Boing! said Zebedee (talk) 14:19, 19 October 2018 (UTC)
  • Does the problem go away if you select "Hide the improved version of the Watchlist" in Special:Preferences#mw-prefsection-watchlist? — xaosflux Talk 13:34, 19 October 2018 (UTC)
    It restores functionality but with a very different interface. Simonm223 (talk) 13:39, 19 October 2018 (UTC)
    Not for me, no. It shows solid bullet points instead of periods, but for everything and does not distinguish between seen and unseen changes. Boing! said Zebedee (talk) 14:19, 19 October 2018 (UTC)

Same problem. Face-sad.svg YoPienso (talk) 13:43, 19 October 2018 (UTC)

It was bad enough to make it monochrome several weeks ago. This is worse. YoPienso (talk) 13:49, 19 October 2018 (UTC)
  • @Boing! said Zebedee: are you seeing bold vs unbold differences on the lines? — xaosflux Talk 14:26, 19 October 2018 (UTC)
    I'm seeing bold vs unbold only if I enable the "Display pages on your watchlist that have changed since your last visit in bold" pref. Boing! said Zebedee (talk) 14:41, 19 October 2018 (UTC)
I'm having this problem as well. Everything looks normal (bold and unbold) except that each line begins with a period. Natureium (talk) 14:31, 19 October 2018 (UTC)
  • Gah this is horrible. Makes maintaining Wikipedia very difficult. "Hide the improved version of the Watchlist" under Preferences -> Watchlist returns two colors "green" for "not reviewed" and "blue" for "review" but than you loss some of the other improvements such as "filters". Doc James (talk · contribs · email) 16:41, 19 October 2018 (UTC)
Can't you still tell what you have any haven't clicked based on what is bold? Natureium (talk) 16:45, 19 October 2018 (UTC)
As User:Xaosflux suggested I turned on under "Preferences -> Gadgets" "Display pages on your watchlist that have changed since your last visit in bold" and that forms a suitable work around. Thanks Doc James (talk · contribs · email) 17:23, 19 October 2018 (UTC)

Hi all -- I'm Marshall Miller, product manager for the WMF Growth team. This is definitely an important issue, and we're looking into it now. We will keep everyone updated here and on the Phabricator task. -- MMiller (WMF) (talk) 17:36, 19 October 2018 (UTC)

I noticed this yesterday. I also have noticed that since yesterday morning US Eastern Time, no new changes have shown up. I presume this is because work is being done? If so it would be nice to have some sort of bannered notice about what's going on, what progress is being made and when we can expect normal service to resume. Daniel Case (talk) 17:52, 19 October 2018 (UTC)
I've put in some temporary CSS that should fix this issue on English Wikipedia for now. I will now work on a proper fix, because we can only fix one wiki at a time this way, and the issue affects all ~900 WMF wikis. --Roan Kattouw (WMF) (talk) 18:12, 19 October 2018 (UTC)
Thanks Roan Kattouw (WMF), I had just added a notice as Daniel Case requested, if people with the issue can confirm this is solved we can take the notice down. — xaosflux Talk 18:15, 19 October 2018 (UTC)
I think you can take the notice down anyway. The symptoms appear to be limited to editors who are running a volunteer-maintained gadget written some years ago by User:Edokter. It is not widely used except among long-time editors at this wiki, and it is solved by not using the gadget. Whatamidoing (WMF) (talk) 18:19, 19 October 2018 (UTC)
What gadget? I wouldn't say I'm a long-time editor, but I'm having this problem. Natureium (talk) 18:29, 19 October 2018 (UTC)
It's a series of gadgets, grouped under the "Watchlist" heading at Special:Preferences#mw-prefsection-gadgets. If you are still having problems, even after reloading your watchlist, then you should be able to resolve them by ticking the box in that section that says "Display pages on your watchlist that have changed since your last visit in bold".
I believe there had been some talk a while ago about resetting the gadgets system so that new accounts would just have normal MediaWiki behavior, rather than using this system. The original purpose of the gadget you need to enable was to disable the gadget that disables normal MediaWiki software functions, which is unnecessarily confusing. Whatamidoing (WMF) (talk) 18:39, 19 October 2018 (UTC)
With all of the "Watchlist" options in the Gadgets prefs disabled, I still see the problem with both seen and unseen changes showing as periods with no distinction. Do you have a "non-gadget" set of prefs to make it work properly? Are you saying the bullet point changes version should not be used and we should rely on the bold/non-bold version permanently? Boing! said Zebedee (talk) 18:42, 19 October 2018 (UTC)
Oh, and the "Display pages on your watchlist that have changed since your last visit in bold" pref is in the gadgets section, so is that the gadget that you're suggesting we should not use or not? I'm really getting quite confused by what you are saying here. Boing! said Zebedee (talk) 18:44, 19 October 2018 (UTC)
  • I am having this problem on all my browsers, even mobile. L293D ( • ) 19:11, 19 October 2018 (UTC)
  • @L293D: are you having the problem with moved pages that Wumbolo is having, or the problem with the indicators? — xaosflux Talk 19:31, 19 October 2018 (UTC)
Problems with indicators. L293D ( • ) 19:33, 19 October 2018 (UTC)


─────────────── I put my workaround in the "watchlist base" gadget, assuming that nobody would have it disabled (because it's enabled by default, and its description tells you not to disable it), but aparently 482 users have disabled it anyway. I'll move my workaround to MediaWiki:Common.css so it actually applies to everyone. --Roan Kattouw (WMF) (talk) 19:29, 19 October 2018 (UTC)

We have deployed a permanent fix for the issue (and therefore removed the temporary CSS fix). After refreshing your browser, the watchlist should be behaving as expected and back to normal now. Please let me know if any of you are still experiencing the original issue, and thank you for your patience as we worked on this. There is only one outstanding issue: when using highlighting, all highlighted rows have filled-in circles, whether they are seen or unseen. The fix for that is written and will be deployed on Monday. -- MMiller (WMF) (talk) 20:57, 19 October 2018 (UTC)

Moved page issue on WL

I can confirm this bug. Steps to reproduce: Watch the redirect "Grievance Studies" affair but do not watch the target Grievance Studies affair. Enable "Expand watchlist to show all changes, not just the most recent" at Special:Preferences#mw-prefsection-watchlist. The watchlist then includes entries like this:
  • (diff | hist) . . "Grievance Studies" affair‎; 12:14 . . (+523)‎ . . ‎Al83tito (talk | contribs)
The diff and hist links say curid=58713610 and title=%22Grievance_Studies%22_affair. The links go to the diff and history at Grievance Studies affair. Page information says 58713610 is the page ID of Grievance Studies affair [13] while the redirect has page ID 58824385 [14]. curid overrides title on the hist link so it goes to the history of Grievance Studies affair and not the redirect. If curid is manually removed [15] then the title is used and it shows the history of the redirect. Like Wumbolo, I have verified that Grievance Studies affair is not in Special:EditWatchlist. Only the redirect is there. The error happens both with and without "Hide the improved version of the Watchlist" at Special:Preferences#mw-prefsection-watchlist. I tested other recent page moves and they don't have similar errors when you only watch the old title. PrimeHunter (talk) 22:23, 19 October 2018 (UTC)
United States presidential election, 1896 and Draft:Jean Morrison are examples of other recent moves where the page has recent edits which show up when you only watch the redirect. The watchlist only shows edits made before the move. If you swap the watchlist entries to only watch the new title and not the redirect then edits made before the move disappear from the watchlist when they should have been shown, while edits made after the move are shown as expected. PrimeHunter (talk) 22:44, 19 October 2018 (UTC)

Deleting pages

It is taking an unusually long time. Wikipedia is otherwise normally responsive.--Bbb23 (talk) 19:36, 19 October 2018 (UTC)

I've been experiencing this as well (see my thread at WP:AN). Mass delete seems particularly slow.--Jezebel's Ponyobons mots 22:52, 19 October 2018 (UTC)
Same. Noticed it ~10 hours ago when I did some bulk deletions with Twinkle. ~ Amory (utc) 00:27, 20 October 2018 (UTC)

Template:TardisIndexFile

The TardisIndexFile template affixed in the "External links" section of every article on a Doctor Who episode is faulty and/or outdated. These links all lead to empty error pages. I would fix the template myself if I knew exactly which part of the code was the culprit.Bjones (talk) 22:31, 19 October 2018 (UTC)

@Bjones: looks like this just provides an external link to wikia, such as [16] - this should be able to be adjusted, but we would need to know where to point these links to on wikia. Do you know what an example wikia link for this would be? — xaosflux Talk 22:38, 19 October 2018 (UTC)
This is a problem specific to mobile and specific to Wikia's redirection on their site. It's not our fault. There's a thread somewhere recently on this page or its archives of an IP having an issue. Please contact the people at Wikia support. --Izno (talk) 22:54, 19 October 2018 (UTC)
This is a variant of the problem at Wikipedia:Village pump (technical)/Archive 169#Links to Harry Potter wiki but Wikia's behaviour has changed since then. I guess [www.wikia.com] redirected to [tardis.wikia.com] or another working url in the past. Now it doesn't for me with Firefox on Windows 10 but [www.wikia.com] does redirect correctly for me. At the time of the old thread, the issue only affected some mobile devices, and the link without C: didn't fix it. Now it seems to affect more or all user agents, and dropping C: fixes it in some cases. It requires more testing considering the number of Wikia wikis and devices but maybe the Wikia entry at meta:Interwiki map should change from [www.wikia.com] to [www.wikia.com] to increase the number of working links without fixing all of them. Or maybe somebody should ask Wikia what they are doing. For the old example, [www.wikia.com] and [www.wikia.com] are both broken for me so removing C: doesn't work there. [harrypotter.wikia.com] works but I haven't found a working url where harrypotter:Hermione_Granger is a substring as required for wikia:harrypotter:Hermione Granger to be fixable. I will post to meta:Talk:Interwiki map#Wikia. PrimeHunter (talk) 23:27, 19 October 2018 (UTC)

Proposals

RfC: Notify pending-changes reviewers during large backlogs

Should random pending changes reviewers be notified when the backlog is too large? Enterprisey (talk!) 07:25, 18 September 2018 (UTC)

The pending changes backlog sometimes grows to over 20-30 pages, some of which have been waiting for over a day. This situation is not ideal because there are over eight thousand editors who could take care of them. Thus, a bot should be written to notify pending changes reviewers (PCRs) when the backlog gets too large. This RfC covers only opt-out methods of doing the notification. One proposed method: a bot pings a small number of random PCRs on a central page, to avoid spamming talk pages. A given user would only be pinged once every few months, also to avoid spam. PCRs who have recently reviewed changes wouldn't be pinged, because they presumably already know. There could be a maximum edit count/tenure of PCRs who get pinged. (Although a couple of experienced users noted on the idea lab discussion that they just forget S:PC exists, so that may not be the best idea.) The effect of the pings on reviewing activity will be recorded, and used to adjust how many PCRs are pinged.

This RfC is only for opt-out notifications. This idea was first discussed at the idea lab section. Enterprisey (talk!) 07:25, 18 September 2018 (UTC)

Survey (Notifying PCRs)

  • Support as proposer. Enterprisey (talk!) 07:25, 18 September 2018 (UTC)
  • Please no the watchlist banner is annoying enough to the point I had to beg someone to make a .css workaround so I don’t see it. I’d support getting rid of pending changes as a form of protection that solves nothing while creating more work for everyone involved. I know it will be opt-out, but we really shouldn’t have to opt out of something like this. TonyBallioni (talk) 07:29, 18 September 2018 (UTC)
    TonyBallioni, the odds that you personally get pinged as a result of this are very small. Backlogs don't happen that often, and there are 7,038 other PCRs. It doesn't even have to ping admins. Enterprisey (talk!) 08:04, 18 September 2018 (UTC)
    We should probably pare that number down to editors who've been active in the last 30 days. No point pinging inactive users. — AfroThundr (u · t · c) 08:11, 18 September 2018 (UTC)
    Yup, I'll keep it to recently active editors. Enterprisey (talk!) 08:18, 18 September 2018 (UTC)
  • Oppose - There is already a perfectly good template for reviewers who wish to remind themselves to work on the backlog when it grows a little too large. I fail to see the utility in implementing this. EclipseDude (talk) 07:43, 18 September 2018 (UTC)
    The template doesn't seem to be working very well. Enterprisey (talk!) 07:47, 18 September 2018 (UTC)
    It seems to work decently well for me (once I discovered it existed). I added a fork of it to my user page, where I'm more likely to notice it, since I kind of use my page as a home page. — AfroThundr (u · t · c) 08:11, 18 September 2018 (UTC)
    Yeah, the template itself works fine, but it doesn't seem to be driving enough traffic to S:PC - hence the backlogs. Enterprisey (talk!) 08:18, 18 September 2018 (UTC)
    Perhaps the template should be displayed more prominently on WP:PC instead of as a footnote. Many reviewers are likely unaware of its existence. — AfroThundr (u · t · c) 08:21, 18 September 2018 (UTC)
  • Comment This would be better suited (IMHO) as an opt-in process. After advertising on the Village Pump, there'd likely be plenty of active participants who would sign up for this (myself included). Benefits of making it opt-in:
    • ensures you don't annoy other users who don't want to be bothered by a bot
    • ensures a higher likelihood of an actual response from the users pinged
    • increased frequency of pings to users since they actually want the pings
    As I mentioned in the original discussion, having users opt-in via a template (or signing a central page) would be a good method of doing this, and could even allow for the editor to specify their ideal notification criteria. — AfroThundr (u · t · c) 08:07, 18 September 2018 (UTC)
    Yeah, if this doesn't pass I'll write an opt-in bot instead. I just figured an opt-out bot would be more effective. Enterprisey (talk!) 08:09, 18 September 2018 (UTC)
    Second this. I would be more supportive of an opt-in process. EclipseDude (talk) 08:11, 18 September 2018 (UTC)
  • I don't have problem with this, but please make it "opt-in." –Ammarpad (talk) 14:38, 18 September 2018 (UTC)
  • (Summoned by bot) Comment Would support an opt-in version of this and/or if the PERM page was changed to make it clear that this was opt-out going forward for people granted the PERM that would be OK with me too. In general I think there's value in people with PERMS being alerted to backlogs. Best, Barkeep49 (talk) 14:58, 20 September 2018 (UTC)
  • Oppose opt-out if this is going to include all sysops (who also have pending changes review access) - else, perhaps this could be a css controlled watchlist banner ("There are %somehighnumber% of backlogged pending changes")? — xaosflux Talk 15:06, 20 September 2018 (UTC)
    This will not include sysops. I considered a banner, but I only want to notify a very limited number of people about this, to reduce the overall level of annoyance. There's already a banner, I think, but it doesn't show count. Enterprisey (talk!) 22:06, 20 September 2018 (UTC)
    @Enterprisey: I think you get a banner if there are any PC's that are for pages on YOUR watchlist. I'm suggesting that IF (PC log>n)&&(usergroup in reviewer) => SHOW BACKLOG BANNER. — xaosflux Talk 22:18, 20 September 2018 (UTC)
    Ah, I get what you're saying. Enterprisey (talk!) 22:51, 20 September 2018 (UTC)
    I think this is an intriguing approach to the problem. Best, Barkeep49 (talk) 01:41, 21 September 2018 (UTC)
  • Oppose I don't see this as a major problem, and the tried-and-true approach of complaining on WP:AN if the backlog is severe enough (more than 75 articles to review or 48 hours) should be sufficient. There's no issue with a rate-limited opt-in reminder system if people want that. power~enwiki (π, ν) 22:03, 24 September 2018 (UTC)
  • (Summoned by bot) Oppose an opt-out system, but an opt-in system seems useful. I am guessing that enough editors would volunteer to be pinged once the backlog reaches a certain size. Pinging PCRs without their approval may cause more annoyance than it is worth. Hrodvarsson (talk) 00:09, 3 October 2018 (UTC)
  • Support if opt in - this would be seriously irritating to be notified of for random people making up the enormous pending changes user right. However an opt-in system has something to say for it. I'd suggest 60 articles/36 hours as a better point for this to occur. Nosebagbear (talk) 14:46, 6 October 2018 (UTC)
  • Support Opt in only per others. It would be incredibly annoying for a message to be sent to thousands of people just to resolve a very temporary 30-80 edit backlog. Moreover, with that many people, you'd probably have everybody jumping on the same examples, which would result in a lot of annoying duplicate work and edit conflicts. — Insertcleverphrasehere (or here) 14:20, 11 October 2018 (UTC)
  • Strong support opt-in and support on opt-out (if admins are not included). If you aren’t interested in PCR, why do you have the permission for it? There’s a backlog that needs to be addressed and it relates to editor retention - if a user’s first edit is to a PC page and they don’t see it go live soon after (or at least see it reverted with a reasonable explanation), they might get confused or give up with editing. Bilorv(c)(talk) 10:50, 15 October 2018 (UTC)
I (and other PCs) can be interested in an aspect of Wiki and be beneficial without wanting to be pestered by it. On that logic, admins should receive help requests on all aspects because they went through the toil of RfA for all the admin rights. Nosebagbear (talk) 20:18, 16 October 2018 (UTC)

Make "view-source" an optional tab for the left of the search bar.

The view source tab would be good for the bar because it would make it easier if you want to look into wikicode and see how some formatting was used and borrow templates and citations that you need without the risk of accidentally ruining anything on the page in question. It already exists as a replacement for edit on protected pages.

What do you guys think? Discuss-Dubious (t/c) 13:55, 3 October 2018 (UTC)

@Discuss-Dubious: 'view-source' just goes to &action=edit, it is not a function to just call. — xaosflux Talk 15:58, 3 October 2018 (UTC)
Oh, okay then. Hmm. I wonder if making a new action for non-protected pages is a good technical fix. Where can I go to propose that? Discuss-Dubious (t/c) 19:49, 3 October 2018 (UTC)
phab: --Redrose64 🌹 (talk) 20:47, 3 October 2018 (UTC)
@Discuss-Dubious: Also, if you don't want to change the source, I think you can just click "edit source" and when you're done, leave without clicking "Publish changes", so that nothing happens. SemiHypercube 16:02, 3 October 2018 (UTC)
Yes, I know about that. That was what I did prior to creating this proposal. I thought the idea would better facilitate this by entirely removing the element of risk I perceive of accidentally publishing a page where you have casually pressed "cut" instead of "copy" entirely. Discuss-Dubious (t/c) 19:49, 3 October 2018 (UTC)
You could also use &action=raw to view the wikisource, but depending on your browser settings this may open a file download (or open) requester instead of displaying it... —PaleoNeonate – 20:39, 3 October 2018 (UTC)
This sounds like a good idea to implement the idea. We can call that. Discuss-Dubious (t/c) 17:56, 9 October 2018 (UTC)
@Discuss-Dubious: have you tried that option? On some browsers it prompts a file stream download, and on others it displays the HTML content section - this does not help achieve your original proposal at all. — xaosflux Talk 22:38, 9 October 2018 (UTC)
I haven't used it on a browser which prompted a download. However, I do think something could be made from it. Discuss-Dubious (t/c) 01:45, 14 October 2018 (UTC)
If you enable "Prompt me when entering a blank edit summary" in Preferences -> Edit, you won't save the changes you unintentionally made if you accidentally click "Publish" instead of "cancel". Unless you've also unintentionally added an edit summary, of course, but what's the odds of that? --RexxS (talk) 22:29, 11 October 2018 (UTC)
I don't always see reason to use an edit summary, though. That's a good idea, but not sure it's really for me. Discuss-Dubious (t/c) 01:45, 14 October 2018 (UTC)

Why isn't mobile number and / or email required for new User Creation?

Duplicate of comment posted at the help desk, and elsewhere Ivanvector (Talk/Edits) 13:37, 8 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.

A lot of time is wasted in sockpuppet investigations and still they seem to have infested Wiki.My suggestion is to require email and / or mobile validation to create new accounts on Wiki. Existing users should also provide them to continue using their IDs. Email authentication is free of cost and easiest to set up, while mobile number verification may require sending an OTP to the number which can have a minuscule cost involved of sending an SMS. Email verification would be sufficient since to create new email IDs, the companies send OTPs to the mobile and user cannot register multiple email IDs linked to a single mobile number. Even small websites have these type of validations then why can't Wiki? Since sockpuppetry is becoming a nuisance on Wiki. Hopefully something gets done in this regard, if this is not the place for suggestion kindly let me know where to write it. Thanks! — Preceding unsigned comment added by 117.222.30.200 (talk) 13:21, 8 October 2018 (UTC)

Folks watching this page: there was a discussion about this same thing very recently, possibly still ongoing, which I read but didn't participate in and now I can't find it. If someone here knows what I'm talking about, could they ping the IP? Cheers. Ivanvector (Talk/Edits) 14:57, 8 October 2018 (UTC)
That would be the idea lab. --Izno (talk) 15:06, 8 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.

Bot to add external party originality flag to new pages feed

Hello all, a new bot request is open at Wikipedia:Bots/Requests for approval/EranBot 3 regarding adding a new attribute to Special:NewPagesFeed for suspected Wikipedia:New_pages_patrol#Copyright_violations_(WP:COPYVIO). Feedback on usage and verbiage is welcome at the BRFA. — xaosflux Talk 17:36, 10 October 2018 (UTC)

@Xaosflux:--Was the section-header-title constructed by you? WBGconverse 05:01, 11 October 2018 (UTC)
@Winged Blades of Godric: for this section? Yes. Tried to keep neutral, as I have more specific opinions in the other discussion. This bot will read new submissions, submit them to a third party who will generate a rating related to the originality of the text, then if the rating response is unoriginal will insert a 'potential copyright violation' flag here for further review. Much more details in the BRFA. — xaosflux Talk 11:37, 11 October 2018 (UTC)

RFC:Close MedCom?

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)
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)

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)

RfC: should we automatically pending-changes protect TFAs?

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)

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 easily 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)

Alternative proposal: semi-protect TFAs

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)

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)

Suggestion re IPA

As an English speaker not familiar with the IPA, it took me quite a while to find the "Pronunciation respelling for English" page. It would be most helpful if a link to a central directory of such help pages could be inserted in the left column of Wikipedia, Wiktionary, etc. — Preceding unsigned comment added by Gar*1746 (talkcontribs) 04:41, 15 October 2018 (UTC)

I think you have something here. I have long wondered at the actual utility of providing IPA translations as I don;’t believe most people understand how it works or are helped by their inclusion in articles. Phonetic translation seems much more accessible to a general audience. Beeblebrox (talk) 19:12, 15 October 2018 (UTC)
It is, they are, and it has come up before. I'm too tired to go look up the links now (I expect a search of the MOS archives will find them), but expect any attempt to remove/replace (it with something useful) to come up against strong opposition. The usual argument is 'phonetic isnt standard' - which is true to an extent due to dialect differences vs 'No one knows how to use IPA' - which is also substantially true if you consider the readers of articles. Only in death does duty end (talk) 22:01, 15 October 2018 (UTC)
Hovering over IPA does provide tooltips like "k in kind" which is helpful, but as the vast majority of people don't know IPA, so have I wondered at their inclusion.. Galobtter (pingó mió) 11:56, 16 October 2018 (UTC)
And “hovering” only works if you are using a mouse, which with the prominence of touchscreens an increasing number of users do not. I haven’t used one regularly since 2011. Beeblebrox (talk) 18:10, 19 October 2018 (UTC)

RfC for creating a featured quality source review process

Following discussions at Wikipedia talk:Featured article candidates about the process for source reviews of featured article candidates, a request for comment has been opened about creating a new "featured quality source review" process. Please check out the proposal at Wikipedia:Featured article candidates/Featured quality source review RfC and add your feedback. --RL0919 (talk) 18:07, 17 October 2018 (UTC)

Change to election/referendum naming format

There was a recent RfC on changing the naming convention for elections and referendums to move the year to the start (in common with most other event naming formats). The RfC was advertised to numerous WikiProjects (Elections and Referendums, Politics, Politics of the United Kingdom, U.S. Congress, Pakistani politics, New Zealand/Politics, Indian politics, Chinese politics and Australian politics) and was closed with consensus in favour.

When I started the RfC, I said I would request a bot run to move the articles if the change succeeded; this has been done, and there is currently a live bot request, where it's been suggested that the change should also be flagged up here for any last comments, as it will involve moving around 35,000 articles. Cheers, Number 57 21:15, 17 October 2018 (UTC)

Oppose the bot, which is now being discussed at Wikipedia:Bots/Requests for approval/TheSandBot. (Why didn't @Number 57 link to the BRFA?)
Inadequate consensus at RFC, esp in relation to using a bot to bypass WP:RM on such a huge scale. The RFC was poorly attended (only 16 !votes), and I re-read the discussion several times before I spotted the mention of a bot in the last line of the RFC nomination.
No other participant in the RFC mentioned the bot, so it is unclear whether any of them had noticed it.
Also note that none of the WikiProject notifications I have checked mentioned using a bot to bypass WP:RM on >32k articles. And while nearly all countries have elections, only those countries with standalone politics projects were notified at all. The lack of a standalone politics project is no reason to deprive editors in other countries of any notification. E.g. I just used WP:AWB to count the Irish articles which are likely to be renamed: 860 of them under Category:Elections in Ireland matching (\d\d \(Ireland\)|\d\d)$. Same method found 118 in Brazil, and 211 in Germany.
So editors working on elections in Spain, Ireland, South Africa, Vietnam, Kenya, Peru and over 200 countries receive zero warning of this until their watchlist lights up as a bot starts renaming articles. There is even a suggestion at the RFA for the bot to be unthrotted[17], which would make impede the chances of other editors to raise objections.
So the consensus to change the guideline is weak. And I don't see a consensus to use the bot -- that is too big an issue to bury in the small print.
This needs a fresh RFC, with much better notification, in which the question of changing the guideline is clearly separated from a decision on whether to use a bot. --BrownHairedGirl (talk) • (contribs) 05:25, 19 October 2018 (UTC)
@BrownHairedGirl: The BRFA is linked, click on "live bot request". As for the rest of the statement, I am all for further consensus (and therefore a new RfC). That said, if there was a decision to uphold the current one, then it would be unrealistic to dump 35,200+ articles into WP:RM. That would probably turn some heads as being disruptive in nature and is also unrealistic to be done entirely by hand. Given this and the sheer number of pages involved, it could be logically implied that a bot was/would be intended to enact said consensus (if reached, whatever form that may be, assuming a large number need moving). --TheSandDoctor Talk 05:58, 19 October 2018 (UTC)
@TheSandDoctor: Ah, sorry - I didn't spot the link (low contrast on my screen). I have struck that comment.
Glad we agree about the RFC. But I wasn't suggesting a lump of 35k articles thrown into WP:RM. Instead, take time to allow scrutiny. E.g. run them through RM in clusters, or run RFCs on particular sets. Move involve a lot of manual work, so it may be appropriate to have some less far-reaching bot, e.g. a bot to hnadle making WP:RM listings for clusters. There are many possible solutions in between the poles of 35k individual RM nominations and a bot doing it all in one batch with no further notification or discussion. --BrownHairedGirl (talk) • (contribs) 06:24, 19 October 2018 (UTC)
  • Oppose - when we sign comments, the year does not come first. Vorbee (talk) 07:56, 19 October 2018 (UTC)

Idea lab

Redesigned page-protection padlock icons

Redesigned icons (right) compared to the existing icons and descriptions (left)
Protection redesign - XYZt.png

I redesigned the page-protection padlock icons for a more minimalist and intuitive look. The redesigned icons use solid colors, since the shiny reflections off of the current ones make the edge hard to distinguish from the background. Some less-used protection icons now have symbols on them for clarity. For example, a create-protected page has a plus sign, and a cascade-protected page — where all pages transcluded onto the page are also protected — has a chain symbol.

Changes from original
  • One solid color instead of colored metallic texture
  • No shadows
  • No glow
  • Minimum 3:1 contrast ratio (WCAG AA 2.0 compliant)
  • Thicker shackle that matches the color of the main body
  • Rounded rectangle main body
  • Embedded white symbol for some padlocks

Posted by XYZt (talk) at 00:17, 29 September 2018 (UTC) — Updating over time — Thank you for your feedback and suggestions! I think I'll have a proposal posted by next weekend. Due to school projects, I won't be able to post the proposal and respond to questions from Monday to Wednesday.

The edges on the padlocks have a glow that make them appear to be fading into the background

Looks nice. I don't think really need to change the locks though. funplussmart (talk) 00:38, 29 September 2018 (UTC)

Thanks! In my opinion, the main problem that the current locks have is that they have parts that blend in with the white background (e.g. the white glow at the edges, a thin shackle). I think having a solid colored version is easier to see. The embedded icons are another idea that I think would help people identify the locks' different purposes. XYZt (talk) 00:49, 29 September 2018 (UTC)

These look great! The addition of icons to some of the less common locks is really helpful, I'm not sure how anyone can remember them from colour alone. the wub "?!" 16:43, 29 September 2018 (UTC)

I agree, these look great and are a clear improvement.Tazerdadog (talk) 18:58, 29 September 2018 (UTC)

Hmm, I think the current set looks a little "smarter", however these are significantly clearer and more useful when it comes to easily knowing what each padlock indicates. Given that clarity is key, I'd happily support these as better. They would require alteration of some of the most used templates, so I imagine there might be some opposition just on those grounds, rightly or not. Nosebagbear (talk) 22:53, 29 September 2018 (UTC)

Support implementation. The fade into background was a particular problem on mobile and for us editors with Corrected vision. I like the symbols int he middle as well. Thanks for doing this. Thanks, L3X1 ◊distænt write◊ 00:03, 30 September 2018 (UTC)

Support implementation, seems like they could be usable in mobile view. @XYZtSpace: Side note, if these were actually implemented, would these images be new files or replace the old ones? SemiHypercube 01:01, 30 September 2018 (UTC)

I'd advocate making them with new names so the old ones would stay around for archival purposes. Thanks, L3X1 ◊distænt write◊ 01:03, 30 September 2018 (UTC)
The old ones will still be visible on each file's revision history (note that for files, the image history is available on the same page as the main image). Posted by XYZt (talk  |  contribs) on 01:12, 30 September 2018 (UTC)
Thanks. These images would probably be uploaded as an revision on the old files' pages, as these icons are linked by about 30 protection templates combined. Changing the file link on each template would be time-consuming. Posted by XYZt (talk  |  contribs) on 01:12, 30 September 2018 (UTC)
XYZtSpace, all the templates use one module - the images are defined in one place, Module:Protection_banner/config Galobtter (pingó mió) 14:18, 30 September 2018 (UTC)
@Galobtter: Got it, thanks! I guess that eliminates the need to upload the redesigns to the same file names then. -- XYZt (talk  |  contribs) 23:04, 30 September 2018 (UTC)

I believe all wikis use the locks, so I think any change like this should probably be proposed on meta. I'm not sure though. funplussmart (talk) 01:03, 30 September 2018 (UTC)

@Funplussmart: we can change these locally without impacting any other project. The "default" is nothing; we shadow the commons file names (e.g. File:Padlock.svg) to maintain local protection and control of the image. — xaosflux Talk 01:53, 30 September 2018 (UTC)
That's why I said "I'm not sure". funplussmart (talk) 01:54, 30 September 2018 (UTC)
If you want to propose these globally, the template one shouldn't rely on the English "T" as it's interior markup. — xaosflux Talk 01:56, 30 September 2018 (UTC)
Perhaps having "{{}}" instead of "T" would do it. funplussmart (talk) 02:03, 30 September 2018 (UTC)
Someone else suggested that too. I'm not sure if it would fit though. Will test it out later. Posted by XYZt (talk  |  contribs) on 02:25, 30 September 2018 (UTC)
Update: I'm not sure if it's as eligible as the "T". Posted by XYZt (talk  |  contribs) on 02:31, 30 September 2018 (UTC) Lock-bracket-protection-test.png
The two brackets on the right are too close together. Can you try to make them equidistant? funplussmart (talk) 02:36, 30 September 2018 (UTC)
They are actually the same distance apart as the left pair. I made the distance between them farther now Bracket-protection-magenta-test2.png
Instead of {{}} try just {}. — xaosflux Talk 02:48, 30 September 2018 (UTC)
I think the last one looks okay. funplussmart (talk) 02:50, 30 September 2018 (UTC)
() I would say that { is probably sufficient, even, if we didn't want to use a T. The T has the advantage that there are less curves and points to render relatively. --Izno (talk) 23:28, 30 September 2018 (UTC)
It seems that Wikidata uses a lock design similar to this already, though the color appears to be somewhat different. For example, check the lock on the top-right of Wikidata's main page. Does this have any relation to you, XYZt? —Nøkkenbuer (talkcontribs) 15:25, 30 September 2018 (UTC)
That's cool! I don't use WikiData often and didn't notice it. No relation whatsoever. -- XYZt (talk  |  contribs) 16:23, 30 September 2018 (UTC)

Pale colors, especially yellow but also pale blue, do not stand out well on white background. They need a black border or other detail. Jim.henderson (talk) 02:34, 30 September 2018 (UTC)

Thanks for the feedback. I made the yellow, teal, and light blue locks a bit darker. Posted by XYZt (talk  |  contribs) on 02:56, 30 September 2018 (UTC)
In general, please ensure these are WCAG AA if not AAA compliant against the background. --Izno (talk) 06:24, 30 September 2018 (UTC)
Well, they're certainly better than the current locks. Create and Pending Changes were always the hardest to spot, for me. Thanks, L3X1 ◊distænt write◊ 13:45, 30 September 2018 (UTC)
I make no judgement of the current locks; just asking that WP:Accessibility#Color be observed. --Izno (talk) 14:25, 30 September 2018 (UTC)
For an aesthetic point of view the originals look like padlocks whereas the new ones look like so many handbags. Tinky Winky anyone? Martin of Sheffield (talk) 16:21, 30 September 2018 (UTC)
I thought that the similar lock designs currently used at Wikidata also somewhat resembled handbags. However, the padlock icon is deeply embedded in Wikipedia symbolism, so I doubt anyone will be confused about it and newcomers can easily figure it out. It will, at worst, be a potential accessibility improvement at the cost of creating an obscure running joke in the commmunity. As far as I am concerned, being able to better see the icons and distinguish them without referring to the documentation is worth the unending terror of administrators saying that "protection of article X is now in the bag" and that they "bagged the article". —Nøkkenbuer (talkcontribs) 17:49, 30 September 2018 (UTC); edited at 17:53, 30 September 2018 (UTC)
Do not awaken my ability to rant for hours on locks and lock types… :P Thanks, L3X1 ◊distænt write◊ 01:11, 1 October 2018 (UTC)

I'll be honest I do prefer the current ones only because I hate change and because it's what I've been used to seeing for the last 5-6 years, That being said I do like these and I also like the little symbols on the locks which helps to differentiate between locks, Somewhat unrelated but touching on Nøkkenbuer's comment I also like the fact they're near-identical to the ones used on Wikidata, (Never used WikiData but just liked the locks).

All in all I think they look great although I do wonder if having a black border around the padlock and lock may be better?, Dunno but anyway I like these :). –Davey2010Talk 16:53, 30 September 2018 (UTC)
I guess when it comes to minimalism, even divergent designing tends to converge due to the constraints of minimalist aesthetics. In any case, I have no opposition to the new designs. Like Davey2010, I also like the internal icons, which help with decoding the padlocks and reinforce the meaning of the color scheme.
My only suggestions would be to check for color accessibility and ensure AAA-level contrast, which may be achievable by simply darkening the colors if they are not already compliant; and to consider disambiguating all the padlocks with icons so that they are useful even when stripped of their color. For the latter, the semi-protection symbol can be a shield icon with the left half filled and the other, empty half given a dotted outline; full protection can be a full shield; and extended confirmed protection can be something like a shield outline with a smaller shield filling it. —Nøkkenbuer (talkcontribs) 17:26, 30 September 2018 (UTC)
An addendum: I want to note that the additional icons suggestion is just that and I understand multiple reasons why including icons on those three may be undesirable. Even without any internal icons, I am still not opposed to the change, if only because the new design is more visually accessible. —Nøkkenbuer (talkcontribs) 17:36, 30 September 2018 (UTC)
I was able to make them meet AA-large standards, but meeting AAA would turn the gold lock into a (frankly disgusting) shade of brown, and make Pending Changes darker than what Semi is now. However, black outlines is a viable solution to this. XYZt (talk  |  contribs) – 07:52, 1 October 2018 (UTC)
I am fine with that and understand it entirely. The prior colors were no issue for me; I just want to encourage accessibility considerations as a matter of principle. The fact that it's even AA-compliant is already far more accessible than is often the case in the Internet, nevermind the fact that the design itself improves accessibility over the current one. Whether AAA-level compliance is reached is probably not an issue; and the demographic for which AA and AAA compliance is a determinative difference is probably very, very small. None may even use Wikipedia, at least not in ways that are relevant to this proposal, and I frankly doubt Wikipedia is generally AAA-compliant. If I recall correctly, our wikilink colors aren't.
Regardless, I don't think it will be ground for anyone to oppose your proposals, myself included. Thanks for being so responsive to the feedback. —Nøkkenbuer (talkcontribs) 14:41, 1 October 2018 (UTC)
By the way, XYZt, it seems your design is indeed at the vanguard of contemporary web aesthetic, since Mozilla Firefox and Google Chrome also use a similar padlock to indicate valid HTTPS connections. If these are "handbags", as has been alleged, then it seems the movers and shakers of the Internet are into handbags, too. —Nøkkenbuer (talkcontribs) 14:51, 1 October 2018 (UTC)

@XYZtSpace: Even though the black lock is hardly used (but probably since Office actions are very rare), do you think you could change the black lock so that it has a silhouette of the WMF logo on it to emphasize that it is done by the WMF Office? SemiHypercube 23:22, 30 September 2018 (UTC)

Good idea. XYZt (talk  |  contribs) – 23:26, 30 September 2018 (UTC)
@SemiHypercube: I tried it out and it isn't quite as legible as the "O" even after increasing the thicknesses of the lines.
Semi tesseract suggestion.png
XYZt (talk  |  contribs) – 02:30, 1 October 2018 (UTC)
@XYZtSpace: Have you tried making the lock, and the others, SVG files instead of PNG? The current locks are SVG files, so making the new ones SVG might make them legible. SemiHypercube 12:24, 1 October 2018 (UTC)
That's not how svg files work. My graphics software rendering a vector shape at 15x20px is the same quality as Wikipedia rendering an svg at 15x20px. And at this scale, file size doesn't matter much anyway. XYZt (talk  |  contribs) – 14:57, 1 October 2018 (UTC)
I assume all present understand that this will require a consensus at WP:VPR, and we're just deciding the specifics of that proposal. In my opinion that should be an RfC, considering the very high visibility of the change. Thanks, just making sure. ―Mandruss  16:07, 1 October 2018 (UTC)
I think I'll divide the proposal into two parts — One for changing the locks into solid colors, and one for the embedded symbols. XYZt (talk  |  contribs) – 17:06, 1 October 2018 (UTC)
Gray shackles
I like the concept, but I would make the shackels a standard gray color on all the locks to make them look less like shopping bags (#949494 is the lightest gray that meets accessibility requirements). I've seen lots of colorful locks, but almost all have silvery shackles. Also, while the PNGs are fine as a concept, I would like to see these as SVGs before implementation. --Ahecht (TALK
PAGE
) 21:38, 1 October 2018 (UTC)
I think the idea is to be very symbolic, not realistic. Also, I care less than none about resembling a handbag. I remember significant opposition to the "Your notices" icon now in use at the top of each page, because it would look like a bra to some. The predicted outcry did not materialize. I also note that the handle of a handbag often has a different color from the body. ―Mandruss  21:53, 1 October 2018 (UTC)
I'll upload all the SVGs in a few hours. XYZt (talk  |  contribs) – 00:29, 2 October 2018 (UTC)
@Ahecht: Here are the SVGs. XYZt (talk  |  contribs) – 21:43, 2 October 2018 (UTC)
@XYZtSpace: Could you upload a template-protect padlock with curly braces as you said? And could you also try making the office protect lock with the WMF logo on it? (Though the licensing might(?) have to be different because it uses a logo? Or is a licensing change not needed?) SemiHypercube 21:23, 2 October 2018 (UTC)
@SemiHypercube: The WMF logo is in the public domain. XYZt (talk  |  contribs) – 21:42, 2 October 2018 (UTC)

As the one who first commented about the new designs looking like hand/shopping bags, may I say that the grey shackle design is much clearer and they do look like padlocks now. Martin of Sheffield (talk) 22:01, 2 October 2018 (UTC)

  • Given that comments seem to have stalled out, I'd say once @XYZtSpace: is free (hopefully on Thursday (11th Oct)) they should shift this to Wikipedia:Village pump (proposals) - it should also be requested to be placed on centralised discussions Nosebagbear (talk) 19:13, 7 October 2018 (UTC)

These are great. A lot easier to understand than the old locks, too. MoonyTheDwarf (BN) (talk) 19:35, 10 October 2018 (UTC)

The new locks are easier to understand and more noticeable than the older ones. I support changing the locks, as long as all the locks are changed to have a grey shackle. 344917661X (talk) 00:47, 11 October 2018 (UTC)

@XYZtSpace: I like the new icons. Are they based on the ones used at Wikidata? I think the two sets should probably use consistent colours (except maybe where the older set doesn't have enough colour contrast). Jc86035's alternate account (talk) 06:10, 14 October 2018 (UTC)

Semi-protected suggestion

@XYZtSpace: These are very good icons, and I support the change. I have one suggestion, though: a different one for "semi-protected"; something that emphasizes the semi aspect.    → Michael J    14:20, 17 October 2018 (UTC)

i like the gray shackle versions  pythoncoder  (talk | contribs) 02:27, 19 October 2018 (UTC)

That's a good suggested change by @Michael J:, I like it. Not sure which school system @XYZtSpace: is on, but next week is half term in a lot of places, so that might offer a chance to move this great set of work to Proposals for the full RfC. I think the key bit we really need to hear now is from the template experts who can tell us of how much difficulty a change on this scale may have. Nosebagbear (talk) 22:50, 19 October 2018 (UTC)

Temporary non-admin page protection

Will it be a good idea to have a new permission where a non-admin can temporarily protect a page to stop heavy Vandalism? For example, sometimes there are pages which get vandalised at a very fast rate and due to a very large backlog, an admin might take some long time. An example is this article, which was vandalised so heavily by different users and IPs that it not only took a lot of time, but also confusion. The page protection took some time due to the backlog. The permissions of this protection can be made strict, and only trusted users who are active in RC patrolling can be given it. What do you people think? Knightrises10 (talk) 12:21, 1 October 2018 (UTC)

@Knightrises10: Actually, there was an RfC on this not too long ago. Reading this might be helpful for developing this, if it will pass. SemiHypercube 12:31, 1 October 2018 (UTC)
@SemiHypercube: I'm going through that discussion and think that it's correct to say that an admin can take away the right in case of abuse, just like they do on rollback. Also, the page can be protected just for like 15 minutes or less. Need some suggestions. Should I take this to proposals? Knightrises10 (talk) 12:46, 1 October 2018 (UTC)
Probably dead on arrival. This is proposed about every six months and no formulation has come close to reaching a broad consensus in favor of implimentation. GMGtalk 13:42, 1 October 2018 (UTC)
So it should rather be forgotten it means? Knightrises10 (talk) 13:53, 1 October 2018 (UTC)
At least in my opinion, it's almost guaranteed to be a non-productive use of time, at least until some future date when the feelings of the community at large shift toward more radical unbundling of sysop rights. No idea when or if that might actually happen. GMGtalk 14:40, 1 October 2018 (UTC)

─────────────────────────I'm not often in disagreement with GMG (And to be fair that editor isn't opposing this idea, just opining that it is unlikely to be successful).

I could be in support of a proposal to give very limited protection capability to some class of users. My proposed class would be extended confirmed (I wouldn't mind a somewhat more stringent criteria but this one is easy and creating a new class sounds like a lot of work). The capabilities would be semi-protecting only (not full protection) and limited to 15 minutes. The harm that could come to the encyclopedia if someone incorrectly semi'd an article for 15 minutes is absurdly small, while the benefit is meaningful. Abusers, after a first warning, could have the right removed. If even this small proposal seems too much, make it a six-month trial and see how it works. Seems to me that an immediate semi on an article being repeatedly vandalized to give time to post to AIV to request more substantial measures (longer semi, blocking offending party) is a pretty reasonable step.--S Philbrick(Talk) 14:51, 1 October 2018 (UTC)

Oh yes. To clarify, I would personally support such a proposal, and I even drafted one myself last year at User:GreenMeansGo/Page protector. I simply don't think the community will support it, and more to the real problem, the opposition isn't on one or two central issues that can be fixed by amending the proposal itself. Opposition has always been broad and based on a half-dozen or more issues that can't be easily reconciled. GMGtalk 14:56, 1 October 2018 (UTC)
Unfortunately, the last time it was proposed, most of the community opposed it with the reason it will lead to abuse. Rollback also has same concern, but isn't it working pretty well - users who abuse the rollback have their rights taken away. Knightrises10 (talk) 15:21, 1 October 2018 (UTC)
Looking over it broadly, the opposes include all the following:
  • Potential for abuse/protection warring
  • Conflict with having a protect button but not a block button, and/or not a delete button, and/or not an unprotect button, and/or not able to see deleted edits
  • Users who can be trusted to protect should just become admins anyway/users who can't become admins shouldn't be given this right to begin with
  • How this tool might interact with the ability to unprotect, to unprotect pages protected by another non-admin, or to unprotect pages protected by an admin
  • Potential degradation of status as “the encyclopedia anyone can edit”
  • Solution looking for a problem/ RFPP works well enough to render the right unnecessary
  • Concern that it is easier to grant an unbundled right than it is to remove it
  • Concern that this would add an unofficial prerequisite to RfA
  • Semiprotection is already overused
I don't see a way to adjust a proposal to account for the majority of those oppose rationales. GMGtalk 15:35, 1 October 2018 (UTC)
  • As told before, permissions can be taken away.
  • Protecting button should be considered different from deleting button. I don't think they should be compared, as block and deletion are something more sensitive.
  • Rollbackers, reviewers are also trusted users but not admins. A user can be trusted and yet not an admin.
  • The pages will only be protected on case of heavy Vandalism, so it will remain an encyclopedia that anyone can edit. Admins also protect pages, but we don't call it degradation of encyclopedia because it's necessary at that time.
  • Again users shouldn't be allowed to unprotect pages protect by others.
I can answer some. But as Sphilbrick said, we can at least try this for some months, giving this right at the moment to only a few very trustworthy users. Knightrises10 (talk) 15:47, 1 October 2018 (UTC)
One idea that could be considered is NeilN's proposal that was suggested in the RfC, which many people thought was good. SemiHypercube 15:58, 1 October 2018 (UTC)
Read his idea and I think that should have no concern - Knightrises10 (talk) 16:05, 1 October 2018 (UTC)
So guys, I'm taking this to proposals as I think it can have another debate. :| Knightrises10 (talk) 18:53, 1 October 2018 (UTC)
  • Just a tech note: Adding new "access groups" is EASY, adding a new technical workflow is not - for one it would require that there are developers that want to work on it (in this case a new tech process to build this protection workflow). — xaosflux Talk 19:58, 1 October 2018 (UTC)
  • @Knightrises10: - as well as the full, recent, RFC there was a also a discussion following on to specifically consider shorter protection. In a sense it was a discussion of NeilN's proposal that garnered more support during the RFC. I was unsure enough both of the level of support and of my own personal views to take it onto proposals, but it's worth a read, I feel.
I've also cut out a rough summary of points that were agreed as a good starting basis:
  1. Protection would be limited to semi-protect.
  2. Protection duration would be limited to between 45m-3 hours (TBD).
  3. Right holders ("RHs") could only protect the same page once within 24 hours.
  4. RHs could only protect 2 pages within one hour.
  5. There would be stringent requirements at WP:PERM to acquire this right. At a minimum: 2000 posts (or 1500 mainspace?), a clean 6 month block record, registered user for 150 days, proven track record in Counter-vandalism, proven track record in Requests for Page Protection.
  6. The right could only be used in Main or Talk (not including User Talk) namespaces.
  7. Right could only be used in instances of vandalism from multiple IPs/newly registered accounts. Alternate uses of protection (such as against unsourced details etc) would not be permitted
There was some specific dispute on this point:
8. Use of the right must be accompanied by a full request for some form of page protection at WP:RFPP. Failure to do so would be deemed a mis-use of the right.

Nosebagbear (talk) 14:53, 6 October 2018 (UTC)

I would support any attempts to create a non-admin page protection right given that RPP is one of the most frustrating parts of the site given the current admin shortage, the criteria listed above were created in a discussion I participated in but feel that they are far too stringent.The harm 1 or 2 innaporitate semi-protects can do is minimal compared to the amount of vandalsim granting this ability could prevent.Zubin12 (talk) 15:13, 6 October 2018 (UTC)
Hi @Zubin12: - The harm of some inappropriate semi-protects could do bigger than some missed vandalism - on some active pages it could prevent dozens of individuals from editing, it also grants certain users significant power in any potential editing dispute without them having gone through the full RfA rigmarole. Additionally, you need to look at the maximum size the RFPP backlog gets to - the issue is usually some remaining on the list for extensive periods of time, rather than dozens at once overwhelming present admins. Thus a fairly small additional core of users with limited abilities would at least reduce the issues. Finally, on a bluntly pragmatic front, strict criteria improve the chances of agreement that one of the triple-prong of core admin rights isn't being challenged. Nosebagbear (talk)
I do think a time in point 2 could be higher, but I don't think longer than 4-6 hours could be justified, however a time of 3 hours seemed a rough compromise of the points up to the point when I scribbled the above down Nosebagbear (talk)

Accounts without email addresses

Background:

Many editors forget their passwords. If they have an email address associated with their account, they can request a password reset, but if they don't have an email address associated with their account they are out of luck. This is understandably upsetting and disappointing to such editors. Wikipedia's policy is that registered users are not required to maintain a working email address, but many editors are unaware that there is no provision to reset a password without such an address.

If you've worked at the helpdesk, you've seen occasional such requests. If you are an OTRS agent, you've seen hundreds of such requests over the last few years. It's never fun to explain to someone with an active account that they have to discard it and start over. I'd like to cut those down considerably, and I'd like to be in a position that if it happens ever again, I can politely point out that they affirmatively chose this option knowing the consequences.

Proposal: I suspect that there will be resistance to requiring that registered editors have a working email address, so I don't propose to change that. However, I think it would be worth making it clearer to editors that lack of an associated email address means that in the case of a lost password, their only option is to create a new account.

At present, if you create an account through the ACC tool found at: Wikipedia:Request an account, you will have to initially supply a working email address. In contrast, if you create an account here: Special:CreateAccount, The request for an email addressed is marked optional. There is nothing on that page informing editors of the severe consequences of failing to provide an email address.

One option is to change that page to make it clear that while optional failure to include the address could lead to severe consequences if you forget your password. I know we want that page as simple as possible, but we could let people create an account without an address only if they affirmatively check a box indicating that they understand the consequences.

A second option is to make it mandatory on that page but let them know that they could remove the email address if they choose at a later time.

Removing the address can be done through preferences which does indicate some of the consequences but I'd like to see it more explicit. I wouldn't uglify that page with bold red text, But if an editor chooses the option to remove their email address they are to receive a pop up box with ugly bold red text informing them of the consequences of this action and insisting that they click a checkbox indicating that they understand.--S Philbrick(Talk) 18:18, 1 October 2018 (UTC)

I support the principle of having a huge "do you understand the risks?" warning box before allowing account creation without an email address. I totally oppose making it mandatory; the WMF has notoriously lax security, and as someone who themselves has had their email address leaked by them, I can entirely empathise with someone not wanting the WMF to get their paws on any personally identifying information, particularly if they're working on something politically or culturally sensitive. If we do go down the mandatory email route, at the very least we need to point out the risks of sharing information with the WMF, and ideally to talk signups through the mechanics of creating a burner account on a free email site. ‑ Iridescent 18:30, 1 October 2018 (UTC)
  • As an admin, when I'm about to move a page over another page that already exists, when I click the move button, the dialog reloads with an informational message informing me of what I'm about to do, and includes a new check box forcing me to acknowledge that I'm about to delete the other page. It's an extra-step nag screen that forces me to acknowledge my action, you know, in case I didn't understand what I was about to do and might be about to break something. I don't see any reason why we wouldn't do something similar for a user about to create an account with no email address, currently our only password recovery method, just an extra confirmation step that they really want to create an account they'll never be able to recover if they lose access. However, like Iridescent said, I strongly oppose forcing users to supply a working email. Ivanvector (Talk/Edits) 18:58, 1 October 2018 (UTC)
  • We can easily change the prompt at MediaWiki:Createacct-emailoptional, I'll have to check if we can add wikitext there - perhaps to a page about why it is so important? — xaosflux Talk 19:50, 1 October 2018 (UTC)
    Wikitext breaks there due to the special load on the right panel; but it can easily be changed from "optional" to "required for password recovery" or the like. — xaosflux Talk 19:54, 1 October 2018 (UTC)
  • Support the required for password recovery language offered by xaosflux. Best, Barkeep49 (talk) 22:41, 1 October 2018 (UTC)
  • Support/Oppose per Iri. I didn't start off with a password. Thanks, L3X1 ◊distænt write◊ 21:32, 2 October 2018 (UTC)
  • Support this is basically what I suggested a while ago in phab:T159837. Though I move the 'consequence' into an additional confirmation step, instead of into the main interface. —TheDJ (talkcontribs) 07:53, 3 October 2018 (UTC)
  • Support (though this is the idea lab!) language as indicated by Xaosflux. I would be against any mandatory requirement. Nosebagbear (talk) 18:37, 8 October 2018 (UTC)

Why isn't mobile number and / or email required for new User Creation?

A lot of time is wasted in sockpuppet investigations and still they seem to have infested Wiki.My suggestion is to require email and / or mobile validation to create new accounts on Wiki. Existing users should also provide them to continue using their IDs. Email authentication is free of cost and easiest to set up, while mobile number verification may require sending an OTP to the number which can have a minuscule cost involved of sending an SMS. Email verification would be sufficient since to create new email IDs, the companies send OTPs to the mobile and user cannot register multiple email IDs linked to a single mobile number. Even small websites have these type of validations then why can't Wiki? Since sockpuppetry is becoming a nuisance on Wiki. Hopefully something gets done in this regard, if this is not the place for suggestion kindly let me know where to write it. Thanks! — Preceding unsigned comment added by 117.222.30.200 (talk) 13:21, 8 October 2018 (UTC)

For the reasons I've already explained to you in detail last time you asked this, and as also given in detail literally immediately above this post. When you don't like the reply you've been given in one place, the solution is rarely to ask exactly the same question somewhere else. ‑ Iridescent 15:37, 8 October 2018 (UTC)
This is the first time I have brought this issue up myself. That may be someone else you are talking about. Anyways, so wwhat was your opinion back then? Thanks! — Preceding unsigned comment added by 117.222.30.200 (talk) 16:53, 8 October 2018 (UTC)
O RLY? You are aware that this is a wiki and we can see the three other occasions you've asked this, right? ‑ Iridescent 01:13, 9 October 2018 (UTC)
Seems like an SPA except it's an IP, also it was a diffrent person just above that proposed it but still. Remagoxer (talk) 11:23, 12 October 2018 (UTC)

2 grades of watchlist

I find that there are 2 types of article that I have in my watchlist. The first are those that I have edited and have some general interest in any changes/developments. It is not a big problem if I miss something or if there is no activity on the article for a long while. The second category is where I (or another editor) have flagged a problem and am awaiting a response. This could be a {{Citation needed}} tag, or a comment on a talk page. For some "low traffic" articles, it seems to me appropriate to leave these alerts in place for some time before acting on them if there is no response. (I have had another editor get upset when I have acted after flagging an issue 2 weeks previously - so a longer delay seems to avoid dispute.) Relying on memory and a filtered contributions page do not seem to be 100% reliable in picking up any article that I intend to watch in this way.

The solution would be to have an "enhanced watchlist" - just an extra flag you can put on an article where you do not want to miss any activity - and perhaps a facility to show only those enhanced watchlist articles/talk pages with no edits since switching to the enhanced status. (It is this last category that seem most difficult to track effectively.) I would be interested to see if anyone else felt there was value in this change - or if there is an existing solution of which I am not aware.
ThoughtIdRetired (talk) 07:44, 3 October 2018 (UTC)

Yeah, this is a good feature. You can approximate this with MusikAnimal's awesome script User:MusikAnimal/customWatchlists, by creating a "high-priority" custom watchlist. I don't think that last feature is supported, but I pinged Musik to check. Enterprisey (talk!) 07:55, 3 October 2018 (UTC)
That script badly needs rewriting! But it should mostly work :) You can view the "raw list" of pages, not just ones with recent changes, if that helps. By the way this proposal is basically Wikipedia:Perennial proposals#Multiple watchlists. I think we're still a long ways away before we have native support for it. But I can improve customWatchlists, it's been on my to-dos for some time MusikAnimal talk 17:02, 3 October 2018 (UTC)
Thanks. I think my requirement for spotting cases of no activity (after tagging or talk page comment) on certain watchlist articles is different from the archived discussions. It is an editing methodology that seems to work with apparent "fossils" that may or may not have a following with strong opinions. (Some of these fossils are full of the most amazing nonsense, sometimes referenced with sources whose content has little similarity to the article.)
Being more of an "article content" editor, rather than someone who is into the nuts and bolts of Wikipedia, I only have a passing understanding of the technical issues. Bearing in mind that I might have only about 10 articles where I am waiting to see if anyone reacts to a tag or a talk page comment, I might start cutting and pasting a handful of selected article names into a corner of my sandbox. (Or perhaps I could put a section on my user page: "waiting for answers on...") It is only one step better than using a post-it note, but at least it is simple.
ThoughtIdRetired (talk) 19:12, 3 October 2018 (UTC)
Because I didn't see a mention yet in this thread, I wondered if you knew about Special:RecentChangesLinked? This works using pages including custom watchlists, an example: Special:RecentChangesLinked/Wikipedia:WikiProject Skepticism/Skeptic watchlists which shows changes to pages linked in Wikipedia:WikiProject Skepticism/Skeptic watchlists. —PaleoNeonate – 20:54, 3 October 2018 (UTC)
That's a good idea, PaleoNeonate. I think it would work for a lot of people.
MusikAnimal, do you remember whether multiple watchlists has been in the m:Community Wishlist in the past? I think that the maps item last year proved that a little organization can go a long way towards getting what editors need, and I believe that nominations begin soon. WhatamIdoing (talk) 18:10, 4 October 2018 (UTC)
I use a cruder "top and bottom" method. I first look at the top of my watchlist. Most changes are on articles that are not urgent for me, and I don't check them until they approach the bottom of my five days watchlist (recently re-preferenced from six). This has the advantage of keeping me aware of boring, raging content disputes on an interesting topic, without being tempted to stick my nose too deeply into them. On some pages, such as VP, I look into each change when it arrives at the top of the page, at least if the section header and edit summary give a hint that it will interest me. Jim.henderson (talk) 09:58, 5 October 2018 (UTC)
A few years back, I talked with an editor who skipped the first week of her watchlist. This allowed her to skip nearly all contentious discussions and focus on adding content. It seemed like a good idea (only I can't see myself doing it). WhatamIdoing (talk) 03:17, 10 October 2018 (UTC)
We specialize based on our talents. I lack the discipline to cut my watchlist below 5,500 pages, but have the power to detach myself from reaction and take a longer view. So, having left the necessary pig-wrestling to those who have the stomach for it, I come along after the battle to kill the crippled sentences, plug the leaking modifiers, rearrange the disordered paragraphs and so forth. Jim.henderson (talk) 10:43, 13 October 2018 (UTC)

English or Latin?

Considering to open a new portal. Abstract

Extended content

LOGOS (schema)

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42
02 SOFTWARE HARDWARE OUTPUT INPUT F

o

r

m

a

03
04 No cuál? Σ de adonde? 0 eso allí!! AZ qué?
05 MATEMÁTICA INFORMÁTICA ARTE ° IDIOMAS
06 X E

L

E

M

E

N

T

O

No Recta y Plano É

T

E

R

C No Aplicación A

i

R

E

0 Expresión P

I

E

D

R

A

AZ Impresión
07 ARITMÉTICA Σ ASISTENCIA CONCEPTO SEMÁNTICA
08 Σ Operaciones y Tablas G 0 Método 1 Plaza R
09 ÁLGEBRA 1 ADMINISTRACIÓN DISENO ETIMO
10 0 Ecuaciones y Fórmulas A 2 Práctica 2 Museo B
11 ANA 6 DESA BELL SINT '
12 1 Gráficas y Àreas T AZ Teoría 3 Zoo y Jardín K
13 GEOMETRÍA R COORDINACIÓN ESCÉNICAS SEMIO
14 2 Formas y Cuerpos B Archivo 4 Tarima
15 Universidad del Valle, Colombia UV CIVILIZACIÓN EVOLUCIÓN CULTURA C

o

n

f

i

g

u

r

a

c

i

ó

n

16 método experimental
17 R cómo? 3 de que forma? 6 cuándo? 9 Quién?
18 Presentación INDUSTRIA CRÓNICA RELIGIÓN
19 M

E

T

A

L

7 Salud T

I

E

M

P

O

AZ Iluminación F

E

U

E

R

C Destino
20 No. Título 6 FISIO X PSICO 9 BIOGRAFÍA B MÍSTICA
21 Modelo Progreso Origen
22 1 Σ. Resumen 5 ING 8 ANT R MONO
23 xp Automatización Desarrollo Templo
24 p 0. Introducción 4 MECA & TRÓN 7 HISTORIA AZ POLI
25 ÷T Medios Desenvolvimiento Santuario
26 ρ 1. Contenido 3 CONST PRODX 6 ASTRO 9 NATUR
27 Laboratorio Herramienta Concepción Elemental
28 xd³ CUERPO ESPÍRITU ALMA F

u

n

c

i

ó

n

29 m 2. Materiales
30 ÷t 2 con qué? 5 de que modo? 8 porqué?
31 Q 3. Procedimientos NATURALEZA SOCIEDAD FILOSOFÍA
32 xd M

A

D

E

R

A

6 Conservación A

G

U

A

9 Tendencia ! A

L

T

U

P

R

O

F

B
33 M 4. Indicaciones 5 FÍSICA X QUÍMICA 8 ESTAD X SOCIO R EPISTEMO
34 ÷t Laboratorio Distribución
35 F 5. Metodología 4 BIO 7 EDU AZ META
36 Informe Campo Mercado
37 xd 3 AGRO & ALIME 6 COMER & COMUN 9 PARAPSICO
38 E 6. Observaciones Taller Personal
39 ÷t 2 RECUR PRODU 5 TRABA SERVI 8 LÓGICA
40 P 7. Resultados Bodega Contrato
41 PARTÍCULA ONDA E

s

t

r

u

c

t

u

r

a

42 8. Análisis
43 1 sobre qué? 4 a donde? 7 para qué?
44 9. Resultados ☽♁ AMBIENTE GOBIERNO ÉTICA
45 Anexo T

I

E

R

R

A

5 Protección S

O

N

I

D

O

8 Capital ? L

U

Z

R
46 4 VER SORGE ENT 7 UNIDAD X FUERZA AZ METAÉTICA
47 AZ. Glosario Mantenimiento Democracia
48 3 ECO 6 POL 9 DEON
49 R. Registro Adaptación Empresa
50 2 HELIO & METEO 5 ECON & ADMÓN 8 AXIO
51 B. Bibliografía NIcho Constitución
52 1 GEO HYDRO 4 DEREC JUSTI 7 TELEO
53 K. Agradecimientos _ Caja
54 Formúla Estructura Función Configuración

Cloud forest (talk) 20:03, 5 October 2018 (UTC)

What the heck is this? WBGconverse 06:43, 6 October 2018 (UTC)
To editors who are wondering what this is, see also WP:TEAHOUSE#Portal (permalink). Enterprisey (talk!) 07:32, 6 October 2018 (UTC)
Now blocked, as after being warned over a month ago this user is continuing to spam-bomb Wikipedia with inappropriate lengthy posts like this. Their main area of activity is on Wikiversity rather than here; I suspect this is a good faith editor who doesn't understand that what's acceptable over there isn't acceptable here, but they've ignored more than enough warnings by now. ‑ Iridescent 12:19, 6 October 2018 (UTC)

steamboats in the mon

Hi, I have an idea on steamships. I have already created 2 articles, and would want more help. Thank you.Huff slush7264 Chat With Me 13:17, 7 October 2018 (UTC)

If you want any help at all you need to start by giving a bit more information out. What is meant by "steamboats in the mon"? Which articles have you created and what help do you require? I was glad to see you removed that l33t nonsense, it has no place in Wikipedia. Regards, Martin of Sheffield (talk) 16:38, 7 October 2018 (UTC)

Idea: Watchlist page flagging

I think I've pitched this before, but with the recent changes to the watchlist I figured I'd bring it up again. I have close to 15,000 pages on my watchlist and I'd love to be able to flag certain pages in my watchlist with color-coded labels, to make it easier to get to articles that have been recently problematic. Example: If a sock operator is known for editing at Vijay (actor), I would flag the article with the sockmaster's name to make it easier to spot recent flare-ups. Another example: If a film article has seen a lot of users perniciously inflate or deflate box office figures, I might flag the article with a green label so I could get a quick reminder to check it out.

I deal with many Indian film articles, about films in the many languages of India (Hindi, Tamil, Malayalam, etc.) A lot of the titles are meaningless to me, so I might gloss over them in my watchlist. The flagging would be helpful. Thanks for listening! Cyphoidbomb (talk) 13:50, 8 October 2018 (UTC)

That sounds like another idea for the m:Community Wishlist. WhatamIdoing (talk) 03:14, 10 October 2018 (UTC)
@WhatamIdoing: Hmm, seems like that's closed... Cyphoidbomb (talk) 02:00, 12 October 2018 (UTC)
@Cyphoidbomb: The poll is run each year. The next one starts accepting new wishlist items pretty soon. --Izno (talk) 02:06, 12 October 2018 (UTC)

Change "Publish changes" button in Draft Space

Apologies if this has been suggested before - I looked in the archives and didn't see anything - but I think the "Publish changes" button is confusing to many newer editors who are working in draft space. I would like to suggest that in draft space the "Publish changes" button read "Save draft". I don't know how feasible in the mediawiki software this would be to do but think it would help make clearer that what the user's doing by pressing the button. Best, Barkeep49 (talk) 15:50, 8 October 2018 (UTC)

Yes, please. This seems to confuse many new editors that are working on drafts at AfC. Natureium (talk) 15:51, 8 October 2018 (UTC)
@Whatamidoing (WMF): Since I'm pretty sure you have the history/know the people for the last time this button was changed. --Izno (talk) 16:38, 8 October 2018 (UTC)
"Publish changes" was decided by the community, is being implemented by the WMF Editing team, and has the backing of the Legal team. It cannot be changed without the approval of the Legal team.
That being said, back then, it was determined that "some editors worried that this change would confuse new editors. There have been no indications so far that this is the case." That perception may have changed. – Finnusertop (talkcontribs) 16:47, 8 October 2018 (UTC)
I say this only based on my experience trying to help people on IRC who are confused about how to save their drafts. I figured this was not a "easy change" and am glad to know now that it's even more involved than I had realized. Best, Barkeep49 (talk) 22:47, 8 October 2018 (UTC)
As barkeep49 said, this confuses a number of people that come to #wikipedia-en-help and can't figure out how to save their draft to keep working on later, without "publishing" it. Natureium (talk) 22:49, 8 October 2018 (UTC)
I have also seen it repeatedly, coaching at edit-athons, though more often it's a Talk Page that confuses. I would prefer "send" but if that is thought to create an expectation of privacy, then "send public". Jim.henderson (talk) 22:59, 8 October 2018 (UTC)
IMO "Post" might be more appropriate (in English) for talk pages, but there's a fundamental problem: In MediaWiki, all pages get the same button, regardless of namespace.
Barkeep49, would you do me a favor, the next time you get this question? Would you please ask the person if they're looking for a way to privately save their drafts? My impression is that when people ask for a way to save their drafts, they're correctly recognizing that "Publish" is going to make the draft public, and that's not what they want to do. So "Where's the save button?" doesn't mean they can't figure out what the Publish button does; it means they know exactly what the Publish button does, and what that button actually does is not what the users want to do. They want to save the draft privately, until they think it's good enough to post on the internet – which, of course, can't be done. Whatamidoing (WMF) (talk) 20:56, 9 October 2018 (UTC)
I am happy to do that Whatamidoing (WMF). Best, Barkeep49 (talk) 21:44, 9 October 2018 (UTC)
It's been quiet on this front for the last week. I did have someone tonight with this question. They reported that they were looking to save privately but if the button had said "Save draft" they would not have been confused. So mixed result from a sample size of 1. Best, Barkeep49 (talk) 04:01, 16 October 2018 (UTC)
I think one consideration is that even Draft space is not entirely private; stuff posted there can still be found by anyone who gets there through other Wikipedia categories/project pages or through search engines which don't exclude Draft space. Jo-Jo Eumerus (talk, contributions) 09:06, 16 October 2018 (UTC)

Poor articles

Is there a place to list and draw attraction to poor articles, particularly articles which are of high-importance? -Inowen (nlfte) 04:32, 14 October 2018 (UTC)

On your personal "to-do" list perhaps? Failing that the article's talk page, or a related project's talk page. Martin of Sheffield (talk) 07:56, 14 October 2018 (UTC)
I think I found it: WP:AFI. But it seems to need improvements itself. -Inowen (nlfte) 18:51, 14 October 2018 (UTC)

Minor canned edit summaries

For convenience, I think that when a user selects a minor canned edit summary, the minor edit check box should be automatically checked if it hasn't been checked already. Care to differ or discuss with me? The Nth User 23:51, 15 October 2018 (UTC)

@The Nth User: But what if an IP is using it (unregistered users cannot mark edits as minor)? Also, I don't think this is such a good idea, since vandals could use auto-minor edits to further evade vandalism, (in fact, seeing "canned edit summary" tagged onto an edit only attracts my attention when I am recent changes patrolling) so this isn't a good idea even if unregistered users cannot mark edits as minor. SemiHypercube 00:03, 16 October 2018 (UTC)
@SemiHypercube: The first point is easy to fix; just code it so it only checks the checkbox if there is one. The second point may or may not be a problem depending on how most users search for vandalism. I use a personal filter setup at Special:Recent changes, and I doubt that the filters pay attention to the edit summary for the reason that you pointed out: Vandals might use edit summaries like "fixed typos" to mask disruptive edits. However, if most users pay attention to edit summaries when searching for vandalism, then your point is valid, and my change should not be enacted. Care to differ or discuss with me? The Nth User 00:13, 16 October 2018 (UTC)

Miscellaneous


Donna Strickland wins Nobel prize -- without enwiki article

FYI: Donna Strickland won a Nobel Prize in Physics this week (she's now on our Main page of course). It appeared that she had no enwiki article at the time of Nobel announcement. (It was deleted in 2014 for copyright reasons). -DePiep (talk) 20:11, 5 October 2018 (UTC)

And then deleted again later for apparent lack of notability. But apparently some 33% of new Nobel winners have no article, which is slightly surprising. The man who won the Chemistry Nobel the next day had no article either, which has of course received no media coverage whatsoever, whereas this has been all over the media & several discussions here that I can't be bothered to link to (usual places - do a what links here). Johnbod (talk) 22:48, 5 October 2018 (UTC)
For the record, not 'deleted again', declined at article creation (with a request for more sources). Alanscottwalker (talk) 22:50, 5 October 2018 (UTC)
While it's entirely possible that whoever proposed deletion or declined the article creation failed to properly follow WP:ACADEMIC, the coverage of this is rather silly and misunderstands how Wikipedia operates. Are we just supposed to assume that researchers might win a Nobel in the future when reviewing articles? The fact that there are past Nobel winners that don't have articles is far more concerning than someone not having an article prior to winning a Nobel. signed, Rosguill talk 22:56, 5 October 2018 (UTC)
Wow. Johnbod Could you give the wiki page where this number is described & discussed? - DePiep (talk) 11:30, 6 October 2018 (UTC)
Well, List_of_Nobel_laureates lists all and none is a red link. -DePiep (talk) 13:04, 6 October 2018 (UTC)
I think Johnbod means that at the time the Nobel is announced, some have no article; but it is rapidly created due to the Nobel. 33% might be too high but as a regular at WP:ITNC where we do post the announcement of all Nobels, there is at least one or two laureates each year that have no article at the time of announcement, and editors step up to make one based on the weight of the Nobel so that it is done for the ITN posting. But that's also not accounting for how many start in poor shape that would be on the cusp of deletion (in the same manner as Strickland's draft) and get improved. I'd argue its something like 10-15% of Laureates don't have articles when the Nobel is announced, but closer to 60-75% that have very poor articles at that same point in time, all which are created/improved on the announcement. --Masem (t) 13:13, 6 October 2018 (UTC)
It's 13.19% of Nobel Laureates in Physics, Chemistry, and Physiology and Medicine since 2007.[18] GMGtalk 13:32, 6 October 2018 (UTC)
Well, that's one figure. The 33% covers a wider group of 212 Nobel winners, but going right back to WP's start - see User_talk:Bradv#About_your_rejection_of_the_AfC_on_Donna_Strickland. Johnbod (talk) 18:51, 6 October 2018 (UTC)
Did her page not exist because she is a women? No. -DePiep (talk) 21:23, 6 October 2018 (UTC)
We can't really say that in any statistical sense. There are too few women Nobel laureates overall to draw any conclusions. It very well may be the case. Now it may also very well be the case that this was the result of systemic bias, but also that that systemic bias lies largely external to Wikipedia, as some have pointed out, that we are often hamstrung by sources that themselves tend to prefer writing about men. GMGtalk 10:59, 17 October 2018 (UTC)
Another issue that is hard for academics that do not have much coverage until they get an esteemed award is that we have COI problems with BLPs in general where people are posting effective resumes to get hits. We have to err on the side of exclusion if notability is not there in the article. I would argue that Strickland could have passed some tests for notability prior to the Nobel, but those sources to support that were not provided at the state the draft was rejected. We need to stress to editors to make sure that when they create these articles they strive to make it encyclopedic rather than promotions/resume or CV-ish or the like. --Masem (t) 23:18, 5 October 2018 (UTC)
Yup... remember that there are two prongs to WP:Notability - the first is that the subject has to have done something noteworthy... the second is that others (reliable sources) have to have taken note of what the subject did. There are lots of academics who achieve the first prong without achieving the second. Blueboar (talk) 12:57, 6 October 2018 (UTC)
Clerly (TM), the physics editors, the Canadian editors, the Women in Red editors, and the press journalists (not to mention other groups/projects), failed us, they should all be fired. Alanscottwalker (talk) 18:05, 6 October 2018 (UTC)
Getting them fired seems rather harsh, surely fairer that they should have their pay deducted from 28 March to 3 October for failing to anticipate the future actions of the Nobel committee. . . dave souza, talk 00:57, 7 October 2018 (UTC)
Note: The original article in 2014 was deleted as an unambiguous copyright violation. It had nothing to due with notability. Rmhermen (talk) 19:39, 6 October 2018 (UTC)
Where does it say that? Hawkeye7 (discuss) 01:11, 7 October 2018 (UTC)
Admins can see it, and I vouch for what others have said about the deleted version. It was a copyvio outright from university pages. --Masem (t) 01:14, 7 October 2018 (UTC)
Here. You don't need to be an admin to see the deletion log. – Finnusertop (talkcontribs) 16:02, 9 October 2018 (UTC)
Since this was being raised as a persistent question, I had a careful look and the version that was deleted in March 2014 was an exact word for word copy of the two paragraphs of the OSA biography (as archived 2015-08-28) with the order of the paragraphs swapped, and a new opening sentence stating "Donna Strickland is a past president of the Optical Society." So it was a webpage of The Optical Society rather than a university page. . . . dave souza, talk 15:57, 9 October 2018 (UTC)
If anyone is interested, I reviewed scientists who won the Nobel since 2007. There were 12 (out of 91) that didn't have an article at the time that they won. A few more details here: [twitter.com]. Dragons flight (talk) 16:01, 9 October 2018 (UTC)

Arabic diacritics in {{lang}} template in lead

At Zanzibar, someone has removed the diacritics from the spelling of the Arabic name for the territory. Do we have a guideline as to whether or not to provide the vocalized form? Largoplazo (talk) 18:04, 13 October 2018 (UTC)

I didn't find any (if there was one, I guess it would be in Wikipedia:Manual of Style/Arabic#Lead paragraph). Since a strict transliteration is encouraged next to the Arabic text, the non-vocalised form might actually be more useful (for searching etc.), but I don't think it's a difference that merits enforcing in either way. One related guideline is for Hebrew, it says not to include vowels (Wikipedia:Naming conventions (Hebrew)#Vowels and shva). Tokenzero (talk) 12:32, 14 October 2018 (UTC)

Talk:Kosovo Pomoravlje#Title

Talk:Kosovo Pomoravlje#Title --SrpskiAnonimac (talk) 21:03, 15 October 2018 (UTC)

Baidu Baike

Why Baidu Baike (baike.baidu.com) has 16000000 articles but English Wikipedia has 5700000 articles — Preceding unsigned comment added by Amirh123 (talkcontribs) 15:04, 16 October 2018 (UTC)

They have a relaxed approach to copyright issues and notability.©Geni (talk) 20:55, 16 October 2018 (UTC)

but 16000000 is very big — Preceding unsigned comment added by Amirh123 (talkcontribs) 09:06, 17 October 2018 (UTC)

and quality and legality are important for us here. --Zac67 (talk) 09:15, 17 October 2018 (UTC)
As a random example, it has three pages (1 2 3) on exactly the same topic (the Baikonur Cosmodrome). To be fair, the first one seems to have a lot of content than Wikipedia (English or Chinese) does not (even some potentially interesting references, like [1] there). But, for example, the section "Historical events (历史事件)" is just copied from reference 2 there. There are also far fewer references in total, so it's much less likely to be credible. Some articles are known to be copied and plagiarized from Wikipedia, without attribution; some are machine translated (which leads to terrible language quality); see Wikipedia:Mirrors and forks/Baidu Baike. Baidu Baike is also more open to self-promoting content, so people create articles just to advertise themselves. Probably the main factor though is big numbers of very short articles on nonsense topics; for example, one article for each mobile app that provides a few wallpapers (see this search). Tokenzero (talk) 11:14, 17 October 2018 (UTC)

Question

Does the article "Freestyle battle" need to be a redirect to the article "Battle rap", or? --SrpskiAnonimac (talk) 14:30, 18 October 2018 (UTC)