Wikipedia:Village pump (policy)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Winged Blades of Godric (talk | contribs) at 06:22, 14 October 2018 (→‎bureaucrat access to manage copyviobot group: That the BRFA is on hold, for this.......). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

"WP:VPP" redirects here. For proposals, see Wikipedia:Village pump (proposals).
 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts
The policy section of the village pump is used to discuss proposed policies and guidelines and changes to existing policies and guidelines.
If you want to propose something new that is not a policy or guideline, use Village pump (proposals).
If you have a question about how to apply an existing policy or guideline, try one of the many Wikipedia:Noticeboards.
This is not the place to resolve disputes over how a policy should be implemented. Please see Wikipedia:Dispute resolution for how to proceed in such cases.

Please see this FAQ page for a list of frequently rejected or ignored proposals.


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

  • 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)[reply]
  • 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)[reply]
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)[reply]
I do so below. Andrewa (talk) 06:28, 27 August 2018 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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:
 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)[reply]
@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)[reply]
To editor 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • ? 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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]
  • 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)[reply]
    • 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)[reply]
  • 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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]
  • Support restoring. It helps to set the tone and focus, even if not strictly necessary. Peter coxhead (talk) 10:35, 30 August 2018 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]

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

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
As it turns out, you were probably wiser than I. Apologies. Andrewa (talk) 06:15, 28 August 2018 (UTC)[reply]

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

See above. — Rhododendrites talk \\ 14:14, 27 August 2018 (UTC)[reply]
OK... but what exactly is wrong with it? Andrewa (talk) 20:04, 27 August 2018 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Fair enough. I suppose that was a bit harsh. Struck the first part with apologies. — Rhododendrites talk \\ 21:26, 27 August 2018 (UTC)[reply]

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

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

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

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


Heads-up at the project talk page

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

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

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


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

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)[reply]
  • 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)[reply]
@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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
FWIW, I went and left a notification of this RfC at Wikipedia_talk:WikiProject_Figure_Skating.—Bagumba (talk) 10:10, 11 September 2018 (UTC)[reply]

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

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)[reply]
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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
  • 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)[reply]
    • Agree. Normal English-language usage should prevail absent a much stronger rationale than has been suggested. 121a0012 (talk) 03:36, 16 September 2018 (UTC)[reply]
  • 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)[reply]
    Well put. Dondervogel 2 (talk) 12:02, 13 September 2018 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
    • ... 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)[reply]
    • 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)[reply]
      • 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)[reply]
  • 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)[reply]
  • 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)[reply]
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)[reply]
  • 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)[reply]

RFC: Capitalization of Senator

At Talk:Dan_Sullivan_(American_senator)#Requested_move_8_September_2018 it is pointed out that Senator and Senators are often capitalized when they should not be per MOS:JOBTITLES; e.g. should be List of U.S. senators from X, but U.S. Senate and Senator Smith. Do we have consensus to fix this widespread error with the help of scripts, bots, or other tools? -- Dicklyon (talk) 02:05, 14 September 2018 (UTC)[reply]

Political titles are often improperly capitalized. I don't think we need consensus to fix those errors. -- Ajraddatz (talk) 16:24, 14 September 2018 (UTC)[reply]
Agreed with the above from Ajraddatz. --Bsherr (talk) 22:40, 14 September 2018 (UTC)[reply]
We do need consensus. I think you both mean we already have it via clear guidelines, so we don't need this RFC. I tend to agree, but when asking for bot help one needs to be sure. Dicklyon (talk) 03:27, 15 September 2018 (UTC)[reply]
We have consensus per WP:JOBTITLES. We don't have to litigate every single job title individually, the existing policy covers the lot of them. Given the millions of potential job titles, it would get tedious to start an RFC for each of them. On the question of the use of a bot, I tend to lean against the automated fixing, as there is too much opportunity for doing it wrong. But there should be no problem with a human fixing them. --Jayron32 15:17, 24 September 2018 (UTC)--Jayron32 15:17, 24 September 2018 (UTC)[reply]

More specifically, are there any objections to this bot request I just submitted: Wikipedia:Bot_requests#Bot to fix capitalization of "Senator" in specific contexts? I realize this won't fix everything; maybe we can find more patterns that are safe to do automatically. Dicklyon (talk) 03:48, 15 September 2018 (UTC)[reply]

The problem with bots is that they are notoriously bad at determining context. This seems like something that should be done manually. Blueboar (talk) 11:24, 15 September 2018 (UTC)[reply]
As the linked bot proposal shows, this would involve only specific narrow contexts that a bot can easily get right; 250 moves (5 per state) and links to them. Dicklyon (talk) 16:17, 15 September 2018 (UTC)[reply]
I've made multiple objections on that page. Most are technical in nature and don't need to be repeated here. However, I'm not convinced that changing "United States Senator" to "United States senator" is correct. I agree that "American senator" or "Colorado senator" is the correct capitalization, as the word senator is merely a descriptor and not a title in that phrasing. While it's not quite the same, the capitalization of United States Attorney does not appear to be in dispute. power~enwiki (π, ν) 03:50, 16 September 2018 (UTC)[reply]
I'm hoping you'll follow up there to explain; I don't understand your objections. Dicklyon (talk) 00:27, 19 September 2018 (UTC)[reply]

On a related note, I have filed a CFD discussion regarding Category:Alabama State Senators; Wikipedia:Categories for discussion/Log/2018 September 17 is the log-page. power~enwiki (π, ν) 02:39, 17 September 2018 (UTC)[reply]

I support that one. But don't understand your objections to my proposal. Looking forward to clarification on the bot page, as that's where more of the details are. Dicklyon (talk) 03:28, 17 September 2018 (UTC)[reply]
I see these category moves were unanimously supported and executed already. That's encouraging. Dicklyon (talk) 04:34, 27 September 2018 (UTC)[reply]

I support bot treatment, but perhaps it should be by human review. Tony (talk) 03:45, 27 September 2018 (UTC)[reply]

The intention is to do by bot only cases in which human review is clearly not necessary. Please review the revised proposal at Wikipedia:Bot_requests#Bot to fix capitalization of "Senator" in specific contexts and say if there are any reservations about the possbility of a bot following that narrow proposal could need human review. Dicklyon (talk) 04:29, 27 September 2018 (UTC)[reply]

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

The size guidelines are for readable prose size, so citations/references are indeed excluded. Galobtter (pingó mió) 19:10, 17 September 2018 (UTC)[reply]
  • (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)[reply]
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)[reply]
How would a normal editor determine that? People have different experiences with load time. WhatamIdoing (talk) 18:51, 25 September 2018 (UTC)[reply]
  • 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)[reply]
  • As noted to 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)[reply]
  • 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 (talk ⋅ contribs) 02:13, 20 September 2018 (UTC)[reply]
@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)[reply]
  • 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)[reply]
  • 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)[reply]
    • 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)[reply]
  •  Question: Is there any warning displayed during editing when the target value is exceeded? Samsara 18:10, 1 October 2018 (UTC)[reply]
  • 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 (talk ⋅ contribs) 22:01, 6 October 2018 (UTC)[reply]
    • 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)[reply]
  • 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)[reply]
    • 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 (talk ⋅ contribs) 11:27, 12 October 2018 (UTC)[reply]
  • 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)[reply]

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

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

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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Support creator, Oppose significant contributors. --Guy Macon (talk) 16:51, 24 September 2018 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Oppose because watchlists are a thing. --Jayron32 17:28, 24 September 2018 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • Oppose in favor of Option 2 below. shoy (reactions) 18:01, 24 September 2018 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]

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

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)[reply]
  • Oppose as instruction creep. Xxanthippe (talk) 22:33, 24 September 2018 (UTC).[reply]
  • 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)[reply]
  • 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)[reply]
  • Oppose: instruction creep and does not work in some cases. --K.e.coffman (talk) 05:52, 25 September 2018 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Oppose We should not be making creator notification mandatory. — AfroThundr (u · t · c) 22:28, 25 September 2018 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • Oppose as instruction creep and cause no one owns a given page. -DJSasso (talk) 15:48, 27 September 2018 (UTC)[reply]
  • Oppose per above. -FASTILY 05:54, 28 September 2018 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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))[reply]
  • 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)[reply]
  • 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)[reply]

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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Neutral SarekOfVulcan (talk) 15:05, 24 September 2018 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • Oppose significant contributors, Support creator. --Guy Macon (talk) 16:52, 24 September 2018 (UTC)[reply]
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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Support - Better than Option 1 above, reduces bureaucracy. shoy (reactions) 18:00, 24 September 2018 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Support If there are significant contributors then their interest can be assumed. Graeme Bartlett (talk) 08:39, 25 September 2018 (UTC)[reply]
  • Oppose - as per Natureium and Insertcleverphrasehere. Cwmhiraeth (talk) 10:15, 25 September 2018 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
    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)[reply]
    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)[reply]
  • Counter proposal Adopt the same language used at Wikipedia:Articles for deletion#substantial. —Farix (t | c) 18:56, 25 September 2018 (UTC)[reply]
  • Support Notifications to the creator should be optional. — AfroThundr (u · t · c) 22:28, 25 September 2018 (UTC)[reply]
  • 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)[reply]
  • 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 (talk ⋅ contribs) 07:26, 27 September 2018 (UTC)[reply]
  • Oppose per above. Strongly implies requirement, which is what I'm opposing above as well. -FASTILY 05:54, 28 September 2018 (UTC)[reply]
  • 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)[reply]
  • Support per WP:OWN. Number 57 20:13, 9 October 2018 (UTC)[reply]

PROD proposal 3: Deprecate PROD

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)[reply]
  • Oppose, would be a step backwards. Fish+Karate 13:47, 24 September 2018 (UTC)[reply]
  • 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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
  • 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)[reply]
  • 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)[reply]
    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)[reply]
  • 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)[reply]
@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)[reply]
  • (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)[reply]
  • Well then, why don't you be the hero Wikipedia needs? Reyk YO! 14:39, 24 September 2018 (UTC)[reply]
  • I just don't have the brainpower right now to draft a cogent RfC. Natureium (talk) 14:51, 24 September 2018 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
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)[reply]
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)[reply]
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)[reply]
"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)[reply]
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)[reply]
"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)[reply]
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)[reply]
  • 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)[reply]
  • Oppose Reduces bureaucracy in a few cases, which is a good thing. --SarekOfVulcan (talk) 15:00, 24 September 2018 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • Oppose. I agree it reduces bureaucracy sometimes. –Ammarpad (talk) 17:27, 24 September 2018 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Oppose PROD still has an important role to play. shoy (reactions) 17:56, 24 September 2018 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 'Oppose more time would be wasted. Xxanthippe (talk) 22:31, 24 September 2018 (UTC).[reply]
  • Oppose pbp 23:35, 24 September 2018 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Oppose prod still works well. Graeme Bartlett (talk) 08:34, 25 September 2018 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Oppose Per reasons above. We shouldn't try to axe this process. — AfroThundr (u · t · c) 22:28, 25 September 2018 (UTC)[reply]
  • Oppose there is no reason to axe a process that works well. -DJSasso (talk) 15:50, 27 September 2018 (UTC)[reply]
  • Oppose – it works. SemiHypercube ✎ 00:31, 28 September 2018 (UTC)[reply]
  • Oppose per above. Just no. -FASTILY 05:54, 28 September 2018 (UTC)[reply]
  • Oppose  pythoncoder  (talk | contribs) 19:14, 29 September 2018 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Oppose Prod largely works; the biggest issue is the ability to remove it without a rationale. Number 57 20:13, 9 October 2018 (UTC)[reply]

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)[reply]
  • Oppose as the exceptions are bureaucracy that would create more work for no benefit. TonyBallioni (talk) 17:11, 24 September 2018 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Oppose because watchlists are a thing. --Jayron32 17:27, 24 September 2018 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Oppose as instruction creep. Xxanthippe (talk) 22:29, 24 September 2018 (UTC).[reply]
  • 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)[reply]
  • 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)[reply]
    • 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)[reply]
  • 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)[reply]
  • 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. Iffy★Chat -- 10:20, 25 September 2018 (UTC)[reply]
  • Oppose This is really no different than Proposal #1 and my reason still stands. —Farix (t | c) 18:58, 25 September 2018 (UTC)[reply]
  • Oppose as instruction creep and cause no one owns a given page. -DJSasso (talk) 15:50, 27 September 2018 (UTC)[reply]
  • 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)[reply]
  • Oppose per above. Reeks of process creep and promotes WP:OWN -FASTILY 05:54, 28 September 2018 (UTC)[reply]
  • Oppose as IMHO no different from #1 to which I opposed aswell. –Davey2010Talk 22:26, 29 September 2018 (UTC)[reply]
  • 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)[reply]
  • Oppose per WP:OWN. Number 57 20:13, 9 October 2018 (UTC)[reply]

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

  • 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)[reply]
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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]
  • 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)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

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

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)[reply]
  • 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)[reply]
    • 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)[reply]
      • 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)[reply]
        • 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)[reply]
          • 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)[reply]
    • 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 (u • t • c) 16:31, 24 September 2018 (UTC)[reply]
  • 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)[reply]
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)[reply]
You are not the only one. This may be a fairly common reason. · · · Peter (Southwood) (talk): 06:18, 26 September 2018 (UTC)[reply]
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)[reply]
  • 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)[reply]
  • 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). (Swarm ♠ talk) 19:53, 24 September 2018 (UTC)[reply]

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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Comment This is the same as the withdrawn Proposal 5 above. --MelanieN (talk) 02:33, 30 September 2018 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Oppose per WhatamIdoing. Use AFD. Johnbod (talk) 22:39, 6 October 2018 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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 - 2¢ 16:58, 12 October 2018 (UTC)[reply]

Wikipedia self-advertising (e.g. 'Monuments')

This repeated badgering of readers is inappropriate, and should stop.

It is irrelevant to our mission - to provide reliable information. — Preceding unsigned comment added by JohnWheater (talk • contribs) 07:02, 30 September 2018 (UTC)[reply]

  • Non-profits market themselves and their activities routinely. Promoting ourselves and our sister projects aids in our mission to provide free knowledge and content to anyone in every language. So long as it doesn’t reach mainspace in actual article content, it’s fine. TonyBallioni (talk) 07:05, 30 September 2018 (UTC)[reply]
  • I have some sympathy for this, because the Wikipedia:Wiki Loves Monuments banners seem to re-appear more frequently than average. However, the purpose of the banners is to encourage people to "provide reliable information" in the form of photos about encyclopedic subjects. We can't provide all of that reliable information if we can't find someone who can go out and take a picture, and those banners have been hugely effective at collecting that information. WhatamIdoing (talk) 20:45, 1 October 2018 (UTC)[reply]

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

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)[reply]
@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)[reply]
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)[reply]
That's the one. — Rhododendrites talk \\ 17:32, 30 September 2018 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]

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

Looks more like a Guideline. Dicklyon (talk) 03:17, 5 October 2018 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
  • No, per zzuuzz. This is a solution looking for a problem. Dennis Brown - 2¢ 16:51, 12 October 2018 (UTC)[reply]

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

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.
checkY Unanimous consensus in favor.∯WBGconverse 06:22, 14 October 2018 (UTC)[reply]
Tracked in Phabricator
Task T206731
Resolved

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)[reply]
  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, per WP:SNOW. Headbomb {t · c · p · b} 02:35, 11 October 2018 (UTC)[reply]
  • Support per common sense. Natureium (talk) 02:43, 11 October 2018 (UTC)[reply]
  • Seems reasonable. SQLQuery me! 03:19, 11 October 2018 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
    @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)[reply]
  • Support per common sense. I'm glad "copyviobot" is starting to be clarified. SemiHypercube ✎ 12:02, 11 October 2018 (UTC)[reply]
  • Obviously ~ Amory (u • t • c) 14:27, 11 October 2018 (UTC)[reply]
  • 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)[reply]
  • Support  — fr + 09:24, 12 October 2018 (UTC)[reply]
  • 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)[reply]
    @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)[reply]
  • Support. Thryduulf (talk) 22:31, 12 October 2018 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

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

WP:NOSHARING. DonIago (talk) 16:59, 12 October 2018 (UTC)[reply]
No, that's not allowed; see WP:NOSHARING or WP:ROLE. Ivanvector (Talk/Edits) 16:59, 12 October 2018 (UTC)[reply]
Such an account would be blocked as being compromised. TonyBallioni (talk) 17:02, 12 October 2018 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(policy)&oldid=863961812"