Wikipedia:Village pump (proposals)/Archive 154

Source: Wikipedia, the free encyclopedia.

Approving a bot request that would create episode redirects

I've recently manually added some missing redirects to episode list entries (see

Memento Mori (The Punisher) as an example) and wanted to be more efficient with my time and make a bot request for it. I've been instructed per Wikipedia:Bot policy#Mass article creation
to post first here and gain community consensus to this as this will create a lot of new redirects.

Some background: Episode redirects help readers find the episode they are looking for when using the search bar and from web searches. They also enable editors to link to these episode entries from other articles when there is need to. Currently there are over 13k episode redirects listed at

Template:R to TV episode list entry. I've also verified with WikiProject Redirect that these are valid redirects (admittedly only one editor responded, but some days that's all you can hope for). --Gonnym (talk
) 18:19, 6 November 2018 (UTC)

Are you asking to create a redirect for every episode of every TV show in existence, and then to redirect them all to the appropriate list article? Sounds like a lot of work (even for a bot) with little net gain. Most episodes are unlikely to be targets of a user search or of a link from another Wikipedia article. What is your evidence that this task is needed? --Jayron32 19:14, 6 November 2018 (UTC)
I wouldn't go so far and say that. The aim is for redirects to episode lists (such as
The Punisher (season 1)#Episodes) and only those with a name. I have no evidence and I don't really see where I can even find something like that, but you can view the question in a different way. Are episode names notable? Yes. Do reviews and other sites talking about episodes use their name? Yes. Some have enough coverage for stand-alone articles (and have editors that wanted one to be created), while others are left as an entry to the list. Is it common Wikipedia practice (regardless of this request) to create redirects? Yes. Over 13k redirects are listed in the tracking category. Is usage of redirects helpful for editors? Yes. Linking to specific episodes is commonly used from actor and character articles, as well as additional crew member articles. Episode names are also listed in disambiguation pages, which further supports the notion that the community sees a use for them. I also don't follow the "a lot of work" argument. If the work isn't disruptive and it isn't placed on someone who does not wish to do it, why is that a problem? This request also follows Wikipedia:Redirect#Purposes of redirects: Sub-topics or other topics which are described or listed within a wider article. (Such redirects are often targeted to a particular section of the article). --Gonnym (talk
) 20:14, 6 November 2018 (UTC)
I'm still not sure I necessarily think a bot is best for this task. I understand that sometimes an episode name is a good search/link term and where we don't have an article, it makes a reasonable redirect term. However, merely because we demonstrate a specific episode has a name (beyond something like S04E21 or some such) doesn't mean that such a name is widespread enough that anyone outside of a very narrow number of people would be searching for/linking to that name itself. They could be, but I think that judgement is best left to humans. Bots have a hard time deciding between "Yeah, this is a well-known name, but not enough to create an article about this one episode; let's redirect it to the list article" and "Sure, I can prove that this episode had a name, but really, no one knows that name". This seems like a test better suited to a person rather than a bot. --Jayron32 03:40, 9 November 2018 (UTC)
I understand your arguments, but could you explain what harm a redirect will have? It has one purpose, to point to the entry of a list. The "bot" does not have any task of "deciding" if an article should be created or a redirect - It only creates a redirect to a previously created list. I'm really not seeing why this would be an issue. Also, to comment on doesn't mean that such a name is widespread enough that anyone outside of a very narrow number of people would be searching for/linking to that name itself - the name does not need to be widespread enough or even known by readers. Look at a page such as
some were redirects) and some which aren't. In this case, it is enough if even only the editor who added the information to the article knows the name. That editor could then link to these episodes and let other readers enjoy a seamless experience (compare that to the episodes which aren't linked and require much more effort for the reader to reach the point where their page is). --Gonnym (talk
) 12:56, 9 November 2018 (UTC)
I get that there is no harm, but what you're doing is creating thousands of redirects that stand little to no chance of ever being used, even once. It's the sort of indiscriminate make-work task that isn't harmful per-se, but in my mind you've also not shown that the task is needed, or that a bot is the best way to do what is needed. Being pointless is reason enough to not do it. --Jayron32 17:44, 9 November 2018 (UTC)
I give up with you then. I've shown you that they are useful, I've shown you that they are being used and yet you claim on both cases the opposite is true. /sigh --Gonnym (talk) 17:50, 9 November 2018 (UTC)
Some of them are. Create redirects for those. The presumption that every episode of every TV series needs a redirect now, and that we need a bot to create them is what the problem is. If one is being used, I do not oppose creating that one redirect. It's the presumption that all of them are needed that leads me to oppose this. --Jayron32 05:51, 10 November 2018 (UTC)

RFC:Close MedCom?

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

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

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


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

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

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

Rationale:

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

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

For all of these reasons, and again with the upmost respect for those that have striven to keep this project alive, I believe that it is time to admit that this process is almost entirely unused and redundant and to mark it as historical and shut down its mailing list.

talk
) 17:50, 10 October 2018 (UTC)

MedCom discussion

It now appears inevitable that MedCom will be shut down. The reasoned Oppose !votes are being shouted down. This raises the question is what will happen the next time there is a long complicated content dispute. What will probably happen is that we will lose two respected editors. It isn’t just a matter of taking the acronym RFM out of a list and the procedure MedCom out of a list of processes. It would be like disbanding the volunteer fire department because there hasn’t been a fire recently. Not every content dispute can be contained by DRN and specialty noticeboards. If we have a case that needs real mediation, at present, we can find a mediator. If we cross that entry out of the list, then we just throw it to
WP:ANI
and possibly a trip to ArbCom, and eventually topic-bans will be imposed, and in all likelihood one of the two editors, probably a respected content contributor, will be sufficiently embittered by the inability of the community to resolve the content dispute that they will likely leave Wikipedia.
The Support side has not considered the future adverse consequences of doing away with MedCom as the fall-back last resort for content disputes. Just because it hasn’t been used recently doesn’t mean that it isn’t needed. There hasn’t been a fire. That doesn’t mean that there won’t be a fire.
Since we are now almost certain to mark the MedCom as historical, the best way to recover from this mistake will be to create something having a similar function and mission. What we ought to be doing, rather than looking for a procedure to take out of a list of procedures, is trying to improve our dispute resolution procedures. Just getting rid of one that hasn’t been used recently is very much the wrong answer. It would have been better to propose improvements to DRN ‘’before’’ proposing to get rid of MedCom, but I don’t see any real hope now. Robert McClenon (talk) 01:59, 15 October 2018 (UTC)
I'm sorry, Mr McClenon, and if you perceive this as 'shouting down', I can certainly apologise further, but having read through various MedCom cases, I find it hard to accept this position...I see a combination of 1) dislocation of discussion that should have taken place on the article talk pages to a backroom space 2) dancing around obvious behavioural issues for the sake of reaching the illusion of a compromise. A comment made by
Geometry guy in 2007 sums up, I think, the problems with the so-called mediation process. It applies an overbearing bureaucracy to disputes that could be resolved through talk page discussion or other normal channels, trying to force some kind of 'compromise' to appease warring parties, with the ultimate result of either failing completely because of an inability to deal with underlying behavioural problems, or comprising the content of the encylopaedia for the sake of appeasing editors participating in advocacy for a certain position. The reality is that we have better tools to deal with disputes on Wikipedia now...the false dichotomy between the so-called 'content' and 'conduct' disputes has been cast aside, and systems like discretionary sanctions have been brought in to encourage more moderate conduct in areas prone to discord. MedCom, I think, is truly a relic of a more idealistic era in Wikipedia's development. It no longer serves a practical purpose. All this proposal intends to do is recognise the status quo, nothing more. RGloucester
03:33, 15 October 2018 (UTC)
  • False. Every single Wikipedia dispute resolution mechanism divides conduct and content, its why we have
    Wikipedia:CONTENTDISPUTE. Similarly, you can't argue content disputes at AN/I, nor can Arbitration decide content issues. And whatever the elaboration of mediation, as Wikipedian's do like to write long explanations, Mediation's process is simple: someone shows up, states a problem and notices others, and a volunteer shows up and responds. Alanscottwalker (talk
    ) 19:18, 15 October 2018 (UTC)
    You misunderstood me. My point was, if a so-called content dispute cannot be resolved by talk page discussion, various noticeboards, RfCs, &c., it usually means that there is a conduct issue, not a true content issue, and it should be dealt with as such. The 'black and white' distinction between content and conduct disputes is no longer relevant...hence the development of things like community and ArbCom discretionary sanctions, which force a 'drop the stick'-style approach on the part of editors in dispute-laden topic areas, lest they be sanctioned. RGloucester 19:31, 15 October 2018 (UTC)
    The content/conduct distinction is always relevant on every one of our boards. Every one -- that is our policy -- repeatedly. Your odd argument amounts to, 'oh, we can just tell people to shut-up, instead of mediating', which actually makes no sense because of the arbitrariness and strange value of it. RfC's are often weirdly sprung, poorly constructed, and poorly researched, so it is bizarre to hold them up as models for deliberation. (e/c) As for talk pages, the reason the 'shut up' method is employed there, at all, is because talk pages are without other boundaries. Alanscottwalker (talk) 19:46, 15 October 2018 (UTC)
    I've said my bit...my time is up. I still think the comment by Geometry guy is very relevant...but, I too must 'drop the stick'... RGloucester 19:56, 15 October 2018 (UTC)
    It is true that many disputes have both a content aspect and a conduct aspect. There are very few disputes that are purely conduct disputes. If the problem is simply the conduct of an editor who is a vandal, troll, or flamer, the offending editor normally gets indeffed quickly, without a real dispute. Content dispute resolution mechanisms, such as DRN and MedCom, operate on the optimistic assumption that the parties will set aside their conduct concerns long enough to resolve the content issue, and then the conduct issue is resolved as a side benefit. Conduct dispute resolution mechanisms, such as
    Arbitration Enforcement, operate on the recognition that the offending editor who is preventing the content issue from being resolved can be sanctioned long enough to resolve the content dispute. There never was a black-and-white distinction, except for vandals, trolls, and flamers. It is still true that throwing away a content dispute resolution process is unwise. Robert McClenon (talk
    ) 02:32, 16 October 2018 (UTC)
    The only comment I want to add here (and responding to actual points made is not "shouting down") regards seeing "MedCom as the fall-back last resort for content disputes". It is not, never has been, and can not possibly be the fall-back last resort for content disputes - not if it can make no binding decisions. Boing! said Zebedee (talk) 09:09, 16 October 2018 (UTC)
  • Strong support - Wow, it's definitely time to put this thing out of its misery. MedCom is inaccessible, redundant, ineffective, archaic relic, particularly in the context of modern dispute resolution, which is heavily streamlined in favor of formal, community-based consensus building, which easily handles both routine and complex disputes with binding decisions. At this point, it's more of a distraction from measures which actually resolve disputes. It's less useful than the long-defunct
    let it go when they can't secure a consensus, and who will drag out disputes past a reasonable point. When these situations arise, we're not relying on this bureaucratic dinosaur to walk them through their dispute and hope everyone will be agreeable, even though they're spending weeks and weeks of their life trying to come to an understanding in an online argument. We're investigating the underlying behavior and sanctioning or warning users, or implementing page restrictions, or going to ArbCom for binding solutions, so that actual collaborative, good faith editors do not get burned out and can continue contributing. That's why MedCom is an obsolete relic, not because we haven't had any "complex disputes" lately. Also, this whole thing is just out of touch with the community. It's purported to be this formal, serious thing, the be-all and end-all of dispute resolution, with legitimacy stemming from Jimbo himself, but in reality it's the pet project of this closed club of a small handful of users (or more realistically, one user), who decide from within what their membership is, and what their rules are, and when to take a case (read: never) and really don't contribute anything to DR. It's totally out of whack. The "chair" of MedCom's comments above just goes to show how out of touch with DR and the community this whole thing has become. Rather than actually demonstrating how and why MedCom has done and can still do good for the community, his case for keeping it is that we somehow 'need' his committee, because they don't accept newcomers into their ranks, or because they will accept disputes that drag on for months while DRN won't (I wonder why), or because they "mediate". I've been involved in DR pretty much since I became active here, and this kind of mediation-based approach to DR has never been particularly effective anyway, and keeping around a self-important group of 'mediators' who have long-since outlived their usefulness to the project is just silly. I thank those who have invested time in this project, but it's time to pull the plug.  Swarm  talk 
    00:26, 16 October 2018 (UTC)
  • Strong support: I was pretty convinced of MedCom's uselessness when I was on (and chaired) the committee--and that was 2007. I've toyed with the idea of proposing its closure off and on over the years, but never got around to writing something up. FACE WITH TEARS OF JOY [u+1F602] 03:01, 16 October 2018 (UTC)
  • Support. At Wikipedia:Mediation Committee it says "The Mediation Committee ... is the last stage of content dispute resolution on the English Wikipedia. Mediation is entered into voluntarily by the parties to the dispute and does not result in binding resolutions." But that is self-contradictory - a voluntary venue that does not result in binding resolutions can not possibly be the last stage in resolving anything. In practice, consensus arrived at by community discussion is the ultimate stage in content dispute resolution, and that is binding - and if editors refuse to follow it, sanctions can be applied directly from that. And as content dispute resolution often requires a good understanding of a subject and the sources supporting it, and with the way Wikipedia has massively developed since 2003, a small number of chosen editors really can not be up to that job. The Mediation Committee is one of those things that I think was a good idea and had its value in the early days, but the community has moved on and has bypassed it as a means of content dispute resolution. I thank all those who have served on it or contributed to it in other ways, but I think it's time to let it go. Boing! said Zebedee (talk) 08:57, 16 October 2018 (UTC)
    But Consensus is
    that are binding, so the fact that mediation recognizes that is the only choice mediation has. -- Alanscottwalker (talk
    ) 09:24, 16 October 2018 (UTC)
    That link to ) 09:37, 16 October 2018 (UTC)
    There are millions of things that have no consensus, and regularly result in no consensus. And how is consensus reached, even in the things where it can be found, by discussion, even mediated discussion. And even then consensus is provisional by policy. Alanscottwalker (talk) 09:44, 16 October 2018 (UTC)
    And in cases where there is no consensus, MedCom is powerless to act, so it can not be what it claims to be. Once you take away the obviously incorrect claim that MedCom is the last stage of content dispute resolution, I simply don't see what it offers that
    WP:DRN doesn't. Boing! said Zebedee (talk
    ) 10:04, 16 October 2018 (UTC)
    Act? If discussion is an act, it certainly can discuss (act on) things with no consensus, that's what all content dispute resolution forums do, there is no guarantee of consensus. A stage is just a forum, after all. Binding is only used once in Consensus policy and it is in CONEXCEPT, not in the rest of the policy.-- Alanscottwalker (talk) 10:38, 16 October 2018 (UTC)
    I honestly don't understand the point you are trying to pursue here, and this seems to be going in circles. If there is any way MedCom can actually be the last stage of content dispute resolution or can achieve anything that
    WP:DRN can't, I'm really not getting it from what you are saying. Anyway, I've explained my reasoning as best I can, and I'm happy to leave it to whoever judges the consensus now. Boing! said Zebedee (talk
    ) 10:59, 16 October 2018 (UTC)
    (E/C) There is no other stage, it is the last on the list, per policy. MEDCOM has a slightly different structure, where experienced mediators are willing to discuss sources, analyse research, and policy, at length among willing participants. Anyone, who has been involved in complex content disputes knows they last months and months, through many stages Alanscottwalker (talk) 11:05, 16 October 2018 (UTC)
    Oh, you take the last stage of content dispute resolution to simply mean it's the last item included on a arbitrary list? That's meaningless, and if we simply take it off the list it won't be. To be of any value, the last stage of content dispute resolution must mean more than that. And yes, I know that disputes can be long and complex (we have plenty that have been going on for years, on and off), but merely stating that says nothing about MedCom's ability to solve them any better than current processes. Let's face it, MedCom already doesn't actually exist - it's just User:TransporterMan, who has overstayed his term in the chair. Anyway, thanks for answering those two specific points, but I remain in disagreement and still see no value in MedCom. Boing! said Zebedee (talk) 11:30, 16 October 2018 (UTC)
    Well, just to add on your earlier strain of thought, no, many of us involved in complex content disputes do not want admins (who can hardly claim to be the font of all knowledge) striking their heavy (sometimes incompetent) hand against the people we disagree with. As for the rest, it's just bizarre, because MEDCOM is set-up by CONSENSUS policy, to not be used much. You just contented consensus is arbitrary in its listing, so by that, consensus is arbitrary, is your argument. Alanscottwalker (talk) 11:50, 16 October 2018 (UTC)
    Nobody is suggesting that admins should decide content disputes (and we are forbidden from doing so anyway), so that strikes me as a false dichotomy. If a list of processes can be decided by consensus, then it can be changed by consensus too - which is what we are considering here.

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

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

Arbitrary Page Break

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

Extended discussion

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

The Real Problem

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

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

Closure

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

Teahouse FAQ

Some questions seem to come up very frequently at the teahouse, like "How do I edit a page?" or "How do I get my page published?", would it be useful to have an FAQ with a link on the main teahouse? [Username Needed] 15:42, 12 November 2018 (UTC)

@Username Needed: Sounds like a great question for Wikipedia talk:Teahouse. No better people to ask than those who regularly contribute there. ―Mandruss  16:32, 12 November 2018 (UTC)

Sounds like a good idea.Vorbee (talk) 18:10, 13 November 2018 (UTC)

Feature Request

Feature request: that the Wikipedia picture of the day be added to the article of the day email notification. I don't see why it's not included, since there's already quote of the day, etc. Benjamin (talk) 04:19, 13 November 2018 (UTC)

What's the process for requesting this? Benjamin (talk) 08:47, 13 November 2018 (UTC)
There is Commons:Daily-image-l for the Commons POTD, but POTD on Wikipedia is somewhat different. Have you tried mailing dal-feedback @ wikimedia.org? MER-C 13:28, 13 November 2018 (UTC)
@Benjaminikuta: where are you getting this email from? (who is sending it, where did you sign up?) — xaosflux Talk 14:26, 13 November 2018 (UTC)
Looks like it's this (I'd never heard of it). Thincat (talk) 18:22, 13 November 2018 (UTC)
@Benjaminikuta: if you are getting this email from the "Daily article mailing list" please note this is an inter-project list and is not managed here on the English Wikipeida, however you can contact the list managers at: dal-feedback at wikimedia.org. I suspect if they are going to include a Featured Image it will probably be the one from commons:Commons:Picture of the day. — xaosflux Talk 19:01, 13 November 2018 (UTC)
I emailed them, and they told me to post here. Benjamin (talk) 23:10, 13 November 2018 (UTC)
Benjaminikuta, that's pretty crazy (per what Xao said). At any case, contact MZMcBride, who developed the script and Matthewrbowker, who currently runs the script.WBGconverse 12:44, 14 November 2018 (UTC)

Human Rights and Liabilities 1

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.
This is completely ridiculous and not even a proposal. (Snow closure) ProgrammingGeek talktome 15:08, 15 November 2018 (UTC) (non-admin closure)

Hello,

herewith i propose to you to look or ask the UN <html>www.un.org</html> whether you <html>www.wikipedia.org</html> (sorry for citing unverifiables here) are in fact promoting crimes against humanities by offering and promoting such articles like:

1. Schizophrenia

etc.

And whether you are in fact liable here.

Thank you.

Nradabhatse die Katze Nradabhatse die Katze (talk) 23:23, 14 November 2018 (UTC)

Why? GMGtalk 23:27, 14 November 2018 (UTC)
What? Providing reliably sourced information about a mental disorder isn't human rights abuse. I hold some strange opinions but that isn't one of them.

If they're getting massages and I'm not, I think my human rights are being abused!

— Jen Barber, The IT Crowd

ProgrammingGeek talktome 23:30, 14 November 2018 (UTC)

Recommend (snow) close as there is nothing in this proposal that is actionable. Regards,
Contact me | Contributions
). This message was left at 01:58, 15 November 2018 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

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

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.

  • There is ☒Nno consensus to pending-changes-protect the TFA page, as a default measure.This, obviously, does not affect the discretion of administrators to implement PCP at a TFA, (per the protection-policy), for purposes as may be otherwise deemed fit.
  • There is checkY consensus to disallow non-autoconfirmed users from adding images on TFAs, as a default measure.

Signed by WBGconverse on 19:04, 16 November 2018 (UTC)


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

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

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

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

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

Alternative proposal: semi-protect TFAs

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

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

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

General Discussion

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

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


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

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

Pretty much any national-level politician is a bad choice for PC, especially as election time approaches. See above. —Jeremy v^_^v Bori! 10:34, 25 October 2018 (UTC)
Actually meant ECP, corrected myself. Blackmane (talk) 01:54, 26 October 2018 (UTC)
  • Support. There are enough watchers that valid changes will be swiftly approved, and there have been so many instances of vandalism that we do need to do something. This is kinder than semiprotection. Guy (Help!) 13:00, 16 November 2018 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

!Remind me bot

Those of you familiar with Reddit will probably know about the !remind me bot. Sometimes, especially when dealing with protected edit requests that haven't been discussed, I find that I want to come back to a conversation after a given length of time. That's why I'm proposing a Wikipedia !remind me bot.

This would work by the bot detecting instances of {{Remind me}}, something like the following:

A1307
 A1(M) 
 B1043 
 A141 
Huntingdon viaduct
 A1198 
 B1040 
 A14 
Swavesey interchange
under construction
Bar Hill interchange
Girton interchange
 M11 

The detection is clearly plausible, as AnomieBOT does the same for edit requests.

The bot would cache the asking user, and the time. After the time had elapsed, the bot could either reply below the reminder with a ping, or give a talkback on the user's talk page. Or it could be able to do both, and be configured by an option in the template. Bellezzasolo Discuss 12:47, 15 November 2018 (UTC)

You may be interested in m:Community Wishlist Survey 2019/Notifications/Article reminders. The voting phase for m:Community Wishlist Survey 2019 begins November 16 at 18:00 UTC. Anomie 12:57, 15 November 2018 (UTC)
I've worked on this in the past, and one (or several?) probably-not-ready extensions exist that could be deployed here. It's probably better to write the extension. Enterprisey (talk!) 04:15, 17 November 2018 (UTC)

Page movers and the title blacklist

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.
There is an checkY unanimous consensus to assign the tboverride permission to the (extendedmover) user group.WBGconverse 05:11, 17 November 2018 (UTC)

I just got a request from pagemover

Good Morning!!! (Australian TV program) to match a naming convention, and IJBall couldn't do it because the !!! was blacklisted. I'm an admin, so I was able to do this easily. But why should I have to? We've now permitted pagemovers to do things as significant as moving without redirect (i.e. converting a blue link into a red link); shouldn't they also have the ability to override the title blacklist? Nyttend (talk
) 02:09, 5 November 2018 (UTC)

Tech notes (page movers and the title blacklist)

Without a new permission needing to be created this proposal is to:

  • ADD the tboverride permission to the (extendedmover) user group.

Implementation notes:

Related notes:

  • "Warning" for blacklist hits is not currently available and isn't 'easy' compared to assigning a permission to a group. This is being looked at for everyone (including admins) already, see phab:T192933.

Discuss (page movers and the title blacklist)

  • Support Sounds like a good idea. Page mover is supposed to be an unbundling of admin rights, so it makes sense to do this to do page moves like this more easily. SemiHypercube 02:21, 5 November 2018 (UTC)
The thing that I'd really like to see added to Page mover is the ability to move an article from userspace or draftspace and overwrite a mainspace redirect with a trivial (i.e. 1-edit) revision history – currently, I am not able to do this, and instead have to do round-robin moves to accomplish the same... As for the title blacklist moves – if that's implemented, I'd like us page movers to get a warning screen before finalizing such a move. --IJBall (contribstalk) 03:24, 5 November 2018 (UTC)
That's rarely necessary. All you have to do is first move the redirect to some different title: the vast majority of topics are far from having the optimal redirect density, and you should almost always be able to think of a good redirect title (from an
alternative disambiguation, etc.) that doesn't exist yet. – Uanfala (talk)
14:32, 5 November 2018 (UTC)
Why should I have to "move" a redirect that I created (in the most recent instance I'm thinking of) that literally has one entry in the revision history (its creation)?! This is a pointless exercise in the extreme! I can move a mainspace article over such a redirect even if I'm not a page mover! – Why shouldn't I be able to do exactly the same thing, except when moving an article from userspace/draftspace to mainspace as a page mover?! --IJBall (contribstalk) 20:39, 6 November 2018 (UTC)
I have no opinion on the proposal, I was simply pointing out one obvious, and almost always overlooked alternative to the awkward practice of round robin swaps. – Uanfala (talk) 23:40, 6 November 2018 (UTC)
  • Support makes sense. Also allow overwriting redirects. That is a common issue I have at AfC. Get a nice notable draft and find a redirect in the way. The redirect is there because the topic is notable enough to need links but no one wrote up a page yet. Legacypac (talk) 03:51, 5 November 2018 (UTC)
  • The problem with that is that you could overwrite significant history. Maybe you typically encounter redirects with no real history, but sometimes a draft will have significant history that shouldn't (
    or mustn't) be deleted, and I know I've encountered situations where I had to decline a {{db-move}} because the target had significant history. IJBall's solution, restricting it to pages with one edit in the history, would accomplish your desired goal without risking the deletion of important history. Nyttend (talk
    ) 04:18, 5 November 2018 (UTC)
  • Unfortunately that will not happen anytime soon. It will require (editprotected) right. –Ammarpad (talk)
  • Support as proposed, I can't see any issues with that. Thryduulf (talk) 12:14, 5 November 2018 (UTC)
  • Support - PM & TPE require similar levels of trust. Cabayi (talk) 12:49, 5 November 2018 (UTC)
  • Support. Seems perfectly reasonable to me. Boing! said Zebedee (talk) 13:02, 5 November 2018 (UTC)
  • Support. If they can't be trusted to decide when to overide the blacklist, they shouldn't be trusted to move a page without leaving a redirect. --Guy Macon (talk) 17:08, 5 November 2018 (UTC)
  • Comment I added a technical recap section above, feel free to amend as needed. — xaosflux Talk 04:22, 6 November 2018 (UTC)
  • Support But I really had no intention of using Page Mover to work around not having the admin bit. Hawkeye7 (discuss) 04:36, 6 November 2018 (UTC)
  • Support. Appears to be useful and low risk. Occasional mistakes can be fixed. · · · Peter (Southwood) (talk): 06:42, 6 November 2018 (UTC)
  • Support as pagemovers are already trusted to make sensible choices, and are expected to have more capability. Graeme Bartlett (talk) 20:21, 8 November 2018 (UTC)
  • Support Template editors can already do this (editnotices). It makes sense for page movers to be able to do so as well. Bellezzasolo Discuss 17:33, 12 November 2018 (UTC)
  • Support L293D ( • ) 04:22, 16 November 2018 (UTC)
  • Snow close in favour of the proposal. It's pretty clear that this is a pretty uncontroversial change to give trusted users a natural extension of their pre-existing rights. ProgrammingGeek talktome 04:39, 16 November 2018 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Reminder to VOTE NOW!

for the urgently required tools proposed by the

New Page Reviewers at the Community Wishlist Survey for the Page Curation and New Pages Feed improvements - vote NOW. Kudpung กุดผึ้ง (talk
) 12:11, 18 November 2018 (UTC)

Rfc : Should users be allowed to canvass for proposals at the Community Wishlist Survey ?

Should users be allowed to canvass for proposals which have been put forward in the Community Wishlist Survey ? — fr+ 09:41, 20 November 2018 (UTC)

  • Allowed, as long as you are not disruptive. And, Danny and Co. explicitly encourage us to do so.WBGconverse 10:00, 20 November 2018 (UTC)
  • @Deskana:--

Here goes a list:--

In response to a general conflict, Danny notes on his t/p:-- but I think your time would be better spent in encouraging editors to vote.......

There are several explicit examples, where Danny has said that explicit canvasing is allowed; a-prior to the start of wishlist.

As to a particular proposal about developments to NPP suite, a newsletter was sent to all the page-patrollers which stated The NPP community is hoping for a good turnout in support of the requests to Santa for the tools we need.......So please put in a vote today.We are counting on significant support not only from our own ranks, but from everyone......

A Signpost Report went along the same lines.

Kudpung explicitly asks for vote by posting threads over three village pumps.

Over a centralised thread, Kudpung then notes Don't worry, the canvassing isn't over yet - we still have more up our sleeves. But such a campaign has to be extremely carefully crafted, worded, and presented.....

Danny replies It's good to keep telling people about the survey....You're winning. You'll get what you want.....

Over another thread on IcpH's t/p about the same locus, Danny notes .......You all are currently doing the correct thing to get the result that you want. This is the correct procedure, and you're participating successfully........

The examples above does not equate to canvassing in all the cases. The NPP Newsleters certainly wasn't. But in the 3 VP posts and to an extent, in the Signpost article, canvassing is quite evident.

FWIW, even I have supported their efforts and commended them.

But, canvasing is explicitly allowed and it has been engaged in, solely on advice of WMF folks. They think that working on core-functionalities cannot be tended to, if they are not popular aka sexy enough and to make them popular, we can take almost every possible route. Otherwise, there's no alternative for improvements of routine maintenance functionalities. See the case of improvement of undelete logs et al, for one. WBGconverse 15:55, 20 November 2018 (UTC)

  • One post to an appropriate noticeboard is ok (see my post at the math wikiproject). It was the multiple posts to inappropriate noticeboards that led to the reverts. Johnuniq (talk) 10:12, 20 November 2018 (UTC)
  • In general, no. There are 212 proposals, canvassing for these would be disruptive in most cases. Note that this RfC is caused by the filing editor canvassing a proposal to 4 village pumps and
    Fram (talk
    ) 10:15, 20 November 2018 (UTC)
It might be OK to remove a post canvassing a proposal for the reasons you suggest, but it was not OK to remove a discussion that involved several editors. When there have been responses, the window to remove the initial post has passed. "Village pump (proposals)" is an appropriate place to discuss a proposal. somebody uninvolved (talk) 10:26, 20 November 2018 (UTC)
  • No as a general rule. We could quickly end up in a situation where lots of people are canvassing for their proposals, thereby encouraging others to canvas for their proposals so that their proposal isn't left behind, to the point that the noticeboards are flooded with canvassing which nobody pays attention to since there's so much of it (tragedy of the commons). A general post about voting in the wishlist is fine, as are some more targeted posts (e.g. informing the bot community about a bot-related proposal), but not mass canvassing. --Deskana (talk) 11:20, 20 November 2018 (UTC)
  • Yes as per statement on Community Wishlist front page: A reasonable amount of canvassing is acceptable. You've got an opportunity to sell your idea to as many people as you can reach. Feel free to reach out to other people in your project, WikiProject or user group. Obviously, this shouldn't involve sockpuppets, or badgering people to vote or to change their vote. But a good-faith "get out the vote" campaign is absolutely okay. - Basically, don't make a nuisance of yourself and we'll be fine. It's a shame that such reasonable approaches frequently need to be hammered down with numbers and strict boundaries because people aren't smart enough to gauge when too much is too much. But we are not exactly facing a crippling epidemic of canvassing ATM, so I'd suggest not blowing this out of proportion. --Elmidae (talk · contribs) 11:43, 20 November 2018 (UTC)
  • No if it’s being done in the same way the editor in question as been doing it, as seen here, where they are clear pushing a specific stance/outcome in the discussion. I don’t oppose it if they can manage to post a neutral comment merely alerting people of the discussions existence, though I’m starting to wonder if this editor can separate themselves from the issue enough to do that honestly... Sergecross73 msg me 13:42, 20 November 2018 (UTC)
  • Fram:, the issue being discussed here does not pertain solely to my edits rather it pertains to the general context, as I have said in my statement as OP. What I want is a consensus position from the community which can be used for later reference in such situations. Additionally, I don't intend to go back to posting any notifications whatsoever, even if the outcome of this discussion allows me to do so. — fr+
    14:42, 20 November 2018 (UTC)
  • "Please vote support for my idea" is something that anyone should be able to say in relevant forums, such as WikiProjects discussing the subject the proposal's focus or in discussions about the Wishlist survey itself. Blue Rasberry (talk) 14:58, 20 November 2018 (UTC)
  • Yes, within reason. These are not discussions seeking to measure levels of consensus, this is a community Wishlist, where the tech team wants to know the level of support for ideas in terms of measured interest in the actual community. And also note that banning canvassing on the English Wikipedia will just reduce the likelihood that ideas useful to the English Wikipedia will come to fruition, because all other Wikimedia project will still canvas.
    b
    }
    15:10, 20 November 2018 (UTC)
  • Yes. TonyBallioni (talk) 15:26, 20 November 2018 (UTC)
  • Yes, but within reason. One thread on VPT for each proposal might be over the top, but I don't really see the current situation being a problem. The Wishlist survey is designed to measure what tools are most needed by the editing community, and that includes advocacy for proposals. --AntiCompositeNumber (talk) 15:45, 20 November 2018 (UTC)
  • Yes - The community wishlist process is important, and not well publicized. It's fine to post to a few noticeboards to get the word out. It's also fine to post to individual user talk pages, if the user has previously expressed an interest.- MrX 🖋 17:24, 20 November 2018 (UTC)
  • Yes but not on Village Pump - canvassing on appropriate boards, talk pages, volunteer lists etc is all good as they are a reasonably relevant group of people. But if we allow each proposal 1 post on VPP then we are going to be absolutely buried under them. Nosebagbear (talk) 19:10, 20 November 2018 (UTC)

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

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.
  • There is ☒Nconsensus against the letter and spirit of this proposal. A contingent in opposition contested the proposal's premise of "huge backlogs". characterizing the same as "non-existent". The lack of a reply, one might expect, lends the contest credibility at the proposal's expense. Others demonstrated how effort would be duplicated and editing resources squandered for naught. Many in support seemed to endorse non-admins closing discussions as delete without making a specific case for RfD in particular while others yet expressed sentiments of need in developing a proposal more fully to have what is needed for such likes to prevail.

    Interestingly,

    John Cline (talk
    ) 19:41, 26 November 2018 (UTC)


Today, I am going to propose that non-admins should have the right to close deletion discussions as "delete" at

WP:RFD discussion as "delete" and then tag the corresponding page for speedy deletion with {{db-xfd}} so that an admin can delete soon after. Pkbwcgs (talk
) 12:33, 20 October 2018 (UTC)

"Clearing the backlog" does nothing if admins still have to go and read all those discussions to ensure that the consensus was right (they have to do this as it is ultimately their responsibility to use the delete button appropriately). We don't need a knee-jerk response here. Just go ask at
WP:AN if some admins can come over and clear the backlog. — Insertcleverphrasehere (or here
) 13:00, 20 October 2018 (UTC)
I've already done two non-admin delete closures. This is possible when an admin has come along and deleted while the xfD is ongoing. Hawkeye7 (discuss) 08:43, 21 October 2018 (UTC)
  • Stephni meyer), but that is different from RfD actually being backlogged. I can't think of any sizable backlog there since early 2016 and even then, it wasn't to the point where I would call it problematic. -- Tavix (talk
    ) 15:07, 22 October 2018 (UTC)
@Zchrykng: Yes a template like {{db-xfd}}. — Insertcleverphrasehere (or here) 13:52, 22 October 2018 (UTC)
  • Oppose. It's rare that there is actually a significant backlog of discussions that are simple closures (with any outcome).
    WP:ANRFC. Thryduulf (talk
    ) 14:30, 22 October 2018 (UTC)
  • Strong oppose. This comes up frequently enough that I have listed out my reasons at User:Tavix/non-admin closes. -- Tavix (talk) 14:43, 22 October 2018 (UTC)
  • TBH I think what this shows is that having something like an "eliminator" user right would be useful. Galobtter (pingó mió) 14:48, 22 October 2018 (UTC)
  • Support - I did make this same proposal some time ago. I don't think this would help address any backlogs and I agree that in the more recent past this process hasn't really been plagued with backlogs anyway. I pretty much agree entirely with Thryduulf's comment, but this is more of a "why not?" support. I don't think the sky is going to fall if we let non-admins conclude that a discussion closed as "delete" just because they can't push the buttons: we let non-admins close every other kind of result anyway. Personally I think it's silly that we trust experienced editors like feminist to neutrally assess the result of a discussion but only if the result fits in a certain box. If such a user can determine the consensus of a "keep" discussion they are just as capable of determining the consensus of a "delete" discussion. Ivanvector (Talk/Edits) 15:29, 22 October 2018 (UTC)
  • Oppose per the sound reasoning at User:Tavix/non-admin closes. -DJSasso (talk) 16:31, 22 October 2018 (UTC)
  • Neutral. I have previously argued against NAC deletion, though the marginal cases of all admin-regulars having already chipped in, and the faffiness of RfA are softening me up to the idea of non-admins closing discussions to mandate admin action. As one of the RfD admin-regulars I am probably expected to leave a comment here, so I'm writing this to say why I don't feel strongly either way. Deryck C. 17:23, 22 October 2018 (UTC)
  • I'd like to find some way to make this work. Before I was an admin, I did good work (I'd like to think) with non-admin closures, including deletion results in venues that allowed it. I mostly agree that the RfD backlog hasn't been bad enough recently to really need this, but that has not always been true and likely will not be true again sometime in the future. So I don't want to argue against planting seeds just because I currently have enough food, proverbially speaking. The first thing that comes to mind is a system in which one or more admins indicate "hey, a non-admin delete close could work here". I don't know how to design a clean mechanism like that, though. I imagine it'd be invoked most when admins are involved. We wouldn't want it to just be a way for admins to try to cut short discussion on something they want to see deleted. (Please ping me if a response is requested; I won't be watching this page.) --BDD (talk) 19:22, 22 October 2018 (UTC)
  • Comment the mechanics are very simple. Close as Delete and tag the redirect G6 housekeeping noting "deleted at RfD" or similar. An admin working CSDs can just press the button. If some non-Admins closed the non-comtroversal ones the Admins woukd be freed up to close the tougb ones, though there are not a lot of tough RfD discussions. I favor letting non-Admins do everything possible to demonstrate a good trackrecord and this is a good place for someone to show their judgement. Legacypac (talk) 19:33, 22 October 2018 (UTC)
  • Oppose per the excellent essay at User:Tavix/non-admin_closes. All this does is create duplicate work. The scripts that we have make adding all the templates trivial, so a non admin doing that isn't really helping. The best that can be said for this proposal is that it might give qualified individuals the chance to better demonstrate that they are qualified for RfA, but they can do that in other ways. — Insertcleverphrasehere (or here) 19:56, 22 October 2018 (UTC)
  • Oppose. I don't understand the reasoning here at all; there's no backlog to speak of at RFD and hasn't been since the disruptive editor who used to fill it with spurious and time-consuming comments (all of which needed to be reviewed by the closing admin just in case it was one of the rare occasions when he was making a sensible point) has been sitebanned, and needing to have two closers for each discussion would increase the workload, not decrease it. ‑ 
    Iridescent
    20:02, 22 October 2018 (UTC)
  • Oppose, noting that (I think) I supported a similar proposal a while ago. It makes sense for TfD and CfD to allow non-admin "delete" closures because templates and categories need to be orphaned/emptied/replaced before they are deleted, and this extra work can be done quicker if non-admins are involved in the process. RfD has no similar issue. feminist (talk) 10:32, 23 October 2018 (UTC)
@Feminist: I have not seen non-admins close CfD discussions as "delete" and XFDCloser doesn't let me close CfD discussions as "delete". Pkbwcgs (talk) 11:38, 25 October 2018 (UTC)
Also, Wikipedia:Categories for discussion/Working is fully protected which makes it impossible for non-admins to close CfD discussions as "delete". Pkbwcgs (talk) 11:47, 25 October 2018 (UTC)
See Wikipedia_talk:Categories_for_discussion/Working#Protection_of_WP:CFD.2FW.2C_take_3. feminist (talk) 13:04, 25 October 2018 (UTC)
@Feminist: Okay. However, XFDCloser doesn't let non-admins close a CfD discussion as "delete". Pkbwcgs (talk) 14:06, 25 October 2018 (UTC)
  • Consensus has determined that only trusted users (aka those who succeeded in RfA) should have access to deletion tools, as with great power comes great responsibility. Therefore, letting non-Admins close as delete and having them delete the pages would be large break of consensus. Kirbanzo (talk) 18:54, 28 October 2018 (UTC)
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.

Diffs should include log extracts

I recently looked at this diff and was misled by what I saw. It looked like my G11 tag had been deleted for no reason. What I didn't notice was that between those two versions, the page had been deleted and then restored. It would be useful for the diff to include a note, "Two intervening administrative actions not show; see log for details" (with a link to the log). Any thoughts on this before I go ahead and open a Phab feature request? -- RoySmith (talk) 15:34, 27 November 2018 (UTC)

Why the hell not? No downsides; useful feature; do it. ProgrammingGeek talktome 15:51, 27 November 2018 (UTC)

I do a lot of CSDing and then pages come back and I have to figure out why. This would be very helpful. Legacypac (talk) 20:23, 27 November 2018 (UTC)

How often are you CSDing pages that are later undeleted? Natureium (talk) 20:30, 27 November 2018 (UTC)
RoySmith, that would be quite helpful and I have suffered from the same confusion, a few times.WBGconverse 05:56, 28 November 2018 (UTC)