Latest comment: 5 years ago155 comments69 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
Summary --> There is a strong consensus to Ydisband the Mediation Committee in entirety. And, all processes and components thereof, shall be marked as historical.
Details -->
The broader theme of the comprehensive analysis by the OP, (Beeblebrox) has been heavily supported by numerous participants.
There is a broad consensus that MEDCOM is akin to a toothless process that hasn't served any practical purpose in the recent spans and that the process of RFCs are far superior and useful, in the locus of resolving content-disputes.
The opposition camp contains some interesting take(s) on the issue but I am afraid that they have failed to turn the tide in their favor, by a count of heads as well as by a weighing of arguments (and corresponding rebuttals).
RMClenon, TransporterMan, Coffman et al have argued for MedCom to be sustained in light of the potential of the process to resolve complicated content disputes (without delving into conduct) but the rebuttals are good-enough.(vide RGloucester, Swarm, Boing et al) That the inner-machinery of the project is heavily non-transparent and the working is overtly bureaucratic compounds the dismal scenario.
A few folks (Blackmane, AGK, Steven Crossin et al) have supported ideas of a reform to increase it's effectiveness but they consist of a diverse bunch of proposals, which has failed to progress anywhere past the brainstorming session(s) and there is accordingly, an absence of consensus on that locus.There is also a lack of consensus as to merging this to DRN, (despite no rebuttal).
Interested people may pursue such ideas separately and present to the community, for an evaluation.
Isaacl's comment at the end of the Extended Discussion section, might be a worthy read:-)
Should the Mediation Committee be closed and marked as historical? 18:11, 10 October 2018 (UTC)
This RFC stems from a previous discussion, now viewable here. The discusion was not overly long and did not result in any real conclusions, so it seems a formal RFC is advisable to determine consensus on the subject.
I would like to be clear from the outset that this is not intended to attack or disparage the users who have dedicated their time and effort to this project, but rather to ask if the project itself is actually accomplishing anything of real value to Wikipedia overall or if it has become redundant to the point where it should be closed.
Rationale:
Medcom accepts very few cases. The last case accepted was just over a year ago.
This is mainly because “lower” forms of dispute resolution are required first, similar to ArbCom proceedings.
The other reason cases may not be accepted is that unlike Arbitration cases, Medcom cases require that all parties agree to participate and the decisions reached are not binding.
Of the few cases that are accepted, very few succeed at resolving the issue, the last case marked successful was over two years ago.
The process, instead of complementing other dispute resolution procedures, appears to have become redundant to them.
Content disputes, which are all that Medcom handles (as opposed to behavioral issues) are mostly handled by talk page discussions, content RFCs, or WP:DRN
Interest in being on the committee is very low. For the last few years its chairperson has been doing pretty much all the work, which consists almost entirely of rejecting cases as premature. While other, nearly inactive users have indicated their willingness to return to help if a case were to be accepted, it is essentially a one-man project and has been for some time.
It is worth noting that the chairperson’s term expired some eight months ago but there apparently been no inclination whatsoever to either re-elect or replace them. In fact, it looks like the chair is the only member who has commented on the project’s main talk page in the last three years.
Given the previous points, it seems undesirable to have a process where, in the rare case that it actually takes on a case that case is decided either by the same person every time or by users who are mostly inactive on Wikipedia.
So, we’ve got a process that by it’s own records, hasn’t resolved any issues in a few years, hasn’t been used at all so far this year, and whose internal processes are stagnated and handled almost exclusively by one user.
For all of these reasons, and again with the upmost respect for those that have striven to keep this project alive, I believe that it is time to admit that this process is almost entirely unused and redundant and to mark it as historical and shut down its mailing list. Beeblebrox (talk) 17:50, 10 October 2018 (UTC)Reply
MedCom discussion
Support Doesn't appear to be active, other dispute resolution noticeboards seem to work better. SemiHypercube✎ 00:38, 11 October 2018 (UTC)Reply
Support pet project of a small number of users that doesn't really do anything anymore. It gets a fair amount of requests, but they are never heard, and the community has pretty much moved past centralized content dispute resolution in this manner, preferring talk page RfCs and if need be, an RfC on a policy page or noticeboard. TonyBallioni (talk) 00:44, 11 October 2018 (UTC)Reply
Support – No longer a useful process...much like WP:RFC/U was, back when it was abolished. Other forms of dispute resolution have been used in its place for years, with greater effect. No reason to retain the air of community bureaucracy at a process that is largely maintained by one person. In the end, people have voted with their feet. Abolish it. RGloucester — ☎ 00:45, 11 October 2018 (UTC)Reply
Support - seems to have no purpose at all these days. Home Lander (talk) 01:08, 11 October 2018 (UTC)Reply
Support Inactive, useless. TonyBalloni sums it up nicely. ThePlatypusofDoom(talk) 01:46, 11 October 2018 (UTC)Reply
Support per above. --Rschen7754 02:17, 11 October 2018 (UTC)Reply
Oppose the abolishment of all the forums for editor review (apart from RfA) was not a benefit to the encyclopedia-building project, and I don't think abolishing MedCom will be either. It will be far more work to resurrect this in the future than to let it linger idle for now. Some forum that is the clear forum-of-last-resort for content disputes is needed; I don't see DRN or ARBCOM as filling that role. MedCom should have some type of reform to be more relevant, but doing it at the barrel of a gun won't work. power~enwiki (π, ν) 03:11, 11 October 2018 (UTC)Reply
MedCom isn’t a forum of last resort. We have no such thing for content disputes and never have. TonyBallioni (talk) 03:29, 11 October 2018 (UTC)Reply
It actually has no authority whatsoever, being entirely voluntary and non-binding. I also object to the characterization of this being the “barrel of a gun” as what it really is is just admitting that medcom doesn’t do anyhting anymore so there’s no point in directing users to it. There already isn’t an actual committee. Beeblebrox (talk) 06:14, 11 October 2018 (UTC)Reply
Well, it certainly needs to either be more willing to do *something*, or actually be a forum of last resort. I plan to stay an oppose !vote, but without some viable reform proposal this will certainly be marked historical. There's a good chance it won't do anything for the next year+ even if it isn't marked historical. power~enwiki (π, ν) 15:29, 11 October 2018 (UTC)Reply
If it gets to the point that the talk page, RFCs, RSN, DRN, &c., cannot solve a content dispute, that almost certainly means that there are conduct issues. That's the essential problem with the structure of this thing...it isn't fit for purpose, and so it doesn't do anything. In the end, though, its excessively bureaucratic proceedings are a relic of another era, and I personally am happy to condemn them to history. RGloucester — ☎ 15:39, 11 October 2018 (UTC)Reply
@Power~enwiki: Which other now-abolished forums for editor review are you referring to? 142.160.89.97 (talk) 07:21, 16 October 2018 (UTC)Reply
Support It is already dead, so may as well save the time of all the people requesting resolution through it. They are better off starting a WP:RFC to determine consensus which is how content is settled per policy. If lower forms of resolution have not resolved the dispute, it is extremely unlikely that a completely voluntary non-binding and toothless process will do either, and this is reflected in the reality of the situation. Galobtter (pingó mió) 07:17, 11 October 2018 (UTC)Reply
Support per above rationale. Inactive, and preference for talk pages and RfCs. Better to redirect attention of volunteers elsewhere than have a semi-morubund venue. --Tom (LT) (talk) 07:37, 11 October 2018 (UTC)Reply
Oppose I do not see any clear benefits of closing MedCom down now. At least the proposers have not specified any. In addition, {{historical}} template is used to mark pages or processes that have become completely inactive and for a long time. These is not true in the case of MedCom - there is still some activity. So, this is not an appropriate proposal. If somebody wants to simply close it down, there should be a wider RFC, not a small discussion on this board. Ruslik_Zero 09:44, 11 October 2018 (UTC)Reply
Uhh, where would a wider RFC be than a discussion at the pump advertised at WP:CENT as this discussion is? Galobtter (pingó mió) 09:47, 11 October 2018 (UTC)Reply
Yeah, I find this comment very bizarre. You can disagree with the reasoning I presented but there is nothing inappropriate about it, it is widley advertised, and if somebody just shut this discussion down now that would be wildly inappropriate. Beeblebrox (talk) 18:35, 11 October 2018 (UTC)Reply
Neutral - I don't think the Mediation Committee has ever really played a very important role. It's non-binding, and it adds a layer of bureaucracy to dispute resolution that most editors don't want to deal with. Nevertheless, a part of me wants to see it reformed and modernized so that it can serve some sort of purpose. But at this point, it may not be feasible. Kurtis(talk) 09:50, 11 October 2018 (UTC)Reply
Oppose — If MedCom is closed WP will have no DR mechanism to mediate complex disputes. DRN is specifically designed to handle disputes which can be resolved within 14 days and has an automated case-closing mechanisms for cases which do not fit that mold. Moreover, anyone can be a DRN volunteer. Current volunteers generally discourage newcomers to Wikipedia from volunteering, but they can do so if they care to. (Third Opinion is the best training ground for newcomer volunteers.) Cases which are accepted at MedCom, and there have not been any recently, it is true, often take weeks to months to resolve with multiple different specific issues being considered. MedCom has never taken many cases and DRN has, as it should, taken away the simple cases that might have previously been handled at MedCom, but MedCom still plays a necessary part, if only rarely. — TransporterMan (TALK) 12:17, 11 October 2018 (UTC) (Chairperson, Mediation Committee)Reply
Counterproposal. Retain but improve MedCom by making it the actual last resort. Make it mandatory to participate at MedCom by making a good faith effort to resolve a dispute if the case is accepted for mediation by the Committee. The requirement would not require a party to actually resolve the dispute, but only to participate in mediation and make a bona fide good effort to do so. Parties who refuse to participate, or who participate and fail to make a good faith effort, should be barred from continuing to participate in the dispute and from editing the article in question in a manner related to the dispute (this is equivalent to the same requirement in real world court-ordered pre-trial mediation: you've got to show up and make an effort to resolve the case). The mechanics of this will need to be worked out, members of the Committee who are administrators could impose the limited topic ban or the Committee could, in the alternative, make a recommendation to ANI. Either way, the community would have to trust the Committee to prevent this from becoming a means of gaming disputes. Cases should be required to at least file the case for consideration at Third Opinion or DRN or RFC before coming to MedCom, so as to weed out the simple cases. Respectfully submitted, TransporterMan (TALK) 12:17, 11 October 2018 (UTC)Reply
I would recommend starting a separate RFC for a replacement venue of any sort, if you think Wikipedia should have one. --Izno (talk) 14:09, 11 October 2018 (UTC)Reply
Sorry to break this to you, but Wikipedia currently has no dispute resolution mechanisms to mediate complex disputes. MedCom doesn’t exist already. Beeblebrox is just asking we admit that and stop wasting people’s time by sending them through a process that doesn’t actually exist. TonyBallioni (talk) 12:21, 11 October 2018 (UTC)Reply
I cold not be more opposed to yor counter proposal. No way no day can we give Medcom “teeth”. Currently it’s basically you, but in theory there are three other mediators. None of you were elected or appointed by the community so there is basis for any sort of real authority. (for those of you who are unaware, Medcom selects it’s own members, and has it’s own mailing list where they discuss their inner workings. It’s very much a closed shop) Beeblebrox (talk) 18:50, 11 October 2018 (UTC)Reply
What if a precondition of the counter-proposal getting acceptance was all current (and future) members have to stand for election in the same manner as ArbCom members do? Additionally, how about actually giving MedCom a couple of dentures to make binding content-related decisions (ie: "Source X cannot be used in this context unless wider community consensus agrees to it" or "The reliability of that source is currently disputed so cannot be used until {condition}") DaxBane 10:09, 18 October 2018 (UTC)Reply
Support - There are too many backstage venues as it stands. This one has atrophied. Carrite (talk) 12:26, 11 October 2018 (UTC)Reply
Support per the proposer. It seems fairly clear that the WP:RFC process is superior for content disputes; where it is inhibited is when conduct becomes an issue, but that's a separate set of processes anyway. --Izno (talk) 14:09, 11 October 2018 (UTC)Reply
Support As it appears largely redundant, and has pretty much shut down on its own already, it seems smart to officially 'close' the venue. — Insertcleverphrasehere(or here) 14:14, 11 October 2018 (UTC)Reply
Zaphod sums it up well, and honestly Power~enwiki lays it out well enough. I've always liked MedCom — it aims to fill a much-needed space for content disputes — and in my starrier-eyed days of the very late aughts, once thought it'd be nice to serve. Still, it's not filling that space because nobody uses it. I think the project would be better if MedCom were a productive place of dispute resolution, but it's not. As such, keeping it "active" and as an "option" is probably doing more harm than good, interrupting other resolution methods and drawing out disputes needlessly. There are good things nobody uses, and after trying and trying, there's no shame or harm in admitting it's not working. ~ Amory(u • t • c) 15:45, 11 October 2018 (UTC)Reply
This proposal is a remarkable coincidence. I began discussing the underuse of mediation with a couple of my committee colleagues last week.
As noted by the other commenters (both supporting and opposing), the notion of mediation is a good one. We would all like for it to be working and achieving results. However, it just isn't functioning as a process. In the end, accepted requests and successful cases – ie frequency of resolving disputes – is what matters.
I would propose that we provide an opportunity at this stage to propose updates to the process for 2018 and onwards. As I say, some early work has already been done on this question so it should not be too long in the works. I hesitate to call those updates a 'reform', because as a community we tend to prefer incremental improvements. Nevertheless, some of the proposals under development could quite easily turn the process into an effective one. I suppose they are reformatory in nature.
For what it's worth, the crux of the proposals is to bring mediation into the dispute resolution process as an effective, functioning noticeboard or process. At the moment, it sits apart from the other dispute resolution venues – ignored and ignorable. I propose reform to this discussion – that we give updating the process a try. We strip back some of the vestigial bureaucracy. We make it an actual, go-to process that actively solves advanced content disputes. In my view, there is a gap in our community for such a thing. And in the existing mediation process, we have a solid base (nearly 2 decades of precedent and experience) and existing material to work with (the process is recognised in the ratified Arbitration policy etc.). If the consensus here is to reform and it does not work, I would propose closing it myself. AGK ■ 17:31, 11 October 2018 (UTC)Reply
Actual practice suggests we do not need this form of mediation to resolve disputes. If such a process were needed, MedCom would not've fallen away as it did. There are better venues for content dispute resolution, and behavioural problems are dealt with in the usual channels. I simply do not see the benefit of continuing to emphasise a process that has died a natural death...it 'died' for a reason, and for those reasons I am opposed to reform. If such proposals were to create an entirely new body, from the ground up, and then seek community consensus for establishment, that'd be another thing. But I do not see the benefit in launching such a proposal under the auspices of the existing 'MedCom' mandate, which has clearly run its course. RGloucester — ☎ 17:42, 11 October 2018 (UTC)Reply
That is a rather brazen – and, in my view, incorrect – view of dispute resolution. All around the community there are content disputes that do not get solved until one editor grows frustrated enough to lash out. At that stage, they are blocked or receive a sanction in enforcement of general sanctions. We then call that consensus by default, regard the dispute resolved, and carry on with a deficient article. I do not see the "actual practice" that led us here as right, and I am proposing we update the process to tackle the wider problem of a serious dearth in effective solutions for protracted disputes. Or perhaps we could just redirect the whole thing to some essay and continue decentralising the facilities for editors in dispute to receive guidance from experienced editors; certainly that is the way things more generally are heading.
Disputes on the project today, as the encyclopedia matures and its expansion plateaus, are increasingly about obscure or intractable issues. Closing down processes that we, as a community, have designed to steer those disputes back on track will do nothing to stop the car driving off the cliff. Creating a mediation process is one case where the project elders probably had it right. We just need to update it. AGK ■ 18:00, 11 October 2018 (UTC)Reply
The biggest problem with what you're proposing is that it really has nothing to do with MedCom...it's a proposal for an entirely new process, replacing the existing MedCom with something different. In as much as this is what you propose, I cannot accept the use of the existing MedCom policy to create an entirely new process. I'd rather this be marked historical, as it is indeed historical, and defunct, and something new prepared for review by the community. What you propose, I think, is a circumvention of community consensus. RGloucester — ☎ 18:23, 11 October 2018 (UTC)Reply
Support purely on grounds of inactivity, I think it's entirely possible for a process like MedCom to play a role in our dispute resolution processes. Activity has consisted of the chairperson rejecting requests for some time and it doesn't seem to be actually resolving disputes. Given that we are basically misleading people into thinking it's a working process if we don't tag it as inactive/historical. If a significant number of active editors are willing to commit to reviving the project then I'd be happy to change this. Hut 8.5 18:17, 11 October 2018 (UTC)Reply
Neutral Like AGK, I wish this were more active. I say this as someone who has not participated, primarily because I believe that good mediation requires a certain skill level which typically require some training and I haven't had formal training. There are many people who have had such training and frankly surprised we haven't attracted more of them. If I were a mediation professional, I might see Wikipedia as a great place to practice skills. While that hasn't happened, perhaps it will. We've got a small national conversation about civility in progress, and, ever the optimist, perhaps that will spark more interest in mediation and some of those people will show up here and offer to help. There might be some value in having an existing structure rather than having to reinvent from scratch. Arguably, if this is marked as historical, it doesn't mean it goes away so that goal could be accomplished even if this is marked as historical, but I prefer something a little softer. Perhaps a message at the top of the page that says this projectprocess is currently inactive but could be reinvigorated if enough participants show interest.--S Philbrick(Talk) 18:27, 11 October 2018 (UTC)Reply
To note, MedCom is not a project...it is actually a policy-based process specified by Wikipedia:Mediation Committee/Policy. The remaining one active member of the Committee has not even been able to follow this policy, in that he has continued serving despite the end of his term. I really find it hard to accept that we have a policy that literally no one follows or uses...is this not contradicting the very nature of Wikipedia policy itself? RGloucester — ☎ 18:31, 11 October 2018 (UTC)Reply
I thought this point was insignificant to the discussion, but as it keeps coming up – the coordinator/chair would be reconfirmed by email. They just do not announce it or make a song and dance. AGK ■ 18:57, 11 October 2018 (UTC)Reply
I didn’t mention the internal processes used because as you say it has no bearing on the core reasons for this proposal, but if we were to do that I think the community would be rather surprised. I’m not aware of any other group who determine their own membership devoid of community input and decide who their chair is in an off-wiki discussion on their own privileged mailing list. Beeblebrox (talk) 19:06, 11 October 2018 (UTC)Reply
Oppose This is a truly silly proposal. This proposal does not benefit Wikipedia in the least, and is a waste. Just because something is not that active right now, does not mean it won't reactivate in the future. We just saw that with the Signpost, and the needlessness of this RfC is plain - you don't like that someone is over there fielding complaints, etc., find something useful to do with your time, and focus on writing articles, not complaining about other people offering to mediate disputes and respond to complaints in a slightly structured forum. Alanscottwalker (talk) 18:39, 11 October 2018 (UTC) As it is now argued below that oppose comments are not supportive, there must be some confusion, being supportive of editors who want to provide mediation for others who want it is being supportive of MEDCOM, and it is the right thing to do. -- Alanscottwalker (talk) 12:35, 12 October 2018 (UTC)Reply
Keeping MEDCOM open misleads people into thinking it actually resolves disputes and wastes their time filing out a request for mediation only to get it rejected. Galobtter (pingó mió) 18:52, 11 October 2018 (UTC)Reply
What nonsense. Never in the history of problem solving has having to state the problem to someone else formally, and the parties involved, ever been a hindrance to problem solving, the opposite is the case. Alanscottwalker (talk) 19:56, 11 October 2018 (UTC)Reply
A straw man if I’ve ever seen one. Unless you can point out where anyone is “complaining about people other people offering to mediate disputes“ as that is not anywhere in the rationale at the top. This is only about admitting the obvious, this process may have had a place once but it has been rendered obsolete and redundant by a cultural shift towards other forms of dispute resolution. This isn’t personal, so I don’t appreciate you trying to make it so. Beeblebrox (talk) 18:59, 11 October 2018 (UTC)Reply
What? Personal? I said nothing personal. And you don't need to repeat your already rejected argument that there are too many ways for people to go about solving problems. Alanscottwalker (talk) 20:13, 11 October 2018 (UTC)Reply
WP:BAG. I think it is time we step back and let other community members independently assess the original proposal, the counter-proposals, and the limited further discussion. Badgering is causing the signal-to-noise ratio of this thread to plummet. AGK ■ 19:13, 11 October 2018 (UTC)Reply
I hear you, but when some people are suggesting this be closed as innapropriate and others are trying to personalize the dispute instead of responding to the actual issues under discussion it can be hard to restrain oneself. Beeblebrox (talk) 20:12, 11 October 2018 (UTC)Reply
Well, this proposal is complaining about people offering to mediate disputes, so calling a spade, a spade is just appropriate. The proposal's reason is, 'we don't like the way you mediate.' Alanscottwalker (talk) 20:46, 11 October 2018 (UTC)Reply
Every word of what you wrote is wrong. Beeblebrox (talk) 21:16, 11 October 2018 (UTC)Reply
Every word is not only right, it's evident. Alanscottwalker (talk) 22:01, 11 October 2018 (UTC)Reply
Again, senseless, 'there are too many ways to go about addressing issues in somewhat different formats' is not even a coherent critique. Alanscottwalker (talk) 20:06, 11 October 2018 (UTC)Reply
At the time of the last discussion about this at VP Policy, about a month ago, at least 3-4 other current active members of the Committee either indicated in that discussion or on the Commitee's mailing list that they are, indeed, still active. It's not correct that I'm the sole surviving member. Moreover, past members who are inactive are still members and I wouldn't hesitate to poll them should our active member list be depleted and a mediator needed. - TransporterMan (TALK) 19:27, 11 October 2018 (UTC)Reply
Support as per everyone above, No point keeping and sending editors to something that's pretty much inactive, There are other venues which are quicker and simpler. –Davey2010Talk 20:08, 11 October 2018 (UTC)Reply
Neutral Would be nice to see it given a place but without a significant review into how Dispute Resolution works and the Mediation Policy it is not sustainable. In its current state, it's not worth keeping. RhinosF1 (talk) 20:17, 11 October 2018 (UTC)Reply
Seems like that would be the best way actually. RhinosF1 (talk) 20:25, 11 October 2018 (UTC)Reply
support, largely as stated: redundant to other forums that produce better results. Guy (Help!) 21:10, 11 October 2018 (UTC)Reply
Support per nom. Effectively defunct. There should be prominent pointers to other dispute resolution forums like DRN though. ---- Patar knight - chat/contributions 00:15, 12 October 2018 (UTC)Reply
Support per nomination and Carrite (too many backstage venues), and largely redundant. . Kudpung กุดผึ้ง (talk) 02:47, 12 October 2018 (UTC)Reply
Oppose: I'm not sure if I knew about the Committee existence. It sounds like it could be something useful for mediating complex disputes. Even if the case log is not very active now, it does not mean that it may not pick up in the future. K.e.coffman (talk) 05:32, 12 October 2018 (UTC)Reply
Support Largely ineffective, generally redundant to many other binding processes that we have. Closure is overdue. –Ammarpad (talk) 05:54, 12 October 2018 (UTC)Reply
Oppose per TransporterMan. Process is important, especially when it comes to complicated disputes. Having an outlet for such that is less looming than the arbitration committee benefits the community, even if it is not used very often. As long as their are volunteers willing to run it, we should allow it to stand.— Godsy (TALKCONT) 08:43, 12 October 2018 (UTC)Reply
Support per the nominator's rationale; I find the oppose reasoning unconvincing. Enterprisey (talk!) 09:05, 12 October 2018 (UTC)Reply
Support also per nom: the project has clearly become moribund, and, with respect, to the oppose comments, they mostly consist of IDLI arguments. Which, of course, are not supportive arguments.——SerialNumber54129 09:51, 12 October 2018 (UTC)Reply
Support I cannot find fault with anything in the nomination statement (content or form :), and as mentioned above, there are actual downsides to stringing along a factually dead component of the mediation meta-process. Pruning deprecated components is not structural deletionism, it's necessary basic housework. --Elmidae (talk · contribs) 12:41, 12 October 2018 (UTC)Reply
Oppose closing it down wholesale. Better to reform it into something useful than to shut it down entirely. feminist (talk) 13:27, 12 October 2018 (UTC)Reply
Support: Medcom is unnecessary bureaucracy, an obscure and confusing part of a complex set of intricately linked dispute resolution processes. It's barely active and it doesn't seem to work. Certainly most users would not know when to turn to it. Dispute resolution reform is necessary and cutting out processes that have died a natural death should be part of that reform. — Bilorv(c)(talk) 18:13, 12 October 2018 (UTC)Reply
The simple answer to the neutral question asked in this request is no; the Mediation Committee should not be closed and marked as historical. Unfortunately both concepts, simple and neutral, end with that.--John Cline (talk) 20:05, 12 October 2018 (UTC)Reply
Support this is mostly just acknowledging the current state of things. If people want some kind of binding arbitration/mediation that is actually useful, they should start an RfC proposing that rather than keeping this on life support or standing by while another inch of dust accumulates. {{u|zchrykng}} {T|C} 00:39, 13 October 2018 (UTC)Reply
Support per above. Opposes are unconvincing. -FASTILY 02:41, 14 October 2018 (UTC)Reply
Weakish support - I opened the previous VPP thread, but still haven't come to a solid conclusion about the best way forward. I get the point some people have made there are opportunities for reform, and that it would be best to work towards making it useful rather than shutting it down. However, I'm not convinced that those reform efforts wouldn't be better suited for DRN, incorporating some flexibility to make it cover the cases that would otherwise go to RFM. I also appreciate the idea that some aspects of RFM seem a bit anachronistic in wikiculture (like the committee selected by themselves). There is indeed a value in doing it that way, but I think that arbcom has shown that we can have decent results with community-appointed members. Robert McClenon made some good points in the previous discussion about the relationship between DRN and RFM and what characterizes each of them, so I wouldn't want to immediately say that DRN should absorb RFM, but I do think that if RFM is closed, the very next step should be a thorough evaluation of DRN to see how it could, as the sole forum of its kind, be made most useful (whether by framing it as an eventual expansion to include RFM-type cases or just as an analysis and reform process in its own right. Also, pinging Robert McClenon and TenOfAllTrades, both active in the previous discussion but haven't commented here yet. — Rhododendritestalk \\ 15:06, 14 October 2018 (UTC)Reply
Oppose – I opposed the idea of shutting down the MedCom the last time it was suggested, even though the MedCom has not had a case in more than a year. As both I and User:TransporterMan have said, DRN is a lightweight process for disputes that can be resolved by discussion in one to two weeks, or at most three to four weeks. DRN has never been meant to be a heavyweight process for disputes that may drag on for months. I understand that the proponent is proposing in good faith to shut down a process that hasn’t been used recently, but it is a process (not a project) that doesn’t have a substitute. There are two problems currently with MedCom, but the two problems tend to offset each other. First, there is a shortage of mediators, but, second, there are very few cases for which formal mediation is in order. My own guess is that if, while this RFC is still running, a case is accepted by MedCom, MedCom will find a volunteer mediator to handle the case.
It now appears inevitable that MedCom will be shut down. The reasoned Oppose !votes are being shouted down. This raises the question is what will happen the next time there is a long complicated content dispute. What will probably happen is that we will lose two respected editors. It isn’t just a matter of taking the acronym RFM out of a list and the procedure MedCom out of a list of processes. It would be like disbanding the volunteer fire department because there hasn’t been a fire recently. Not every content dispute can be contained by DRN and specialty noticeboards. If we have a case that needs real mediation, at present, we can find a mediator. If we cross that entry out of the list, then we just throw it to WP:ANI, which is at best a damage-containment effort, or to ArbCom. What will happen the next time that there is a content dispute for which formal mediation is appropriate is that, first, it will go to DRN. Handling the dispute will burn out the DRN volunteer moderator who tries to handle the case without actual experience in conflict resolution, and they will likely not only leave DRN but leave Wikipedia. The conduct issues that had been contained while the content was being addressed will then re-emerge, and there will be multiple trips to WP:ANI and possibly a trip to ArbCom, and eventually topic-bans will be imposed, and in all likelihood one of the two editors, probably a respected content contributor, will be sufficiently embittered by the inability of the community to resolve the content dispute that they will likely leave Wikipedia.
The Support side has not considered the future adverse consequences of doing away with MedCom as the fall-back last resort for content disputes. Just because it hasn’t been used recently doesn’t mean that it isn’t needed. There hasn’t been a fire. That doesn’t mean that there won’t be a fire.
Since we are now almost certain to mark the MedCom as historical, the best way to recover from this mistake will be to create something having a similar function and mission. What we ought to be doing, rather than looking for a procedure to take out of a list of procedures, is trying to improve our dispute resolution procedures. Just getting rid of one that hasn’t been used recently is very much the wrong answer. It would have been better to propose improvements to DRN ‘’before’’ proposing to get rid of MedCom, but I don’t see any real hope now. Robert McClenon (talk) 01:59, 15 October 2018 (UTC)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 WP:ANI and Arbitration Enforcement, operate on the recognition that the offending editor who is preventing the content issue from being resolved can be sanctioned long enough to resolve the content dispute. There never was a black-and-white distinction, except for vandals, trolls, and flamers. It is still true that throwing away a content dispute resolution process is unwise. Robert McClenon (talk) 02:32, 16 October 2018 (UTC)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 WP:RFCU or WP:WQA, and frankly it's amazing that it still exists. This concept, where you have some very "complex" dispute and the only viable solution is for a mediator to walk both parties through it ad infinitum until they reach an understanding is, quite simply, unrealistic, and to present it as some sort of "last resort" DR measure that we might need someday is a joke. Editors are expected to competently pursue DR and seek and abide by consensuses. The community no longer tolerates editors who are obstinate and obtuse, who can't or won't communicate effectively to resolve disputes, who won't listen, or who won't let it go when they can't secure a consensus, and who will drag out disputes past a reasonable point. When these situations arise, we're not relying on this bureaucratic dinosaur to walk them through their dispute and hope everyone will be agreeable, even though they're spending weeks and weeks of their life trying to come to an understanding in an online argument. We're investigating the underlying behavior and sanctioning or warning users, or implementing page restrictions, or going to ArbCom for binding solutions, so that actual collaborative, good faith editors do not get burned out and can continue contributing. That's why MedCom is an obsolete relic, not because we haven't had any "complex disputes" lately. Also, this whole thing is just out of touch with the community. It's purported to be this formal, serious thing, the be-all and end-all of dispute resolution, with legitimacy stemming from Jimbo himself, but in reality it's the pet project of this closed club of a small handful of users (or more realistically, one user), who decide from within what their membership is, and what their rules are, and when to take a case (read: never) and really don't contribute anything to DR. It's totally out of whack. The "chair" of MedCom's comments above just goes to show how out of touch with DR and the community this whole thing has become. Rather than actually demonstrating how and why MedCom has done and can still do good for the community, his case for keeping it is that we somehow 'need' his committee, because they don't accept newcomers into their ranks, or because they will accept disputes that drag on for months while DRN won't (I wonder why), or because they "mediate". I've been involved in DR pretty much since I became active here, and this kind of mediation-based approach to DR has never been particularly effective anyway, and keeping around a self-important group of 'mediators' who have long-since outlived their usefulness to the project is just silly. I thank those who have invested time in this project, but it's time to pull the plug. Swarm talk 00:26, 16 October 2018 (UTC)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 not binding. On Wikipedia, there are only a very, very few things that that are binding, so the fact that mediation recognizes that is the only choice mediation has. -- Alanscottwalker (talk) 09:24, 16 October 2018 (UTC)Reply
That link to WP:CCC simply says that consensus can change. At the time a consensus is reached, it is binding until a new consensus some time later replaces it - and in the meantime, editors are bound to abide by it and can be (and regularly are) sanctioned for failing to follow it. In fact, with the few exceptions at WP:CONEXCEPT, consensus is ultimately the only binding process the community has at its disposal. Oh, and I'll add that the inability of MedCom to make binding decisions is nothing to do with WP:CONEXCEPT. Boing! said Zebedee (talk) 09:37, 16 October 2018 (UTC)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 WP:ARBPOL#Scope and responsibilities, or the Arbitration archives, or Wikipedia:General sanctions#Arbitration Committee-authorised sanctions, or the Wikipedia:Arbitration enforcement log. Arbcom actions and Arbcom-empowered admin actions resolve disputes exceedingly effectively, long before they're ripe for Medcom, which has between a 2% and 0% success rate even as a formal DR body. Medcom already doesn't fit into the DR process. Also, you're claiming that it's not Medcom's fault that they claim to be the "last line of DR", and it's just a matter of policy. Not even getting into the fact that Medcom policy isn't determined by the community, but Medcom themselves (who the community, stunningly, does not have jurisdiction over), nowhere in Medcom policy does it say or imply that it is the last stage of dispute resolution. Swarm talk 04:16, 18 October 2018 (UTC)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 CONSENSUS ("ArbCom does not settle content disputes or change policy") that arbitration is about admin action, not content. Arbcom does not handle content (is I think universally agreed) and Arbcom's SCOPE certainly does not say it should handle content, rather it says it regulates Administrative action, prescribes Administrative action, and takes Administrative action (generally, by reversal of administrative action but also imposing bans and the like, removing Admin permissions, etc) - that is all that is meant by "all and only about admin action." So, no, it's not me, being objectively wrong. As for the rest, MedCom is approved Content DR process (the last) by WP:CONSENSUS policy ("For disputes involving many parties or complicated issues or which otherwise need more time for resolution than is allowed at DRN, the Mediation Committee (MedCom) is staffed by members with proven mediation ability."). Alanscottwalker (talk) 18:55, 18 October 2018 (UTC)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. — xaosfluxTalk 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. Beeblebrox (talk) 22:18, 2 November 2018 (UTC)Reply
Support, no successfully closed cases in years? C'mon, folks, what's dead is dead. If anyone truly appreciates what Medcom did and believes it served a valuable niche, the solution isn't to prop up the corpse with wires and duct tape, the solution is to replace it with something better and more efficient that will actually survive. Andrew Lenahan - Starblind 19:45, 30 October 2018 (UTC)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. @AGK:'s thoughts (Hi there!) stands out for me (I agree with some aspects of those that are supporting closure, noting that in most cases, MedCom is underused, somewhat bureaucratic and outdated. The concept of binding content dispute resolution has been discussed ad nauseaum over the years (WP:BCD being an example), but I think it's unlikely to ever have traction except in limited circumstances (think [[Wikipedia:WikiProject_Ireland_Collaboration/Poll_on_Ireland_article_names|Ireland Article Names), so discussion about making MedCom binding I think is not worth pursuing.
DRN was proposed by me way back when to deal with lightweight, simplex disputes in a rapid manner. The motivating ideas behind it were:
1. Have more eyes on a dispute, by creating a many-to-many relationship between DR volunteers and participants, possibly reducing burnout of volunteers
2. Resolve most disputes quickly, as trends over time showed that the longer a dispute went on for, the less likely it was to be resolved successfully (this wasn't universal, however). The data is quite old, but there's a survey done in 2012 with some data too (WP:DRSURVEY).
Historically, there was a conversation between those that ran DRN and those on MedCom about a conversation on referring disputes to MedCom that would benefit from mediation, to MedCom. I do believe that in some instances, mediation may be merited. I've mediated some disputes in the past which had several issues to work through, and sometimes they need to be worked through methodically. I would argue that the universal agreement to mediation is a rule that should be abolished however - if there is a case where there are 6 participants, the case has been brought in good faith and one person opposes, then the case should proceed in my belief - as one presently can just oppose and game the process. Perhaps a conversation on what happens to that person if they oppose should be had, but I think it's a necessary conversation.
The other factor in my argument to keeping MedCom open (but reform) is that MedCom is the only content dispute resolution process where discussions are privileged. This is designed to facilitate open discussion, because good faith conversations (even if at times, heated) cannot be used in ArbCom proceedings. No other forum affords this.
I think MedCom also needs new blood. Maybe the criteria for membership should be altered to make it less of a vote of existing members, and more based on dispute resolution experience. I'm not sure, but the nomination process seems a little antiquated. Lastly, a prerequisite to mediation should also be other proper DR forums should be used first. Open to the idea of MedCom only accepting cases referred by a DR volunteer, but aware that this is more bureaucracy, not less. Overall, I do agree that MedCom needs reform, but I think that it should be explored. Keen to work on this with the community - am glad there's been a reason for me to return from the grave!. StevenCrossin 01:52, 31 October 2018 (UTC)Reply
Support closure, without prejudice to re-opening it in future, per Amory. I too like the idea of the Mediation Committee, and agree it has done great work in the past. However it simply isn't active enough now to be a viable form of dispute resolution. Our dispute resolution systems are confusing enough as it is, and it does a disservice to users to point them at this process which at the moment will most likely either reject their request or leave them in limbo. the wub"?!" 19:28, 2 November 2018 (UTC)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 closure. It is apparent that this process has withered on the vine and no longer serves any useful purpose, if it ever did. - Nick Thornetalk 23:45, 9 November 2018 (UTC)Reply
Extended discussion
Could someone point me to the last case that the Committee took on? K.e.coffman (talk) 05:32, 12 October 2018 (UTC)Reply
@K.e.coffman:. I think this archive gives sort of that. Specifically, it may be this case which was closed on 5 August 2017 as "partly successful", that's some 15 months ago. The last truly "successfully closed case" is this closed in June 2016, over two years ago. But it's noteworthy that, their rejection rate outnumbered acceptance rate by almost a factor of 20. For every one accepted case, 20 are rejected as not suitable for mediation as this page can show. Between January 2013 to date they rejected 282 cases and accepted only 14 as suitable or ripe for mediation. In that 14 cases only 5 were closed as truly "successful", the last being in 2016. Another 6 closed as "unsuccessful", "failed" or "unclear status". At least one was closed as "stale" and another closed as "parties refused to participate". I counted this off the cuff from the data of this and this pages. I believe there may be ommision, but overall I see a picture of of a dead and toothless process that we can do better without. –Ammarpad (talk) 15:15, 12 October 2018 (UTC)Reply
The overall success rate over the last five years seems to be around 1-2% of the total number of cases filed, while the overall success rate for the last two years is 0% by any measure.
There is a similar situation at arbcom, accepted case numbers are down, extraneous subcommittees such as WP:BASC have been shut down, and the committee itself is shrinking.
This is actually a good thing in that it would seem to indicate that many problems are being adequately addressed before things get to the point of needing an entire committee to resolve them.
I completely belive what Tranporter Man says about the willingness of largely inactive mediators to return if needed. The fact that they haven’t been needed in years is the whole point. Beeblebrox (talk) 18:53, 12 October 2018 (UTC)Reply
Evaluating this RFC: Medcom is not "just any" process created by a user on a whim. It is one of the first two content DR processes created at Wikipedia (the other, and first, being RFC) and, if my memory serves, was created by or in cooperation with Jimbo Wales himself, who also appointed the first mediators. Just as Arbcom would not be shut down without a consensus involving both a very large number of participants and a strong number of !votes in favor of termination, neither should Medcom. While this RFC has a couple of weeks to go, the response here so far would seem to me to be entirely inadequate to take any decisive action to terminate Medcom or mark it as historical, even if the "support" !votes were unanimous, which they are not. Regards, TransporterMan (TALK) 16:15, 15 October 2018 (UTC)Reply
Comment 1 - Deprecating MedCom is being inaccurately compared to deprecating User conduct RFCs. The difference is that no one has cited any actual harm done by having MedCom available. RFC/U was doing real harm, because the procedure was both rigid and confrontational. Because of its rigidity, it was hard to use it correctly, so that the most common result was an incomplete RFC/U, which didn't even start a comment process, but did further offend the subject editor. Its original purpose, which was to serve as input to User:Jimbo Wales for a request to ban a user before there was an ArbCom, had long become obsolete. MedCom doesn't do any harm, and still may serve a purpose when DRN and other options have fallen through. Robert McClenon (talk) 18:45, 15 October 2018 (UTC)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 don’t see any need for a panel of admins, as others have stated the consensus is fairly obvious. As the person who initiated this I am willing to help with the necessary adjustments mentioned above if needed. Beeblebrox (talk) 21:13, 9 November 2018 (UTC)Reply
I have no objections to a one-person closure, to be clear. Please be careful with the closure, though. Best, Kevin (aka L235·t·c) 21:26, 10 November 2018 (UTC)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 Today's Featured Articles?
Latest comment: 5 years ago143 comments74 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
There is Nno consensus to pending-changes-protect the TFA page, as a default measure.This, obviously, does not affect the discretion of administrators to implement PCP at a TFA, (per the protection-policy), for purposes as may be otherwise deemed fit.
There is Yconsensus to disallow non-autoconfirmed users from adding images on TFAs, as a default measure.
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 a fair compromise that prevents vandalism but still allows constructive edits. TeraTIX 00:05, 14 October 2018 (UTC)Reply
Support. TFA is a big target for vandalism. Considering it's the very first thing that shows up on Wikipedia's main page, a ton of people could see that vandalism, and some times it can be extreme. However, this is the encyclopedia that anyone can edit, so I don't necessarily like the idea of always locking the first thing that appears on the main page so that only certain users can edit it. PCP seems like a good idea to me.--SkyGazer 512Oh no, what did I do this time? 00:11, 14 October 2018 (UTC)Reply
Support, at least until we have a working filter, or a better way to stop this kind of vandalism. Suffusion of Yellow (talk) 00:14, 14 October 2018 (UTC)Reply
Supportper everyone else. The advantage of pending changes is it allows IPs and new users to make their change, without it being instantly visible to all and sundry. I get the objections about Pending Changes reviewers not being as active as they should be and articles sitting in the queue for entirely too long. I also get the objections about things getting confusing when there are a bunch of edits that are a mix of constructive and unconstructive edits. However, I would not describe pending changes as "useless". Today's Featured Article and other main-page featured content serve several purposes for Wikipedia - (1) showcasing our work, and (2) inviting people to get involved. Semi or full protection circumvents (2). Allowing people to vandalize and have it be visible circumvents (1). Pending changes protection allows people to get involved without showcasing the destructive efforts of vandals. ~ ONUnicorn(Talk|Contribs)problem solving 00:21, 14 October 2018 (UTC)Reply
Comment. During the pending changes trial, trialled pages that had high amounts of edits per day (such as Barack Obama and George W. Bush) had to have PC removed from them because the volume of edits overwhelmed the ability of CRASH to approve edits. This needs to be kept in mind - if a TFA is controversial or popular enough, PC becomes limited in use. (I am not !voting on this as everybody who gives a damn already knows my views on Flagged Revisions and its bastard understudies.) —Jeremyv^_^vBori! 00:22, 14 October 2018 (UTC)Reply
Comment the TFA we've had for less than an hour has already been vandalized fivesixten times with obscene images, and it's continuing. L293D (☎ • ✎) 01:35, 14 October 2018 (UTC)Reply
Support, but perhaps an edit filter that prevents non-autoconfirmed editors from adding or changing images on TFAs would be better given Jéské Couriano's comments above. --Ahecht (TALK PAGE) 02:40, 14 October 2018 (UTC)Reply
Support It makes sense, and doesn't block anonymous contributions completely. — AfroThundr (u · t · c) 03:06, 14 October 2018 (UTC)Reply
Support As other editors have stated, this seems to be the best compromise while maintaining the project. ProgrammingGeek talktome 03:27, 14 October 2018 (UTC)Reply
Oppose per the protection policy and Jéské Couriano. "Pending changes protection should not be used as a preemptive measure against violations that have not yet occurred." If a given TFA is having vandalism problems, an admin should use their discretion to apply whatever remedy is best, whether that be (range) blocking or a higher level of protection. I believe the status quo is a better state of affairs than significantly increasing the workload of reviewers. Yes, TFAs get vandalized, but they have far more eyes on them and get reverted almost immediately, whereas it's not unusual for me to see pages in the reviewer queue for over an hour. I would oppose any default protection of a page, even (especially) TFA, per the protection policy and knowing how slow pending changes reviewing can be am even less in favor of this proposal. Wugapodes[thɑk][ˈkan.ˌʧɹɪbz] 05:54, 14 October 2018 (UTC)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: @Only in death: While I understand the oppose rationale, it misses the spirit of the policy; protection policy says "Pending changes protection should not be used as a preemptive measure against violations that have not yet occurred.". Since all TFA articles are being routinely targeted (while they are TFA), it can safely be assumed that future TFAs will also be targeted unless protected (just the same as if a single article has been recently repeatedly targeted, it can be assumed that it will be targeted again unless protected). In other words, IP vandalism to all TFAs is occurring, therefore TFAs should be routinely protected to stop this vandalism (at the lowest level needed, and for the duration only of the TFA), and I don't see this as contrary to WP:NO-PREEMPT. — Insertcleverphrasehere(or here) 14:53, 14 October 2018 (UTC)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. power~enwiki (π, ν) 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 Bannertalk 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, User:TheDragonFire300. (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. — BillHPike (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
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. Beeblebrox (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. — MusikAnimaltalk 20:06, 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. LugnutsFire 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. — Newslingertalk 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"? SeptentrionalisPMAnderson 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
You note it's high-traffic - what about the 2nd oppose (it might actually be the largest) that pending changes escalates rapidly in difficulty to resolve/authorise once more than one editor has stacked up pending changes? Nosebagbear (talk) 12:58, 16 November 2018 (UTC)Reply
Support. The "anyone can edit" philosophy should of course be upheld wherever possible, but pragmatism trumps upholding unrealistic ideals. Darylgolden(talk)Ping when replying 12:27, 14 November 2018 (UTC)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. Beeblebrox (talk) 19:04, 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 solutionThis 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. — MusikAnimaltalk 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) — MusikAnimaltalk 22:11, 15 October 2018 (UTC)Reply
Oppose Not in favour of the use of edit filters. Hawkeye7(discuss) 21:55, 15 October 2018 (UTC)Reply
Support It is very unlikely that an image added to a TFA would benefit the article as the imagery will have been considered and discussed in the FA review, and the risk of image vandalism is high. Hrodvarsson (talk) 00:17, 16 October 2018 (UTC)Reply
Support: I'm not sure that most valdalism is adding images, but would not hurt. --K.e.coffman (talk) 03:16, 16 October 2018 (UTC)Reply
Support if PC-protection of TFA does not succeed: I'd prefer PC protection, but this would also eliminate some of the most egregious vandalism on TFAs. Regards, User:TheDragonFire300. (Contact me | Contributions). This message was left at 10:49, 16 October 2018 (UTC)Reply
Support provided the same edit filter also disallows removing images as well. Alternatively, as mentioned above more judicious use of the bad image list can help. —Jeremyv^_^vBori! 17:50, 16 October 2018 (UTC)Reply
Support. It's true that IPs sometimes make constructive edits to the text of TFAs, and I understand people's desire to keep that open as a possibility. But I can't imagine any acceptable image being uploaded by an IP or brand new user. It would either be inappropriate for the article, or it would have improper licensing, or both. If we can find a way to technically block changes or uploads to images, I'm all for it. --MelanieN (talk) 20:00, 16 October 2018 (UTC)Reply
Support. Sounds like it should be effective without compromising the "anyone can edit" ideal and without clogging up articles with pending changes. Boing! said Zebedee (talk) 15:31, 17 October 2018 (UTC)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, seems like a good compromise. Kaldari (talk) 20:12, 18 October 2018 (UTC)Reply
Support if PC-protection of TFA does not succeed: I'd prefer PC protection, but if there is not a consensus for PCP, then this is a good compromise. --BrownHairedGirl(talk) • (contribs) 14:37, 19 October 2018 (UTC)Reply
Support, assuming it's both technically possible and the PCP proposal fails. — Bilorv(c)(talk) 01:52, 22 October 2018 (UTC)Reply
Strong oppose per User:Jimbo Wales/Statement of principles 2 and 3 and WP:AGF. Image vandalism of TFAs is a recent problem and should be resolved if and when it occurs with blocks, range blocks, page protection, and/or adding the image to the image blacklist as suitable to the individual case, not a blanket and convoluted edit filter that will confound and bite good faith newcomers. IPs should be just as allowed to engage in WP:BRD of images on TFA as any other editor, and the idea that newcomers will understand Wikipedia well enough to make a talk page request for the addition of an image is not compelling. Wugapodes[thɑk][ˈkan.ˌʧɹɪbz] 08:02, 22 October 2018 (UTC)Reply
Oppose technically infeasible and would result in poor experience for anons making legitimate edits. -FASTILY 07:49, 25 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
Only temporarily, in response to an actual vandalism wave or PoV-war. I.e., this really isn't any different from any other WP:RFPP case. Just go there and report the problem and let the protection-focused admins deal with it as they normally do. — SMcCandlish☏¢ 😼 06:19, 13 November 2018 (UTC)Reply
Support - too much potential for damage by adding an unsuitable image. Darylgolden(talk)Ping when replying 12:23, 14 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
Weak oppose - frustrates IPs with good contributions, though does reduce work for patrollers. Ultimately there are many eyes on main page, so vandalism will not be missed Cas Liber (talk·contribs) 01:41, 15 October 2018 (UTC)Reply
Oppose. The fact that it's a perennial proposal is not a reason to oppose in itself. However, this is the encyclopedia that anyone can edit it, and I think taking away the ability for everyone to edit the current featured article at all would be contrary to that purpose.--SkyGazer 512Oh no, what did I do this time? 14:01, 15 October 2018 (UTC)Reply
Oppose for the reasons I explained above. --Jayron32 15:18, 15 October 2018 (UTC)Reply
Oppose The ability to edit the featured article is part of how we invite people to get involved. ~ ONUnicorn(Talk|Contribs)problem solving 15:30, 15 October 2018 (UTC)Reply
Oppose, for the reasons I mentioned above, which echoes the points of the other opposes here. --AntiCompositeNumber (talk) 17:07, 15 October 2018 (UTC)Reply
Oppose It would contradict the "anyone can edit" motto if the first article on the main page is always unable to be edited by anons or new users. An edit filter preventing addition of images, as discussed above, is about the limit of autoprotection that should be considered in my opinion. Hrodvarsson (talk) 00:21, 16 October 2018 (UTC)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
Chris troutman, finally. Someone with the guts to say what we've all been thinking. All articles should be fully-protected. Let's shut down RfA, as well, just to make sure none of those pesky vandals are handed the mop. ProgrammingGeek talktome 00:20, 18 October 2018 (UTC)Reply
So? Pareto-optimal solutions are both very difficult to reach, and a very weak condition. How many rules changes do we have that are literally unanimous? SeptentrionalisPMAnderson 00:54, 20 October 2018 (UTC)Reply
Pmanderson, This kind of situation is easily avoided by the absolutist government advocated for in Leviathan. A good first step for this is this proposal. ProgrammingGeek talktome 01:41, 20 October 2018 (UTC)Reply
Neutral, prefer pending changes so new editors can still submit changes via the normal edit button. Deryck C. 17:38, 6 November 2018 (UTC)Reply
Support semi-protection: the amount of penis pictures bombing onto TFA today is just too much. StraussInTheHouse (talk) 16:03, 10 November 2018 (UTC)Reply
While I'm sympathetic to the view that anonymous IP contributions to Wikipedia have, over the years, statistically become less and and less likely to be constructive (especially at "big target painted on them" pages), the constructiveness of them hasn't fallen precipitously, so general consensus has not shifted toward locking anons out of any more editing, even temporarily. It could go that way some day, but I don't see any signs of such a WP:CCC shift yet. For this sort of thing in particular, it would require an analysis proving that anon contribs to TFAs (and perhaps other main-page content) are almost always revert-worthy, and even then you'd have to surmount the argument that deciding to edit a main-page-featured item could be many new editors' first forays into participating as more than readers. (Personally, I doubt that's really true very often, but people will argue it.) — SMcCandlish☏¢ 😼 06:19, 13 November 2018 (UTC)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. Beeblebrox (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. Beeblebrox (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). —Jeremyv^_^vBori! 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. —Jeremyv^_^vBori! 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 quotePmanderson (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. —Jeremyv^_^vBori! 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. SeptentrionalisPMAnderson 00:46, 20 October 2018 (UTC)Reply
Because you forgot a closing parenthesis. —Jeremyv^_^vBori! 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. —Jeremyv^_^vBori! 10:34, 25 October 2018 (UTC)Reply
Support. There are enough watchers that valid changes will be swiftly approved, and there have been so many instances of vandalism that we do need to do something. This is kinder than semiprotection. Guy (Help!) 13:00, 16 November 2018 (UTC)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.
Latest comment: 5 years ago45 comments32 people in discussion
Today, I am going to propose that non-admins should have the right to close deletion discussions as "delete" at Wikipedia:Redirects for discussion. This is because it is one of those deletion noticeboards that have a huge backlog and can stretch for up to two week or even more. I am sure that with the help of non-admins, this backlog will always reduce significantly. XFDCloser should allow non-admins to close a WP:RFD discussion as "delete" and then tag the corresponding page for speedy deletion with {{db-xfd}} so that an admin can delete soon after. Pkbwcgs (talk) 12:33, 20 October 2018 (UTC)Reply
It seems like this will only create duplicate work... Before using the Delete button Admins will still have to re-assess the consensus of the discussion. — Insertcleverphrasehere(or here) 12:40, 20 October 2018 (UTC)Reply
@Insertcleverphrasehere: That's a good point. However, we could restrict this so that users who have more than 10,000 edits can only close these discussions. However, right now there is a backlog of two weeks at WP:RFD and non-admins can currently close any discussion as anything other than keep. Also, if that is the case then what if a non-admin closes a discussion as keep just because they created that redirect when there are five delete votes? Then, they got the consensus wrong! So, if non-admins can't be trusted to close a deletion discussion as "delete", the why should they be trusted to close a deletion discussion as "keep". However, non-admin can close discussions as anything other than "delete" on all noticeboards (except WP:TfD where non-admins can close discussions as "delete" as well) so what is wrong in letting non-admins close WP:RFD discussions as "delete" to clear the backlog? There is no problem in letting non-admins close WP:RFD discussions as "delete" and if there is any problem, it can always go back to admins only closing WP:RFD as "delete". Pkbwcgs (talk) 12:53, 20 October 2018 (UTC)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
WP:RFD does not have any backlog, much less one that's over two weeks. Occasionally a single discussion hangs out in the backlog for some time (eg: Stephni meyer), but that is different from RfD actually being backlogged. I can't think of any sizable backlog there since early 2016 and even then, it wasn't to the point where I would call it problematic. --Tavix(talk) 15:07, 22 October 2018 (UTC)Reply
Agree with @Insertcleverphrasehere. No matter what, the admin doing the "actual deletion" must reassess the situation and be personally assured that the deletion is OK and this is plainly duplication of work. Just what is needed is to draw the attention of willing admins to the area, through the usual ways.–Ammarpad (talk) 13:50, 20 October 2018 (UTC)Reply
Strong oppose: What's the point of closing as delete if the closer cannot delete anyway? Regards, User:TheDragonFire300. (Contact me | Contributions). This message was left at 04:39, 21 October 2018 (UTC)Reply
I supported this the last time it was proposed (Wikipedia talk:Redirects for discussion/Archive 9), and I'm still somewhat sympathetic towards it. It is true that an admin still needs to do the final review, but the main advantage comes from the fact that there are more active administrators at CAT:CSD than WP:RFD. As long as the non-admin closure is performed on clear outcomes only, time is saved by the fact that the deleting admin probably wouldn't have deleted the redirect had the non-admin not drawn attention to it. Close calls and controversial decisions should still be left to administrators. Something similar has already been implemented at WP:TFD with some success. With that being said, the previous discussion was held when, if I recall correctly, the backlog at RfD was pretty severe. I can't confess to being familiar with the RfD backlog today, so perhaps this extension on non-admin closures is simply not necessary (e.g. admins already clear out the easy delete closes quickly). Mz7 (talk) 05:07, 22 October 2018 (UTC)Reply
Strong Support a great way to tackle backlogs. Yes an Admin will need to check the RfD before deleting but they will not need to fill out the fields to close the discussion. It will be very clear very fast which non-Admins are trustworthy to close RfDs where the Admin can just handle the deletions. This will reduce silly relistings as well. Legacypac (talk) 09:34, 22 October 2018 (UTC)Reply
Support. Even though admins will need to check the RfD, most are unlikely to be contentious so that's likely to be little more than a rubber stamp. And in cases that might not be obvious, I generally find it significantly easier to review someone else's judgment of consensus than to judge it myself from scratch. As Legacypac says, it means the admin just has to do a quick CSD delete rather than the formal closing steps of the RfD, so it's one step of bureaucracy taken care of. Mz7 makes the point that CSD has more active admins than RfD - I've personally done lots of CSD work but I don't think I've ever even looked at RfD. On an ideological front I also think it's good to get judgment calls like this devolved away from admin-only wherever practical. Boing! said Zebedee (talk) 10:21, 22 October 2018 (UTC)Reply
Procedural note. The same thing was propsed, and rejected, at an RfC in 2016, see Wikipedia talk:Redirects for discussion/Archive 9#Allow non-admin delete closures?. Of course, things can change, but if there is any obvious change since then, it is that for the past year or so we've had more admins regularly closing discussions, so the backlogs have almost disappeared now. – Uanfala (talk) 12:39, 22 October 2018 (UTC)Reply
It was a close call back then, and two years is a very long time in Wikipedia ;-) Boing! said Zebedee (talk) 13:31, 22 October 2018 (UTC)Reply
Oppose Per above, I don't see the point. As one of the main sysops active at RfD, I don't think lack of sysop activity is a major issue, but rather lack of overall participation. Having a few more sysops swing by would be helpful, but I'd much rather have folks take part in the discussions. Best case scenario there's a half dozen or so participants, and excepting Thryduulf, there's very little actual discussion amongst participants; mostly by the seventh day there have been no comments for five or six days. ~ Amory(u • t • c) 13:40, 22 October 2018 (UTC)Reply
Hypothetical support, practical oppose. I appreciate the intent here; non-admins are perfectly capable of assessing consensus. However, since an admin still has to come along and delete the article, it just creates double work. --Jayron32 13:45, 22 October 2018 (UTC)Reply
Question how would this work mechanically? Maybe a CSD-like tag indicating an RfD was closed by a non-admin as Delete with a link to the closing diff? zchrykng (talk) 13:47, 22 October 2018 (UTC)Reply
Oppose. It's rare that there is actually a significant backlog of discussions that are simple closures (with any outcome). user:Feminist does good work with easy keep and retarget closures and there are 6 active RfD admins (in no particular order) myself, Tavix, Patar knight, Amorymeltzer, Deryck Chan and BDD. The discussions that get left are the ones that are more complicated and need careful assessing of the arguments - NACs would not help these. The one really extended backlog we had recently was Wikipedia:Redirects for discussion/Log/2018 September 17#Stephni meyer which went unanswered for several days at WP:ANRFC but was closed by Ivanvector (an occasional RFD participant and former regular) when I left a message on their talk page. What is needed at RfD is more people (admins and non-admins) participating in discussions and admins patrolling backlogs at WP:ANRFC. Thryduulf (talk) 14:30, 22 October 2018 (UTC)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
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
Comment the mechanics are very simple. Close as Delete and tag the redirect G6 housekeeping noting "deleted at RfD" or similar. An admin working CSDs can just press the button. If some non-Admins closed the non-comtroversal ones the Admins woukd be freed up to close the tougb ones, though there are not a lot of tough RfD discussions. I favor letting non-Admins do everything possible to demonstrate a good trackrecord and this is a good place for someone to show their judgement. Legacypac (talk) 19:33, 22 October 2018 (UTC)Reply
Oppose per the excellent essay at User:Tavix/non-admin_closes. All this does is create duplicate work. The scripts that we have make adding all the templates trivial, so a non admin doing that isn't really helping. The best that can be said for this proposal is that it might give qualified individuals the chance to better demonstrate that they are qualified for RfA, but they can do that in other ways. — Insertcleverphrasehere(or here) 19:56, 22 October 2018 (UTC)Reply
Oppose. I don't understand the reasoning here at all; there's no backlog to speak of at RFD and hasn't been since the disruptive editor who used to fill it with spurious and time-consuming comments (all of which needed to be reviewed by the closing admin just in case it was one of the rare occasions when he was making a sensible point) has been sitebanned, and needing to have two closers for each discussion would increase the workload, not decrease it. ‑ Iridescent 20:02, 22 October 2018 (UTC)Reply
Oppose, noting that (I think) I supported a similar proposal a while ago. It makes sense for TfD and CfD to allow non-admin "delete" closures because templates and categories need to be orphaned/emptied/replaced before they are deleted, and this extra work can be done quicker if non-admins are involved in the process. RfD has no similar issue. feminist (talk) 10:32, 23 October 2018 (UTC)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
@Feminist: Okay. However, XFDCloser doesn't let non-admins close a CfD discussion as "delete". Pkbwcgs (talk) 14:06, 25 October 2018 (UTC)Reply
Oppose Unless there is a user right that allows non admins to delete pages it makes no sense to allow non admins to close as delete unless the article is already deleted and the admin forgot or could not close it. Abote2 (talk) 10:29, 25 October 2018 (UTC)Reply
Oppose per basically hwat Tavix has already summarized at User:Tavix/non-admin closes. There is already a process to determine whether someone is clueful enough to assess consensus and it's called WP:RFA. In fact, proposals like this carry the risk of deterring people from running for adminship by removing incentives (such as the ability to close XFDs as delete). Regards SoWhy 10:37, 25 October 2018 (UTC)Reply
Support per Ivanvector. Also, it's great, actually, to have two users (the closer and the deleter) who believe delete is the policy compliant consensus, further evidencing that is the reasoned course. In addition, it's said that the process suffers from lack of participation, a likely side benefit to this proposal is more policy compliant participation and more experienced participation across the board. (As lack of participation in deletion, often results in a potential closer, not closing, but instead participating). -- Alanscottwalker (talk) 13:22, 25 October 2018 (UTC)Reply
Oppose, per Iridescent. Unnecessary, as there is no significant backlog at RFD. Will not decrease the workload on admins but will increase the overall workload for the project and will make things bureaucratically more complicated without a completing need for it. Also will create a mess at DRV if such deletion decisions are ever appealed there since there will be more things to haggle about (the NAC closure itself and the subsequent deletion by an admin). Nsk92 (talk) 14:30, 25 October 2018 (UTC)Reply
Oppose as meaningless. Admins are responsible for any use of the tools, so they would still have to reevaluate the discussion to determine if the determination of a "delete" consensus was correct. "But _______ told me to!" isn't an excuse for tool misuse. If a non-admin agrees that something should be deleted, they can of course add a "Delete" argument to the discussion, and realistically, greater participation in deletion discussions would be of far more value. SeraphimbladeTalk to me 19:35, 25 October 2018 (UTC)Reply
Support - if this proposal was implemented, admins should not be the ones responsible for that deletion - the non-admin closer would be. Admins would only be responsible for preventing clerical errors - establishing that an RfD was closed as delete for the correct redirect. This is easily handled by an automated tool. Hell, we could make it so an automated tool compiled the NAC deletes onto one page, waiting for an admin to drive-by d-batch all of them. Admins will likely know the closer in the vast majority of deletions that would occur under this rule. In response to the argument that anyone who is trustworthy enough to close RFD discussions as delete should simply pick up the mop at RfA, I have only one thing to say: RfA is buh-roken. Tazerdadog (talk) 06:11, 28 October 2018 (UTC)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
Snow oppose - deletion should always only be carried out by administrators - besides, if it's deleted before the XfD (in this case, RfD) is finished, let some user use the custom close rationale to close it. Kirbanzo (talk) 18:54, 28 October 2018 (UTC)Reply
Oppose. Doubles the work as admins are ultimately responsible for their deletions. The problem with RFD and most non-XFD AFD processes is not a lack of willing administrators, but a lack of participation. ---- Patar knight - chat/contributions 07:52, 4 November 2018 (UTC)Reply
Oppose deletion is best left to admins and if they have to double-check anyway this is a waste of time Atlantic306 (talk) 16:52, 4 November 2018 (UTC)Reply
Support in principle - this discussion is a close parallel to the similar one at TfD awhile back, and contains a lot of the same misunderstandings. NACs at TfD worked well, and IMO the sole condition that would limit using them in a similar way at RfD is the opposition of admins who are regulars there. We had back then the same problem with people who had no idea how the process might work showing up at the RfC to announce that it wouldn't help and would "double the work", never mind that the people actually doing the work at the time knew perfectly well where the pain points were and why this procedural change would reduce them. The difference between the TfD proposal and this one, though, is that it seems that (some of?) the admins involved aren't persuaded (see Amorymeltzer's post above) and they're the ones who actually know what they're talking about when it comes to workload. Opabinia externa (talk) 21:54, 4 November 2018 (UTC)Reply
Oppose (1) the is not a huge backlog in AfD and (2) As a reviewer, I have seen many times pages have been checked reviewed and accepted on the main space even the articles have 0 source/homepage or sources associate with the subjects, let alone the articles pass the notability, reliable secondary source with WP:SIGCOV requirements. If reviewer would accept such articles, other editors might not know/might not have the knowledge of what constitute a page to be deleted. To say that, there are some editors and reviewers do have the understand to carry out the task if a non-admin "delete" closures right is provided/permitted. CASSIOPEIA(talk) 04:27, 13 November 2018 (UTC)Reply
@CASSIOPEIA: Read the topic before commenting. We are talking about WP:RfD, not WP:AfD so please don't talk about articles for deletion. Pkbwcgs (talk) 16:15, 13 November 2018 (UTC)Reply
Proposal/RFC: Redesigning page-protection padlock icons to be more accessible
Latest comment: 5 years ago217 comments104 people in discussion
Hello everyone. The template doesn't seem to like tables inside of it, but I'm leaving this table here just to clarify the conclusions reached. Thanks, ProgrammingGeek talktome 14:35, 13 November 2018 (UTC)Reply
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.
Most discussion seems to have stopped, and I think this RfC has reached its natural conclusion.
Summary: there is consensus to YUpdate the padlocks with grey shackles, without bias towards other discussions as to design specifics
Extended rationale:
There is an overwhelming majority of editors in favour of the new padlock designs. While sheer force of numbers alone does not determine consensus, this proposal is in a somewhat unique position of "I like this side more" to be a pretty valid rationale.
There were a total of 3 editors opposing this proposal.
Two stated that they had a preference for the old design.
One stated that they would support if the icons were removed. I weighted this opposition less because I felt it was more of an "implementation" issue, which I considered separately.
Most people who had an opinion either way stated that they preferred the version with the grey shackles, although I don't really buy (get it?) the assertion that Wikipedia could be mistaken for an ecommerce website without the grey shackles.
The question as to whether or not the padlocks improved accessibility was never really settled. As most editors supported the change anyway, this didn't seem to matter too much. As implementation wouldn't have decreased accessibility, the argument itself wasn't too important in the decision to close.
Much discussion was had over the specifics over the contents of the icons themselves.
Some editors preferred letters over symbols and vice versa. Boing! said Zebedee's suggestion that symbols were easier to learn than colours seemed to be generally agreed upon
Feedback was incorporated into the padlocks (viz. the symbols)
The discussion did not start with the padlocks that were finally agreed upon. While I think that most editors who supported would be generally happy with the final result, I believe that there should be no bias towards further discussion of specifics
Note that this doesn't mean that there should be another discussion - Zebedee's point that requiring another discussion would be needlessly bureaucratic is correct.
Should the page protection padlock icons be redesigned? – XYZt (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.
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 XYZt (talk) 07:00, 25 October 2018 (UTC)Reply
Support (padlock icons)
Support, neutral/unspoken on shackle color (padlock icons)
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
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
Minor tweaks aside, LGTM! ~ Amory(u • t • c) 10:57, 25 October 2018 (UTC)Reply
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
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
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
Good work; support in principle subject to whatever adjustments are deemed necessary. Sandstein 11:32, 25 October 2018 (UTC)Reply
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
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
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
Support as currently designed, strong support with the changes below made. zchrykng (talk) 14:39, 25 October 2018 (UTC)Reply
No brainer. Clear improvement from what we have now. –Ammarpad (talk) 14:51, 25 October 2018 (UTC)Reply
Clear snowed support. Unanimous so far. Discussion proceeds on tweaks. Alsee (talk) 15:20, 25 October 2018 (UTC)Reply
SUpport Big improvement! --Jayron32 15:59, 25 October 2018 (UTC)Reply
Well thought design change. Best, Barkeep49 (talk) 16:10, 25 October 2018 (UTC)Reply
Support looks nice. feminist (talk) 18:07, 25 October 2018 (UTC)Reply
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
(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
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
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. Headbomb {t · c · p · b} 21:07, 25 October 2018 (UTC)Reply
Support - including the meaning of the lock in the image seems obvious. Reywas92Talk 00:05, 26 October 2018 (UTC)Reply
Support minor tweaks notwuthstanding, these are a large improvement. Tazerdadog (talk) 00:23, 26 October 2018 (UTC)Reply
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
Looks like it improves accessibility for some of our users. Mz7 (talk) 06:47, 26 October 2018 (UTC)Reply
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
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
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
Support - more clarity than the current version. Cabayi (talk) 19:13, 26 October 2018 (UTC)Reply
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
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
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
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
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
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
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
Support. Much clearer for all users, not just those with visual impairments. MichaelMaggs (talk) 15:42, 28 October 2018 (UTC)Reply
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
Support - The new padlocks are easier to tell apart and discern, and their iconography is more consistent with other parts of Wikipedia. User:Axisixa[t][c] 07:16, 29 October 2018 (UTC)Reply
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
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
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
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
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
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
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
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
Support They look very nice! Easier on the eyes — MusikAnimaltalk 17:15, 10 November 2018 (UTC)Reply
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.
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
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
Support, preferably without grey shacklesWilliam Avery (talk) 16:04, 29 October 2018 (UTC)Reply
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
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
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
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.
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
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
Support with grey shackles. The protection padlocks have been long overdue for a clarity upgrade. This fits that bill. —Jeremyv^_^vBori! 19:30, 25 October 2018 (UTC)Reply
Support with grey shackles. This is a lighter theme that still delivers the basic messages. De728631 (talk) 19:33, 25 October 2018 (UTC)Reply
Support the basic change. The addition of grey shackles would also be good. -sche (talk) 19:47, 25 October 2018 (UTC)Reply
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
Support with grey shackles.Renata (talk) 00:19, 26 October 2018 (UTC)Reply
Support for grey shackles versions. KCVelaga (talk) 01:16, 26 October 2018 (UTC)Reply
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, User:TheDragonFire300. (Contact me | Contributions). This message was left at 02:46, 26 October 2018 (UTC)Reply
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
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
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
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
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
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. CASSIOPEIA(talk) 09:33, 27 October 2018 (UTC)Reply
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
Support version with grey shackles Much simpler and more accessible. --Joshualouie711talk 22:01, 28 October 2018 (UTC)Reply
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
Support as per my previous comment on the idea lab page. This proposal will be accepted easily since there are only three oppose comments out of the tons of support comments here. Grey shackles would look a lot better in my opinion. 344917661X (talk) 02:00, 26 October 2018 (UTC)Reply
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
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
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
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)
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
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
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
The E, T and O letters should have the same height.
The arrow of the upload protection icon should be a little taller since it's currently a little difficult to see what it is.
I think you should make the images squares (like the originals), since this would make the images easier to resize. You might also want to fit some of the objects to the 20×20 "grid".
Otherwise, I like the icons and would favour their use. Jc86035 (talk) 08:18, 25 October 2018 (UTC)Reply
I'm definitely with you that the character height should be standardized. MarginalCost (talk) 11:38, 25 October 2018 (UTC)Reply
E, F and T now have the same height. I made O slightly larger to compensate for its aliasing. – XYZt (talk | contribs) – 21:03, 25 October 2018 (UTC)Reply
@XYZtSpace: Thanks. I think there are still some issues with the letters, though. The letters should probably have the same stroke width (i.e. the four bars making up the E should be the same width as the two bars forming the T); and the letters probably should be a little narrower – the E and F look a bit stretched out right now. Maybe you could try [width-to-height ratios] 3:4 or 1:1.618. Jc86035 (talk) 18:19, 26 October 2018 (UTC)Reply
For the Upload protection one, just have a vertical arrow rather than the line at the bottom (At first glance I thought this was a ± sign). What is the Icon on the cascade protection lock supposed to be? Would it be better to have a 'C' here instead? — Insertcleverphrasehere(or here) 09:02, 25 October 2018 (UTC)Reply
@Insertcleverphrasehere: It's probably supposed to be a chain (in reference to the protection chain). I agree that it might be clearer to use a "C", or maybe a downward arrow. Jc86035 (talk) 09:17, 25 October 2018 (UTC)Reply
As it says above, "cascade protection, where pages transcluded onto the protected page are also protected, now has a link icon". Boing! said Zebedee (talk) 09:21, 25 October 2018 (UTC)Reply
The chain was clear to me; I like it. MarginalCost (talk) 11:38, 25 October 2018 (UTC)Reply
Do the colors meet accessibility requirements when readers invert their displays? (light text on black background)? Why is semi-protection different from all of the rest? Why are there no tool tips? —Trappist the monk (talk) 09:21, 25 October 2018 (UTC)Reply
I think this is a great idea, with a little refinement as suggested in this discussion. I have added tooltips to the Old/New table. Alt text is still needed. – Jonesey95 (talk) 10:15, 25 October 2018 (UTC)Reply
I took a shot at alt text.[2] ―Mandruss☎ 10:54, 25 October 2018 (UTC)Reply
Judging by my eyes I think the icons should be fine with inverted colors. I left Semi without an embedded symbol because it is the most common protection [citation needed] and most people should be familiar with it. – XYZt (talk | contribs) – 15:10, 25 October 2018 (UTC)Reply
Really? I added an inverted background column to the examples table. —Trappist the monk (talk) 15:50, 25 October 2018 (UTC)Reply
Oh. Thought by "inverted colors" you meant high contrast mode. With black bg only, I think a different set of images will be needed. Either that or implement a white outline that is invisible normally but shows up in dark mode. – XYZt (talk | contribs) – 17:01, 25 October 2018 (UTC)Reply
My first thoughts are that they look a lot clearer and crisper than the old ones. Even without any visual impairment other than age-related long-sightedness, I find them significantly easier to see. Most of symbols on them were not immediately obvious to me, but it's much easier to learn and remember what symbols mean than what colours mean, so I see that as a positive step forward too. Boing! said Zebedee (talk) 09:26, 25 October 2018 (UTC)Reply
I agree with Boing! said Zebedee's assessment that learning symbols is easier than colors. This would seem to follow MOS:COLOR's suggestion that color not be the only method used to convey important information. The use of a colored lock symbol seems to pass that requirement—in that the lock is a symbol itself—but because there are different lock levels, the use of a third symbol matched to a legend would be an improvement. Spintendo 10:15, 25 October 2018 (UTC)Reply
Maybe the third symbol (semi-protection) could be a half-filled padlock (indicating the "semi" status)? Regards SoWhy 10:54, 25 October 2018 (UTC)Reply
How about the letter "S" to go with the extended comfirmed and template editor symbols? Iffy★Chat -- 11:01, 25 October 2018 (UTC)Reply
(edit conflict)Just add an "S". It's already a little odd that the semi is the only one without an icon. I'd actually probably just prefer letters for all of them rather than symbols. We have the added benefit that (if you use O for office), each starts with a unique letter other than Create and Cascade. GMGtalk 11:04, 25 October 2018 (UTC)Reply
I also support adding an "S" to semi-protection. MarginalCost (talk) 11:38, 25 October 2018 (UTC)Reply
It looks like there is consensus for adding "S". Will add it later. – XYZt (talk | contribs) – 17:04, 25 October 2018 (UTC)Reply
Alternatively, it could be 'IP', which would be a lot clearer to non-insiders. Headbomb {t · c · p · b} 21:12, 25 October 2018 (UTC)Reply
Added an account icon. I don't think non-techies will know what an IP is. – XYZt (talk | contribs) – 22:20, 25 October 2018 (UTC)Reply
@XYZtSpace: At the small resolution I think the "person" icon looks a bit deceptive – I thought it was a normal keyhole at first. I don't know what would be better, though. Jc86035 (talk) 18:57, 26 October 2018 (UTC)Reply
Further along that path, change the slashed circle in the fully protected icon to an 'F'. Similarly, change the move protection arrow to an U+003E>GREATER-THAN SIGN (>, >) or U+232A〉RIGHT-POINTING ANGLE BRACKET and rotate the selected character 90° ccw for upload protection. Small detail at small rendering size is too hard to decipher. —Trappist the monk (talk) 11:13, 25 October 2018 (UTC)Reply
Done for Full Protection though I still think that icons should be used over letters, we just have to find the right ones; will replace arrows with chevrons & rmv upload dash tomorrow. – XYZt (talk | contribs) – 06:50, 26 October 2018 (UTC)Reply
However, the current padlock designs have several flaws, many of which harm people who have visual impairments. Harm? Really? Are you really claiming that those of us who are visually impaired will suffer further degradation should we chance to look upon the old icons? Hyperbole has its uses, I suppose, but not here. —Trappist the monk (talk) 11:05, 25 October 2018 (UTC)Reply
I suggest that each symbol should also be accompanied by a mouse-over text explaining what it does. E.g., the "cascade protected icon" should make text appear that explains in one sentence what cascade protection is, and provide a hyperlink to the policy page that explains it. Sandstein 11:34, 25 October 2018 (UTC)Reply
Should we consider changing some of these colors while we're at it? Taking a look at a basic color-blind filter, full protection and move protection end up with basically the same color, as do template, pending changes, and cascading protection. Fixing the first set would be higher priority, since those are used more commonly. MarginalCost (talk) 11:38, 25 October 2018 (UTC)Reply
This was at WP:VPIfor one month before it came here. Where were all these great ideas for improvement then? ―Mandruss☎ 11:44, 25 October 2018 (UTC)Reply
Some of the suggestions have to do with that the icons have changed a bit from presented at VPI (e.g crossed out circle for full protection padlock, addition of E to extended confirmed padlock). Also VPI has the third the watchers that VPR has. Galobtter (pingó mió)
Also VPI has the third the watchers that VPR has. Precisely. If the community is not going to use VPI as intended to a much larger degree, we should get rid of it as unjustifiable complexity in the environment. Way off topic, of course. ―Mandruss☎ 11:51, 25 October 2018 (UTC)Reply
I think the larger influx is probably coming from the page listing at WP:CENT, beyond just VPR watchers. MarginalCost (talk) 13:28, 25 October 2018 (UTC)Reply
XYZtSpace, would you be making the minor design changes, or should others reupload the files if changes are requested? Jc86035 (talk) 14:10, 25 October 2018 (UTC)Reply
Jc86035 Others should feel free to make minor tweaks. For major changes please upload them separately so we can easily compare them. – XYZt (talk | contribs) – 14:49, 25 October 2018 (UTC)Reply
Not sure if this is the correct place for this, but would it be possible to add some CSS or JS to make the icon enlarge when hovered over? Just to make it even easier to see what the icon is? zchrykng (talk) 14:40, 25 October 2018 (UTC)Reply
If you want to know the type of protection, that's the purpose of the tooltip. But if you really want a better look at what's on the front of the padlock, click on it for a larger version. I would oppose adding any size and complexity just to save you that click. ―Mandruss☎ 15:34, 25 October 2018 (UTC)Reply
If you go to Preferences → Gadgets and check "Navigation popups" under the Browsing header, you will get a considerably larger preview of the icon when you hover on it. I recommend you give that a try.--John Cline (talk) 15:55, 25 October 2018 (UTC)Reply
While I have no specific suggestion for changing colors, a complete overhaul of color scheme would be good if it helps create a more clear and understandable structure. It might be good to go with all letters or all symbols, instead of a mix. Perhaps make semi-protect / extended-protect / full-protect into a clear and visible sequence of some sort. The full protect symbol makes sense, but the color feels particularly confusing. T was clear for Template, but I imagine { instead. For semi I imagine thin diagonal white lines, making it more transparent or "semi". Create and Move were easy to guess. The upload symbol was confusing. A plain up arrow would be better. The pending symbol makes sense, although I was stumped when I tried to guess. If we want a symbol for office, maybe an ! or big X. Cascade wasn't clear at first. It makes sense when explained. Down arrow was an interesting suggestion and it extends the pattern of arrow symbols. Alsee (talk) 16:28, 25 October 2018 (UTC)Reply
I've tried the T -> {{ idea before in VPI. The gist of it is that it is too small to be distinguishable on the padlock – XYZt (talk | contribs) – 02:33, 26 October 2018 (UTC)Reply
Right, I suggested a single { for exactly that reason. I think(?) that would fit. Alsee (talk) 08:20, 26 October 2018 (UTC)Reply
The problem is with the limited height, not width. Curly brackets are thin enough that the width of three of them combined can fit in the padlock width. However, the limited height of the padlock and the tallness of the brackets means the brackets have to be squashed down, which makes them resemble less like brackets. – XYZt (talk | contribs) – 18:22, 26 October 2018 (UTC)Reply
Color: I kinda miss the red fully protected icon. That red color was declarative; the fuzzy brass colored lock, meh, not so much. I have suggested elsewhere in this discussion that move and upload protection might be marked with '›' or '>' (perhaps also consider U+3009〉RIGHT ANGLE BRACKET). We could extend that idea to the cascade lock by doing pairs of those characters: '››', '>>', or '〉〉'. Alternately, there are these: U+300B》RIGHT DOUBLE ANGLE BRACKET and U+00BB»RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK (»).—Trappist the monk (talk) 11:29, 26 October 2018 (UTC)Reply
Thanks for the work. I do think @Michael J:'s suggested alteration for Semi-Protect (on right) is a good one - what do people think Nosebagbear (talk) 16:43, 25 October 2018 (UTC)ReplySemilock
imo its style is too different from the other icons to be implemented alongside them. – XYZt (talk | contribs) – 18:15, 26 October 2018 (UTC)Reply
Locks with gray shackles look less like shopping bags
It was mentioned briefly above, but I vastly prefer the versions with grey shackles, as 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) 16:47, 25 October 2018 (UTC)Reply
The new version has a problem in that the top padlock and the third padlock down now look exactly the same. Why does the top padlock no longer have a symbol? — Frayæ (Talk/Spjall) 17:58, 25 October 2018 (UTC)Reply
@Frayae:Ahecht made the grey shackle designs before I added the Full Protection symbol. – XYZt (talk | contribs) – 18:40, 25 October 2018 (UTC)Reply
As XYZt said, those were based on an older version. They should be updated now. --Ahecht (TALK PAGE) 18:57, 25 October 2018 (UTC)Reply
Gray bars look great! ~ Amory(u • t • c) 18:54, 25 October 2018 (UTC)Reply
Looking at the proposed icons, they do not appear to render uniformly; Full, Pending, Office, and Cascade look bigger than the others, I tweaked the sizes in the table marked "Alt1", and believe they are a bit better there.--John Cline (talk) 19:02, 25 October 2018 (UTC)Reply
@John Cline: I was changing the size of the padlocks based on a suggestion above, which is temporarily making the sizes inconsistent. they are fixed now and I removed your table.
As green symbolizes an action is possible, and the point of a protection icon is to restrict actions, should the green move-protection padlock be changed to orange? – XYZt (talk | contribs) – 23:41, 25 October 2018 (UTC)Reply
Oppose I don't think it matters. Green has always been the color of move protection. funplussmart (talk) 11:55, 26 October 2018 (UTC)Reply
@SemiHypercube:, I added the orangelock to the pc2 section of WP:PP, for those curious about what icon it used. Did WP:SUPERPROTECT have a padlock when it was thing? funplussmart (talk) 02:47, 28 October 2018 (UTC)Reply
@Funplussmart: Superprotect did not use a padlock, since it was only used on one page (not on the English Wikipedia, it was on the German Wikipedia in this edit) and that was the common.js page, which transcluding templates (like a protection template) would either be impossible or probably a very bad idea. SemiHypercube✎ 01:15, 29 October 2018 (UTC)Reply
@XYZtSpace: I think the no symbol looked better than the "F". I think the no symbol would at least be a bit clearer to a new user who happens upon it, since "F" on its own doesn't really impart the same "no entry" meaning. Jc86035 (talk) 17:19, 26 October 2018 (UTC)Reply
The point of the symbols is to differentiate the protection levels when the colors can't. Though I think I might change it back to the 🚫 icon, but that doesn't look very clear when scaled down. – XYZt (talk | contribs) – 18:15, 26 October 2018 (UTC)Reply
@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
For others reading my suggestion, see the picture at right for an example what it might look like. SemiHypercube✎ 23:27, 26 October 2018 (UTC)Reply
Nitpick - the O padlock looks like it's a combination dial. Perhaps a more elongated O would work better? Cabayi (talk) 19:11, 26 October 2018 (UTC)Reply
Or possibly put the "no" symbol on the office lock, since office protection tends to be the "thou shalt not touch" variety. ‑‑ElHef (Meep?) 20:52, 26 October 2018 (UTC)Reply
How about the cascading one being a couple of white horizontal lines, as in e.g. "cascading blinds"? wumbolo^^^ 13:29, 27 October 2018 (UTC)Reply
The extended-confirmed padlock is too similar to Israel's flag to be a neutral representation of PI 30/500. wumbolo^^^ 13:32, 27 October 2018 (UTC)Reply
Agree with Trappist the monk. That, and the x-con lock was blue to start with, so there probably isn't a connection between that and the flag of Israel (would you rather have the lock be blue, white, red, green, and black as a compromise, even though 30/500 protection isn't just used for Arab-Israeli conflict-related articles anymore?) SemiHypercube✎ 16:15, 27 October 2018 (UTC)Reply
A good and a bad suggestion. The pending changes protection should contain an eye like the user right icon, because check marks have been historically written with a pencil on a piece of paper, which is the NPR user right's icon. Full protection should contain a mop. wumbolo^^^ 13:46, 27 October 2018 (UTC)Reply
The horizontal lines of E are not that long, and in most fonts the middle line is slightly shorter (see E). The lower horizontal line of F is slightly shorter (see F). O is hardly ever a perfect circle (see O). Particularly at such a small size, such details have a very significant effect on legibility; just ask any professional typographer. ―Mandruss☎ 09:30, 28 October 2018 (UTC)Reply
I will change the O, but for the others I think the distortion will help with visibility at this size. — Preceding unsigned comment added by XYZtSpace (talk • contribs) 04:53, 30 October 2018 (UTC)Reply
No offense intended, but it's apparent that you're fairly clueless about the subtleties of letter recognition. You don't improve recognition by distorting overall shape. ―Mandruss☎ 08:38, 30 October 2018 (UTC)Reply
@Mandruss: Done for all three points for the main variant. Other versions will be updated in ~9 hours (assuming the alarm works). – XYZt (talk | contribs) – 06:09, 4 November 2018 (UTC)Reply
@XYZtSpace: Thanks. The new "O" is indistinguishable from a perfect circle at that size, and there appears to be room to elongate it more, but I'll settle for the other two improvements. ―Mandruss☎ 06:45, 4 November 2018 (UTC)Reply
Considering the Office Actions icon is white in Dark Mode, why not make it red instead of black? Red indicates a serious problem. ANDROS1337TALK 04:40, 30 October 2018 (UTC)Reply
I think the alt text for semi-protection should be changed from This article is semi-protected until... to Register an account to edit this article! to encourage users to edit instead of redirecting them to the more technical page protection policy page. – XYZt (talk | contribs) – 05:11, 30 October 2018 (UTC)Reply
Good idea! I think the featured article icon could be more yellow though. – XYZt (talk | contribs) – 21:43, 30 October 2018 (UTC)Reply
Ok. I've made it more yellow. 🌸 WeegaweeK^ 🌸 17:38, 31 October 2018 (UTC)Reply
Hate to rain on this, but the "more yellow" version has very poor contrast. It needs to either be a darker shade to provide better contrast with the white background, or have a dark border of some kind, to meet WP:ACCESSIBILITY. Ivanvector (Talk/Edits) 17:28, 9 November 2018 (UTC)Reply
As of November 3[update], there has not been any additional discussions for over 3 days. There is a 96.2% support for the main proposal (75/78) and a 75.9% support (22/29) for the grey shackles variant. It seems like there is a strong consensus for the main redesign and a mediocre consensus for the grey shackle version. When will the switch occur? – XYZt (talk | contribs) – 05:19, 4 November 2018 (UTC)Reply
@XYZtSpace: It's pretty obvious that the majority of people want the new padlocks, but what isn't obvious is wether people want the new locks to have grey shackles or coloured shackles, so I would suggest doing a separate proposal for voting on which type of shackle should be used on the new locks. 344917661X (talk) 17:46, 10 November 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
I was a qualitative researcher in schools for several years. I once heard a high school teacher, when describing source reliability, refer to the "locks" on Wikipedia articles as denoting quality, meaning that the pages are vetted/protected. I wonder if the lock icons are altogether the wrong metaphor. (not watching, please {{ping}}) czar 17:35, 10 November 2018 (UTC)Reply
Per my comment, I think we should have uniformity in the padlocks atleast on the distinction of the kind of protection, because the semi-protection and PC padlocks are still pretty vague (PC not as much). I think we keep the standard protections (full/semi/PC and maybe even ECP) on first-letter basis and the rest contextual. --QEDK (後 ☕ 桜) 07:55, 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.
I found about the new icons today. I would like to point out that templates such as {{Extended confirmed topicon}} are still using the old icons. P.S. If they are implemented, I'd suggest the new icons be just an unlocked blue lock, rather than a blue lock + Wikipedia globe. Hdjensofjfnen (♪ Oh, can I get a connection? Alternatively, trout me.) 01:56, 14 November 2018 (UTC)Reply
I don't know how (and likely don't have the tools) to edit SVG files, so pinging @XYZtSpace: on this. SemiHypercube✎ 21:34, 14 November 2018 (UTC)Reply
@Hdjensofjfnen: And maybe a key of matching color next to the open lock to indicate that the user have access. – XYZt (talk | contribs) – 02:01, 15 November 2018 (UTC)Reply
Use the new version at {{Extended confirmed topicon/sandbox}} – XYZt (talk | contribs) – 04:14, 15 November 2018 (UTC)Reply
Oops, didn't read the "/sandbox" part, I changed the main template. SemiHypercube✎ 12:16, 15 November 2018 (UTC)Reply
I like it, now for Template (I'll do it)! Not for the topicon though, fiven the differences, but I'm sure the unlocked icon will be useful somewhere. ∰Bellezzasolo✡Discuss 12:27, 15 November 2018 (UTC)Reply
I agree with Bellezzasolo that this is not suitable (by itself) for the topicon, although I like the design and it should be useful. - tucoxn\talk 16:58, 15 November 2018 (UTC)Reply
I found a use for it in a user script. This script is still a work in progress, as it still does not detect move protection levels or upload protection levels. Ups@ndDowns1234 18:21, 15 November 2018 (UTC)Reply
Some people are very sensitive about their topicons, if changing the icons around building in a 'legacy' switch is advised! — xaosfluxTalk 18:36, 15 November 2018 (UTC)Reply
(edit conflict) For autoconfirmed and extended confirmed user topicons, I'd say use the key and the symbol, but put the symbol next to the key, not on a padlock. The open padlock could be misunderstood as "This page has this protection, but because you're autoconfirmed (or extended confirmed), you can edit this it." A key and a symbol probably won't get misunderstood that way. – Pretended leer {talk} 18:37, 15 November 2018 (UTC)Reply
"This page has this protection, but because you're autoconfirmed (or extended confirmed), you can edit this it." That could actually be a feature. IIRC the mobile version gets rid of the lock icon if you have the rights to edit the page. – XYZt (talk | contribs) – 19:43, 15 November 2018 (UTC)Reply
When you go to protect a page, the banner has the "Full Protection" icon by default. This had me kind of confused because it looked like the page was already protected. Eventually I figured out it the icon was just being used in a generic sense. Perhaps we need another "generic protection" icon which doesn't correspond to any particular level? -- RoySmith(talk) 19:01, 16 November 2018 (UTC)Reply
Just found this RFC. If the new icons are better for colorblind editors, great, but it probably won't benefit readers, and the supporters were obviously influenced by preconceived notions about "modern design" and "new looks". I doubt non-editing readers even notice those icons (my father doesn't). I don't see any evidence presented here about what they perceive on pages, what's useful to them, and whether there really are colorblind readers who notice the icons and can't tell them apart. I hope someday Wikipedians let go of their unrealistic ideas about what's best for "the readers". Not that this problem is unique to them, of course... ♫ekips39(talk)❀ 05:42, 17 November 2018 (UTC)Reply
Page movers and the title blacklist
Latest comment: 5 years ago24 comments20 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
There is an Yunanimous consensus to assign the tboverride permission to the (extendedmover) user group.∯WBGconverse 05:11, 17 November 2018 (UTC)Reply
I just got a request from pagemover IJBall to override the title blacklist — Good Morning!!! (Australian show) needed to be moved to Good Morning!!! (Australian TV program) to match a naming convention, and IJBall couldn't do it because the !!! was blacklisted. I'm an admin, so I was able to do this easily. But why should I have to? We've now permitted pagemovers to do things as significant as moving without redirect (i.e. converting a blue link into a red link); shouldn't they also have the ability to override the title blacklist? Nyttend (talk) 02:09, 5 November 2018 (UTC)Reply
This will allow "page movers" to create user accounts that override the meta:Title_blacklist
Related notes:
"Warning" for blacklist hits is not currently available and isn't 'easy' compared to assigning a permission to a group. This is being looked at for everyone (including admins) already, see phab:T192933.
Discuss (page movers and the title blacklist)
Support Sounds like a good idea. Page mover is supposed to be an unbundling of admin rights, so it makes sense to do this to do page moves like this more easily. 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 spelling, a plausible typo, 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
Maybe note where the target was in the deletion log so that no information is actually deleted? Galobtter (pingó mió) 07:18, 5 November 2018 (UTC)Reply
Just noting that this would allow page movers to create edit notices. Support I don't see much harm that can be done with the ability to override. Also everyone should get a warning screen. As a WP:TPE I can override the blacklist, which can be handy, but also annoying when you accidentally move things to "User:User:Example" etc which the title blacklist forbids. Galobtter (pingó mió) 07:18, 5 November 2018 (UTC)Reply
Support I think the group is restrictive enough to not pose any problem --even if any arises, it can be dealt with in the usual way-- and this will be useful. –Ammarpad (talk) 09:06, 5 November 2018 (UTC)Reply
Support I would even suppport that page movers should be able to move fully protected pages (including to titles that have been fully salted) since indeed they can be trusted with advanced moving. Page swapping is little more than what regular editors can do, they can move A to A (1) and redirect A to A (2) but not move A (2) to A, which is compliant with NC. Crouch, Swale (talk) 09:44, 5 November 2018 (UTC)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. 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. — xaosfluxTalk 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
SupportL293D (☎ • ✎) 04:22, 16 November 2018 (UTC)Reply
Snow close in favour of the proposal. It's pretty clear that this is a pretty uncontroversial change to give trusted users a natural extension of their pre-existing rights. ProgrammingGeek talktome 04:39, 16 November 2018 (UTC)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.
Change "Spouses" to "Table of Spouses"
Latest comment: 5 years ago46 comments11 people in discussion
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
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. — xaosfluxTalk 04:05, 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 Wikipedia:Neutral point of view, and is strongly connected to 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
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
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. —Jeremyv^_^vBori! 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. —Jeremyv^_^vBori! 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
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. —Jeremyv^_^vBori! 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. —Jeremyv^_^vBori! 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. —Jeremyv^_^vBori! 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? —Jeremyv^_^vBori! 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 Thomas, Lucinius, and Ghulam coming from those societies notable by any stretch of the imagination. They become notable for things they have done that historians actually cared enough about to discuss at length in their writings. Your argument on its face is and has always been absurd, and has been roundly rejected by everyone here who has a lick of sense. What is more interesting to me at this point is that literally every edit you have made has been either to this sterile discussion, to bluelink your userpage, or to troll the idea lab. As I mentioned before, I strongly suspect that you are not a new user and are doing this as some sort of breaching experiment or to wind people up. The only thing that keeps me from going to WP:SPI about this is the fact that I haven't the foggiest whose sockpuppet you actually are. —Jeremyv^_^vBori! 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. 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..
Latest comment: 5 years ago1 comment1 person in discussion
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
Approving a bot request that would create episode redirects
Latest comment: 5 years ago14 comments4 people in discussion
I've recently manually added some missing redirects to episode list entries (see Memento Mori (The Punisher) as an example) and wanted to be more efficient with my time and make a bot request for it. I've been instructed per Wikipedia:Bot policy#Mass article creation to post first here and gain community consensus to this as this will create a lot of new redirects.
Some background: Episode redirects help readers find the episode they are looking for when using the search bar and from web searches. They also enable editors to link to these episode entries from other articles when there is need to. Currently there are over 13k episode redirects listed at Category:Redirected episode articles and there is a special template used for this specific redirect, Template:R to TV episode list entry. I've also verified with WikiProject Redirect that these are valid redirects (admittedly only one editor responded, but some days that's all you can hope for). --Gonnym (talk) 18:19, 6 November 2018 (UTC)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 Roxxon Energy Corporation#Television 2. The prose about what episodes the company appears in has some episodes linked to (some are redirects, some were redirects) and some which aren't. In this case, it is enough if even only the editor who added the information to the article knows the name. That editor could then link to these episodes and let other readers enjoy a seamless experience (compare that to the episodes which aren't linked and require much more effort for the reader to reach the point where their page is). --Gonnym (talk) 12:56, 9 November 2018 (UTC)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
I think we should know the specifics of the proposal. What would the redirects look like? Are they going to be of the format Episode name (Series name)? is the bot account going to be simply a frontend for an editor's manual task, or is there going to be an actual bot? How is the bot going to work, will it parse article text to find eligible episode names? How will the source articles be selected? – Uanfala (talk) 13:29, 9 November 2018 (UTC)Reply
I can answer for the specifics about the request, but since I'm not the bot owner and I'm using Wikipedia:Bot requests, I can't answer about the bot itself. The process (may change if better options are available) will be that a list of articles will be provided (from a category such as Category:Lists of television series episodes). The bot will check the {{Episode list}} template in the article and take the needed information. It then checks to see if an article which is not the episode article exists with that name, if there is no article, it will create one with that name, if there is one (which isn't the episode) it will create one with the format of Episode name (Series name) (per WP:NCTV). That's a very rough overview of how it will work (there are also finer details about adding the correct redirect templates and such). For an example redirect, see Memento Mori (The Punisher). --Gonnym (talk) 13:43, 9 November 2018 (UTC)Reply
I've had a look at a few articles in the category: there are ones with a good amount of content about each episode (and hence the appropriateness of a redirect is beyond question), but there are also articles (like List of Galis episodes]) where there's almost no information about each episode. Is it desirable to have redirects in these situations as well? I also see that some of these article list a large number of episodes, sometimes over a hundred. Is it desirable to have so many redirects pointing to a single article? There is a certain (small, but not negligible) maintenance cost to any redirect, and this could become an issue in the case of a topic reorganisation (for example, if at some point a list of episodes is split into individual lists for each season, then each incoming redirect would need to be retargeted by hand). – Uanfala (talk) 21:42, 9 November 2018 (UTC)Reply
Articles like List of Galis episodes won't be included, even ignoring their current condition, as they don't have an episode title. Articles that would fit the criteria are Parks and Recreation (season 5) and Agents of S.H.I.E.L.D. (season 5) as examples. I could limit this to lists that are only part of a season article (as the previous examples). I could also limit this even more, but I'm not sure of any "neutral" criteria. Regarding the amount of redirects to one article, it's important to note the distinction here. When a link is intended for the redirect, its for the exact purpose of reading that episode's information, not for reading a complete season article, searching for the intended reference. It also has the additional bonus of having links already pointing to it if/when an article is created and the redirect can have a short description, allowing even better searching options. --Gonnym (talk) 21:55, 9 November 2018 (UTC)Reply
Oppose at the current time. There are a couple more things to note you haven't apparently thought of - the first is that the best target may not be the "List of ... episodes" article, e.g. On the Buses (series 1) would be a better target than List of On the Buses episodes, but a bot wouldn't know this. The second, and more important, is that episode titles may be ambiguous - e.g. "The Opening Day" is the title of the second episode of The Brittas Empire, but this is also a plausible search term for Opening Day and Opening Day (The Twilight Zone) and it is also the name of an episode from series six of Hi-de-Hi! (and it's possible there are others). Hatnotes could suffice but for a long list of episodes there could be half a dozen or even more "redirects here" hatnotes for various different names - and at this point its getting disruptive. If instead of "The Opening Day (episode)" the redirect is "The Opening Day (The Brittas Empire)" or similar you're not actually going to be providing search terms that are useful to most readers without also creating new disambiguation pages which have a much higher maintenance requirement than redirects and some editors object to disambiguation pages where (almost) none of the targets have individual articles. I'm not against this per se, but I do think you need to take the feedback you've received (and any more that comes in) and refine your proposal, probably in conjunction with a bot operator so that technical questions can be answered, before it's ready for approval. Thryduulf (talk) 23:26, 9 November 2018 (UTC)Reply
Thanks for the comments. I don't know if you've looked at the redirect examples that I've given but they both link to the season article. That was the intent and both the bot and the original list of articles could already know that. As I said above, I gave a rough outline as I don't think it's necessary to talk about the finer points, if editors are still debating the operation itself, as it's a bit of placing the cart before the horse. Your second issue has already been addressed by me It then checks to see if an article which is not the episode article exists with that name, if there is no article, it will create one with that name, if there is one (which isn't the episode) it will create one with the format of Episode name (Series name) - so for "The Opening Day", an article that has been created for since 2006, it will indeed create one at the base name, but this isn't really a bot issue, as even a manual editor would create that. If a redirect was desired to point to "Opening Day" (which seems fair, even though WP:SMALLDETAILS arguments in WP:RM are routinely used to argue the opposite), it should have been created. An easy fix could be to that articles starting with "The" could also check the phrase without it. I'd love to work with a bot operator but they were the ones that sent me here, to first get consensus. Regarding your last point about disambiguation pages, from the ones I've checked and seen there are already disambiguation pages for most episode names that needed it. If new ones shouldn't be created, the few that will fall into this category, will still enjoy being able to be linked to and searched for (type "opening day" and you will see the twilight zone episode pop up. Use mobile, you will also get a short description for it in the search) - that to me still seems like net positives. --Gonnym (talk) 08:24, 10 November 2018 (UTC)Reply
Linking to an edit
Latest comment: 5 years ago1 comment1 person in discussion
Sometimes people need to tell me to delete or undelete or move particular edits. The form often used is e.g "<span class="plainlinks">[https://en.wikipedia.org/w/index.php?title=Saaho&oldid=776932251 776932251]</span>", which displays "776932251". If the edit is not deleted, clicking on the link displays its date and time and editor's name and edit comment, OK. But if that edit is deleted at the time (as sometimes happens, e.g. because currently the only way to delete some edits of a page is to delete all edits of that page and then to undelete some edits), then clicking on the link gets no useful information, but only a fault remark. It would be useful if, at least for administrators, clicking this sort of link also displayed information if that edit is currently deleted.
Sometimes a page is edited 2 or more times in the same minute. When that happens, clicking on the abovementioned sort of link shows time only to the nearest minute, which is sometimes ambiguous, if 2 or more of those edits are by the same editor. It would help if in history displays, times of edits displayed the seconds in edit times. Anthony Appleyard (talk) 12:20, 8 November 2018 (UTC)Reply
Teahouse FAQ
Latest comment: 5 years ago3 comments3 people in discussion
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? [UsernameNeeded] 15:42, 12 November 2018 (UTC)Reply
Sounds like a good idea.Vorbee (talk) 18:10, 13 November 2018 (UTC)Reply
Feature Request
Latest comment: 5 years ago8 comments5 people in discussion
Feature request: that the Wikipedia picture of the day be added to the article of the day email notification. I don't see why it's not included, since there's already quote of the day, etc. Benjamin (talk) 04:19, 13 November 2018 (UTC)Reply
What's the process for requesting this? Benjamin (talk) 08:47, 13 November 2018 (UTC)Reply
There is Commons:Daily-image-l for the Commons POTD, but POTD on Wikipedia is somewhat different. Have you tried mailing dal-feedback wikimedia.org? MER-C 13:28, 13 November 2018 (UTC)Reply
@Benjaminikuta: where are you getting this email from? (who is sending it, where did you sign up?) — xaosfluxTalk 14:26, 13 November 2018 (UTC)Reply
Looks like it's this (I'd never heard of it). Thincat (talk) 18:22, 13 November 2018 (UTC)Reply
@Benjaminikuta: if you are getting this email from the "Daily article mailing list" please note this is an inter-project list and is not managed here on the English Wikipeida, however you can contact the list managers at: dal-feedback at wikimedia.org. I suspect if they are going to include a Featured Image it will probably be the one from commons:Commons:Picture of the day. — xaosfluxTalk 19:01, 13 November 2018 (UTC)Reply
I emailed them, and they told me to post here. Benjamin (talk) 23:10, 13 November 2018 (UTC)Reply
Latest comment: 5 years ago44 comments17 people in discussion
I propose that any stub I created which is below 200 bytes of readable prose/a one line stub without actual information be incubated/moved to user space until they can be fleshed out properly. Most will be at least 5 years unexpanded. It was wishful thinking at the time but there's a lot of currently unacceptable ones which really shouldn't be swamping the categories. There's enough crap content here as it is. There's a lot of "xxx is a village in xx. As of xxx it had a population of xx". Those are bare minimum useful with one fact but I think if there's hundreds of them like that in one category redirect and listify it by district into an A-Z table with population would be more sensible rather than incubate. I was browsing through some places in Nepal etc I created and to be honest a lot of them have degraded with local ips adding dubious, unsourced factoids. Small villages in the developing world are off most people's radars. In a lot of cases we're better off having a list with the population until somebody can write a half decent article and watch it.♦ Dr. Blofeld 12:48, 14 November 2018 (UTC)Reply
Absolutely not. Some places (which are automatically notable) have stub articles <200 bytes long. 'Incubating' these stubs isn't going to help if they just languish in draftspace forever. If they're not being improved now, there's even fewer chances that they'd be improved later. It's a bad idea. Thanks for your suggestion, though -- I'm prone to some less than stellar ideas at times, moreso than most editors. ProgrammingGeek talktome 14:46, 14 November 2018 (UTC) Okay, so apparently I didn't read the proposal closely enough, sincere apologies! Striking in favour of new comment below. (15:59, 14 November 2018 (UTC))Reply
Oppose - I am with ProgrammingGeek on this one, if you see a stub under 200 bytes that fails WP:N then just send it to WP:AfD. - Knowledgekid87 (talk) 14:52, 14 November 2018 (UTC)Reply
I'm not a renowned fan of mass stub creation, but fact of the matter is, it's easier for a new editor to improve an existing stub than it is for them to create one. GMGtalk 14:53, 14 November 2018 (UTC)Reply
I'd also like to see automated or semi-automated stub-suggestions for new editors, but I'll let you know when someone somewhere cares about my opinion. No luck so far. GMGtalk 14:54, 14 November 2018 (UTC)Reply
I think you can configure SuggestBot to do such a thing, but haven't ever really tried. Ivanvector (Talk/Edits) 14:56, 14 November 2018 (UTC)Reply
Well, I meant for example, if someone registers an account, and their first edit is on a rugby player, something like SuggestBot comes by (probably using category information) and says "I see you know that rugby is a thing that exists, here are some stubs (read: things we know you can work on that probably won't get deleted)". But if the user has to configure SuggestBot themselves...well...if they could do that then they know enough of what they're doing that they ain't the target audience. Having said that, queue 4.5 million angry comments about how that is too close to automated welcoming and perennial yadda yadda yadda (even though we've long identified finding work as a barrier to entry for new users). GMGtalk 15:01, 14 November 2018 (UTC)Reply
I think we've hit on a separate discussion here, but I for one like the idea of automatically welcoming new users (or, say, newly autoconfirmed users) and offering them some "getting started" suggestions, like filling out a stub or de-orphaning something or I don't know what. Or make something so more experienced users can trigger suggestions, like putting some derivative of a SuggestBot template on their page along with a welcome template. Ivanvector (Talk/Edits) 16:09, 14 November 2018 (UTC)Reply
Could we just be clear that the stubs concerned here are only those created by Dr. Blofeld. Maybe if he could give us a few representative examples that would be helpful. – Uanfala (talk) 14:58, 14 November 2018 (UTC)Reply
Dr. Blofeld is in the top 50 by edit count not sure exact number but over 350,000 which means XTools doesn't work for finding a list of article creations. One can find them using this but it also includes redirects and page moves. The limit=5000 will work .. probably a huge number in total. -- GreenC 15:04, 14 November 2018 (UTC)Reply
Comment I've come across Dr. Blofeld stubs over the years on obscure topics (regional German language poetry awards) and they have been useful for creating blue links when backlinking or filling in a few details. Sometimes the titles need to be adjusted for English. Not sure it would be helpful to delete unless there are some known cases of bad ideas like every fire station in Belarus. -- GreenC 15:01, 14 November 2018 (UTC)Reply
@ProgrammingGeek, Knowledgekid87, and GreenMeansGo: I think you've misread the question. What Dr. Blofeld is asking for is authorisation to conduct a mass transfer of any stub I created which is still below 200 bytes of readable prose (my emphasis). Dr B would be the first to admit that some of his earlier stubs have problems with sourcing and accuracy, and because there are so many of them (I don't have the numbers but at a rough estimate we're talking between 10,000 and 100,000 pages, many of which are genuinely unexpandable substubs bot-created from databases with no text other than "X is a building in Y" or similar) it would require a bot to perform a bulk move of the relevant pages to a {{noindex}}ed space where the sourcing and prose issues can be cleaned up at leisure, and such a bot would require community consensus. What the three of you are effectively saying is that you're better placed than him to assess his own contributions. ‑ Iridescent 15:08, 14 November 2018 (UTC)Reply
No, I understand the question. I also understand the Dr. B is so prolific it's hard to separate an attitude toward his stub and an attitude about stubs. GMGtalk 15:15, 14 November 2018 (UTC)Reply
I've not been prolific in a very long time, I used to create an enormous number of placeholder stubs pre 2012 which if they've not been expanded this since probably won't soon. My attitude means all stubs not my own but I can't control those.♦ Dr. Blofeld 16:04, 14 November 2018 (UTC)Reply
But other than the fact that they are your stubs, that's not really an argument that doesn't apply equally to all stubs, of which we have 3.2 million (about half the project). If they're non-notable, then yeah. They should be deleted and never should have been created. If they're notable, then it's a waste of time to delete them when they need to at some point in the future be recreated. Besides that, I'm fairly confident in saying that automatically deleting tens or scores of thousands of articles is probably not what the community had in mind when authorizing G7. GMGtalk 16:17, 14 November 2018 (UTC)Reply
The vast majority are notable, but there's a lot of things like one liners on small rivers, obscure villages etc with no real information, a lot which are hardly vital articles and more marginally notable. A great deal of them might be better listified. If G7 is a problem then they can be moved to user space of course.♦ Dr. Blofeld 18:13, 14 November 2018 (UTC)Reply
But again, you're mostly making an argument against stubs in general, and not some critical flaw in these stubs in particular. GMGtalk 21:42, 14 November 2018 (UTC)Reply
Support in case it's not obvious from my comment above. That we automatically delete any article without question from the mainspace if requested in good faith and provided that the only substantial content of the page was added by its author has been a basic principle of Wikipedia for a decade; all that's being requested here is that it be done by technical means rather than Blofeld be forced to manually move 10,000+ pages and tag the resulting cross-namespace redirects for deletion. ‑ Iridescent 15:12, 14 November 2018 (UTC)Reply
Sure We can incubate (do you mean draftify?) these stubs that only you worked on. That way anyone who wants to work on one and get it main worthy can do so. Alanscottwalker (talk) 15:22, 14 November 2018 (UTC)Reply
Some way of removing what we would call "sub stubs" from the mainspace. If they've not been expanded in six years plus years they're unlikely to be soon. I say under 200b as a lot are fleshier and decent. Basically anything which is a one liner xxx is a bla bla bla, get shot of, if it's that notable somebody will write it later. I did mostly create notable subjects but a lot are ones which most people will hardly be looking for information on. I just think it's time we took this project by the scruff of the neck and had a giant cleanup.♦ Dr. Blofeld 15:55, 14 November 2018 (UTC)Reply
Yes, (and next up, how can we get NSPORTS to listify all those player stubs (say, what!?!)) -- Alanscottwalker (talk) 16:02, 14 November 2018 (UTC)Reply
(edit conflict) Changed to Support per Iridescent, provided that Dr. Blofeld is the only user that has contributed to the draft. If there's consensus and you need someone to write the bot, just ping me. Best, ProgrammingGeek talktome 15:59, 14 November 2018 (UTC)Reply
Oppose Yes a lot of the sub-stubs are bad and cannot be expanded, and when this occurs they can be individually deleted for lack of notability. I do not see why they should all be deleted because of this, many of the articles are presumed notable. This would set a precedent to delete in excess of a million articles. Maybe more. — Frayæ (Talk/Spjall) 16:11, 14 November 2018 (UTC)Reply
Support On reflection I think a certain level of minimum quality would be reasonable given what we hold as the standard at AfC. None of these articles would meet the requirements we insist on there so deleting/incubating them is reasonable. — Frayæ (Talk/Spjall) 17:00, 14 November 2018 (UTC)Reply
I don't think you understood the proposal. Natureium (talk) 16:13, 14 November 2018 (UTC)Reply
Yes, nothing is being deleted, just moved behind the scenes until they have adequate information. I did identify a lot of notable subjects but if they're still placeholders after years then they're not going to be developed soon.♦ Dr. Blofeld 16:23, 14 November 2018 (UTC)Reply
If you approve a bot capable of moving substubs to draftspace then it can potentially be used to remove maintenance backlogs to draftspace as well. Incubated articles are deleted after 6 months via G13. This is a bad idea. — Frayæ (Talk/Spjall) 16:30, 14 November 2018 (UTC)Reply
Then we'll put them in a special category so nothing gets deleted and they're linked in a place people can work on them if they wish.♦ Dr. Blofeld 17:08, 14 November 2018 (UTC)Reply
There are no exceptions to G13 and looking at previous RfC discussions on the subject it is going to stay that way. If you want to keep the pages more than 6 months you should make sure they are put in your userspace where you have some say on the matter. — Frayæ (Talk/Spjall) 17:17, 14 November 2018 (UTC)Reply
Move to user space then.♦ Dr. Blofeld 17:30, 14 November 2018 (UTC)Reply
Support. Much better than going through all of them. Natureium (talk) 16:13, 14 November 2018 (UTC)Reply
Support. Deletion criteria should take into account number of backlinks to non-dab mainspace articles; number of external links; byte count of plain-text article body. -- GreenC 16:22, 14 November 2018 (UTC)Reply
Comment. I do not have a strong opinion either way, but if this gets closed as oppose or no consensus, we might still want to make a list of such articles so that interested parties could work on it.--Ymblanter (talk) 16:37, 14 November 2018 (UTC)Reply
A typical stub of mine will look like Thüringische Muschwitz, that's 7 years old. Has an infobox and length but little else and the whole category is flooded with ones like it. I think ones like that would be better off in a List of rivers in Thuringia with a table giving information on source and mouth and length so no information is lost until somebody can write a better article.♦ Dr. Blofeld 17:50, 14 November 2018 (UTC)Reply
Comment I thought we had generally considered that WP functions as a gazetteer, and thus justifying stubs of any officially recognized town/village or natural landmark, with the basis that local sources potentially could be used to expand these (keeping in mind, no deadline exists for that). I understand if we were talking stubs on persons or other less permanent elements to userify them, but places seemed to have been handled differently in the past. --Masem (t) 18:08, 14 November 2018 (UTC)Reply
True, but the issue I think is people searching through categories and wanting to read and find decent articles and finding almost every entry is xxx is a village and no real information. I've been browsing some and it is frustrating when viewed from a reader's perspective. For a lot of those you could currently represent the same information in one list instead of having to browse dozens of articles just to retrieve one figure.♦ Dr. Blofeld 18:22, 14 November 2018 (UTC)Reply
I can see listifying these then by logical groupings to give better context to readers, but this would still demand that redirects be left behind (as a gazetteer, these are searchable terms) and to that end, it doesn't make sense to necessary userify them and instead just appear a redirect to the history. --Masem (t) 18:27, 14 November 2018 (UTC)Reply
Note that I expanded Thüringische Muschwitz a bit and now it is slightly longer than it was when Dr. Blofeld wrote the above comment. If we stick to 200 bytes, it is not eligible now to be moved.--Ymblanter (talk) 19:12, 14 November 2018 (UTC)Reply
Oppose - I think removing them on grounds of quality (vs normal deletion grounds) is incorrect - I don't think it functionally harms Wiki and they can be beneficial if and when someone does want to write on one. Obviously most go a long time without being edited, but there are so many the rate of at least some having edits made must be reasonably high. Nosebagbear (talk) 18:34, 14 November 2018 (UTC)Reply
Leaning oppose. I honestly don't see what's the problem with having these mini-stubs in mainspace, as long as the factual correctness is not in dispute and they have a minimum of sourcing. I would have found Thüringische Muschwitz useful (even in its pre-Ymblanter state), not least because there's the language link to the more developed version on deWP. Also, as noted above, expanding a stub is easier than creating a new article. And every so often someone comes along who does specialize in Nepalese hamlets, even if it does take longer than 6 years - why not make it easy for them to get going? --Elmidae (talk · contribs) 19:24, 14 November 2018 (UTC)Reply
Oppose - if you don't like that they are so short, then you can always just expand them... Thanks. Mike Peel (talk) 20:00, 14 November 2018 (UTC)Reply
Redirecting these villages to the district where we can put a list of all of them would be the preferred way to go. Don't dump them all in userspace or draft where no one will work on them and they will just need to be managed with the tens of thousands of other abandoned pages there. Legacypac (talk) 21:58, 14 November 2018 (UTC)Reply
A huge number did get expanded though, I'd forgotten how many valuable subjects I'd started too! Yeah maybe the ones with hundreds of villages and one liners belong in a list.♦ Dr. Blofeld 23:01, 14 November 2018 (UTC)Reply
Human Rights and Liabilities 1
Latest comment: 5 years ago5 comments4 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
herewith i propose to you to look or ask the UN <html>www.un.org</html> whether you <html>www.wikipedia.org</html> (sorry for citing unverifiables here) are in fact promoting crimes against humanities by offering and promoting such articles like:
What? Providing reliably sourced information about a mental disorder isn't human rights abuse. I hold some strange opinions but that isn't one of them.
If they're getting massages and I'm not, I think my human rights are being abused!
Recommend (snow) close as there is nothing in this proposal that is actionable. Regards, User:TheDragonFire300. (Contact me | Contributions). This message was left at 01:58, 15 November 2018 (UTC)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.
!Remind me bot
Latest comment: 5 years ago3 comments3 people in discussion
Those of you familiar with Reddit will probably know about the !remind me bot. Sometimes, especially when dealing with protected edit requests that haven't been discussed, I find that I want to come back to a conversation after a given length of time. That's why I'm proposing a Wikipedia !remind me bot.
This would work by the bot detecting instances of {{Remind me}}, something like the following:
The detection is clearly plausible, as AnomieBOT does the same for edit requests.
The bot would cache the asking user, and the time. After the time had elapsed, the bot could either reply below the reminder with a ping, or give a talkback on the user's talk page. Or it could be able to do both, and be configured by an option in the template. ∰Bellezzasolo✡Discuss 12:47, 15 November 2018 (UTC)Reply
I've worked on this in the past, and one (or several?) probably-not-ready extensions exist that could be deployed here. It's probably better to write the extension. Enterprisey (talk!) 04:15, 17 November 2018 (UTC)Reply
disband the Mediation Committee in entirety. And, all processes and components thereof, shall be marked as historical.
no consensus to pending-changes-protect the TFA page, as a default measure.This, obviously, does not affect the discretion of administrators to implement PCP at a TFA, (per the protection-policy), for purposes as may be otherwise deemed fit.
.svg){kind=small}
.svg){kind=small}
.svg){kind=small}
.svg){kind=small}
.svg){kind=small}
.svg){kind=small}
.svg){kind=small}
.svg){kind=small}
.svg){kind=small}
.svg){kind=small}
.png)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
looks like 
I think that if these icons are changed the other topicons should be changed too for visual continuity. I have created some ideas for simple versions of the good and featured article icons: File:Minimalist good article icon.svg and file:Minimalist featured article icon.svg. 🌸 WeegaweeK ^ 🌸 16:57, 30 October 2018 (UTC)
∰Bellezzasolo✡ Discuss 12:37, 15 November 2018 (UTC)
wikimedia.org? MER-C 13:28, 13 November 2018 (UTC)
