Wikipedia:Village pump (proposals)

Source: Wikipedia, the free encyclopedia.

This is an old revision of this page, as edited by Winged Blades of Godric (talk | contribs) at 19:10, 12 November 2018 (→‎RFC:Close MedCom?: // Edit via Wikiplus/Close). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts

New ideas and proposals are discussed here. Before submitting:


RfC: Notify pending-changes reviewers during large backlogs

Clear consensus that opt-in is fine, but there's a consensus against opt-out notifications. Galobtter (pingó mió) 11:28, 3 November 2018 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

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

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

This RfC is only for opt-out notifications. This idea was

first discussed at the idea lab section. Enterprisey (talk!) 07:25, 18 September 2018 (UTC)[reply
]

Survey (Notifying PCRs)

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

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

This functionality is not available directly without new software development that could be requested as phabricator. However,
WP:GADGET in the future. — xaosflux Talk 20:19, 3 November 2018 (UTC)[reply
]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

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

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

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

This is awesome, the thread is over, we've found it, thank you @FR30799386:. Discuss-Dubious (t/c) 00:52, 29 October 2018 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

RFC:Close MedCom?

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
  • Summary --> There is a strong consensus to checkY disband the Mediation Committee in entirety. And, all processes and components thereof can 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).
  • I cannot decipher some of the opposition !votes (much of what was said by Allanscottwalker throughout the discussion, JohnCline et al) and they have been pretty much discounted.
  • 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), due to a lack of heads.
  • Interested people may pursue such ideas separately and present to the community, for an evaluation.
  • Isaacl's comment at the end of the Extended Discussion section, might be a worthy read:-)

Respectfully, ∯WBGconverse 19:10, 12 November 2018 (UTC)[reply]

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

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

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

Rationale:

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

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

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

talk) 17:50, 10 October 2018 (UTC)[reply
]

MedCom discussion
It now appears inevitable that MedCom will be shut down. The reasoned Oppose !votes are being shouted down. This raises the question is what will happen the next time there is a long complicated content dispute. What will probably happen is that we will lose two respected editors. It isn’t just a matter of taking the acronym RFM out of a list and the procedure MedCom out of a list of processes. It would be like disbanding the volunteer fire department because there hasn’t been a fire recently. Not every content dispute can be contained by DRN and specialty noticeboards. If we have a case that needs real mediation, at present, we can find a mediator. If we cross that entry out of the list, then we just throw it to
WP:ANI
and possibly a trip to ArbCom, and eventually topic-bans will be imposed, and in all likelihood one of the two editors, probably a respected content contributor, will be sufficiently embittered by the inability of the community to resolve the content dispute that they will likely leave Wikipedia.
The Support side has not considered the future adverse consequences of doing away with MedCom as the fall-back last resort for content disputes. Just because it hasn’t been used recently doesn’t mean that it isn’t needed. There hasn’t been a fire. That doesn’t mean that there won’t be a fire.
Since we are now almost certain to mark the MedCom as historical, the best way to recover from this mistake will be to create something having a similar function and mission. What we ought to be doing, rather than looking for a procedure to take out of a list of procedures, is trying to improve our dispute resolution procedures. Just getting rid of one that hasn’t been used recently is very much the wrong answer. It would have been better to propose improvements to DRN ‘’before’’ proposing to get rid of MedCom, but I don’t see any real hope now. Robert McClenon (talk) 01:59, 15 October 2018 (UTC)[reply]
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)[reply
]
  • 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)[reply
    ]
    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)[reply]
    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)[reply]
    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)[reply]
    It is true that many disputes have both a content aspect and a conduct aspect. There are very few disputes that are purely conduct disputes. If the problem is simply the conduct of an editor who is a vandal, troll, or flamer, the offending editor normally gets indeffed quickly, without a real dispute. Content dispute resolution mechanisms, such as DRN and MedCom, operate on the optimistic assumption that the parties will set aside their conduct concerns long enough to resolve the content issue, and then the conduct issue is resolved as a side benefit. Conduct dispute resolution mechanisms, such as
    Arbitration Enforcement, operate on the recognition that the offending editor who is preventing the content issue from being resolved can be sanctioned long enough to resolve the content dispute. There never was a black-and-white distinction, except for vandals, trolls, and flamers. It is still true that throwing away a content dispute resolution process is unwise. Robert McClenon (talk) 02:32, 16 October 2018 (UTC)[reply
    ]
    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)[reply]
  • Strong support - Wow, it's definitely time to put this thing out of its misery. MedCom is inaccessible, redundant, ineffective, archaic relic, particularly in the context of modern dispute resolution, which is heavily streamlined in favor of formal, community-based consensus building, which easily handles both routine and complex disputes with binding decisions. At this point, it's more of a distraction from measures which actually resolve disputes. It's less useful than the long-defunct
    let it go when they can't secure a consensus, and who will drag out disputes past a reasonable point. When these situations arise, we're not relying on this bureaucratic dinosaur to walk them through their dispute and hope everyone will be agreeable, even though they're spending weeks and weeks of their life trying to come to an understanding in an online argument. We're investigating the underlying behavior and sanctioning or warning users, or implementing page restrictions, or going to ArbCom for binding solutions, so that actual collaborative, good faith editors do not get burned out and can continue contributing. That's why MedCom is an obsolete relic, not because we haven't had any "complex disputes" lately. Also, this whole thing is just out of touch with the community. It's purported to be this formal, serious thing, the be-all and end-all of dispute resolution, with legitimacy stemming from Jimbo himself, but in reality it's the pet project of this closed club of a small handful of users (or more realistically, one user), who decide from within what their membership is, and what their rules are, and when to take a case (read: never) and really don't contribute anything to DR. It's totally out of whack. The "chair" of MedCom's comments above just goes to show how out of touch with DR and the community this whole thing has become. Rather than actually demonstrating how and why MedCom has done and can still do good for the community, his case for keeping it is that we somehow 'need' his committee, because they don't accept newcomers into their ranks, or because they will accept disputes that drag on for months while DRN won't (I wonder why), or because they "mediate". I've been involved in DR pretty much since I became active here, and this kind of mediation-based approach to DR has never been particularly effective anyway, and keeping around a self-important group of 'mediators' who have long-since outlived their usefulness to the project is just silly. I thank those who have invested time in this project, but it's time to pull the plug.  Swarm  talk  00:26, 16 October 2018 (UTC)[reply
    ]
  • 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)[reply]
  • 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)[reply]
    But Consensus is
    that are binding, so the fact that mediation recognizes that is the only choice mediation has. -- Alanscottwalker (talk) 09:24, 16 October 2018 (UTC)[reply
    ]
    That link to
    WP:CONEXCEPT. Boing! said Zebedee (talk) 09:37, 16 October 2018 (UTC)[reply
    ]
    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)[reply]
    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)[reply
    ]
    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)[reply]
    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)[reply
    ]
    (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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]

    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)[reply]
    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)[reply
    ]
    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)[reply]
    Why are you misrepresenting what I said? Nowhere did I say or imply that "Arbcom is the alternative to Medcom". I was clearly saying that the kind of extreme disputes that would normally be under the purview of Medcom are no longer "mediated" (read: tolerated), and are now dealt with via more effective measures, Arbcom being one of them. When you say "Arbcom is all and only about admin action", and "Arbcom can't handle content", you're quite simply wrong. You're objectively wrong on this. See
    Medcom policy does it say or imply that it is the last stage of dispute resolution.  Swarm  talk  04:16, 18 October 2018 (UTC)[reply
    ]
    @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)[reply]
    Well, no, that is not what I am doing. I am just disagreeing with you. Alanscottwalker (talk) 17:48, 18 October 2018 (UTC)[reply]
    Swarm, I was not referring to you about Arbcom, the only thing I was referring to your comment about is admin action, the "and" Arbcom was a different thought. And yes, I do think it is
    WP:CONSENSUS policy ("For disputes involving many parties or complicated issues or which otherwise need more time for resolution than is allowed at DRN, the Mediation Committee (MedCom) is staffed by members with proven mediation ability."). Alanscottwalker (talk) 18:55, 18 October 2018 (UTC)[reply
    ]
    "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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply
    ]
  • Support - Doesn't really serve any useful function. Beyond My Ken (talk) 03:36, 28 October 2018 (UTC)[reply]
  • 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)[reply]
  • 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)[reply
    ]
  • 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)[reply]
    • @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)[reply]
      • 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)[reply
        ]
And “abolish” really isn’t correct either. This is just about marking what is obviously an outdated and unused process as inactive. If it were to be kept open, then yeah, it’s probably overdue for some serious reform, but it seems clear we don’t use it and don’t need it anymore, whatever it’s past role may have been.
talk) 22:18, 2 November 2018 (UTC)[reply
]

Arbitrary Page Break

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

Extended discussion

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

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

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

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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    L235, the consensus is too obvious. I was planning to do it by myself but would probably temporally restrain. ∯WBGconverse 17:31, 9 November 2018 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

RfC: should we automatically pending-changes protect TFAs?

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

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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply
    ]
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)[reply
]
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)[reply]
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)[reply]
  • Support: @
    WP:NO-PREEMPT. — Insertcleverphrasehere (or here) 14:53, 14 October 2018 (UTC)[reply
    ]
  • Support: Common sense application of capabilities to block routine vandalism in an efficient way. MB 15:44, 14 October 2018 (UTC)[reply]
  • 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)[reply]
  • Support. I'd prefer semi-protection, but this would be better than the current situation. SarahSV (talk) 18:39, 14 October 2018 (UTC)[reply]
  • Support this *is* an RFC to change the protection policy, the argument that this is not permitted by the current protection policy is circular. This is a reasonable measure to prevent vandalism while still allowing good-faith new contributors to edit.
    π, ν) 20:11, 14 October 2018 (UTC)[reply
    ]
  • 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)[reply]
    • @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)[reply]
      • 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)[reply]
  • Oppose I prefer a standard 24 hour full protection. The Banner talk 20:49, 14 October 2018 (UTC)[reply]
  • Oppose - I'd prefer semi-protection over pending-changes because the latter requires continued monitoring and accepting/reverting whereas the former doesn't, We should get rid of IP editing altogether and be made into a register-to-edit site but ofcourse I know I'm the minority on that. –Davey2010Talk 20:53, 14 October 2018 (UTC)[reply]
  • Support: it settles the concern of the perennial proposal; it doesn't lock out editing completely, thereby not leaving a poor impression on readers/editors. Regards,
    Contact me | Contributions). This message was left at 23:24, 14 October 2018 (UTC)[reply
    ]
  • 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)[reply]
  • oppose IPs should be able to directly edit TFAs. —
    talk, contribs) 03:05, 15 October 2018 (UTC)[reply
    ]
  • 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)[reply]
    @
    semi-protection, so new users can still edit. SemiHypercube ✎ 11:21, 15 October 2018 (UTC)[reply
    ]
    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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Oppose After vandalism has happened, I'm OK with protecting. Pre-emptive protection is not useful, IMHO. --Jayron32 15:18, 15 October 2018 (UTC)[reply]
  • 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)[reply]
  • 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)[reply
    ]
  • Suppose see what I did there? per the above comment by zzuuzz. This is perhaps a workable stopgap measure but I don’t see it as good permanent solution. So, do it for now, but don’t consider the problem permanantly resolved. Alternatives like the edit filter proposed below should be considered.
    talk) 19:07, 15 October 2018 (UTC)[reply
    ]
  • 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)[reply]
  • Support per TheDragonFire300. Double sharp (talk) 23:57, 15 October 2018 (UTC)[reply]
  • Support Wikipedia is the encyclopedia anyone can edit, not the encyclopedia anyone can vandalize. Pending changes is not going to stop constructive editors from contributing. --Joshualouie711talk 01:21, 16 October 2018 (UTC)[reply]
  • Support semi-protection, a better option than pending changes. --K.e.coffman (talk) 03:16, 16 October 2018 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Oppose per AntiCompositeNumber, zzuuzz, and Beeblebrox. The supports are quite right, this is an issue, a problem, but preventing certain people from editing the very first article they're likely to come across doesn't strike me as the correct solution. Happy days, LindsayHello 14:38, 16 October 2018 (UTC)[reply]
  • 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)[reply]
  • Support - Net positive. shoy (reactions) 20:14, 16 October 2018 (UTC)[reply]
  • 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)[reply
    ]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
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)[reply]
  • 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)[reply]
  • Oppose pending changes simply does not work for articles that receive frequent edits. feminist (talk) 18:06, 19 October 2018 (UTC)[reply]
  • 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)[reply]
  • Support Prevents vandalism while allowing constructive IPs/non-autoconfirmed users to make changes. Philroc (c) 12:26, 24 October 2018 (UTC)[reply]
  • 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)[reply]
  • Oppose per Cas Libre, Yair Rand and Fastily. --Nemo 11:51, 26 October 2018 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • Support. I'm surprised that this wasn't the norm already. TFAs are too high-traffic to avoid being a primary target for vandals, and there's clear evidence that temporary protection is the only way to completely stop it. In regards to the primary oppose reasoning (it's an encyclopedia anyone can edit, and this is preventing that), it's not blocking edits entirely, just hiding them from view of unregistered users until someone can verify them. I've been a big supporter of pending changes for a while, and this is the perfect use case for it. Nathan2055talk - contribs 23:17, 10 November 2018 (UTC)[reply]

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

  • 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)[reply]
  • 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)[reply]
  • Support Seems like a good idea regardless of the outcome of the broader discussion.
    talk) 19:04, 15 October 2018 (UTC)[reply
    ]
  • Support as above. TonyBallioni (talk) 19:12, 15 October 2018 (UTC)[reply]
  • 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)[reply]
  • Support per above. Aoi (青い) (talk) 19:20, 15 October 2018 (UTC)[reply]
  • Support If this would be the only thing that works (but how would it be implemented? Edit filter?) SemiHypercube ✎ 19:24, 15 October 2018 (UTC)[reply]
  • 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)[reply]
@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)[reply]
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)[reply
]
  • 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)[reply]
  • There's no way to make a TFA-specific edit filter; see MusikAnimal's !vote above. -FASTILY 07:55, 5 November 2018 (UTC)[reply]
  • Erm How do you enforce this in a way that doesn't increase human workload? Deryck C. 17:38, 6 November 2018 (UTC)[reply]
  • By setting it to "disallow". L293D (☎ • ✎) 14:33, 9 November 2018 (UTC)[reply]

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

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)[reply]
  • 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)[reply]
    pretty sure your remark misses the point Nosebagbear was trying to make, which is more about the pending changes workload than the TFA workload. PC can get very convoluted when used on busy articles, that’s not really what it’s for and adding TFA could cause less attention to be paid to other articles under PC.
    talk) 19:10, 15 October 2018 (UTC)[reply
    ]
    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)[reply]
Optimally yes, but when there are multiple edits awaiting review it can get difficult to untangle.
talk) 22:14, 15 October 2018 (UTC)[reply
]
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)[reply
]
  • 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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
  • 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)[reply]
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)[reply
]
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)[reply]
Because you forgot a closing parenthesis. —Jeremy v^_^v Bori! 01:29, 22 October 2018 (UTC)[reply]

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

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)[reply]
Actually meant ECP, corrected myself. Blackmane (talk) 01:54, 26 October 2018 (UTC)[reply]

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

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

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

"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)[reply
]
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)[reply]
  • 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)[reply
    ]
@Zchrykng: Yes a template like {{db-xfd}}. — Insertcleverphrasehere (or here) 13:52, 22 October 2018 (UTC)[reply]
  • Oppose. It's rare that there is actually a significant backlog of discussions that are simple closures (with any outcome).
    WP:ANRFC. Thryduulf (talk) 14:30, 22 October 2018 (UTC)[reply
    ]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Oppose per the sound reasoning at User:Tavix/non-admin closes. -DJSasso (talk) 16:31, 22 October 2018 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
@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)[reply]
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)[reply]
See Wikipedia_talk:Categories_for_discussion/Working#Protection_of_WP:CFD.2FW.2C_take_3. feminist (talk) 13:04, 25 October 2018 (UTC)[reply]
@Feminist: Okay. However, XFDCloser doesn't let non-admins close a CfD discussion as "delete". Pkbwcgs (talk) 14:06, 25 October 2018 (UTC)[reply]
  • 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)[reply]

Proposal/RFC: Redesigning page-protection padlock icons to be more accessible
EXAMPLES:
See also: A gallery of the redesigned icons on Wikimedia Commons

Should the page protection padlock icons be redesigned? –

talk  |  contribs) – 07:00, 25 October 2018 (UTC)[reply
]

Background (padlock redesign)

Page-protection padlocks are icons at the top right corner of

protected pages
. However, the current padlock designs have several flaws, many of which harm people who have visual impairments.

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

Proposal (padlock redesign)

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

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

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

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

Alternative designs (padlock redesign)

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


Posted by

talk) 07:00, 25 October 2018 (UTC)[reply
]

Support (padlock icons)

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

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

Support with colored shackles (padlock icons)

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

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

Support with grey shackles (padlock icons)

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

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

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

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

    IPs are human too. 142.160.89.97 (talk) 21:44, 26 October 2018 (UTC)[reply
    ]

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

Oppose (padlock icons)

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

General discussion (padlock icons)

  • imo its style is too different from the other icons to be implemented alongside them. –
    talk  |  contribs) – 18:15, 26 October 2018 (UTC)[reply
    ]
Locks with gray shackles look less like shopping bags
  • @
    XYZtSpace: You probably have so many pings right now, but do you think you could also upload an SVG version of my suggestion for the office-protected padlock with the WMF logo on it? SemiHypercube ✎ 17:33, 26 October 2018 (UTC)[reply
    ]

As a colorblind user, I don't have any problem with the current padlock system. The problem with using color to convey information is that it's generally done in place of conveying it in some other manner, whether in text or in images. With the current padlocks, however, this isn't a problem — you can always generate a tooltip to see what the protection level is, or you can attempt to edit the article. Either you'll be blocked from doing what you're trying to do (and you'll get a link to the protection log), or you can check the page history and view the logs. (If you don't know how to do this, and you're able to edit a page, you probably don't know that the page is protected in the first place and don't care.) Moreover, there are just so many padlocks already that it's hard to keep track of them; even if I could tell the difference between purple and blue, or gold and olive (I can't), I'd have to check because I just don't remember what's what. Nyttend (talk) 02:21, 5 November 2018 (UTC)[reply]

Browser friendly pages

This proposal isn't actionable as it is lacking details. For specific technical assistance feel free to bring examples up at
WP:VPT. Close as there is nothing to do here. — xaosflux Talk 20:21, 3 November 2018 (UTC)[reply
]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Please consider that change to Wikipedia. Make the margins change as the typeface is enlarged. Thanks.— Preceding unsigned comment added by Kloro2006 (talk • contribs)

It does this just fine on my browser (Win 7, both Firefox and Chrome). Can you give us details of your configuration? Shock Brigade Harvester Boris (talk) 03:40, 29 October 2018 (UTC)[reply]
Adding on, works fine over here too. (Arch Linux, Firefox).
talk) 13:15, 29 October 2018 (UTC)[reply
]
Same here, Windows 10/Google Chrome. ProgrammingGeek talktome 23:15, 29 October 2018 (UTC)[reply]
It occasionally does not work depending on non-text elements on the page, especially tables with hard-coded widths. Those should be corrected when we come across them. Otherwise, yeah, works fine for me in any non-mobile browser I've ever used. Ivanvector (Talk/Edits) 17:00, 30 October 2018 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Page movers and the title blacklist

I just got a request from pagemover

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

Tech notes (page movers and the title blacklist)

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

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

Implementation notes:

Related notes:

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

Discuss (page movers and the title blacklist)

  • Support Sounds like a good idea. Page mover is supposed to be an unbundling of admin rights, so it makes sense to do this to do page moves like this more easily. SemiHypercube ✎ 02:21, 5 November 2018 (UTC)[reply]
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)[reply]
That's rarely necessary. All you have to do is first move the redirect to some different title: the vast majority of topics are far from having the optimal redirect density, and you should almost always be able to think of a good redirect title (from an
alternative disambiguation, etc.) that doesn't exist yet. – Uanfala (talk) 14:32, 5 November 2018 (UTC)[reply
]
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)[reply]
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)[reply]
  • 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)[reply]
  • 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)[reply
    ]
  • 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)[reply]
  • Support - PM & TPE require similar levels of trust. Cabayi (talk) 12:49, 5 November 2018 (UTC)[reply]
  • Support. Seems perfectly reasonable to me. Boing! said Zebedee (talk) 13:02, 5 November 2018 (UTC)[reply]
  • 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)[reply]
  • Comment I added a technical recap section above, feel free to amend as needed. — xaosflux Talk 04:22, 6 November 2018 (UTC)[reply]
  • 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)[reply]
  • Support. Appears to be useful and low risk. Occasional mistakes can be fixed. · · · Peter (Southwood) (talk): 06:42, 6 November 2018 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]

Change "Spouses" to "Table of Spouses"

Ain't happenin. As has already been pointed out, the existing infrastructure can handle multiple spouses. There doesn't seem to be any obvious reason to continue this discussion further given unanimous opposition. Let's all go edit an article instead. GMGtalk 00:20, 9 November 2018 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

For example, to people married to more than one person at a time, like Osama bin Laden, you could have a table of the people they were married to all at one time. Otherwise it could be discriminatory against these types of people and I'm sure its driving people away from the project. Braveberet (talk) 03:52, 6 November 2018 (UTC)[reply]

This seems patently ludicrous. —Jeremy v^_^v Bori! 03:43, 6 November 2018 (UTC)[reply]
Well if Wikipedia wants to be neutral like it claims to be, they shouldnt say that being married to more than one person is bad as that would be pushing a political view. Braveberet (talk) 03:52, 6 November 2018 (UTC)[reply]
the =spouse parameter is fairly flexible on most infoboxes already, and you can include dates in the text (e.g.
Madonna_(entertainer)) - so you can already include overlapping dates if the reliable sources support it. — xaosflux Talk 04:05, 6 November 2018 (UTC)[reply
]
Braveberet, What evidence makes you sure its driving people away from the project? · · · Peter (Southwood) (talk): 06:39, 6 November 2018 (UTC)[reply]
Pbsouthwood People won't use wikipedia if it is against them or their viewpoints, and you cant claim to be neutral without actually being neutral. Braveberet (talk) 08:15, 6 November 2018 (UTC)[reply]
1. We generally ignore claims made without evidence, particularly when they are subjective opinions presented as fact. Simply repeating them is not evidence. 2. At Wikipedia, neutrality doesn't mean whatever we want it to mean. It has a narrower definition which is laid out at
reliable sources. I see little to no connection between your arguments and that policy, and I Oppose your proposal. As indicated by Xaosflux above, infoboxes are already sufficiently flexible to handle cases of polygamy. ―Mandruss ☎ 09:13, 6 November 2018 (UTC)[reply
]
Like Mandruss says above. No evidence, no claim. · · · Peter (Southwood) (talk): 09:34, 6 November 2018 (UTC)[reply]
How is it a subjective opinion that neutrality requires being neutral to all points of view? Braveberet (talk) 10:03, 6 November 2018 (UTC)[reply]
See Begging the question. Boing! said Zebedee (talk) 10:08, 6 November 2018 (UTC)[reply]
So you're implying that its fallacious to say that neutrality by definition has to be neutral? Braveberet (talk) 10:15, 6 November 2018 (UTC)[reply]
Already answered.
This page is not for education of (apparently zero-experience) users who are here to school experienced editors about Wikipedia editing and don't listen to the responses. I suggest a quick close. ―Mandruss ☎ 11:24, 6 November 2018 (UTC)[reply]
I'm more apt to say "
alleged zero-experience users", since the only edits Braveberet has made are to this section and to bluelink his userpage. —Jeremy v^_^v Bori! 11:55, 6 November 2018 (UTC)[reply
]
Oppose nonsense. There are zero relevant Google hits on "Table of Spouses". Nobody uses this silly term. The spouse field can already list multiple spouses whether or not they are at the same time. PrimeHunter (talk) 21:13, 6 November 2018 (UTC)[reply]
I think the intent was to deprecate the "Spouses" infobox parameter in favour of a table in the article, which is ludicrous on its face and
unnecessary. —Jeremy v^_^v Bori! 01:36, 8 November 2018 (UTC)[reply
]
Isn't the idea behind Wikipedia to provide a neutral environment, like an encyclopedia, in order to spread neutral and unbiased information? So whats the deal behind Wikipedia being openly against polygamy? Doesnt that actually defeat the purpose of the encyclopedia? Braveberet (talk) 08:38, 8 November 2018 (UTC)[reply]
In no way does the spouses parameter of the infobox represent being against polygamy. The issue is that making a table with the number of spouses is undue weight; there's little reason to devote what amounts to an entire section of an article to the number of spouses one has had (both current and past), especially if it's not a particularly notable aspect of that person. —Jeremy v^_^v Bori! 09:00, 8 November 2018 (UTC)[reply]
Oh cut the stupid accusations and the melodrama, Braveberet, there's absolutely no prejudice against polygamy in the suggestion that the current parameter can handle it perfectly well as it is. Boing! said Zebedee (talk) 08:44, 8 November 2018 (UTC)[reply]
Oppose. The current parameter can handle multiple simultaneous spouses just fine. Boing! said Zebedee (talk) 08:46, 8 November 2018 (UTC)[reply]
Not really, its unclear whether the person was married to multiple people or just one at a time with a list. With a table it makes it more clear. Braveberet (talk) 08:50, 8 November 2018 (UTC)[reply]
Dates can be included, as has already been explained to you, and that makes it clear. Boing! said Zebedee (talk) 08:55, 8 November 2018 (UTC)[reply]
Boing! said Zebedee See Osama bin Laden. No dates, and I doubt you will find one on any page of any notable polygamous marriage. Braveberet (talk) 08:58, 8 November 2018 (UTC)[reply]
Well put some in then! Improve it yourself instead of just whining about prejudice and non-neutrality. Boing! said Zebedee (talk) 09:02, 8 November 2018 (UTC)[reply]
Do you have sources that tell us when they were married? If you want the information, you have to do the work. —Jeremy v^_^v Bori! 09:03, 8 November 2018 (UTC)[reply]
But this is the point, Wikipedians as a whole have made it unclear whether it is a monogamous or polygamous marriage, which is breaking
WP:NPOV. Providing inaccurate information is undesirable on any encyclopedia, especially one like Wikipedia which is accessed by millions of users every week. Thus, it would be benificial to the project to include a Table of Spouses which makes it clear whether it is a monogamous or polygamous marriage. Braveberet (talk) 09:07, 8 November 2018 (UTC)[reply
]
No, it's not, as has been repeatedly explained to you. Putting irrelevant information into a table gives it importance disproportionate to everything else on the page; the spouses parameter of the infobox does the same thing without the UNDUE concerns. —Jeremy v^_^v Bori! 09:10, 8 November 2018 (UTC)[reply]
So you've been told how the current parameter can be used to show polygamy in a perfectly reasonable way, but you're too lazy or unwilling to do it and instead just carry on whining about other people not doing it? So far you have made no constructive contributions to our project whatsoever, and unless you are prepared to put in some effort yourself then you're very unlikely to find much sympathy for your proposals. Boing! said Zebedee (talk) 09:19, 8 November 2018 (UTC)[reply]
And have any other editors contributed to it? The answer is "no" because there is an idea among Wikipedia that polygamy is unnotable, which is blatantly untrue, as many of you refuse to admit. Braveberet (talk) 09:53, 8 November 2018 (UTC)[reply]
You really have no clue about how Wikipedia works, have you? When you see something that nobody has done yet, you do it! Show some willingness to actually contribute rather than just criticizing others, and people might start to listen to you. Boing! said Zebedee (talk) 10:05, 8 November 2018 (UTC))[reply]
You prove my point that it would make it easier for editors, myself included, to fix mistakes on Wikipedia pages by introducing this template. Braveberet (talk) 10:06, 8 November 2018 (UTC)[reply]
Are you really so
incompetent that you are not capable of simply adding some dates, for example changing "Person's name" to "Person's name (19xx-20xx)" without having a new template made for you? Boing! said Zebedee (talk) 10:10, 8 November 2018 (UTC)[reply
]
Maybe if you weren't resorting to ad hominem attacks then you could understand my point. My point isn't that I want to be able to do something, it's that the community as a whole would benefit from this template, as it is more clear and legible which enables readers to understand the content more and not have to go through multiple sources to find their info. Braveberet (talk) 10:13, 8 November 2018 (UTC)[reply]
In what way would including the parallel dates in the current list of spouses mean the reader would have to "go through multiple sources to find their info"? Boing! said Zebedee (talk) 10:23, 8 November 2018 (UTC)[reply]
It would be mistakingly misleading, as with lists, you assume them to be in a hierachical order. It is not clear, with polygamous marriages, that it is not hierachical. Braveberet (talk) 10:27, 8 November 2018 (UTC)[reply]
I think you mean sequential rather than hierarchical, and without dates I agree. But I don't see why a table without dates would be any different, and you have not answered my question of why adding dates would not solve the problem. Boing! said Zebedee (talk) 10:50, 8 November 2018 (UTC)[reply]
And there is sequence too, as polygamous marriages rarely all start at the same time. As you won't even make an effort to try it yourself, I've added the dates to the infobox at Osama bin Laden based on the dates already in the article (which already made it clear they were polygamous marriages). Can you see how that makes the sequence of marriages and the polygamous overlaps clear? Boing! said Zebedee (talk) 11:10, 8 November 2018 (UTC)[reply]
  • Oppose. Having a table of spouses
    makes the polygamy an outsized aspect of the article. It's rare that a polygamist is notable solely for being one; nine times of ten there are other things that make them notable (bin Laden, for example, has a far stronger claim for notability for being an extremist that founded an international network; the number of wives he had is statistical noise compared to this). This is especially so for cultures, both past and present, where polygamy was common practice. —Jeremy v^_^v Bori! 09:10, 8 November 2018 (UTC)[reply
    ]
But shouldn't it be outlined that they are one? Instead of being entirely swept over? Braveberet (talk) 09:12, 8 November 2018 (UTC)[reply]
No. How many times are you going to keep hammering the same point ad nauseam that everyone else has rejected as absurd? —Jeremy v^_^v Bori! 09:15, 8 November 2018 (UTC)[reply
]
I'm only repeating the point because you are refusing to acknowledge it as a notable fact. Someone could infer from what you're saying that you don't think polygamy is a notable fact, which is statistically and empirically untrue. Braveberet (talk) 09:44, 8 November 2018 (UTC)[reply]
That would be because you're displaying a sort of bias here. As I mentioned above, monogamy has never been universal practice; several societies past and present allow for and practise polygamy. This does not make every
WP:SPI about this is the fact that I haven't the foggiest whose sockpuppet you actually are. —Jeremy v^_^v Bori! 21:53, 8 November 2018 (UTC)[reply
]
Showing the spouses in a table instead of a list doesn't indicate whether they are concurrent. You still need to add that info somehow if you want it, and there are existing ways to do that without giving undue attention with a table. Osama bin Laden#Personal life makes it clear there were concurrent spouses. Years in the infobox could also make it clear there. The documentation for the main person infobox at Template:Infobox person#Parameters already recommends to add years for all spouses. PrimeHunter (talk) 10:39, 8 November 2018 (UTC)[reply]
  • Oppose
    WP:IDIDNTHEARTHAT. Closure of this waste-of-time is overdue. Cabayi (talk) 10:25, 8 November 2018 (UTC)[reply
    ]

Oppose. I imagine the wiki would be better served to say "[[Polygamous]] relationship" in the infoboxes in question. It thus wouldn't "sweep over" the concept. Discuss-Dubious (t/c) 17:30, 8 November 2018 (UTC)[reply]

Oppose This is one of those where the nuances are better off being explained in prose in the body of the article. MarnetteD|Talk 17:49, 8 November 2018 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Lint Error repairs in respect of minor italicisation fixes..

I was wanting to work on resolving some of the missing end tag issues here: https://en.wikipedia.org/wiki/Special:LintErrors/missing-end-tag?namespace=0

and had made a batch of repairs here : https://en.wikipedia.org/w/index.php?limit=50&title=Special%3AContributions&contribs=user&target=ShakespeareFan00&namespace=0&tagfilter=&start=&end=

However, most of these are minor italicisation fixes, and thus before continuing I'd like a wider community consensus that a mass sweep of this kind is both acceptable and desirable. ShakespeareFan00 (talk) 11:51, 6 November 2018 (UTC)[reply]

Side disscusion about the need for a Bot flag Wikipedia:Bots/Noticeboard#Lint error repairs..

Approving a bot request that would create episode redirects

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

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

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

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

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)[reply]
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)[reply
]
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)[reply]
I understand your arguments, but could you explain what harm a redirect will have? It has one purpose, to point to the entry of a list. The "bot" does not have any task of "deciding" if an article should be created or a redirect - It only creates a redirect to a previously created list. I'm really not seeing why this would be an issue. Also, to comment on doesn't mean that such a name is widespread enough that anyone outside of a very narrow number of people would be searching for/linking to that name itself - the name does not need to be widespread enough or even known by readers. Look at a page such as
some were redirects) and some which aren't. In this case, it is enough if even only the editor who added the information to the article knows the name. That editor could then link to these episodes and let other readers enjoy a seamless experience (compare that to the episodes which aren't linked and require much more effort for the reader to reach the point where their page is). --Gonnym (talk) 12:56, 9 November 2018 (UTC)[reply
]
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)[reply]
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)[reply]
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)[reply]

Linking to an edit

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

@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)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=868523636"