Wikipedia:Village pump (proposals)/Archive 154

• Village pump
  • Policy
  • Technical
  • Proposals (persistent)
  • Idea lab
  • WMF
  • Miscellaneous

Village pump (proposals) archive  

This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

---

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215

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 Category:Redirected episode articles and there is a special template used for this specific redirect, 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 Roxxon Energy Corporation#Television 2. The prose about what episodes the company appears in has some episodes linked to (some are redirects, 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)

• I think we should know the specifics of the proposal. What would the redirects look like? Are they going to be of the format Episode name (Series name)? is the bot account going to be simply a frontend for an editor's manual task, or is there going to be an actual bot? How is the bot going to work, will it parse article text to find eligible episode names? How will the source articles be selected? – Uanfala (talk) 13:29, 9 November 2018 (UTC)
  • I can answer for the specifics about the request, but since I'm not the bot owner and I'm using Wikipedia:Bot requests, I can't answer about the bot itself. The process (may change if better options are available) will be that a list of articles will be provided (from a category such as Category:Lists of television series episodes). The bot will check the {{Episode list}} template in the article and take the needed information. It then checks to see if an article which is not the episode article exists with that name, if there is no article, it will create one with that name, if there is one (which isn't the episode) it will create one with the format of Episode name (Series name) (per WP:NCTV). That's a very rough overview of how it will work (there are also finer details about adding the correct redirect templates and such). For an example redirect, see Memento Mori (The Punisher). --Gonnym (talk) 13:43, 9 November 2018 (UTC)
    • I've had a look at a few articles in the category: there are ones with a good amount of content about each episode (and hence the appropriateness of a redirect is beyond question), but there are also articles (like List of Galis episodes]) where there's almost no information about each episode. Is it desirable to have redirects in these situations as well? I also see that some of these article list a large number of episodes, sometimes over a hundred. Is it desirable to have so many redirects pointing to a single article? There is a certain (small, but not negligible) maintenance cost to any redirect, and this could become an issue in the case of a topic reorganisation (for example, if at some point a list of episodes is split into individual lists for each season, then each incoming redirect would need to be retargeted by hand). – Uanfala (talk) 21:42, 9 November 2018 (UTC)
      • Articles like List of Galis episodes won't be included, even ignoring their current condition, as they don't have an episode title. Articles that would fit the criteria are Parks and Recreation (season 5) and Agents of S.H.I.E.L.D. (season 5) as examples. I could limit this to lists that are only part of a season article (as the previous examples). I could also limit this even more, but I'm not sure of any "neutral" criteria. Regarding the amount of redirects to one article, it's important to note the distinction here. When a link is intended for the redirect, its for the exact purpose of reading that episode's information, not for reading a complete season article, searching for the intended reference. It also has the additional bonus of having links already pointing to it if/when an article is created and the redirect can have a short description, allowing even better searching options. --Gonnym (talk) 21:55, 9 November 2018 (UTC)
• Oppose at the current time. There are a couple more things to note you haven't apparently thought of - the first is that the best target may not be the "List of ... episodes" article, e.g. On the Buses (series 1) would be a better target than List of On the Buses episodes, but a bot wouldn't know this. The second, and more important, is that episode titles may be ambiguous - e.g. "The Opening Day" is the title of the second episode of The Brittas Empire, but this is also a plausible search term for Opening Day and Opening Day (The Twilight Zone) and it is also the name of an episode from series six of Hi-de-Hi! (and it's possible there are others). Hatnotes could suffice but for a long list of episodes there could be half a dozen or even more "redirects here" hatnotes for various different names - and at this point its getting disruptive. If instead of "The Opening Day (episode)" the redirect is "The Opening Day (The Brittas Empire)" or similar you're not actually going to be providing search terms that are useful to most readers without also creating new disambiguation pages which have a much higher maintenance requirement than redirects and some editors object to disambiguation pages where (almost) none of the targets have individual articles. I'm not against this per se, but I do think you need to take the feedback you've received (and any more that comes in) and refine your proposal, probably in conjunction with a bot operator so that technical questions can be answered, before it's ready for approval. Thryduulf (talk) 23:26, 9 November 2018 (UTC)
  • Thanks for the comments. I don't know if you've looked at the redirect examples that I've given but they both link to the season article. That was the intent and both the bot and the original list of articles could already know that. As I said above, I gave a rough outline as I don't think it's necessary to talk about the finer points, if editors are still debating the operation itself, as it's a bit of placing the cart before the horse. Your second issue has already been addressed by me It then checks to see if an article which is not the episode article exists with that name, if there is no article, it will create one with that name, if there is one (which isn't the episode) it will create one with the format of Episode name (Series name) - so for "The Opening Day", an article that has been created for since 2006, it will indeed create one at the base name, but this isn't really a bot issue, as even a manual editor would create that. If a redirect was desired to point to "Opening Day" (which seems fair, even though WP:SMALLDETAILS arguments in WP:RM are routinely used to argue the opposite), it should have been created. An easy fix could be to that articles starting with "The" could also check the phrase without it. I'd love to work with a bot operator but they were the ones that sent me here, to first get consensus. Regarding your last point about disambiguation pages, from the ones I've checked and seen there are already disambiguation pages for most episode names that needed it. If new ones shouldn't be created, the few that will fall into this category, will still enjoy being able to be linked to and searched for (type "opening day" and you will see the twilight zone episode pop up. Use mobile, you will also get a short description for it in the search) - that to me still seems like net positives. --Gonnym (talk) 08:24, 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 Y disband the Mediation Committee in entirety. And, all processes and components thereof, shall be marked as historical.
• Details -->
  • The broader theme of the comprehensive analysis by the OP, (Beeblebrox) has been heavily supported by numerous participants.
    • There is a broad consensus that MEDCOM is akin to a toothless process that hasn't served any practical purpose in the recent spans and that the process of RFCs are far superior and useful, in the locus of resolving content-disputes.
  • The opposition camp contains some interesting take(s) on the issue but I am afraid that they have failed to turn the tide in their favor, by a count of heads as well as by a weighing of arguments (and corresponding rebuttals).
    • RMClenon, TransporterMan, Coffman et al have argued for MedCom to be sustained in light of the potential of the process to resolve complicated content disputes (without delving into conduct) but the rebuttals are good-enough.(vide RGloucester, Swarm, Boing et al) That the inner-machinery of the project is heavily non-transparent and the working is overtly bureaucratic compounds the dismal scenario.
  • A few folks (Blackmane, AGK, Steven Crossin et al) have supported ideas of a reform to increase it's effectiveness but they consist of a diverse bunch of proposals, which has failed to progress anywhere past the brainstorming session(s) and there is accordingly, an absence of consensus on that locus.There is also a lack of consensus as to merging this to DRN, (despite no rebuttal).
    • Interested people may pursue such ideas separately and present to the community, for an evaluation.
  • Isaacl's comment at the end of the Extended Discussion section, might be a worthy read:-)

Respectfully, ∯WBG^converse 19:10, 12 November 2018 (UTC)

---

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

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

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

Rationale:

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

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

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

MedCom discussion

• Support Doesn't appear to be active, other dispute resolution noticeboards seem to work better. ^Semi_Hypercube ✎ 00:38, 11 October 2018 (UTC)
• Support Per above. – BrandonXLF ^(t@lk) 00:41, 11 October 2018 (UTC)
• Support pet project of a small number of users that doesn't really do anything anymore. It gets a fair amount of requests, but they are never heard, and the community has pretty much moved past centralized content dispute resolution in this manner, preferring talk page RfCs and if need be, an RfC on a policy page or noticeboard. TonyBallioni (talk) 00:44, 11 October 2018 (UTC)
• Support – No longer a useful process...much like WP:RFC/U was, back when it was abolished. Other forms of dispute resolution have been used in its place for years, with greater effect. No reason to retain the air of community bureaucracy at a process that is largely maintained by one person. In the end, people have voted with their feet. Abolish it. RGloucester — ☎ 00:45, 11 October 2018 (UTC)
• Support - seems to have no purpose at all these days. Home Lander (talk) 01:08, 11 October 2018 (UTC)
• Support Inactive, useless. TonyBalloni sums it up nicely. ThePlatypusofDoom (talk) 01:46, 11 October 2018 (UTC)
• Support per above. --Rschen7754 02:17, 11 October 2018 (UTC)
• Oppose the abolishment of all the forums for editor review (apart from RfA) was not a benefit to the encyclopedia-building project, and I don't think abolishing MedCom will be either. It will be far more work to resurrect this in the future than to let it linger idle for now. Some forum that is the clear forum-of-last-resort for content disputes is needed; I don't see DRN or ARBCOM as filling that role. MedCom should have some type of reform to be more relevant, but doing it at the barrel of a gun won't work. power~enwiki (π, ν) 03:11, 11 October 2018 (UTC)

  MedCom isn’t a forum of last resort. We have no such thing for content disputes and never have. TonyBallioni (talk) 03:29, 11 October 2018 (UTC)

  It actually has no authority whatsoever, being entirely voluntary and non-binding. I also object to the characterization of this being the “barrel of a gun” as what it really is is just admitting that medcom doesn’t do anyhting anymore so there’s no point in directing users to it. There already isn’t an actual committee. Beeblebrox (talk) 06:14, 11 October 2018 (UTC)

  Well, it certainly needs to either be more willing to do *something*, or actually be a forum of last resort. I plan to stay an oppose !vote, but without some viable reform proposal this will certainly be marked historical. There's a good chance it won't do anything for the next year even if it isn't marked historical. power~enwiki (π, ν) 15:29, 11 October 2018 (UTC)

  If it gets to the point that the talk page, RFCs, RSN, DRN, &c., cannot solve a content dispute, that almost certainly means that there are conduct issues. That's the essential problem with the structure of this thing...it isn't fit for purpose, and so it doesn't do anything. In the end, though, its excessively bureaucratic proceedings are a relic of another era, and I personally am happy to condemn them to history. RGloucester — ☎ 15:39, 11 October 2018 (UTC)

  @Power~enwiki: Which other now-abolished forums for editor review are you referring to? 142.160.89.97 (talk) 07:21, 16 October 2018 (UTC)

• Support It is already dead, so may as well save the time of all the people requesting resolution through it. They are better off starting a WP:RFC to determine consensus which is how content is settled per policy. If lower forms of resolution have not resolved the dispute, it is extremely unlikely that a completely voluntary non-binding and toothless process will do either, and this is reflected in the reality of the situation. Galobtter (pingó mió) 07:17, 11 October 2018 (UTC)
• Support per above rationale. Inactive, and preference for talk pages and RfCs. Better to redirect attention of volunteers elsewhere than have a semi-morubund venue. --Tom (LT) (talk) 07:37, 11 October 2018 (UTC)
• Oppose I do not see any clear benefits of closing MedCom down now. At least the proposers have not specified any. In addition, {{historical}} template is used to mark pages or processes that have become completely inactive and for a long time. These is not true in the case of MedCom - there is still some activity. So, this is not an appropriate proposal. If somebody wants to simply close it down, there should be a wider RFC, not a small discussion on this board. Ruslik_Zero 09:44, 11 October 2018 (UTC)

  Uhh, where would a wider RFC be than a discussion at the pump advertised at WP:CENT as this discussion is? Galobtter (pingó mió) 09:47, 11 October 2018 (UTC)

  Yeah, I find this comment very bizarre. You can disagree with the reasoning I presented but there is nothing inappropriate about it, it is widley advertised, and if somebody just shut this discussion down now that would be wildly inappropriate. Beeblebrox (talk) 18:35, 11 October 2018 (UTC)

• Neutral - I don't think the Mediation Committee has ever really played a very important role. It's non-binding, and it adds a layer of bureaucracy to dispute resolution that most editors don't want to deal with. Nevertheless, a part of me wants to see it reformed and modernized so that it can serve some sort of purpose. But at this point, it may not be feasible. Kurtis ^(talk) 09:50, 11 October 2018 (UTC)
• Oppose — If MedCom is closed WP will have no DR mechanism to mediate complex disputes. DRN is specifically designed to handle disputes which can be resolved within 14 days and has an automated case-closing mechanisms for cases which do not fit that mold. Moreover, anyone can be a DRN volunteer. Current volunteers generally discourage newcomers to Wikipedia from volunteering, but they can do so if they care to. (Third Opinion is the best training ground for newcomer volunteers.) Cases which are accepted at MedCom, and there have not been any recently, it is true, often take weeks to months to resolve with multiple different specific issues being considered. MedCom has never taken many cases and DRN has, as it should, taken away the simple cases that might have previously been handled at MedCom, but MedCom still plays a necessary part, if only rarely. — TransporterMan (TALK) 12:17, 11 October 2018 (UTC) (Chairperson, Mediation Committee)

  Counterproposal. Retain but improve MedCom by making it the actual last resort. Make it mandatory to participate at MedCom by making a good faith effort to resolve a dispute if the case is accepted for mediation by the Committee. The requirement would not require a party to actually resolve the dispute, but only to participate in mediation and make a bona fide good effort to do so. Parties who refuse to participate, or who participate and fail to make a good faith effort, should be barred from continuing to participate in the dispute and from editing the article in question in a manner related to the dispute (this is equivalent to the same requirement in real world court-ordered pre-trial mediation: you've got to show up and make an effort to resolve the case). The mechanics of this will need to be worked out, members of the Committee who are administrators could impose the limited topic ban or the Committee could, in the alternative, make a recommendation to ANI. Either way, the community would have to trust the Committee to prevent this from becoming a means of gaming disputes. Cases should be required to at least file the case for consideration at Third Opinion or DRN or RFC before coming to MedCom, so as to weed out the simple cases. Respectfully submitted, TransporterMan (TALK) 12:17, 11 October 2018 (UTC)

  I would recommend starting a separate RFC for a replacement venue of any sort, if you think Wikipedia should have one. --Izno (talk) 14:09, 11 October 2018 (UTC)

  Sorry to break this to you, but Wikipedia currently has no dispute resolution mechanisms to mediate complex disputes. MedCom doesn’t exist already. Beeblebrox is just asking we admit that and stop wasting people’s time by sending them through a process that doesn’t actually exist. TonyBallioni (talk) 12:21, 11 October 2018 (UTC)

  I cold not be more opposed to yor counter proposal. No way no day can we give Medcom “teeth”. Currently it’s basically you, but in theory there are three other mediators. None of you were elected or appointed by the community so there is basis for any sort of real authority. (for those of you who are unaware, Medcom selects it’s own members, and has it’s own mailing list where they discuss their inner workings. It’s very much a closed shop) Beeblebrox (talk) 18:50, 11 October 2018 (UTC)

  What if a precondition of the counter-proposal getting acceptance was all current (and future) members have to stand for election in the same manner as ArbCom members do? Additionally, how about actually giving MedCom a couple of dentures to make binding content-related decisions (ie: "Source X cannot be used in this context unless wider community consensus agrees to it" or "The reliability of that source is currently disputed so cannot be used until {condition}") Dax Bane 10:09, 18 October 2018 (UTC)

• Support - There are too many backstage venues as it stands. This one has atrophied. Carrite (talk) 12:26, 11 October 2018 (UTC)
• Support Pretty much dead. MoonyTheDwarf (Braden N.) (talk) 12:44, 11 October 2018 (UTC)
• Support per the proposer. It seems fairly clear that the WP:RFC process is superior for content disputes; where it is inhibited is when conduct becomes an issue, but that's a separate set of processes anyway. --Izno (talk) 14:09, 11 October 2018 (UTC)
• Support As it appears largely redundant, and has pretty much shut down on its own already, it seems smart to officially 'close' the venue. — Insertcleverphrasehere ^{(or here)} 14:14, 11 October 2018 (UTC)
• Zaphod sums it up well, and honestly Power~enwiki lays it out well enough. I've always liked MedCom — it aims to fill a much-needed space for content disputes — and in my starrier-eyed days of the very late aughts, once thought it'd be nice to serve. Still, it's not filling that space because nobody uses it. I think the project would be better if MedCom were a productive place of dispute resolution, but it's not. As such, keeping it "active" and as an "option" is probably doing more harm than good, interrupting other resolution methods and drawing out disputes needlessly. There are good things nobody uses, and after trying and trying, there's no shame or harm in admitting it's not working. ~ Amory (u • t • c) 15:45, 11 October 2018 (UTC)
• This proposal is a remarkable coincidence. I began discussing the underuse of mediation with a couple of my committee colleagues last week.

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

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

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

  Actual practice suggests we do not need this form of mediation to resolve disputes. If such a process were needed, MedCom would not've fallen away as it did. There are better venues for content dispute resolution, and behavioural problems are dealt with in the usual channels. I simply do not see the benefit of continuing to emphasise a process that has died a natural death...it 'died' for a reason, and for those reasons I am opposed to reform. If such proposals were to create an entirely new body, from the ground up, and then seek community consensus for establishment, that'd be another thing. But I do not see the benefit in launching such a proposal under the auspices of the existing 'MedCom' mandate, which has clearly run its course. RGloucester — ☎ 17:42, 11 October 2018 (UTC)

  That is a rather brazen – and, in my view, incorrect – view of dispute resolution. All around the community there are content disputes that do not get solved until one editor grows frustrated enough to lash out. At that stage, they are blocked or receive a sanction in enforcement of general sanctions. We then call that consensus by default, regard the dispute resolved, and carry on with a deficient article. I do not see the "actual practice" that led us here as right, and I am proposing we update the process to tackle the wider problem of a serious dearth in effective solutions for protracted disputes. Or perhaps we could just redirect the whole thing to some essay and continue decentralising the facilities for editors in dispute to receive guidance from experienced editors; certainly that is the way things more generally are heading.

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

  The biggest problem with what you're proposing is that it really has nothing to do with MedCom...it's a proposal for an entirely new process, replacing the existing MedCom with something different. In as much as this is what you propose, I cannot accept the use of the existing MedCom policy to create an entirely new process. I'd rather this be marked historical, as it is indeed historical, and defunct, and something new prepared for review by the community. What you propose, I think, is a circumvention of community consensus. RGloucester — ☎ 18:23, 11 October 2018 (UTC)

• Support purely on grounds of inactivity, I think it's entirely possible for a process like MedCom to play a role in our dispute resolution processes. Activity has consisted of the chairperson rejecting requests for some time and it doesn't seem to be actually resolving disputes. Given that we are basically misleading people into thinking it's a working process if we don't tag it as inactive/historical. If a significant number of active editors are willing to commit to reviving the project then I'd be happy to change this. Hut 8.5 18:17, 11 October 2018 (UTC)
• Neutral Like AGK, I wish this were more active. I say this as someone who has not participated, primarily because I believe that good mediation requires a certain skill level which typically require some training and I haven't had formal training. There are many people who have had such training and frankly surprised we haven't attracted more of them. If I were a mediation professional, I might see Wikipedia as a great place to practice skills. While that hasn't happened, perhaps it will. We've got a small national conversation about civility in progress, and, ever the optimist, perhaps that will spark more interest in mediation and some of those people will show up here and offer to help. There might be some value in having an existing structure rather than having to reinvent from scratch. Arguably, if this is marked as historical, it doesn't mean it goes away so that goal could be accomplished even if this is marked as historical, but I prefer something a little softer. Perhaps a message at the top of the page that says this projectprocess is currently inactive but could be reinvigorated if enough participants show interest.--S Philbrick(Talk) 18:27, 11 October 2018 (UTC)

  To note, MedCom is not a project...it is actually a policy-based process specified by Wikipedia:Mediation Committee/Policy. The remaining one active member of the Committee has not even been able to follow this policy, in that he has continued serving despite the end of his term. I really find it hard to accept that we have a policy that literally no one follows or uses...is this not contradicting the very nature of Wikipedia policy itself? RGloucester — ☎ 18:31, 11 October 2018 (UTC)

  I thought this point was insignificant to the discussion, but as it keeps coming up – the coordinator/chair would be reconfirmed by email. They just do not announce it or make a song and dance. AGK ■ 18:57, 11 October 2018 (UTC)

  I didn’t mention the internal processes used because as you say it has no bearing on the core reasons for this proposal, but if we were to do that I think the community would be rather surprised. I’m not aware of any other group who determine their own membership devoid of community input and decide who their chair is in an off-wiki discussion on their own privileged mailing list. Beeblebrox (talk) 19:06, 11 October 2018 (UTC)

• Oppose This is a truly silly proposal. This proposal does not benefit Wikipedia in the least, and is a waste. Just because something is not that active right now, does not mean it won't reactivate in the future. We just saw that with the Signpost, and the needlessness of this RfC is plain - you don't like that someone is over there fielding complaints, etc., find something useful to do with your time, and focus on writing articles, not complaining about other people offering to mediate disputes and respond to complaints in a slightly structured forum. Alanscottwalker (talk) 18:39, 11 October 2018 (UTC) As it is now argued below that oppose comments are not supportive, there must be some confusion, being supportive of editors who want to provide mediation for others who want it is being supportive of MEDCOM, and it is the right thing to do. -- Alanscottwalker (talk) 12:35, 12 October 2018 (UTC)

  Keeping MEDCOM open misleads people into thinking it actually resolves disputes and wastes their time filing out a request for mediation only to get it rejected. Galobtter (pingó mió) 18:52, 11 October 2018 (UTC)

  What nonsense. Never in the history of problem solving has having to state the problem to someone else formally, and the parties involved, ever been a hindrance to problem solving, the opposite is the case. Alanscottwalker (talk) 19:56, 11 October 2018 (UTC)

  A straw man if I’ve ever seen one. Unless you can point out where anyone is “complaining about people other people offering to mediate disputes“ as that is not anywhere in the rationale at the top. This is only about admitting the obvious, this process may have had a place once but it has been rendered obsolete and redundant by a cultural shift towards other forms of dispute resolution. This isn’t personal, so I don’t appreciate you trying to make it so. Beeblebrox (talk) 18:59, 11 October 2018 (UTC)

  What? Personal? I said nothing personal. And you don't need to repeat your already rejected argument that there are too many ways for people to go about solving problems. Alanscottwalker (talk) 20:13, 11 October 2018 (UTC)

  WP:BAG. I think it is time we step back and let other community members independently assess the original proposal, the counter-proposals, and the limited further discussion. Badgering is causing the signal-to-noise ratio of this thread to plummet. AGK ■ 19:13, 11 October 2018 (UTC)

  I hear you, but when some people are suggesting this be closed as innapropriate and others are trying to personalize the dispute instead of responding to the actual issues under discussion it can be hard to restrain oneself. Beeblebrox (talk) 20:12, 11 October 2018 (UTC)

  Well, this proposal is complaining about people offering to mediate disputes, so calling a spade, a spade is just appropriate. The proposal's reason is, 'we don't like the way you mediate.' Alanscottwalker (talk) 20:46, 11 October 2018 (UTC)

  Every word of what you wrote is wrong. Beeblebrox (talk) 21:16, 11 October 2018 (UTC)

  Every word is not only right, it's evident. Alanscottwalker (talk) 22:01, 11 October 2018 (UTC)

  (edit conflict) @Alanscottwalker: I agree with what Galobtter said. That, and the problem with comparing it with the Signpost is that on the Signpost, there was just an issue of activity of the participants, (though it has been brought up that only one of the members of MedCom is still active) whereas with MedCom it has pretty much been superseded by other dispute resolution pages, such as Wikipedia:Dispute resolution noticeboard, Wikipedia:Administrators' noticeboard/Edit warring, Wikipedia:Third opinion, and the like. ^Semi_Hypercube ✎ 19:02, 11 October 2018 (UTC)

  Again, senseless, 'there are too many ways to go about addressing issues in somewhat different formats' is not even a coherent critique. Alanscottwalker (talk) 20:06, 11 October 2018 (UTC)

  At the time of the last discussion about this at VP Policy, about a month ago, at least 3-4 other current active members of the Committee either indicated in that discussion or on the Commitee's mailing list that they are, indeed, still active. It's not correct that I'm the sole surviving member. Moreover, past members who are inactive are still members and I wouldn't hesitate to poll them should our active member list be depleted and a mediator needed. - TransporterMan (TALK) 19:27, 11 October 2018 (UTC)

• Support as per everyone above, No point keeping and sending editors to something that's pretty much inactive, There are other venues which are quicker and simpler. –Davey2010^Talk 20:08, 11 October 2018 (UTC)
• Neutral Would be nice to see it given a place but without a significant review into how Dispute Resolution works and the Mediation Policy it is not sustainable. In its current state, it's not worth keeping. RhinosF1 (talk) 20:17, 11 October 2018 (UTC)
• I would merge with the Wikipedia:Dispute resolution noticeboard, since it can be arbitrary in dividing lines between "small" and "large" disputes. Also the fewer "go-to" places the better. Cas Liber (talk · contribs) 20:19, 11 October 2018 (UTC)

  Seems like that would be the best way actually. RhinosF1 (talk) 20:25, 11 October 2018 (UTC)

• support, largely as stated: redundant to other forums that produce better results. Guy (Help!) 21:10, 11 October 2018 (UTC)
• Support per nom. Effectively defunct. There should be prominent pointers to other dispute resolution forums like DRN though. ---- Patar knight - ^chat/_{contributions} 00:15, 12 October 2018 (UTC)
• Support per nomination and Carrite (too many backstage venues), and largely redundant. . Kudpung กุดผึ้ง (talk) 02:47, 12 October 2018 (UTC)
• Oppose: I'm not sure if I knew about the Committee existence. It sounds like it could be something useful for mediating complex disputes. Even if the case log is not very active now, it does not mean that it may not pick up in the future. K.e.coffman (talk) 05:32, 12 October 2018 (UTC)
• Support Largely ineffective, generally redundant to many other binding processes that we have. Closure is overdue. –Ammarpad (talk) 05:54, 12 October 2018 (UTC)
• Oppose per TransporterMan. Process is important, especially when it comes to complicated disputes. Having an outlet for such that is less looming than the arbitration committee benefits the community, even if it is not used very often. As long as their are volunteers willing to run it, we should allow it to stand.— Godsy ^(TALK_CONT) 08:43, 12 October 2018 (UTC)
• Support per the nominator's rationale; I find the oppose reasoning unconvincing. Enterprisey (talk!) 09:05, 12 October 2018 (UTC)
• Support also per nom: the project has clearly become moribund, and, with respect, to the oppose comments, they mostly consist of IDLI arguments. Which, of course, are not supportive arguments.——SerialNumber54129 09:51, 12 October 2018 (UTC)
• Support I cannot find fault with anything in the nomination statement (content or form :), and as mentioned above, there are actual downsides to stringing along a factually dead component of the mediation meta-process. Pruning deprecated components is not structural deletionism, it's necessary basic housework. --Elmidae (talk · contribs) 12:41, 12 October 2018 (UTC)
• Oppose closing it down wholesale. Better to reform it into something useful than to shut it down entirely. feminist (talk) 13:27, 12 October 2018 (UTC)
• Support: Medcom is unnecessary bureaucracy, an obscure and confusing part of a complex set of intricately linked dispute resolution processes. It's barely active and it doesn't seem to work. Certainly most users would not know when to turn to it. Dispute resolution reform is necessary and cutting out processes that have died a natural death should be part of that reform. — Bilorv_(c)(talk) 18:13, 12 October 2018 (UTC)
• The simple answer to the neutral question asked in this request is no; the Mediation Committee should not be closed and marked as historical. Unfortunately both concepts, simple and neutral, end with that.--John Cline (talk) 20:05, 12 October 2018 (UTC)
• Support this is mostly just acknowledging the current state of things. If people want some kind of binding arbitration/mediation that is actually useful, they should start an RfC proposing that rather than keeping this on life support or standing by while another inch of dust accumulates. {{u|zchrykng}} {T|C} 00:39, 13 October 2018 (UTC)
• Support per above. Opposes are unconvincing. -FASTILY 02:41, 14 October 2018 (UTC)
• Support Thank all involved for their work and close it. Only in death does duty end (talk) 14:22, 14 October 2018 (UTC)
• Weakish support - I opened the previous VPP thread, but still haven't come to a solid conclusion about the best way forward. I get the point some people have made there are opportunities for reform, and that it would be best to work towards making it useful rather than shutting it down. However, I'm not convinced that those reform efforts wouldn't be better suited for DRN, incorporating some flexibility to make it cover the cases that would otherwise go to RFM. I also appreciate the idea that some aspects of RFM seem a bit anachronistic in wikiculture (like the committee selected by themselves). There is indeed a value in doing it that way, but I think that arbcom has shown that we can have decent results with community-appointed members. Robert McClenon made some good points in the previous discussion about the relationship between DRN and RFM and what characterizes each of them, so I wouldn't want to immediately say that DRN should absorb RFM, but I do think that if RFM is closed, the very next step should be a thorough evaluation of DRN to see how it could, as the sole forum of its kind, be made most useful (whether by framing it as an eventual expansion to include RFM-type cases or just as an analysis and reform process in its own right. Also, pinging Robert McClenon and TenOfAllTrades, both active in the previous discussion but haven't commented here yet. — Rhododendrites ^talk \\ 15:06, 14 October 2018 (UTC)
• Oppose – I opposed the idea of shutting down the MedCom the last time it was suggested, even though the MedCom has not had a case in more than a year. As both I and User:TransporterMan have said, DRN is a lightweight process for disputes that can be resolved by discussion in one to two weeks, or at most three to four weeks. DRN has never been meant to be a heavyweight process for disputes that may drag on for months. I understand that the proponent is proposing in good faith to shut down a process that hasn’t been used recently, but it is a process (not a project) that doesn’t have a substitute. There are two problems currently with MedCom, but the two problems tend to offset each other. First, there is a shortage of mediators, but, second, there are very few cases for which formal mediation is in order. My own guess is that if, while this RFC is still running, a case is accepted by MedCom, MedCom will find a volunteer mediator to handle the case.

It now appears inevitable that MedCom will be shut down. The reasoned Oppose !votes are being shouted down. This raises the question is what will happen the next time there is a long complicated content dispute. What will probably happen is that we will lose two respected editors. It isn’t just a matter of taking the acronym RFM out of a list and the procedure MedCom out of a list of processes. It would be like disbanding the volunteer fire department because there hasn’t been a fire recently. Not every content dispute can be contained by DRN and specialty noticeboards. If we have a case that needs real mediation, at present, we can find a mediator. If we cross that entry out of the list, then we just throw it to WP:ANI, which is at best a damage-containment effort, or to ArbCom. What will happen the next time that there is a content dispute for which formal mediation is appropriate is that, first, it will go to DRN. Handling the dispute will burn out the DRN volunteer moderator who tries to handle the case without actual experience in conflict resolution, and they will likely not only leave DRN but leave Wikipedia. The conduct issues that had been contained while the content was being addressed will then re-emerge, and there will be multiple trips to WP:ANI and possibly a trip to ArbCom, and eventually topic-bans will be imposed, and in all likelihood one of the two editors, probably a respected content contributor, will be sufficiently embittered by the inability of the community to resolve the content dispute that they will likely leave Wikipedia.

The Support side has not considered the future adverse consequences of doing away with MedCom as the fall-back last resort for content disputes. Just because it hasn’t been used recently doesn’t mean that it isn’t needed. There hasn’t been a fire. That doesn’t mean that there won’t be a fire.

Since we are now almost certain to mark the MedCom as historical, the best way to recover from this mistake will be to create something having a similar function and mission. What we ought to be doing, rather than looking for a procedure to take out of a list of procedures, is trying to improve our dispute resolution procedures. Just getting rid of one that hasn’t been used recently is very much the wrong answer. It would have been better to propose improvements to DRN ‘’before’’ proposing to get rid of MedCom, but I don’t see any real hope now. Robert McClenon (talk) 01:59, 15 October 2018 (UTC)

I'm sorry, Mr McClenon, and if you perceive this as 'shouting down', I can certainly apologise further, but having read through various MedCom cases, I find it hard to accept this position...I see a combination of 1) dislocation of discussion that should have taken place on the article talk pages to a backroom space 2) dancing around obvious behavioural issues for the sake of reaching the illusion of a compromise. A comment made by Geometry guy in 2007 sums up, I think, the problems with the so-called mediation process. It applies an overbearing bureaucracy to disputes that could be resolved through talk page discussion or other normal channels, trying to force some kind of 'compromise' to appease warring parties, with the ultimate result of either failing completely because of an inability to deal with underlying behavioural problems, or comprising the content of the encylopaedia for the sake of appeasing editors participating in advocacy for a certain position. The reality is that we have better tools to deal with disputes on Wikipedia now...the false dichotomy between the so-called 'content' and 'conduct' disputes has been cast aside, and systems like discretionary sanctions have been brought in to encourage more moderate conduct in areas prone to discord. MedCom, I think, is truly a relic of a more idealistic era in Wikipedia's development. It no longer serves a practical purpose. All this proposal intends to do is recognise the status quo, nothing more. RGloucester — ☎ 03:33, 15 October 2018 (UTC)

• False. Every single Wikipedia dispute resolution mechanism divides conduct and content, its why we have Wikipedia:CONTENTDISPUTE. Similarly, you can't argue content disputes at AN/I, nor can Arbitration decide content issues. And whatever the elaboration of mediation, as Wikipedian's do like to write long explanations, Mediation's process is simple: someone shows up, states a problem and notices others, and a volunteer shows up and responds. Alanscottwalker (talk) 19:18, 15 October 2018 (UTC)

  You misunderstood me. My point was, if a so-called content dispute cannot be resolved by talk page discussion, various noticeboards, RfCs, &c., it usually means that there is a conduct issue, not a true content issue, and it should be dealt with as such. The 'black and white' distinction between content and conduct disputes is no longer relevant...hence the development of things like community and ArbCom discretionary sanctions, which force a 'drop the stick'-style approach on the part of editors in dispute-laden topic areas, lest they be sanctioned. RGloucester — ☎ 19:31, 15 October 2018 (UTC)

  The content/conduct distinction is always relevant on every one of our boards. Every one -- that is our policy -- repeatedly. Your odd argument amounts to, 'oh, we can just tell people to shut-up, instead of mediating', which actually makes no sense because of the arbitrariness and strange value of it. RfC's are often weirdly sprung, poorly constructed, and poorly researched, so it is bizarre to hold them up as models for deliberation. (e/c) As for talk pages, the reason the 'shut up' method is employed there, at all, is because talk pages are without other boundaries. Alanscottwalker (talk) 19:46, 15 October 2018 (UTC)

  I've said my bit...my time is up. I still think the comment by Geometry guy is very relevant...but, I too must 'drop the stick'... RGloucester — ☎ 19:56, 15 October 2018 (UTC)

  It is true that many disputes have both a content aspect and a conduct aspect. There are very few disputes that are purely conduct disputes. If the problem is simply the conduct of an editor who is a vandal, troll, or flamer, the offending editor normally gets indeffed quickly, without a real dispute. Content dispute resolution mechanisms, such as DRN and MedCom, operate on the optimistic assumption that the parties will set aside their conduct concerns long enough to resolve the content issue, and then the conduct issue is resolved as a side benefit. Conduct dispute resolution mechanisms, such as WP:ANI and Arbitration Enforcement, operate on the recognition that the offending editor who is preventing the content issue from being resolved can be sanctioned long enough to resolve the content dispute. There never was a black-and-white distinction, except for vandals, trolls, and flamers. It is still true that throwing away a content dispute resolution process is unwise. Robert McClenon (talk) 02:32, 16 October 2018 (UTC)

  The only comment I want to add here (and responding to actual points made is not "shouting down") regards seeing "MedCom as the fall-back last resort for content disputes". It is not, never has been, and can not possibly be the fall-back last resort for content disputes - not if it can make no binding decisions. Boing! said Zebedee (talk) 09:09, 16 October 2018 (UTC)

• Strong support - Wow, it's definitely time to put this thing out of its misery. MedCom is inaccessible, redundant, ineffective, archaic relic, particularly in the context of modern dispute resolution, which is heavily streamlined in favor of formal, community-based consensus building, which easily handles both routine and complex disputes with binding decisions. At this point, it's more of a distraction from measures which actually resolve disputes. It's less useful than the long-defunct WP:RFCU or WP:WQA, and frankly it's amazing that it still exists. This concept, where you have some very "complex" dispute and the only viable solution is for a mediator to walk both parties through it ad infinitum until they reach an understanding is, quite simply, unrealistic, and to present it as some sort of "last resort" DR measure that we might need someday is a joke. Editors are expected to competently pursue DR and seek and abide by consensuses. The community no longer tolerates editors who are obstinate and obtuse, who can't or won't communicate effectively to resolve disputes, who won't listen, or who won't let it go when they can't secure a consensus, and who will drag out disputes past a reasonable point. When these situations arise, we're not relying on this bureaucratic dinosaur to walk them through their dispute and hope everyone will be agreeable, even though they're spending weeks and weeks of their life trying to come to an understanding in an online argument. We're investigating the underlying behavior and sanctioning or warning users, or implementing page restrictions, or going to ArbCom for binding solutions, so that actual collaborative, good faith editors do not get burned out and can continue contributing. That's why MedCom is an obsolete relic, not because we haven't had any "complex disputes" lately. Also, this whole thing is just out of touch with the community. It's purported to be this formal, serious thing, the be-all and end-all of dispute resolution, with legitimacy stemming from Jimbo himself, but in reality it's the pet project of this closed club of a small handful of users (or more realistically, one user), who decide from within what their membership is, and what their rules are, and when to take a case (read: never) and really don't contribute anything to DR. It's totally out of whack. The "chair" of MedCom's comments above just goes to show how out of touch with DR and the community this whole thing has become. Rather than actually demonstrating how and why MedCom has done and can still do good for the community, his case for keeping it is that we somehow 'need' his committee, because they don't accept newcomers into their ranks, or because they will accept disputes that drag on for months while DRN won't (I wonder why), or because they "mediate". I've been involved in DR pretty much since I became active here, and this kind of mediation-based approach to DR has never been particularly effective anyway, and keeping around a self-important group of 'mediators' who have long-since outlived their usefulness to the project is just silly. I thank those who have invested time in this project, but it's time to pull the plug.  Swarm  talk  00:26, 16 October 2018 (UTC)
• Strong support: I was pretty convinced of MedCom's uselessness when I was on (and chaired) the committee--and that was 2007. I've toyed with the idea of proposing its closure off and on over the years, but never got around to writing something up. FACE WITH TEARS OF JOY ^{[u 1F602]} 03:01, 16 October 2018 (UTC)
• Support. At Wikipedia:Mediation Committee it says "The Mediation Committee ... is the last stage of content dispute resolution on the English Wikipedia. Mediation is entered into voluntarily by the parties to the dispute and does not result in binding resolutions." But that is self-contradictory - a voluntary venue that does not result in binding resolutions can not possibly be the last stage in resolving anything. In practice, consensus arrived at by community discussion is the ultimate stage in content dispute resolution, and that is binding - and if editors refuse to follow it, sanctions can be applied directly from that. And as content dispute resolution often requires a good understanding of a subject and the sources supporting it, and with the way Wikipedia has massively developed since 2003, a small number of chosen editors really can not be up to that job. The Mediation Committee is one of those things that I think was a good idea and had its value in the early days, but the community has moved on and has bypassed it as a means of content dispute resolution. I thank all those who have served on it or contributed to it in other ways, but I think it's time to let it go. Boing! said Zebedee (talk) 08:57, 16 October 2018 (UTC)

  But Consensus is not binding. On Wikipedia, there are only a very, very few things that that are binding, so the fact that mediation recognizes that is the only choice mediation has. -- Alanscottwalker (talk) 09:24, 16 October 2018 (UTC)

  That link to WP:CCC simply says that consensus can change. At the time a consensus is reached, it is binding until a new consensus some time later replaces it - and in the meantime, editors are bound to abide by it and can be (and regularly are) sanctioned for failing to follow it. In fact, with the few exceptions at WP:CONEXCEPT, consensus is ultimately the only binding process the community has at its disposal. Oh, and I'll add that the inability of MedCom to make binding decisions is nothing to do with WP:CONEXCEPT. Boing! said Zebedee (talk) 09:37, 16 October 2018 (UTC)

  There are millions of things that have no consensus, and regularly result in no consensus. And how is consensus reached, even in the things where it can be found, by discussion, even mediated discussion. And even then consensus is provisional by policy. Alanscottwalker (talk) 09:44, 16 October 2018 (UTC)

  And in cases where there is no consensus, MedCom is powerless to act, so it can not be what it claims to be. Once you take away the obviously incorrect claim that MedCom is the last stage of content dispute resolution, I simply don't see what it offers that WP:DRN doesn't. Boing! said Zebedee (talk) 10:04, 16 October 2018 (UTC)

  Act? If discussion is an act, it certainly can discuss (act on) things with no consensus, that's what all content dispute resolution forums do, there is no guarantee of consensus. A stage is just a forum, after all. Binding is only used once in Consensus policy and it is in CONEXCEPT, not in the rest of the policy.-- Alanscottwalker (talk) 10:38, 16 October 2018 (UTC)

  I honestly don't understand the point you are trying to pursue here, and this seems to be going in circles. If there is any way MedCom can actually be the last stage of content dispute resolution or can achieve anything that WP:DRN can't, I'm really not getting it from what you are saying. Anyway, I've explained my reasoning as best I can, and I'm happy to leave it to whoever judges the consensus now. Boing! said Zebedee (talk) 10:59, 16 October 2018 (UTC)

  (E/C) There is no other stage, it is the last on the list, per policy. MEDCOM has a slightly different structure, where experienced mediators are willing to discuss sources, analyse research, and policy, at length among willing participants. Anyone, who has been involved in complex content disputes knows they last months and months, through many stages Alanscottwalker (talk) 11:05, 16 October 2018 (UTC)

  Oh, you take the last stage of content dispute resolution to simply mean it's the last item included on a arbitrary list? That's meaningless, and if we simply take it off the list it won't be. To be of any value, the last stage of content dispute resolution must mean more than that. And yes, I know that disputes can be long and complex (we have plenty that have been going on for years, on and off), but merely stating that says nothing about MedCom's ability to solve them any better than current processes. Let's face it, MedCom already doesn't actually exist - it's just User:TransporterMan, who has overstayed his term in the chair. Anyway, thanks for answering those two specific points, but I remain in disagreement and still see no value in MedCom. Boing! said Zebedee (talk) 11:30, 16 October 2018 (UTC)

  Well, just to add on your earlier strain of thought, no, many of us involved in complex content disputes do not want admins (who can hardly claim to be the font of all knowledge) striking their heavy (sometimes incompetent) hand against the people we disagree with. As for the rest, it's just bizarre, because MEDCOM is set-up by CONSENSUS policy, to not be used much. You just contented consensus is arbitrary in its listing, so by that, consensus is arbitrary, is your argument. Alanscottwalker (talk) 11:50, 16 October 2018 (UTC)

  Nobody is suggesting that admins should decide content disputes (and we are forbidden from doing so anyway), so that strikes me as a false dichotomy. If a list of processes can be decided by consensus, then it can be changed by consensus too - which is what we are considering here.

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

  Well, you may not, but than others are suggesting that Admin action needs to replace MEDCOM - that is an argument being made, here. (It's also been suggested that complex disputes end quickly, when we know not true). And, it is your argument that raised it should be gotten rid of, for saying it is last, when that is exactly how consensus has wanted it, consensus wanted it to be last on the list, so that's not MEDCOM's fault. And the reason it is last is plain, because it is not meant, nor structured by consensus to be used much (and then the argument is that it's not much used, when that is its consensus design - to not be used much.) Alanscottwalker (talk) 13:15, 16 October 2018 (UTC)

  Can you show me where anyone is suggesting that content disputes should be decided by admins, or that admins should take over the function of MedCom? I accept that I might have missed any such suggestions, but it is definitely not part of the proposal. And yes, I *know* what the consensus currently is! And I am *not* blaming MedCom for it - I am simply saying that consensus can change (wasn't it you who first raised WP:CCC?) and remove it from the list, and that is what we are trying to decide here. And the "keep it because it is last on the list" argument is still empty. Boing! said Zebedee (talk) 13:51, 16 October 2018 (UTC)

  Several times in this discussion admin action has been mentioned as alterantive to MedCom, both Swarm's argument and RGlosters argument most clearly suggest that, and below and above, it's suggested that Arbcom is the alternative to Medcom, and Arbcom is all and only about admin action, so it can't be an alternative to Medcom because Arbcom can't handle content, or if it is made the alternative, Arbcom has to be changed. Your very first post here was in support of admin sanctions in your oppose to MedCom. I never made the 'keep it because its last on the list' argument, so your statement on that is not responding to me, or it is misdirection. You said MedCom should be gotten rid of because it says it is last, but is last on the list because that is what policy says, that's why it says that, WP:CONSENSUS would not allow it to say anything else, just as CONSENSUS would not allow MedCom to be binding. At least we now appear to have agreement that consensus is not binding because it changes, or is still being worked on (and CONSENSUS does not allow it to be binding). -- Alanscottwalker (talk) 15:47, 16 October 2018 (UTC)

  Why are you misrepresenting what I said? Nowhere did I say or imply that "Arbcom is the alternative to Medcom". I was clearly saying that the kind of extreme disputes that would normally be under the purview of Medcom are no longer "mediated" (read: tolerated), and are now dealt with via more effective measures, Arbcom being one of them. When you say "Arbcom is all and only about admin action", and "Arbcom can't handle content", you're quite simply wrong. You're objectively wrong on this. See WP:ARBPOL#Scope and responsibilities, or the Arbitration archives, or Wikipedia:General sanctions#Arbitration Committee-authorised sanctions, or the Wikipedia:Arbitration enforcement log. Arbcom actions and Arbcom-empowered admin actions resolve disputes exceedingly effectively, long before they're ripe for Medcom, which has between a 2% and 0% success rate even as a formal DR body. Medcom already doesn't fit into the DR process. Also, you're claiming that it's not Medcom's fault that they claim to be the "last line of DR", and it's just a matter of policy. Not even getting into the fact that Medcom policy isn't determined by the community, but Medcom themselves (who the community, stunningly, does not have jurisdiction over), nowhere in Medcom policy does it say or imply that it is the last stage of dispute resolution.  Swarm  talk  04:16, 18 October 2018 (UTC)

  @Swarm: If you read back through this discussion, you'll see he's been misrepresenting just about everything everyone says - you, me, Beeblebrox at least. I don't know why he does it, as it's quite clear to anyone else reading it all (and surely will be to whoever judges the consensus), but it's why I've stopped responding to him - there's no point talking to someone who continually does what he's doing. Boing! said Zebedee (talk) 04:31, 18 October 2018 (UTC)

  Well, no, that is not what I am doing. I am just disagreeing with you. Alanscottwalker (talk) 17:48, 18 October 2018 (UTC)

  Swarm, I was not referring to you about Arbcom, the only thing I was referring to your comment about is admin action, the "and" Arbcom was a different thought. And yes, I do think it is CONSENSUS ("ArbCom does not settle content disputes or change policy") that arbitration is about admin action, not content. Arbcom does not handle content (is I think universally agreed) and Arbcom's SCOPE certainly does not say it should handle content, rather it says it regulates Administrative action, prescribes Administrative action, and takes Administrative action (generally, by reversal of administrative action but also imposing bans and the like, removing Admin permissions, etc) - that is all that is meant by "all and only about admin action." So, no, it's not me, being objectively wrong. As for the rest, MedCom is approved Content DR process (the last) by WP:CONSENSUS policy ("For disputes involving many parties or complicated issues or which otherwise need more time for resolution than is allowed at DRN, the Mediation Committee (MedCom) is staffed by members with proven mediation ability."). Alanscottwalker (talk) 18:55, 18 October 2018 (UTC)

  "Arbitrary" was the wrong word, apologies for that - I've struck it, and I now think my comment does not need any further adjective. Boing! said Zebedee (talk) 12:29, 16 October 2018 (UTC)

  I also want to add that the way MedCom is managed, by appointing its own mediators without any community selection process, and conducting its business by internal mailing list, is anathema to the open way the Wikipedia community is supposed to work. Boing! said Zebedee (talk) 10:09, 16 October 2018 (UTC)

  Oh, and I've only just spotted the following at Wikipedia:Mediation_Committee#Policy... "The Mediation Committee policy documents how the Mediation Committee, its mediators, and the formal mediation process operates. This policy is maintained by the Committee and is considered an authoritative codification of how Committee matters should be conducted" (my emphasis). So the committee selects its own members and sets the policy that governs it, making it totally self-governed and not answerable to the community! I'm not suggesting there's anything wrong with the policy page itself, but self-governing fiefdoms like this are simply not compatible with the Wikipedia of 2018, no matter how well-meaning. Boing! said Zebedee (talk) 13:23, 16 October 2018 (UTC)

  In all these years, have you or someone else ever suggested a modification there, if not it has CONSENSUS (and has had for years) - besides, they are not the only small group that elects and selects itself on the pedia, several corners do. Volunteers band together to do things, its how volunteerism often works. And in particular with a matter like mediation, ground rules for mediation in the real world are standard. Alanscottwalker (talk) 13:35, 16 October 2018 (UTC)

  The question of whether anyone has suggested any modifications misses the point - I thought I made it clear that I have no complaints with the policy as it currently exists, and I certainly agree that it currently has consensus simply through the lack of any challenge. The point is that MedCom itself should not get to judge its own policy, regardless of whether it follows consensus - a benign dictator is still a dictator. If there are other groups which are self-selecting and which actually get to set their own governing policy rather than being subject to community consensus, I'd like to know what they are - I know there are projects which set their own guidelines, but they are all subordinate to community consensus and can be overruled. As for the condescending "Volunteers band together to do things, its how volunteerism often works", there's really no need for it and I think it is beneath you. I know how volunteering works, and you know that I know how volunteering works! What is not inherent in the concept of volunteering is a right for volunteer groups to set their own rules independently of whatever organization or group they volunteer under - but now I'm telling you something that you already know. Boing! said Zebedee (talk) 14:17, 16 October 2018 (UTC)

  Please, no one condescended to you. Although, I do find your discovery of public documents that you can go there right now and change those documents/get-those-documents-changed using community processes, an unfair criticism against other editors of Medcom. And noting there are other projects, which ban together on Wikipedia to do things (see eg Milhist and FAC, and those guidelines you mention) is just noting that it is not at all suprisng or unusual. Alanscottwalker (talk) 15:47, 16 October 2018 (UTC)

  I am not criticizing "other editors of Medcom", I am criticizing the concept of a body which decides its own policy rather than being subordinate to community consensus to set it. I asked you about "groups which are self-selecting and which actually get to set their own governing policy" as you appeared to claim there are others, and I specifically made the point that projects which set their own guidelines (which are subordinate to community-decided policy) are not in that category. You responded with a comment about "projects which band together on Wikipedia to do things". I'm not saying there's anything surprising or unusual about "projects which band together on Wikipedia to do things", I'm saying there very much is something unusual and surprising about groups which can set their own governing policy. How am I not making that clear? I've tried hard to hold a meaningful discussion with you, but I see no point in continuing if every response I get from you completely misses or misrepresents my point, and instead argues against a point I have not made or throws up yet another non sequitur. Anyway, I mean no unfriendliness, but I'm done with my discussion with you. Boing! said Zebedee (talk) 16:40, 16 October 2018 (UTC)

  How is it not clear? The community can go there and change those MEDCOM documents (and could in the past - it's an open wiki), right now (just as it can go change FAC process and selection of FAC people and Milhist process and selection of Mihist people, just as in any change of guidelines, policies, etc. etc.). So, whatever you're criticizing, if it's in the Wiki's documents, it can be changed right now by the community and is subject to the community (so it is not true to claim it is not subject to the community, if that is your criticism). But if you are not criticizing what is in the documents (the documents that can be changed by the community right now) then you would have to be criticizing people who drew-up the documents. But that the community would leave it to the people who want to mediate to make-up mediation, would actually make much sense and be very understandable. Alanscottwalker (talk) 19:20, 16 October 2018 (UTC)

• Support closure We provide mediation through other channels. The Wikipedia community does not have the administrative capacity to oversee and support the Mediation Committee as everyone imagined it when that organization was established. In the past few years we have gotten new automated tools for surfacing community discussions and improving the dispute resolution process. I would like to think that now, as compared to 5 years ago, ArbCom is divesting more power and the community boards are stronger, and both are getting more support from the wiki community and WMF community tech development. While I would like to endorse more infrastructure to support community health, the mediation committee takes a lot of labor and does not give a good return for what goes into it. I prefer to focus on our other offerings until those are stronger and even better defined. For last resorts see arbcom and for general issues use the boards. Blue Rasberry (talk) 14:39, 16 October 2018 (UTC)
• Weakish oppose As many have stated, MedCom as it is doesn't really provide much of a service, largely because it is voluntary and non bonding. However, IMO I do think we need to have somewhere for editors to go for a binding resolution on content, but absolutely does not touch conduct, which is what we have ArbCom for. Of course, this would entail the management of MedCom to be quite different to how it is now. Members would have to be elected, policies would need the power of community consensus behind it and a charter drawn up. Blackmane (talk) 01:25, 18 October 2018 (UTC)
• Oppose Its fairly poor in its current state. But I would like to see it improved rather than abolished. Make it binding on those involved so people can know that their time in going through the process will not be wasted. Still should be voluntary by those starting the process. -Obsidi (talk) 01:38, 19 October 2018 (UTC)
• Support - we already have other methods of mediation that aren't as dead as this one, so archiving it is inconsequential. Kirbanzo (talk) 17:23, 19 October 2018 (UTC)
• Oppose - I don't see last case 2017 as that inactive, and some users are willing to use and maintain the process. Also, I can agree with the concept that more disputes should be solved via "content" rather than "conduct". GreyGreenWhy (talk) 18:40, 20 October 2018 (UTC)
• Support; regardless of inactivity, the process seems to be fairly unsuccessful at best per Ammarpad's comments in the section below. Jc86035 (talk) 09:13, 24 October 2018 (UTC)
• Merge into WP:DRN, as per Casliber. As someone who has twice participated in mediation (once productively and once to no resolution), it makes me very sad to see this proposal, but it also makes me sad that the process is used as little as it is. I want to say strongly that TransporterMan and the other members of the committee have been doing excellent work and deserve the appreciation of the community, something that strikes me as disappointingly lacking in this discussion. That said, I think that the idea of merging into DR is a very good idea. DRN often amounts to "we can't really deal with that here", and although such a merge won't fix all of the problems that DRN has, it would add a level of dealing with the most complicated content disputes. I find it noteworthy that the first sentence of DRN is "This is an informal place to resolve small content disputes as part of dispute resolution." Note the word "small". We need a way to address large content disputes, too. --Tryptofish (talk) 20:27, 26 October 2018 (UTC)
• Support - Doesn't really serve any useful function. Beyond My Ken (talk) 03:36, 28 October 2018 (UTC)
• Support. Any concerns as to how to improve current dispute resolution process should be put forward in a future proposal.   —  Hei Liebrecht 04:39, 29 October 2018 (UTC)
• Support being able to focus on large scale content issues without resorting to removing editors for conduct issues is desirable, but MedCom has failed to effectively do this, and I think it is due to the nature of the process. I support the idea of mediators, but this needs some WP:TNT. — xaosflux ^Talk 04:53, 29 October 2018 (UTC)
• Oppose. We don't close projects unless either (1) no active participant wants to carry on; or (2) there is demonstrable harm in carrying on the project. Given User:TransporterMan's comment, and the fact that mediation isn't compulsory at the moment, we have no grounds to abolish the mediation committee. Deryck C. 10:45, 29 October 2018 (UTC)
  • @Deryck Chan: There are no grounds to close, because one of those two requirements need to be satisfied? Interesting. What policy or consensus are you getting that from? I've never heard of that principle. A substantial rationale has been made in the proposal. Some are disagreeing, but you're going so far as to say that the rationales provided go out the window by default, due to the existence of two specific prerequisites to closing parts of the project. A very bold and authoritative statement coming from an administrator, for which I sincerely hope you have something concrete to back it up.  Swarm  talk  20:48, 29 October 2018 (UTC)
    • Actually that is what happens with wikiprojects 99% of the time. If it goes inactive/no longer serves a purpose, its just left alone or sometimes marked inactive - but its almost never 'closed' as such. See here for a quick answer. So Deryck is correct in thats the general consensus to deal with Wikiprojects. The core difference however is that almost all wikiprojects that go inactive/defunct are based around article editing and not administrative (small a) functions. There is no downside to letting a wikiproject devoted to articles going inactive and not being marked as such/closed, because someone might take it up again in the future. With projects based on admin functions/problems between editors, there does need to be 'closure' so editors understand its no longer a valid route to seek assistance - the 'harm' in this situation being wasting editors time thinking MEDCOM is actually a functioning process. To Deryck: See the precedent at WP:WQA and the associated discussion here. Only in death does duty end (talk) 21:15, 29 October 2018 (UTC)

And “abolish” really isn’t correct either. This is just about marking what is obviously an outdated and unused process as inactive. If it were to be kept open, then yeah, it’s probably overdue for some serious reform, but it seems clear we don’t use it and don’t need it anymore, whatever it’s past role may have been. Beeblebrox (talk) 22:18, 2 November 2018 (UTC)

• Support, no successfully closed cases in years? C'mon, folks, what's dead is dead. If anyone truly appreciates what Medcom did and believes it served a valuable niche, the solution isn't to prop up the corpse with wires and duct tape, the solution is to replace it with something better and more efficient that will actually survive. Andrew Lenahan - Starblind 19:45, 30 October 2018 (UTC)

Arbitrary Page Break

• Reform (weak oppose) - I was aroused from my grave by a Signpost email regarding this thread and have thought carefully about my thoughts here. Many of those that I've worked with in dispute resolution over the years have commented here. @AGK:'s thoughts (Hi there!) stands out for me (I agree with some aspects of those that are supporting closure, noting that in most cases, MedCom is underused, somewhat bureaucratic and outdated. The concept of binding content dispute resolution has been discussed ad nauseaum over the years (WP:BCD being an example), but I think it's unlikely to ever have traction except in limited circumstances (think [[Wikipedia:WikiProject_Ireland_Collaboration/Poll_on_Ireland_article_names|Ireland Article Names), so discussion about making MedCom binding I think is not worth pursuing.

DRN was proposed by me way back when to deal with lightweight, simplex disputes in a rapid manner. The motivating ideas behind it were:

1. Have more eyes on a dispute, by creating a many-to-many relationship between DR volunteers and participants, possibly reducing burnout of volunteers

2. Resolve most disputes quickly, as trends over time showed that the longer a dispute went on for, the less likely it was to be resolved successfully (this wasn't universal, however). The data is quite old, but there's a survey done in 2012 with some data too (WP:DRSURVEY).

Historically, there was a conversation between those that ran DRN and those on MedCom about a conversation on referring disputes to MedCom that would benefit from mediation, to MedCom. I do believe that in some instances, mediation may be merited. I've mediated some disputes in the past which had several issues to work through, and sometimes they need to be worked through methodically. I would argue that the universal agreement to mediation is a rule that should be abolished however - if there is a case where there are 6 participants, the case has been brought in good faith and one person opposes, then the case should proceed in my belief - as one presently can just oppose and game the process. Perhaps a conversation on what happens to that person if they oppose should be had, but I think it's a necessary conversation.

The other factor in my argument to keeping MedCom open (but reform) is that MedCom is the only content dispute resolution process where discussions are privileged. This is designed to facilitate open discussion, because good faith conversations (even if at times, heated) cannot be used in ArbCom proceedings. No other forum affords this.

I think MedCom also needs new blood. Maybe the criteria for membership should be altered to make it less of a vote of existing members, and more based on dispute resolution experience. I'm not sure, but the nomination process seems a little antiquated. Lastly, a prerequisite to mediation should also be other proper DR forums should be used first. Open to the idea of MedCom only accepting cases referred by a DR volunteer, but aware that this is more bureaucracy, not less. Overall, I do agree that MedCom needs reform, but I think that it should be explored. Keen to work on this with the community - am glad there's been a reason for me to return from the grave!. Steven Crossin 01:52, 31 October 2018 (UTC)

• Support closure, without prejudice to re-opening it in future, per Amory. I too like the idea of the Mediation Committee, and agree it has done great work in the past. However it simply isn't active enough now to be a viable form of dispute resolution. Our dispute resolution systems are confusing enough as it is, and it does a disservice to users to point them at this process which at the moment will most likely either reject their request or leave them in limbo. the wub "?!" 19:28, 2 November 2018 (UTC)

• Support closure. Redundant. All the important dispute resolution discussion happens way before it ever reaches MedCom, and by the time we should be at the MedCom level of the DR process the dispute is either already resolved or requires ArbCom intervention anyway. -- œ^™ 19:51, 3 November 2018 (UTC)
• Support the closure, as it is nearly fully inactive. Dreamy Jazz 🎷 ^{talk to me | my contributions} 12:14, 5 November 2018 (UTC)
• Support closure. It is apparent that this process has withered on the vine and no longer serves any useful purpose, if it ever did. - Nick Thorne ^talk 23:45, 9 November 2018 (UTC)

Extended discussion

• Could someone point me to the last case that the Committee took on? K.e.coffman (talk) 05:32, 12 October 2018 (UTC)

  @K.e.coffman: according to the history of Wikipedia:Requests_for_mediation/Tasks in the last 3 years the following 5 cases were accepted and processed:

  1. Wikipedia:Requests for mediation/Rana vs Lithobates (20150924->20151026)
  2. Wikipedia:Requests for mediation/Christian terrorism (20141023->20151223)
  3. Wikipedia:Requests for mediation/Ghouta chemical attack (20150606->20150717)
  4. Wikipedia:Requests for mediation/Expulsion of Cham Albanians (20160927->20161113)
  5. Wikipedia:Requests for mediation/FXCM (20170726->20170731)

  — xaosflux ^Talk 15:04, 12 October 2018 (UTC)

• @K.e.coffman:. I think this archive gives sort of that. Specifically, it may be this case which was closed on 5 August 2017 as "partly successful", that's some 15 months ago. The last truly "successfully closed case" is this closed in June 2016, over two years ago. But it's noteworthy that, their rejection rate outnumbered acceptance rate by almost a factor of 20. For every one accepted case, 20 are rejected as not suitable for mediation as this page can show. Between January 2013 to date they rejected 282 cases and accepted only 14 as suitable or ripe for mediation. In that 14 cases only 5 were closed as truly "successful", the last being in 2016. Another 6 closed as "unsuccessful", "failed" or "unclear status". At least one was closed as "stale" and another closed as "parties refused to participate". I counted this off the cuff from the data of this and this pages. I believe there may be ommision, but overall I see a picture of of a dead and toothless process that we can do better without. –Ammarpad (talk) 15:15, 12 October 2018 (UTC)

• The overall success rate over the last five years seems to be around 1-2% of the total number of cases filed, while the overall success rate for the last two years is 0% by any measure.
• There is a similar situation at arbcom, accepted case numbers are down, extraneous subcommittees such as WP:BASC have been shut down, and the committee itself is shrinking.
• This is actually a good thing in that it would seem to indicate that many problems are being adequately addressed before things get to the point of needing an entire committee to resolve them.
• I completely belive what Tranporter Man says about the willingness of largely inactive mediators to return if needed. The fact that they haven’t been needed in years is the whole point. Beeblebrox (talk) 18:53, 12 October 2018 (UTC)

• Evaluating this RFC: Medcom is not "just any" process created by a user on a whim. It is one of the first two content DR processes created at Wikipedia (the other, and first, being RFC) and, if my memory serves, was created by or in cooperation with Jimbo Wales himself, who also appointed the first mediators. Just as Arbcom would not be shut down without a consensus involving both a very large number of participants and a strong number of !votes in favor of termination, neither should Medcom. While this RFC has a couple of weeks to go, the response here so far would seem to me to be entirely inadequate to take any decisive action to terminate Medcom or mark it as historical, even if the "support" !votes were unanimous, which they are not. Regards, TransporterMan (TALK) 16:15, 15 October 2018 (UTC)
• Comment 1 - Deprecating MedCom is being inaccurately compared to deprecating User conduct RFCs. The difference is that no one has cited any actual harm done by having MedCom available. RFC/U was doing real harm, because the procedure was both rigid and confrontational. Because of its rigidity, it was hard to use it correctly, so that the most common result was an incomplete RFC/U, which didn't even start a comment process, but did further offend the subject editor. Its original purpose, which was to serve as input to User:Jimbo Wales for a request to ban a user before there was an ArbCom, had long become obsolete. MedCom doesn't do any harm, and still may serve a purpose when DRN and other options have fallen through. Robert McClenon (talk) 18:45, 15 October 2018 (UTC)

More to the point, RfC/U had no dedicated volunteers, it was just a roving, changing band exercising mobocracy, and was just a board where people pilloried, and often bullied one another (we certainly don't need another page for that). On the other hand, Wikipedia is based on volunteerism, and these MedCom people are volunteers, who volunteer to mediate. Alanscottwalker (talk) 18:56, 15 October 2018 (UTC)

• Comment 2 - I am deeply unimpressed by the good-faith comments by some Support !voters that DRN should be strengthened and reformed, because I don't see those who are advocating deprecating MedCom as doing anything to improve DRN. They don't want MedCom, and they are hoping that someone else will step in and do something to improve DRN. Robert McClenon (talk) 18:45, 15 October 2018 (UTC)
• Comment 3 - As noted above, when an issue comes along for which formal mediation is appropriate, we will probably lose two productive editors from Wikipedia, the DRN volunteer who burns out trying to mediate a case that needs formal mediation, and the more collaborative of the two editors, who learns that the remaining content processes are stacked against a collaborative editor in favor of an aggressive editor. I know that isn't what anyone wants to have happen, but that is what will happen when a case comes along that requires formal mediation. Robert McClenon (talk) 18:45, 15 October 2018 (UTC)
• Comment 4 - You should have asked what are the next steps before just going ahead with crossing a process off a list. Robert McClenon (talk) 18:45, 15 October 2018 (UTC)
• Regarding the statements made by some supporters that talk page discussions and RFCs are generally successful in resolving content disputes if there are no conduct issues: there are many discussions that fade out and fail to reach a conclusion due to a lack of sustained participation, and many RFCs that do not achieve a consensus, in many cases because there are equally valid opposing views that are just based on different underlying assumptions or interpretations, which English Wikipedia's decision-making model is not well equipped to resolving. This is a gap in content dispute resolution that needs to be filled. (Unfortunately, the mediation process as it is currently implemented by the mediation committee doesn't strike me as being a particularly effective way to deal with these types of disagreements in English Wikipedia: its voluntary nature doesn't help with the problem of sustained participation, and unless the community agrees to have representatives of major viewpoints enter in mediation on its behalf, it's too hard to have formal mediation with large disputes.) It is demotivating for editors to know that any edit they make could get challenged and trying to resolve it can mean long, protracted discussions, with possibly no definitive resolution ever arriving. isaacl (talk) 16:30, 28 October 2018 (UTC)
• On another note, I'm a bit uncomfortable telling a group of volunteers that they should not pursue an initiative that is optional and hasn't affected other community processes. I realize in theory it might divert editors into a long process with an uncertain ending that fails to adapt quickly enough to new editors entering the dispute on article pages, but in practice (due to the paucity of accepted cases) there's no evidence of this happening, so it's hard to evaluate if the process can adequately deal with this. (For instance, the mediation process could be placed on hold or discontinued if there were signs of new editors entering that could resolve the dispute through continued public discussion.) isaacl (talk) 17:33, 9 November 2018 (UTC)

The Real Problem

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

Look to how the real world resolves this: representatives are chosen to present the major opposing viewpoints, and mediation is held amongst them. This would require that the community be willing to delegate discussion to a small group of people. As in the real world, the result could be presented back to the community for ratification, or it could be deemed binding (the option just needs to be selected beforehand). isaacl (talk) 16:47, 5 November 2018 (UTC)

Don't be so sad. The process of content consensus is never ending through generations of users (and multiple forums) and it will always be so, until the great Editorial Board is adopted (which is no time soon). We actually have had very useful mediations in developing sourced/policy based content but there you go, we don't do that anymore (down the road, how often RfC's are useless, or malformed, or misinformed, or not informed, at all. Then again, some of the most useful content RfC's have been developed in, perhaps you guest it . . . mediation). Alanscottwalker (talk) 19:32, 9 November 2018 (UTC)

Closure

• I've been looking through this RfC and plan on closing it at some point in the next couple days. It looks, at a glance, that some participants may feel more confident in the result if a three-admin panel closes this RfC. Is that the preference of the participants, or will a single closer suffice? Kevin (aka L235 · t · c) 07:40, 9 November 2018 (UTC)

  If you need 3 people to judge the consensus above something is wrong. A blind hamster could do it. Only in death does duty end (talk) 08:44, 9 November 2018 (UTC)

  I think the consensus is obvious too and do not think three people need to close here. But there is a significant volume of comments and people get bent out of shape when they don't feel their (side's) comments were accurately reflected. Three people closing can help avoid that. --Izno (talk) 12:50, 9 November 2018 (UTC)

  I agree. I think the consensus is clear, but there are some pretty strong opinions, and I think a 3-member panel would help generate a better sense of fairness. Boing! said Zebedee (talk) 13:31, 9 November 2018 (UTC)

  I don't see any specific indications that some participants will feel more confident if a panel of editors (admins or non-admins) closes the RfC. However if the closers would feel more confident with a panel, they should feel free to proceed with this approach. isaacl (talk) 17:23, 9 November 2018 (UTC)

  L235, the consensus is too obvious. I was planning to do it by myself but would probably temporally restrain. ∯WBG^converse 17:31, 9 November 2018 (UTC)

• Come on, now. The consensus above maybe idiotic, but we all know votes matter. The only hiccup will be addressing the amendments to the multiple policies or guidelines and templates, including Arbcom templates that say, in a content dispute, if nothing else works go to Med Com. Good luck. Alanscottwalker (talk) 18:52, 9 November 2018 (UTC)

• I don’t see any need for a panel of admins, as others have stated the consensus is fairly obvious. As the person who initiated this I am willing to help with the necessary adjustments mentioned above if needed. Beeblebrox (talk) 21:13, 9 November 2018 (UTC)
• I have no objections to a one-person closure, to be clear. Please be careful with the closure, though. Best, Kevin (aka L235 · t · c) 21:26, 10 November 2018 (UTC)

• I think it's easy enough to establish whether or not a consensus has been reached. The closer would not even need to provide an analysis beyond 'consensus/no consensus' but it is traditional to say a few words. It's due for closure, and It does not need a panel of of people to come up with the result. FWIW, if I hadn't voted, I'd close it now and that would be the end of it. Kudpung กุดผึ้ง (talk) 02:35, 11 November 2018 (UTC)

The 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.∯WBG^converse 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? GMG^talk 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, User:TheDragonFire300. (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 Y consensus to disallow non-autoconfirmed users from adding images on TFAs, as a default measure.

Signed by ∯WBG^converse 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)

• Support a fair compromise that prevents vandalism but still allows constructive edits. TeraTIX 00:05, 14 October 2018 (UTC)
• (edit conflict) Support Even though this is (probably) based on a perennial proposal, this sounds like a reasonable compromise (though this might put extra work on pending changes reviewers. ^Semi_Hypercube ✎ 00:07, 14 October 2018 (UTC)
• Support. TFA is a big target for vandalism. Considering it's the very first thing that shows up on Wikipedia's main page, a ton of people could see that vandalism, and some times it can be extreme. However, this is the encyclopedia that anyone can edit, so I don't necessarily like the idea of always locking the first thing that appears on the main page so that only certain users can edit it. PCP seems like a good idea to me.--SkyGazer 512 ^{Oh no, what did I do this time?} 00:11, 14 October 2018 (UTC)
• Support, at least until we have a working filter, or a better way to stop this kind of vandalism. Suffusion of Yellow (talk) 00:14, 14 October 2018 (UTC)
• Support per everyone else. The advantage of pending changes is it allows IPs and new users to make their change, without it being instantly visible to all and sundry. I get the objections about Pending Changes reviewers not being as active as they should be and articles sitting in the queue for entirely too long. I also get the objections about things getting confusing when there are a bunch of edits that are a mix of constructive and unconstructive edits. However, I would not describe pending changes as "useless". Today's Featured Article and other main-page featured content serve several purposes for Wikipedia - (1) showcasing our work, and (2) inviting people to get involved. Semi or full protection circumvents (2). Allowing people to vandalize and have it be visible circumvents (1). Pending changes protection allows people to get involved without showcasing the destructive efforts of vandals. ~ ONUnicorn^{(Talk|Contribs)}problem solving 00:21, 14 October 2018 (UTC)
• Comment. During the pending changes trial, trialled pages that had high amounts of edits per day (such as Barack Obama and George W. Bush) had to have PC removed from them because the volume of edits overwhelmed the ability of CRASH to approve edits. This needs to be kept in mind - if a TFA is controversial or popular enough, PC becomes limited in use. (I am not !voting on this as everybody who gives a damn already knows my views on Flagged Revisions and its bastard understudies.) —Jeremy v^_^v ^Bori! 00:22, 14 October 2018 (UTC)
• Comment the TFA we've had for less than an hour has already been vandalized five six ten times with obscene images, and it's continuing. L293D (☎ • ✎) 01:35, 14 October 2018 (UTC)

  I added it to the bad image list. --Redrose64 🌹 (talk) 08:02, 14 October 2018 (UTC)

• Support, but perhaps an edit filter that prevents non-autoconfirmed editors from adding or changing images on TFAs would be better given Jéské Couriano's comments above. --Ahecht (TALK
  PAGE) 02:40, 14 October 2018 (UTC)
• Support It makes sense, and doesn't block anonymous contributions completely. — AfroThundr ^{(u · t · c)} 03:06, 14 October 2018 (UTC)
• Support As other editors have stated, this seems to be the best compromise while maintaining the project. ProgrammingGeek ^talktome 03:27, 14 October 2018 (UTC)
• Support Seams reasonable. – BrandonXLF ^(t@lk) 04:41, 14 October 2018 (UTC)
• Oppose per the protection policy and Jéské Couriano. "Pending changes protection should not be used as a preemptive measure against violations that have not yet occurred." If a given TFA is having vandalism problems, an admin should use their discretion to apply whatever remedy is best, whether that be (range) blocking or a higher level of protection. I believe the status quo is a better state of affairs than significantly increasing the workload of reviewers. Yes, TFAs get vandalized, but they have far more eyes on them and get reverted almost immediately, whereas it's not unusual for me to see pages in the reviewer queue for over an hour. I would oppose any default protection of a page, even (especially) TFA, per the protection policy and knowing how slow pending changes reviewing can be am even less in favor of this proposal. Wugapodes [t^hɑk] [ˈkan.ˌʧɹɪbz] 05:54, 14 October 2018 (UTC)

• Support Why should we have to deal with all this vandalism when it is so easily prevented. Pending changes won't stop good faith changes. It will prevent readers from looking at vandalised articles. Hawkeye7 (discuss) 06:10, 14 October 2018 (UTC)
• Strong oppose on principle. This is the encyclopedia that anyone can edit, no permission or approval required. If we don't hold to that principle on the most-viewed article on the site, what do we have? We can use existing anti-vandalism measures, including the BIL and rangeblocking, without violating this principle. I don't suppose there's a way to have one of the anti-vandalism bots "pay more attention" to the featured article, so that obvious vandalism could be reverted instantaneously? --Yair rand (talk) 14:03, 14 October 2018 (UTC)
• Oppose If we are not going to allow pending changes to be pre-emptively applied to all the BLP's out there (where constant vandalism can have a real world effect and distress on the subject) then really the Battle of Hochkirch can just deal with it like any other article. This RFC is also functionally pointless, as it cannot over-rule the existing policy WP:PCPP and any admin applying protection in such a manner against policy is at risk of being accused of abusing their tools. Want to alter the policy? Start an RFC for that. Only in death does duty end (talk) 14:13, 14 October 2018 (UTC)

There's a difference between protecting a ~millionish articles and one article a day. If this RfC is in favour of preemptive protection, then certainly the policy would be amended to reflect that consensus; policies are merely written down consensuses, and just because the RfC doesn't explicitly mention amending the policy doesn't mean there has to be a separate RfC per WP:NOTBURO. Galobtter (pingó mió) 14:27, 14 October 2018 (UTC)

Well yes, I would rather protect a millionish articles to prevent potential actual harm than hurting the feelings of a 18th century Prussian battlefield. And I am Prussian... But really, if as a result of this someone attempts to amend the protection policy to remove the 'do not pre-emptively use PC' (which is what you appear to be suggesting) it will be reverted within seconds. Only in death does duty end (talk) 14:43, 14 October 2018 (UTC)

The amendment would not be to remove "do not pre-emptively use PC" but to add that "An exception is TFAs, which are pre-emptively PC protected by a bot." or something along that lines Galobtter (pingó mió) 15:09, 14 October 2018 (UTC)

• Support: @Only in death: While I understand the oppose rationale, it misses the spirit of the policy; protection policy says "Pending changes protection should not be used as a preemptive measure against violations that have not yet occurred.". Since all TFA articles are being routinely targeted (while they are TFA), it can safely be assumed that future TFAs will also be targeted unless protected (just the same as if a single article has been recently repeatedly targeted, it can be assumed that it will be targeted again unless protected). In other words, IP vandalism to all TFAs is occurring, therefore TFAs should be routinely protected to stop this vandalism (at the lowest level needed, and for the duration only of the TFA), and I don't see this as contrary to WP:NO-PREEMPT. — Insertcleverphrasehere ^{(or here)} 14:53, 14 October 2018 (UTC)
• Support: Common sense application of capabilities to block routine vandalism in an efficient way. MB 15:44, 14 October 2018 (UTC)
• Support - Per nominator L293D's experience. Much as I like having busy beavers on TFAs, we should probably do something about the more disruptive ones. Kurtis ^(talk) 18:24, 14 October 2018 (UTC)
• Support. I'd prefer semi-protection, but this would be better than the current situation. SarahSV ^(talk) 18:39, 14 October 2018 (UTC)
• Support this *is* an RFC to change the protection policy, the argument that this is not permitted by the current protection policy is circular. This is a reasonable measure to prevent vandalism while still allowing good-faith new contributors to edit. power~enwiki (π, ν) 20:11, 14 October 2018 (UTC)
• Oppose as pending changes is useless at the best of times and creates more work than it's worth on active articles. I could get behind semi-protection, but I'm a hard no on expanding pending changes to anything: it really is the most useless technical feature in MediaWiki. Also, note to the closer, this should not be read as "Oh, he might be fine with semi-protection, so split the baby with pending changes." I think nothing is better than pending changes because it doesn't require all the extra work and allows good faith people to edit. Semi would be better, despite the loses, but PC would be terrible and result in mangled histories. TonyBallioni (talk) 20:45, 14 October 2018 (UTC)
  • @TonyBallioni: Could you clarify your vote a bit? Are you saying that PCP would be more work? There are dozens of editors who patrol the TFA for vandalism, and PC would save them all that work. If we have a vandal who vandalizes the TFA ten times (as it happened yesterday) with obscene images and the vandalism stays for one minute average, the average of 40,000 pageviews TFAs get would mean 278 people load the TFA with a glaring vagina image on top of it. L293D (☎ • ✎) 13:57, 15 October 2018 (UTC)
    • No, it would increase their work substantially: pending changes does absolutely nothing to reduce workload. It increases it on busy article (TFA being one of the most busy) because it requires reviewing of edits, deciding whether or not to affirmatively approve them, and causes good changes by even those with sysop to get stuck in a technical nightmare of pending approvals that no one really understands how it works, instead forcing people to do mass reverts of up to 10 edits and then make the good changes again because no one can figure out how the approval process works. Pending changes is a technical nightmare and should rarely if ever be used for pure practical reasons: there aren't circumstances where it is justified where semi-protection isn't better, and if it's "minor but recurring vandalism" just let it go through: it's much easier to just revert. No work is ever saved with pending changes. It's only ever increased. TonyBallioni (talk) 14:12, 15 October 2018 (UTC)
• Oppose I prefer a standard 24 hour full protection. The Banner talk 20:49, 14 October 2018 (UTC)
• Oppose - I'd prefer semi-protection over pending-changes because the latter requires continued monitoring and accepting/reverting whereas the former doesn't, We should get rid of IP editing altogether and be made into a register-to-edit site but ofcourse I know I'm the minority on that. –Davey2010^Talk 20:53, 14 October 2018 (UTC)
• Support: it settles the concern of the perennial proposal; it doesn't lock out editing completely, thereby not leaving a poor impression on readers/editors. Regards, User:TheDragonFire300. (Contact me | Contributions). This message was left at 23:24, 14 October 2018 (UTC)
• Oppose - frustrates IPs with good contributions, and does not diminish work for patrollers. And there are many eyes on main page. Cas Liber (talk · contribs) 01:41, 15 October 2018 (UTC)
• oppose IPs should be able to directly edit TFAs. — BillHPike (talk, contribs) 03:05, 15 October 2018 (UTC)
• oppose Wikipedia is the "Encyclopedia that anyone can edit" so having the TFA protected would give a bad impression on new editors Abote2 (talk) 10:04, 15 October 2018 (UTC)

  @Abote2: This proposal refers to having pending changes protection, not semi-protection, so new users can still edit. ^Semi_Hypercube ✎ 11:21, 15 October 2018 (UTC)

  No, they can not. They can submit changes for approval. It is not the same thing. --Yair rand (talk) 13:53, 15 October 2018 (UTC)

• Support: pending changes doesn’t stop anyone from editing. There’s need for protection and in fact, if most TFAs are getting semi-protected midway through, pre-emotive PC is actually a decrease in protection as it means all people will be able to edit at any point in the day (barring extreme spam of vandalism which would require an increase in protection). — Bilorv_(c)(talk) 10:55, 15 October 2018 (UTC)
• Oppose in favor of different solution. I think it was MusikAnimal's original suggestion, but why not do something closer to tagging TFA with an invisible template and creating an edit filter specifically to disallow changes within a File name for any unconfirmed editor on that tagged page, as well as disallow additions of new files. It's a bit less harsh than either of the proposed options and should alleviate the worst of the problem behind the LTA. (If you are an EFM, please feel free to tell me this isn't feasible.) --Izno (talk) 14:02, 15 October 2018 (UTC)
• Oppose After vandalism has happened, I'm OK with protecting. Pre-emptive protection is not useful, IMHO. --Jayron32 15:18, 15 October 2018 (UTC)
• Oppose I'm a bit on the fence for this one, as I recognize the issues that persistent vandalism on one of the most public pages of the day. However, I would lean in favor of not protecting TFA. Even though it doesn't say it in the top left corner, this is still the "encyclopedia that anyone can edit." Semi-protection would be out of the question as a preemptive measure. Pending changes might work, but only if edits were reviewed quickly. It is not unusual for me to look at my dashboard and see the pending changes backlog rated as "High" or "Critical", and I have no doubt that the backlog would extend to TFA. Pending changes would then not be workable. I would be supportive to targeted measures (edit filters) for specific types of vandalism. --AntiCompositeNumber (talk) 17:04, 15 October 2018 (UTC)
• Oppose as a permanent solution. Full disclosure: I've PC-protected today's TFA, and yesterday's TFA, and tomorrow's TFA preemptively. I may well continue doing this for a while and encourage others to do the same. I'm perfectly happy with that - though I would prefer no protection it's obviously a sensible precaution at this time. However I don't think this should be a permanent state of affairs, as this proposal suggests. There's been very few times in the last many years that preemptive protection has been an appropriate response. The vandals in any case also target other articles on the main page, and have been known to also use accounts. Autoconfirmed is an easy bar. Ultimately I'd prefer to see an edit filter implementation targeting image edits, like the one being discussed at WP:AN. -- zzuuzz ^(talk) 18:31, 15 October 2018 (UTC)
• Suppose see what I did there? per the above comment by zzuuzz. This is perhaps a workable stopgap measure but I don’t see it as good permanent solution. So, do it for now, but don’t consider the problem permanantly resolved. Alternatives like the edit filter proposed below should be considered. Beeblebrox (talk) 19:07, 15 October 2018 (UTC)
• Weak support Thanks for starting this. I brought this up (permalink) at AN, under the safe assumption the community wouldn't agree to preemptively PC protect long-term, but that it would be a wise short-term solution. But frankly, I do think we should PC-protect the TFA, for the full 24 hours, unconditionally. This is not just about the image vandalism. I can't count how many times I was reading the TFA, and noticed something was off (entire sections missing, broken wikitext, dubious claims, etc.), before finally figuring out it had been vandalized. I am a strong believer in the no-preemptive protection philosophy, but you don't need to wait for the TFA to be vandalized. It will happen, with absolutely certainty, and it may linger there for minutes. This is normally fine and typical of the wiki, except this article we're advertising to millions of readers as being of utmost quality. PC seems like a great solution because everyone still gets to edit. And remember, most people don't edit, they just read. Ideally they will be reading the version we intended for them to see. Worry of clogging up the PC backlog is what makes me unsure. On one hand, almost all of it (for TFA) would be vandalism, which will get reverted by patrollers no slower than it is now, and then the pending changes will no longer be in the queue. But there are good edits in there too, and overall the high edit rate may make the reviewing process more cumbersome. This is why we usually reserve PC for articles that have a low-ish edit rate. I'd like to first see how our "PC trial" (so to speak) goes over the next few days, as I know we're going to be adding it again. We can review the data, good vs bad edits, get an idea of how the PC backlog is affected, and go from there. One other thing I might suggest is to not show the PC lock icon at the top-right on TFA. — MusikAnimal ^talk 20:06, 15 October 2018 (UTC)
• Support per TheDragonFire300. Double sharp (talk) 23:57, 15 October 2018 (UTC)
• Support Wikipedia is the encyclopedia anyone can edit, not the encyclopedia anyone can vandalize. Pending changes is not going to stop constructive editors from contributing. --Joshualouie711^talk 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, Lindsay^Hello 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 (t • c) 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. Nathan2055^{talk - 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. Beeblebrox (talk) 19:04, 15 October 2018 (UTC)
• Support as above. TonyBallioni (talk) 19:12, 15 October 2018 (UTC)
• Support (as I commented above). In principle adding or changing an image on TFA seems as straightforward as move protection - one of those things that is rarely appropriate. -- zzuuzz ^(talk) 19:18, 15 October 2018 (UTC)
• Support per above. Aoi (青い) (talk) 19:20, 15 October 2018 (UTC)
• Support If this would be the only thing that works (but how would it be implemented? Edit filter?) ^Semi_Hypercube ✎ 19:24, 15 October 2018 (UTC)
• Oppose as permanent solution This would be easily achieved via an edit filter This not yet true. See this AN discussion (permalink). Anyway, the image vandalism is a temporary problem. It will go away, and there will (very occasionally) be constructive edits of adding images to the TFA. We should not outright disallow this indefinitely. Don't worry about the short-term; if and when we are able to use an edit filter we will. — MusikAnimal ^talk 19:38, 15 October 2018 (UTC)

  @MusikAnimal: the image vandalism is a temporary problem: no, its not; this image vandalism has been present for seven months. As to the technical implementation, a bot would add some invisible template such as {{TFA filter}} and remove it at the end of the day. The edit filter should be fairly simple: If the article contains the template and !"autoconfirmed" in USER_RIGHTS and added_lines contain [[File:, then disallow. L293D (☎ • ✎) 21:36, 15 October 2018 (UTC)

  The edit filter is simple if the bot automation exists, which it does not. Once that's done, we have means to target this specific image vandalism to TFA. We don't necessarily need to ban all imagery. Yes the image vandalism has been going on for a while but seven months is not that long if we're talking about an indefinite ban. And please, don't discuss private filter implementation on public venues (albeit yours was rather straightforward and guessable) — MusikAnimal ^talk 22:11, 15 October 2018 (UTC)

• Oppose Not in favour of the use of edit filters. Hawkeye7 (discuss) 21:55, 15 October 2018 (UTC)
• Support It is very unlikely that an image added to a TFA would benefit the article as the imagery will have been considered and discussed in the FA review, and the risk of image vandalism is high. Hrodvarsson (talk) 00:17, 16 October 2018 (UTC)
• Support: I'm not sure that most valdalism is adding images, but would not hurt. --K.e.coffman (talk) 03:16, 16 October 2018 (UTC)
• Support if PC-protection of TFA does not succeed: I'd prefer PC protection, but this would also eliminate some of the most egregious vandalism on TFAs. Regards, User:TheDragonFire300. (Contact me | Contributions). This message was left at 10:49, 16 October 2018 (UTC)
• Support provided the same edit filter also disallows removing images as well. Alternatively, as mentioned above more judicious use of the bad image list can help. —Jeremy v^_^v ^Bori! 17:50, 16 October 2018 (UTC)
• Support. It's true that IPs sometimes make constructive edits to the text of TFAs, and I understand people's desire to keep that open as a possibility. But I can't imagine any acceptable image being uploaded by an IP or brand new user. It would either be inappropriate for the article, or it would have improper licensing, or both. If we can find a way to technically block changes or uploads to images, I'm all for it. --MelanieN (talk) 20:00, 16 October 2018 (UTC)
• Support this proposal. No such user (talk) 15:10, 17 October 2018 (UTC)
• Support as a compromise. — Insertcleverphrasehere ^{(or here)} 15:14, 17 October 2018 (UTC)
• Support. Sounds like it should be effective without compromising the "anyone can edit" ideal and without clogging up articles with pending changes. Boing! said Zebedee (talk) 15:31, 17 October 2018 (UTC)
• Support It should work Elitemagikarp (talk) 15:49, 17 October 2018 (UTC)
• Support I support locking down all of Wikipedia. This is a step in the right direction. Our best, most-advertised works are obviously the targets of vandals. Chris Troutman (talk) 00:02, 18 October 2018 (UTC)
• Support Johnbod (talk) 00:13, 18 October 2018 (UTC)
• Support, seems like a good compromise. Kaldari (talk) 20:12, 18 October 2018 (UTC)
• Support if PC-protection of TFA does not succeed: I'd prefer PC protection, but if there is not a consensus for PCP, then this is a good compromise. --BrownHairedGirl (talk) • (contribs) 14:37, 19 October 2018 (UTC)
• Support per B!sZ. Mathglot (talk) 22:22, 21 October 2018 (UTC)
• Support, assuming it's both technically possible and the PCP proposal fails. — Bilorv_(c)(talk) 01:52, 22 October 2018 (UTC)
• Strong oppose per User:Jimbo Wales/Statement of principles 2 and 3 and WP:AGF. Image vandalism of TFAs is a recent problem and should be resolved if and when it occurs with blocks, range blocks, page protection, and/or adding the image to the image blacklist as suitable to the individual case, not a blanket and convoluted edit filter that will confound and bite good faith newcomers. IPs should be just as allowed to engage in WP:BRD of images on TFA as any other editor, and the idea that newcomers will understand Wikipedia well enough to make a talk page request for the addition of an image is not compelling. Wugapodes [t^hɑk] [ˈkan.ˌʧɹɪbz] 08:02, 22 October 2018 (UTC)
• Oppose per MusikAnimal. Philroc (c) 12:57, 24 October 2018 (UTC)
• Oppose technically infeasible and would result in poor experience for anons making legitimate edits. -FASTILY 07:49, 25 October 2018 (UTC)
  • Fastily, why would it technically infeasible? Filters are able to detect lots of stuff; surely they could detect when an IP or new account performs an edit that adds a new file-display link to a page? No comment on your experience argument. Nyttend (talk) 01:59, 5 November 2018 (UTC)
    • There's no way to make a TFA-specific edit filter; see MusikAnimal's !vote above. -FASTILY 07:55, 5 November 2018 (UTC)
• Erm How do you enforce this in a way that doesn't increase human workload? Deryck C. 17:38, 6 November 2018 (UTC)

  By setting it to "disallow". L293D (☎ • ✎) 14:33, 9 November 2018 (UTC)

• Only temporarily, in response to an actual vandalism wave or PoV-war. I.e., this really isn't any different from any other WP:RFPP case. Just go there and report the problem and let the protection-focused admins deal with it as they normally do.  — SMcCandlish ☏ ¢ 😼  06:19, 13 November 2018 (UTC)
• Support - too much potential for damage by adding an unsuitable image. Darylgolden^(talk) Ping when replying 12:23, 14 November 2018 (UTC)

Alternative proposal: semi-protect TFAs

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

General Discussion

• Workload issues - There only seem two reasons to oppose, either a strong "no pre-emption" POV or an issue with the resolution. Placing PC on high activity articles like this would have a massive increase. PC already is ruled out in favour of standard semi-protect if used on a traditionally active article. Additionally, resolving PCs becomes increasingly problematic the more of them are "stored-up" since accepting just the good ones becomes trickier much more quickly. Normally PC does as a happy medium between protection and censorship, but enacting it here I think would be a significant increase in workload, reducing speeds on other articles as well. Nosebagbear (talk) 18:26, 14 October 2018 (UTC)

  The amount of workload remains the same; you still have to check the TFA as often as possible, usually at least once every half hour. The difference is that the readers would not be not subjected to vandalism. It's only one day, whereas high traffic articles are every day. Hawkeye7 (discuss) 23:57, 14 October 2018 (UTC)

  pretty sure your remark misses the point Nosebagbear was trying to make, which is more about the pending changes workload than the TFA workload. PC can get very convoluted when used on busy articles, that’s not really what it’s for and adding TFA could cause less attention to be paid to other articles under PC. Beeblebrox (talk) 19:10, 15 October 2018 (UTC)

  The request appears on the watchlist and you approve it. That's how it is supposed to work. Hawkeye7 (discuss) 22:08, 15 October 2018 (UTC)

Optimally yes, but when there are multiple edits awaiting review it can get difficult to untangle. Beeblebrox (talk) 22:14, 15 October 2018 (UTC)

This is essentially the crux of my comment and no-vote. I'm not talking out of my ass; the situation with PC on high-volume articles has been discussed ad nauseam, especially in the various RfCs on its retention/expansion. It's generally accepted that if an article is being heavily edited, PC is not helpful because of the fact that it belays edits until CRASH can be arsed to go through the queue, and in more technical articles this is another strike against it because, during the time you're trying to understand a source, more edits are being shoved into the queue which will also need approval. Throwing more men at it won't help - again, Barack Obama is an article that did not want for eyes (as he was President during the PC trial) and they came to the conclusion that PC was an active detriment compared to the semi-protection that was on it before (and reapplied when PC was removed from it). —Jeremy v^_^v ^Bori! 17:57, 16 October 2018 (UTC)

• Question: I see that while this is under discussion, the current TFA is PC-protected. Zzuuzz PC-protected it for four days, the 15th through the 19th, with the edit summary "upcoming TFA". Was this a test, or a BOLD change, or what? Is the actual proposal here to PC protect the page for four days? --MelanieN (talk) 23:23, 16 October 2018 (UTC)

  I've mentioned this above. I think MusikAnimal might have even referred to it as a 'trial'. I'd describe it as a temporary measure in response to the current vandalism, and I've picked three/four days, because that's how long TFAs actually remain linked on the main page. The protection (four articles to date) has prevented anus/vagina images being displayed on two of the articles. I have also PC-protected a couple of articles 'in the news' in response to the vandalism. There is no long term strategy implied. -- zzuuzz ^(talk) 23:30, 16 October 2018 (UTC)

  For now, it has worked great and not even one of the "problems" the opposers raised have happened. No logjam, no "trouble sorting edits" or anything similar. L293D (☎ • ✎) 23:45, 16 October 2018 (UTC)

  I would argue that's more because of the obscurity of the TFAs in question. —Jeremy v^_^v ^Bori! 05:39, 17 October 2018 (UTC)

• Comment: The points made by Jéské Couriano (Jeremy) and TonyBallioni need to be understood by anyone considering this proposal who isn't a Pending Changes reviewer: Reviewing changes on active pages is, due to the current PC review workflow, an extremely daunting task. I'm sure there are ways it could be improved, but as things currently stand single-edit reviews are relatively easy, and relatively quick, but when an article in the queue consists of several changes by multiple editors, it can sometimes sit there for many hours before one of us finds the energy to tackle it. (Accumulating more edits, and as a result becoming an even more daunting task.) That may be a state we wish to avoid the TFA ending up in.

Perhaps the PC review queue listing could be updated to display certain articles, including TFA, as "immediate review" candidates, with a request that those reviews be performed before the rest of the queue. That might help alleviate the buildup a bit, though it still doesn't change the fact tha the review system is designed in a way that makes the effort required to perform a review grow exponentially with the number of editors and edits pending. -- FeRDNYC (talk) 02:58, 18 October 2018 (UTC)

I should note that I am not a member of CRASH (and in fact gave up adminship because it includes reviewer); that said I have participated in the lion's share of RfCs on the subject, including the RfCs and straw polls that took place around the tail end of the "trial". Workload on very busy pages was indeed brought up quite a bit, and I will quote Pmanderson (talk · contribs) with regards to the situation I've mainly been using as my counterpoint to this:

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

The reason that the issue has not manifested on the present TFAs that have been PC-protected is that their subjects are fairly obscure and do not attract interest enough to see the volume of edits that something even reasonably popular would see as a matter of course. —Jeremy v^_^v ^Bori! 10:06, 18 October 2018 (UTC)

Thanks. Why the sic? A pending-changes reviewer who's not confident on the subject of the article is not much better than no review. Septentrionalis PMAnderson 00:46, 20 October 2018 (UTC)

Because you forgot a closing parenthesis. —Jeremy v^_^v ^Bori! 01:29, 22 October 2018 (UTC)

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

Pretty much any national-level politician is a bad choice for PC, especially as election time approaches. See above. —Jeremy v^_^v ^Bori! 10:34, 25 October 2018 (UTC)

Actually meant ECP, corrected myself. Blackmane (talk) 01:54, 26 October 2018 (UTC)

• 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 Y unanimous consensus to assign the tboverride permission to the (extendedmover) user group.∯WBG^converse 05:11, 17 November 2018 (UTC)

---

I just got a request from pagemover IJBall to override the title blacklist — Good Morning!!! (Australian show) needed to be moved to 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)

Tracked in Phabricator
Task T209753

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:

• This will allow "page movers" to create pages that override the MediaWiki:Titleblacklist

  As noted below this will allow editing of Wikipedia:Editnotices

• This will allow "page movers" to create user accounts that override the meta:Title_blacklist

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. ^Semi_Hypercube ✎ 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 (contribs • talk) 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 spelling, a plausible typo, 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 (contribs • talk) 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)

• Maybe note where the target was in the deletion log so that no information is actually deleted? Galobtter (pingó mió) 07:18, 5 November 2018 (UTC)

• Just noting that this would allow page movers to create edit notices. Support I don't see much harm that can be done with the ability to override. Also everyone should get a warning screen. As a WP:TPE I can override the blacklist, which can be handy, but also annoying when you accidentally move things to "User:User:Example" etc which the title blacklist forbids. Galobtter (pingó mió) 07:18, 5 November 2018 (UTC)
• Support I think the group is restrictive enough to not pose any problem --even if any arises, it can be dealt with in the usual way-- and this will be useful. –Ammarpad (talk) 09:06, 5 November 2018 (UTC)
• Support I would even suppport that page movers should be able to move fully protected pages (including to titles that have been fully salted) since indeed they can be trusted with advanced moving. Page swapping is little more than what regular editors can do, they can move A to A (1) and redirect A to A (2) but not move A (2) to A, which is compliant with NC. Crouch, Swale (talk) 09:44, 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.∯WBG^converse 10:00, 20 November 2018 (UTC)
  • @Winged Blades of Godric: Can you link to the post where Danny encouraged canvassing? I'm curious to read what he said. Thanks! --Deskana (talk) 11:23, 20 November 2018 (UTC)
    • Never mind, a link got posted below to the m:Comminuty Wishlist Survey 2019 noting that "reasonable amount of canvassing is acceptable". --Deskana (talk) 13:38, 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. ∯WBG^converse 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 WP:AN[1]. This kind of behaviour should not be encouraged, no matter what people at the WMF may prefer. A general notice that the Wishlist survey is happening is fine of course, but turning our pumps, noticeboards, project talk pages, ... into a place to canvass for hundreds of proposals is very bad advice from the WMF and not something we should support here. In general, he general idea that you can decide which fixes are the most urgent by seeing who is the best in canvassing support is a fallacy that may be appropriate for awards like "best empoyer" or "best product" elections which are nothing but marketing scams, but is not the way the WMF should be run, and not something we should be encouraging either. Inform people that this popularity contest exists, but don't canvass for individual proposals. 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)
  • That the WMF (or someone there) feels the need to explicitly promote violations of our canvassing guideline doesn't mean that it should be accepted here, but more that the WMF needs to be informed once again that they should respect local policies. Fram (talk) 12:27, 20 November 2018 (UTC)
    • What about the request just above to vote "for the urgently required tools proposed..."? Isn't that also WP:Canvassing, as in "done with the intention of influencing the outcome of a discussion in a particular way"? Jack N. Stock (talk) 12:35, 20 November 2018 (UTC)
      • Yes. Fram (talk) 12:55, 20 November 2018 (UTC)
        • It's fine for the Community Wishlist page to say that limited canvassing is okay, and for local policy here to be stricter and disallow it. This is the way the global and local checkuser policies interact for example, with the local policy here being somewhat stricter than the global one. --Deskana (talk) 13:37, 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)
•  Comment: @Sergecross73 and 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)

• Thats fine, my general sentiment would apply to anyone. Sergecross73 msg me 15:15, 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. Headbomb {t · c · p · 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, Hawkeye7's comment showed that the opposition was not as much against non-admins closing the discussions as delete as it was against non-admins closing them as delete while in need of deletion. As such, the lack of contrary decries indicate that his mentioned form of non-admin closure is an acceptable form and is hereby made part of this proposal's close.

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

• It seems like this will only create duplicate work... Before using the Delete button Admins will still have to re-assess the consensus of the discussion. — Insertcleverphrasehere ^{(or here)} 12:40, 20 October 2018 (UTC)
  • @Insertcleverphrasehere: That's a good point. However, we could restrict this so that users who have more than 10,000 edits can only close these discussions. However, right now there is a backlog of two weeks at WP:RFD and non-admins can currently close any discussion as anything other than keep. Also, if that is the case then what if a non-admin closes a discussion as keep just because they created that redirect when there are five delete votes? Then, they got the consensus wrong! So, if non-admins can't be trusted to close a deletion discussion as "delete", the why should they be trusted to close a deletion discussion as "keep". However, non-admin can close discussions as anything other than "delete" on all noticeboards (except WP:TfD where non-admins can close discussions as "delete" as well) so what is wrong in letting non-admins close WP:RFD discussions as "delete" to clear the backlog? There is no problem in letting non-admins close WP:RFD discussions as "delete" and if there is any problem, it can always go back to admins only closing WP:RFD as "delete". Pkbwcgs (talk) 12:53, 20 October 2018 (UTC)

"Clearing the backlog" does nothing if admins still have to go and read all those discussions to ensure that the consensus was right (they have to do this as it is ultimately their responsibility to use the delete button appropriately). We don't need a knee-jerk response here. Just go ask at WP:AN if some admins can come over and clear the backlog. — Insertcleverphrasehere ^{(or here)} 13:00, 20 October 2018 (UTC)

I've already done two non-admin delete closures. This is possible when an admin has come along and deleted while the xfD is ongoing. Hawkeye7 (discuss) 08:43, 21 October 2018 (UTC)

• WP:RFD does not have any backlog, much less one that's over two weeks. Occasionally a single discussion hangs out in the backlog for some time (eg: Stephni meyer), but that is different from RfD actually being backlogged. I can't think of any sizable backlog there since early 2016 and even then, it wasn't to the point where I would call it problematic. -- Tavix ^(talk) 15:07, 22 October 2018 (UTC)

• Agree with @Insertcleverphrasehere. No matter what, the admin doing the "actual deletion" must reassess the situation and be personally assured that the deletion is OK and this is plainly duplication of work. Just what is needed is to draw the attention of willing admins to the area, through the usual ways.–Ammarpad (talk) 13:50, 20 October 2018 (UTC)
• Strong oppose: What's the point of closing as delete if the closer cannot delete anyway? Regards, User:TheDragonFire300. (Contact me | Contributions). This message was left at 04:39, 21 October 2018 (UTC)
• I supported this the last time it was proposed (Wikipedia talk:Redirects for discussion/Archive 9), and I'm still somewhat sympathetic towards it. It is true that an admin still needs to do the final review, but the main advantage comes from the fact that there are more active administrators at CAT:CSD than WP:RFD. As long as the non-admin closure is performed on clear outcomes only, time is saved by the fact that the deleting admin probably wouldn't have deleted the redirect had the non-admin not drawn attention to it. Close calls and controversial decisions should still be left to administrators. Something similar has already been implemented at WP:TFD with some success. With that being said, the previous discussion was held when, if I recall correctly, the backlog at RfD was pretty severe. I can't confess to being familiar with the RfD backlog today, so perhaps this extension on non-admin closures is simply not necessary (e.g. admins already clear out the easy delete closes quickly). Mz7 (talk) 05:07, 22 October 2018 (UTC)
• Strong Support a great way to tackle backlogs. Yes an Admin will need to check the RfD before deleting but they will not need to fill out the fields to close the discussion. It will be very clear very fast which non-Admins are trustworthy to close RfDs where the Admin can just handle the deletions. This will reduce silly relistings as well. Legacypac (talk) 09:34, 22 October 2018 (UTC)
• Support. Even though admins will need to check the RfD, most are unlikely to be contentious so that's likely to be little more than a rubber stamp. And in cases that might not be obvious, I generally find it significantly easier to review someone else's judgment of consensus than to judge it myself from scratch. As Legacypac says, it means the admin just has to do a quick CSD delete rather than the formal closing steps of the RfD, so it's one step of bureaucracy taken care of. Mz7 makes the point that CSD has more active admins than RfD - I've personally done lots of CSD work but I don't think I've ever even looked at RfD. On an ideological front I also think it's good to get judgment calls like this devolved away from admin-only wherever practical. Boing! said Zebedee (talk) 10:21, 22 October 2018 (UTC)
• Procedural note. The same thing was propsed, and rejected, at an RfC in 2016, see Wikipedia talk:Redirects for discussion/Archive 9#Allow non-admin delete closures?. Of course, things can change, but if there is any obvious change since then, it is that for the past year or so we've had more admins regularly closing discussions, so the backlogs have almost disappeared now. – Uanfala (talk) 12:39, 22 October 2018 (UTC)

  It was a close call back then, and two years is a very long time in Wikipedia ;-) Boing! said Zebedee (talk) 13:31, 22 October 2018 (UTC)

• Oppose Per above, I don't see the point. As one of the main sysops active at RfD, I don't think lack of sysop activity is a major issue, but rather lack of overall participation. Having a few more sysops swing by would be helpful, but I'd much rather have folks take part in the discussions. Best case scenario there's a half dozen or so participants, and excepting Thryduulf, there's very little actual discussion amongst participants; mostly by the seventh day there have been no comments for five or six days. ~ Amory (u • t • c) 13:40, 22 October 2018 (UTC)
• Hypothetical support, practical oppose. I appreciate the intent here; non-admins are perfectly capable of assessing consensus. However, since an admin still has to come along and delete the article, it just creates double work. --Jayron32 13:45, 22 October 2018 (UTC)
• Question how would this work mechanically? Maybe a CSD-like tag indicating an RfD was closed by a non-admin as Delete with a link to the closing diff? zchrykng (talk) 13:47, 22 October 2018 (UTC)

@Zchrykng: Yes a template like {{db-xfd}}. — Insertcleverphrasehere ^{(or here)} 13:52, 22 October 2018 (UTC)

• Oppose. It's rare that there is actually a significant backlog of discussions that are simple closures (with any outcome). user:Feminist does good work with easy keep and retarget closures and there are 6 active RfD admins (in no particular order) myself, Tavix, Patar knight, Amorymeltzer, Deryck Chan and BDD. The discussions that get left are the ones that are more complicated and need careful assessing of the arguments - NACs would not help these. The one really extended backlog we had recently was Wikipedia:Redirects for discussion/Log/2018 September 17#Stephni meyer which went unanswered for several days at WP:ANRFC but was closed by Ivanvector (an occasional RFD participant and former regular) when I left a message on their talk page. What is needed at RfD is more people (admins and non-admins) participating in discussions and admins patrolling backlogs at WP:ANRFC. Thryduulf (talk) 14:30, 22 October 2018 (UTC)
• Strong oppose. This comes up frequently enough that I have listed out my reasons at User:Tavix/non-admin closes. -- Tavix ^(talk) 14:43, 22 October 2018 (UTC)
• TBH I think what this shows is that having something like an "eliminator" user right would be useful. Galobtter (pingó mió) 14:48, 22 October 2018 (UTC)
• Support - I did make this same proposal some time ago. I don't think this would help address any backlogs and I agree that in the more recent past this process hasn't really been plagued with backlogs anyway. I pretty much agree entirely with Thryduulf's comment, but this is more of a "why not?" support. I don't think the sky is going to fall if we let non-admins conclude that a discussion closed as "delete" just because they can't push the buttons: we let non-admins close every other kind of result anyway. Personally I think it's silly that we trust experienced editors like feminist to neutrally assess the result of a discussion but only if the result fits in a certain box. If such a user can determine the consensus of a "keep" discussion they are just as capable of determining the consensus of a "delete" discussion. Ivanvector (^Talk/_Edits) 15:29, 22 October 2018 (UTC)
• Oppose per the sound reasoning at User:Tavix/non-admin closes. -DJSasso (talk) 16:31, 22 October 2018 (UTC)
• Neutral. I have previously argued against NAC deletion, though the marginal cases of all admin-regulars having already chipped in, and the faffiness of RfA are softening me up to the idea of non-admins closing discussions to mandate admin action. As one of the RfD admin-regulars I am probably expected to leave a comment here, so I'm writing this to say why I don't feel strongly either way. Deryck C. 17:23, 22 October 2018 (UTC)
• I'd like to find some way to make this work. Before I was an admin, I did good work (I'd like to think) with non-admin closures, including deletion results in venues that allowed it. I mostly agree that the RfD backlog hasn't been bad enough recently to really need this, but that has not always been true and likely will not be true again sometime in the future. So I don't want to argue against planting seeds just because I currently have enough food, proverbially speaking. The first thing that comes to mind is a system in which one or more admins indicate "hey, a non-admin delete close could work here". I don't know how to design a clean mechanism like that, though. I imagine it'd be invoked most when admins are involved. We wouldn't want it to just be a way for admins to try to cut short discussion on something they want to see deleted. (Please ping me if a response is requested; I won't be watching this page.) --BDD (talk) 19:22, 22 October 2018 (UTC)

• Comment the mechanics are very simple. Close as Delete and tag the redirect G6 housekeeping noting "deleted at RfD" or similar. An admin working CSDs can just press the button. If some non-Admins closed the non-comtroversal ones the Admins woukd be freed up to close the tougb ones, though there are not a lot of tough RfD discussions. I favor letting non-Admins do everything possible to demonstrate a good trackrecord and this is a good place for someone to show their judgement. Legacypac (talk) 19:33, 22 October 2018 (UTC)
• Oppose per the excellent essay at User:Tavix/non-admin_closes. All this does is create duplicate work. The scripts that we have make adding all the templates trivial, so a non admin doing that isn't really helping. The best that can be said for this proposal is that it might give qualified individuals the chance to better demonstrate that they are qualified for RfA, but they can do that in other ways. — Insertcleverphrasehere ^{(or here)} 19:56, 22 October 2018 (UTC)
• Oppose. I don't understand the reasoning here at all; there's no backlog to speak of at RFD and hasn't been since the disruptive editor who used to fill it with spurious and time-consuming comments (all of which needed to be reviewed by the closing admin just in case it was one of the rare occasions when he was making a sensible point) has been sitebanned, and needing to have two closers for each discussion would increase the workload, not decrease it. ‑ Iridescent 20:02, 22 October 2018 (UTC)
• Oppose, noting that (I think) I supported a similar proposal a while ago. It makes sense for TfD and CfD to allow non-admin "delete" closures because templates and categories need to be orphaned/emptied/replaced before they are deleted, and this extra work can be done quicker if non-admins are involved in the process. RfD has no similar issue. feminist (talk) 10:32, 23 October 2018 (UTC)

@Feminist: I have not seen non-admins close CfD discussions as "delete" and XFDCloser doesn't let me close CfD discussions as "delete". Pkbwcgs (talk) 11:38, 25 October 2018 (UTC)

Also, Wikipedia:Categories for discussion/Working is fully protected which makes it impossible for non-admins to close CfD discussions as "delete". Pkbwcgs (talk) 11:47, 25 October 2018 (UTC)

See Wikipedia_talk:Categories_for_discussion/Working#Protection_of_WP:CFD.2FW.2C_take_3. feminist (talk) 13:04, 25 October 2018 (UTC)

@Feminist: Okay. However, XFDCloser doesn't let non-admins close a CfD discussion as "delete". Pkbwcgs (talk) 14:06, 25 October 2018 (UTC)

• Oppose Unless there is a user right that allows non admins to delete pages it makes no sense to allow non admins to close as delete unless the article is already deleted and the admin forgot or could not close it. Abote2 (talk) 10:29, 25 October 2018 (UTC)
• Oppose per basically hwat Tavix has already summarized at User:Tavix/non-admin closes. There is already a process to determine whether someone is clueful enough to assess consensus and it's called WP:RFA. In fact, proposals like this carry the risk of deterring people from running for adminship by removing incentives (such as the ability to close XFDs as delete). Regards SoWhy 10:37, 25 October 2018 (UTC)
• Support per Ivanvector. Also, it's great, actually, to have two users (the closer and the deleter) who believe delete is the policy compliant consensus, further evidencing that is the reasoned course. In addition, it's said that the process suffers from lack of participation, a likely side benefit to this proposal is more policy compliant participation and more experienced participation across the board. (As lack of participation in deletion, often results in a potential closer, not closing, but instead participating). -- Alanscottwalker (talk) 13:22, 25 October 2018 (UTC)
• Oppose, per Iridescent. Unnecessary, as there is no significant backlog at RFD. Will not decrease the workload on admins but will increase the overall workload for the project and will make things bureaucratically more complicated without a completing need for it. Also will create a mess at DRV if such deletion decisions are ever appealed there since there will be more things to haggle about (the NAC closure itself and the subsequent deletion by an admin). Nsk92 (talk) 14:30, 25 October 2018 (UTC)
• Oppose as meaningless. Admins are responsible for any use of the tools, so they would still have to reevaluate the discussion to determine if the determination of a "delete" consensus was correct. "But _______ told me to!" isn't an excuse for tool misuse. If a non-admin agrees that something should be deleted, they can of course add a "Delete" argument to the discussion, and realistically, greater participation in deletion discussions would be of far more value. Seraphimblade ^{Talk to me} 19:35, 25 October 2018 (UTC)
• Support - if this proposal was implemented, admins should not be the ones responsible for that deletion - the non-admin closer would be. Admins would only be responsible for preventing clerical errors - establishing that an RfD was closed as delete for the correct redirect. This is easily handled by an automated tool. Hell, we could make it so an automated tool compiled the NAC deletes onto one page, waiting for an admin to drive-by d-batch all of them. Admins will likely know the closer in the vast majority of deletions that would occur under this rule. In response to the argument that anyone who is trustworthy enough to close RFD discussions as delete should simply pick up the mop at RfA, I have only one thing to say: RfA is buh-roken. Tazerdadog (talk) 06:11, 28 October 2018 (UTC)

• Consensus has determined that only trusted users (aka those who succeeded in RfA) should have access to deletion tools, as with great power comes great responsibility. Therefore, letting non-Admins close as delete and having them delete the pages would be large break of consensus. Kirbanzo (talk) 18:54, 28 October 2018 (UTC)

• Snow oppose - deletion should always only be carried out by administrators - besides, if it's deleted before the XfD (in this case, RfD) is finished, let some user use the custom close rationale to close it. Kirbanzo (talk) 18:54, 28 October 2018 (UTC)
• Oppose. Doubles the work as admins are ultimately responsible for their deletions. The problem with RFD and most non-XFD AFD processes is not a lack of willing administrators, but a lack of participation. ---- Patar knight - ^chat/_{contributions} 07:52, 4 November 2018 (UTC)
• Oppose deletion is best left to admins and if they have to double-check anyway this is a waste of time Atlantic306 (talk) 16:52, 4 November 2018 (UTC)
• Support in principle - this discussion is a close parallel to the similar one at TfD awhile back, and contains a lot of the same misunderstandings. NACs at TfD worked well, and IMO the sole condition that would limit using them in a similar way at RfD is the opposition of admins who are regulars there. We had back then the same problem with people who had no idea how the process might work showing up at the RfC to announce that it wouldn't help and would "double the work", never mind that the people actually doing the work at the time knew perfectly well where the pain points were and why this procedural change would reduce them. The difference between the TfD proposal and this one, though, is that it seems that (some of?) the admins involved aren't persuaded (see Amorymeltzer's post above) and they're the ones who actually know what they're talking about when it comes to workload. Opabinia externa (talk) 21:54, 4 November 2018 (UTC)
• Oppose (1) the is not a huge backlog in AfD and (2) As a reviewer, I have seen many times pages have been checked reviewed and accepted on the main space even the articles have 0 source/homepage or sources associate with the subjects, let alone the articles pass the notability, reliable secondary source with WP:SIGCOV requirements. If reviewer would accept such articles, other editors might not know/might not have the knowledge of what constitute a page to be deleted. To say that, there are some editors and reviewers do have the understand to carry out the task if a non-admin "delete" closures right is provided/permitted. CASSIOPEIA^(talk) 04:27, 13 November 2018 (UTC)
  • @CASSIOPEIA: Read the topic before commenting. We are talking about WP:RfD, not WP:AfD so please don't talk about articles for deletion. Pkbwcgs (talk) 16:15, 13 November 2018 (UTC)
• Support This will help reduce the work administrators. —Eli355 (talk • contribs) 21:54, 22 November 2018 (UTC)
• Oppose as admin required to delete anyway Cas Liber (talk · contribs) 02:33, 23 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.

Diffs should include log extracts

Tracked in Phabricator
Task T72239

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.∯WBG^converse 05:56, 28 November 2018 (UTC)

• RoySmith, what is needed is just to add a null revision for delete and undelete events; this has been requested since 2014. There were some objections and then discussion petered out. See phab ticket above. –Ammarpad (talk) 09:14, 28 November 2018 (UTC)