Wikipedia talk:Requests for comment

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Dispute Resolution
WikiProject icon This page is within the scope of WikiProject Dispute Resolution, a collaborative effort to improve dispute resolution practices on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
          A Wikipedia ad has been created for this project page. Click [show] to view it.

RFCs on Wikiprojects - a hijacking strategy[edit]

Background: I have been participating in wp: WikiProject Breakfast for several years. WP-Breakfast has always had very sparse discussion and when FLOW was looking for volunteer wikiprojects to test the software, I was instrumental in getting discussion there converted to FLOW. Since FLOW appeared to have serious software bugs, discussion was carried on in spurts of activity. However, recently a group of Wikiproject-outsiders suddenly materialized at WP-Breakfast for the sole purpose of running an RFC to stop the use of FLOW. The RFC squeeked through with a small vocal minority of editors who were never around before to contribute to any testing, and when I objected to this process and tried to ask questions I was told to go off and read wp:RFC.

If don't believe that this process which allows vocal minorities who happen to know all the correct buzzwords to hijack direction is in the spirit of wikipedia. Just my $.02. Ottawahitech (talk) 06:10, 7 January 2016 (UTC)please ping me

Ottawahitech I was the one who pointed you to WP:RFC and suggested you read it, for the purpose of informing you what a RFC is. Let me be perfectly clear what a RFC is. RFC stands for "Requests for comment". The very first paragraph says

Requests for comment (RfC) is an informal process for requesting outside input concerning disputes, policies, guidelines or article content. It uses a system of centralized noticeboards and random, bot-delivered invitations to advertise discussions to uninvolved editors. The normal talk page guidelines apply to these discussions.

What can we learn from reading this? Well its normal when a number of outside editors shows up at a RFC. Thats the purpose of a RFC, to get outside input on a question. Most of the time because there is an impasse with the editors on the page already. Unless you have some proof of WP:CANVASSING, that is the editors were specifically targeted and invited to the RFC based on how they would respond. Pointing out that the people who commented on the RFC were from outside is like pointing out that there are fish in the sea. Secondly, I know of no policy that places a specific number on the number of people that needs to comment before a RFC can be said to come to consensus. The rule is they run for 30 days, this one ran more, and that they are closed by someone who is uninvolved. I have never even seen the page before reading the RFC to close it. By your own words "WP-Breakfast has always had very sparse discussion". We are not going to see large groups of people responding. But the RFC was on the projects talk page, that page was the subject of the RFC. There is no need for a large group. The 10 or so responders are enough. So far I have not seen you point to one policy, guideline, or diff for what you are now placing on uninvolved pages, that can be considered forum shopping. I think it would be in your own best interests for you to find some policy, guideline, or diff soon. AlbinoFerret 07:32, 7 January 2016 (UTC)
  • What can we learn from reading this?
I have learnt, again, that wikipedia is a bureaucracy where a small minority of editors who spend their time making up the convoluted system of rules and regulations are those who decide things for the rest of us, never mind common sense or the philosophy on which Wikipedia was built. At this point I concede defeat and will let the rest of the this vast community have their say. Ottawahitech (talk) 15:48, 7 January 2016 (UTC)
  • Ottawahitech, A couple of points from an un-involved bystander - Do you not see the contradiction between your 2 complaints:
  • "a group of Wikiproject-outsiders suddenly materialized at WP-Breakfast"
  • "a small minority of editors ... who decide things for the rest of us"
Setting aside your personal investment of time/effort in FLOW - is it serving the needs of wp:WikiProject Breakfast? - Do you expect a discussion at wt:WikiProject Breakfast to be conducted for the benefit of Breakfast or of FLOW?
An RFC is an open request for comment, I don't think you can complain when "outsiders" offer comments at odds with your "small minority of editors". Regards, Bazj (talk) 16:49, 7 January 2016 (UTC)
  • @Ottawahitech: In reference to you saying "wikipedia is a bureaucracy where a small minority of editors who spend their time making up the convoluted system of rules and regulations are those who decide things for the rest of us, never mind common sense or the philosophy on which Wikipedia was built" (and this does not reference the issue of the RFC at the WikiProject, but only that statement): What you fail to see is that Wikipedia is a community of users and, just like the community where you live, some folks contribute to the community by participating in civic projects (for example, by attending and speaking at City Council meetings or serving on boards or commissions), others contribute to the economy by working, and others just live there. Anyone, however, can do any of those things. The "small minority" to which you refer would include you if you cared to join in, but just like in your city, if you don't care to join in then you either have to live by the policies that are adopted, argue for their inapplicability in particular situations, or decide to join in to get them changed. In fact, the barrier to entry into participating in those decisions is much smaller here than in the real world. All you have to do is to go to the talk page of the policy or guideline you think needs to be changed and propose the change. Why so many and so complex policies? Again it's the same reason as the real world: We get tired of addressing the same issues again and again and policies not only provide a standard answer, but they provide a consistent answer so that the same issue or question is not answered one way in one place and a different way in another place (with the "losers" in both places then yelling, "See, we were right, it was done our way over there!"). But each time you propose a policy, questions then arise how that policy is to be applied in particular situations. So for the same reason the policy was created in the first place, new sub-policies are formed and the "rules" become increasingly complex. Regards, TransporterMan (TALK) 15:37, 8 January 2016 (UTC)
RFCs are indeed intended to get the views of uninvolved editors. However, the views of uninvolved editors are largely irrelevant when the question is how a small group of editors should work together, per the official guideline at Wikipedia:WikiProject Council/Guide. WikiProjects have significant leeway in their internal operations.
In particular, if someone wanted to demonstrate that there is a widespread consensus to disable all Flow pages, then that editor would need to start an RFC on that point. The community can say "nowhere at all", but it cannot say "it's okay in general, but not on the page used by this particular little group". WhatamIdoing (talk) 18:05, 7 January 2016 (UTC)
@WhatamIdoing: "the views of uninvolved editors are largely irrelevant when the question is how a small group of editors should work together, per the official guideline at Wikipedia:WikiProject Council/Guide." Strange, I can find no mention of "uninvolved" there, and not one of the mentions of "involved" has anything relevant to say about your claim here. Nothing else in that texts seems to support your claim either, but I may have missed the relevant bit. However, the more important point is that, as stated at the MEdiawiki page, there is no consensus to enable Flow anywhere on Wikipedia, and no requests to enable a page will be granted. A long time ago, permission was given to have two temporary tests on two Wikiprojects, and an RfC has now decided that that temporary test is over. The wikiproject members have no authority to override that decision (they are free to participate in the RfC, which they did), and the wikiproject council guide has no bearing on this. The decision to end the Flow trial will also have zero impact on how the project works (or, in general, doesn't), no processes, discussions, ... will be made impossible or even more difficult. Fram (talk) 11:07, 12 January 2016 (UTC)
If Alsee wanted to demonstrate that there is a consensus to remove Flow from all pages, then Alsee should have (a) actually asked that question and (b) done so on a more appropriate page, e.g., a village pump. If there were actually evidence of a community-wide consensus to remove Flow from all pages, then the WikiProject would have to go along with that. But – and here you may want to go back to the /Guide again – WikiProjects are groups of people, and, like any other social group, they are most effective when given responsibility and authority over their interactions. "Outsiders" don't get to demand that they work or talk in a particular way. (All of us can insist that all of us work or talk in a particular way, but that's not what the instant RFC was about.) You can't use an RFC (or any other process) to force a single WikiProject to change its scope, to change the color on its banner, or anything else. You can use an RFC to force everyone to stop using the color green in the Wikipedia: namespace, if that's what the community wants to do, but to achieve that, the RFC actually needs to be about everyone, not about six editors who are occasionally working together in a small group.
This is all sort of academic: There were bona fide participants on both sides of the question, and strict exclusion of all non-participants might well result in the same result. (Also, the devs aren't bound by RFCs here anyway.) But in terms of procedures, and in terms of showing respect for volunteers who are trying to work together, this shouldn't have been an RFC, because the views of non-members/non-participants on the question of how participants ought to be permitted to talk to each other are actually irrelevant. When you're talking solely about that page (and that RFC was talking solely about that single page), then all that matters is the views of the actual participants. WhatamIdoing (talk) 01:41, 13 January 2016 (UTC)
WhatamIdong, as community liaison you should know better than to include technically correct but irrelevant and inflammatory aspects like "(Also, the devs aren't bound by RFCs here anyway.)" into such discussions. Yes, the devs can do whatever they like. And all that will achieve is huge problems for the WMF in the end, with the trust some people still have in it completely eroded, with every kind of attempt made to sabotage those devs in such an instance, and (in this particular case) with a huge backlash against Flow as well, as something that the devs would try to impose against our wishes. The Devs aren't boudn by RfCs here, and the enwiki community can decide to fork and leave the devs to play with an dying site. Neither is very relevant to the discussion here.
Alsee didn't want to "demonstrate that there is a consensus to remove Flow from all pages", the RfC was about the removal of it from one page only. But every discussion on enwiki has shown a great reluctance to allow Flow anywhere (apart from the one wt:Flow test page probably), and every Flow page that has been challenged (RfC or AfD) has been shut down so far.
And I note that finally, you have, as I have become used to, made strong claims in your initial post, "the views of uninvolved editors are largely irrelevant when the question is how a small group of editors should work together, per the official guideline at Wikipedia:WikiProject Council/Guide.", which you are unable to back up when challenged, but are unable to retract as well apparently. I know that you were answering here in your personal capacity, just like you happened to propose and defend the Breakfast project for Flow trial in your personal capacity, not your community liaison one, but please remind me why we would support a WMF cronie who regularly spouts nonsense about policies, guidelines, technical issues, or nearly everything that could put the WMF and their pet projects in a bad light, for the position of "community liaison"? Oh right, because you display the same attitude in your "personal" capacity when someone touches your pet project, no matter how dead as a dodo it is.
Flow is technically unfit to be deployed anywhere, an accident waiting to happen (remember when I blocked the echo notifications of dozens of editors with only 10 characters in a single Flow page?) and not having Flow is no problem for any of the discussions people theoretically might have on the project talk page. Your defense is based entirely on red herrings, and your comments about the freedom any project has, including the implementation of new software not wanted by the wider community, is not based on any reality.
TLDR: WhatamIdoing, stop talking nonsense. Fram (talk) 08:32, 13 January 2016 (UTC)
Fram, I try to rewrite my posts if I catch something like "cronie" in an edit-preview. (I do a plenty of rewriting, with mixed success.) We all need to work together and I try to remember that a rewrite might increase the chances of reaching a positive long-term outcome. Alsee (talk) 21:25, 13 January 2016 (UTC)
I usually do as well. With some people, the chance of reaching such an outcome is next-to-zero though. If you have had many discussions, on multiple topics, with the same person (sometimes in their WMF guise, sometimes in their personal-but-just-happens-to-support-the-WMF-preferred-outcome guise), and you have witnessed the frequency of their incorrect statements and their lack of correction once these things are pointed out, then you just give up hope for them. Using or not using "cronies" won't change this anymore. Fram (talk) 07:31, 14 January 2016 (UTC)
@WhatamIdoing I would like to point out a couple facts. 1. The RFC was started by a non member of the wikiproject. 2. Only 2 members participated in the RFC, both with remove Flow comments. Had more members commented and those members wanted to keep flow, the closer should take this into consideration in the close. But that isnt what happened here, "If "ifs" and "buts" were candy and nuts, we'd all have a merry Christmas." sounds about right for this discussion. AlbinoFerret 15:28, 13 January 2016 (UTC)
AlbinoFerret, there were more than two WikiProject Breakfast participants who commented during the RFC. For example, Ottawahitech is a long-time participant, and is also a proponent of keeping Flow on the page. But as I said above, ignoring the irrelevant POVs of non-participants would not necessarily change the end result. My interest in this discussion is a matter of principle, not a matter of practical effect in the instant case.
Fram, I'd be happy to see a diff in which I proposed enabling Flow at WikiProject Breakfast. I'll make it easy for you: The original proposal is right here, and my name isn't anywhere in it. I support the right of WikiProjects to determine, for themselves, the best ways for their group to work together. If they decide that they do or don't want Flow, then I support their decision. What I can't support is a couple of people who have personally contested this software in multiple forums trying to impose their antipathy for Flow on the WikiProject. If you want it off all pages, then you need to have an RFC about getting it off all pages, not an RFC about imposing your wishes on a small group that you don't even pretend to belong to. WhatamIdoing (talk) 17:09, 13 January 2016 (UTC)
WhatamIdoing please provide the diff where Ottawahitech signed his name to the member list. Because I cant seem to find it in the list. AlbinoFerret 21:06, 13 January 2016 (UTC)
AlbinoFerret, the membership lists are irrelevant. They're never up to date, they often overstate the membership by including people who signed up and then quit editing. There are many people who participate but didn't want to officially sign up (in some cases, "signing up" means getting spam in the form of newsletters). Some WikiProjects refuse to have them entirely. If you want to know who the actual participants are, then you look at comments (especially replies). For small groups, and all inactive ones, it's also a good idea to take a look at the active editors in the area, e.g., Wikipedia:WikiProject Directory/Description/WikiProject Breakfast. And since I know that it's impossible for everyone to know that such resources exist, then the easy "rule" to remember is that whenever you've got questions or disputes involving a WikiProject, then you should drop by WT:COUNCIL and ask. WhatamIdoing (talk) 02:42, 14 January 2016 (UTC)
So you dont have a diff? I disagree, to be a member of a wikiproject your name should be on the member list. Ill grant you if a member list does not exist then its harder to tell who is a member, but that isnt the case here, a member list exists. If your name is not on the member list, your not a member. The home page of Wikiproject Breakfast has a member tab thats quite large. Anyone can put their name on the list. If you havent , then your not a member. The whole argument is that "members" were ignored. Well so far IMHO only 2 members commented on the RFC, and they said remove flow. The rest is just arm waving and distractions. AlbinoFerret 04:41, 14 January 2016 (UTC)
Thank you for sharing your personal opinion. Speaking as one of the editors who has spent many years supporting WikiProjects, updating the guideline on them, helping people organize new ones, and resolving disputes between them, I'm telling you that your personal opinion does not reflect the general way these groups work. Adding your name to the list, and then never editing a single page within the project's scope (e.g., "Planecrashexpert", one of the so-called members), does not actually make you a participant. (And if you go back and look at my comments, you will find that I use the word participant almost exclusively.) WP:WikiProject defines a WikiProject this way: "A WikiProject is a group of contributors who want to work together as a team to improve Wikipedia." The link there is to social group, which defines that term in part as "a social group has been defined as two or more people who interact with one another". You cannot be part of a social group if you don't show up and interact with the other people in the group. But you most certainly can be part of a group even if you don't fill out a particular piece of paperwork. This fact is even recorded in the FAQ on WikiProjects: "What's the biggest WikiProject? Nobody knows, because not all participants add their names to a membership list, and membership lists are almost always out of date."
BTW, if you'd like to talk to someone else about this, then you might look at this Signpost report to find the names of some of the most experienced editors in this area, or you can post your question at WT:COUNCIL. But you're not going to hear experienced editors agree that a "member" who does nothing more than sign his name on the membership page is actually a member, or that a participant who is active in the group but never signs the membership page is somehow not a valid part of the group. WhatamIdoing (talk) 05:52, 14 January 2016 (UTC)
Thanks for sharing your personal opinion, FAQ's are not policy. Anyway this whole section is in the wrong place, and the RFC close was reviewed and passed, so this whole section is rather a waste of time. AlbinoFerret 06:55, 14 January 2016 (UTC)
So you didn't propose it and I was wrong about that, fine (see how hard that is, admitting when you have made a mistake?) I've done more Flow testing than most project members there, and that was the purpose of the trial, not some way to improve the prohect (which it hasn't done clearly). Not a single good argument has been given why Flow would be beneficial to the project, only some principled "stay of our turf" comments. You are free to make clear what you consider the best way for your group to work together, but a) no work is being done on that project anyway, and b) no indication of why Flow would be a better way to work together has ever been given. And I didn't start the RfC, but once such an RfC was started, I was free to participate in it. So don't lecture on what kind of RfC I should have started when I haven't started the "wrong" one to begin with. I have done my part in getting rid of Flow on pages that protested against getting it but got it imposed by the WMF anyway, I have done my part in testing the things that go wrong (or horribly wrong) with Flow, I know the problems in adminning Flow pages, I have read the messages of people removing Flow pages from their watchlist because of Flow (good way to promote Wikiproject participation). Are you even aware that your precious project (of which you aren't a member apparently) talk page is not even editbale by IPs and new editors? Yes, it has been protected since September 2014 because it is a Flow page (and not by me, by the way). So please explain again, for the benefit of all of us, how having Flow as your talk page format has helped the project and its members in any even minute way, and how keeping it in Flow format will be beneficial? Fram (talk) 21:08, 13 January 2016 (UTC)
  • I tried to avoid commenting here to let this section die naturally. Apparently it didn't work. Chuckle. We really shouldn't be debating Flow here, we shouldn't be debating the WMF-Community interaction here, we shouldn't be debating the close here (that was handled and resolved at Admin Noticeboard).
If/when I want to start an RFC about the site-wide status of Flow, WhatamIdoing is absolutely right. That is a Village Pump discussion. I've considered it, but I'm in no rush and I have other priorities at the moment. Of course anyone else on either side of the issue is welcome to start that RFC. It might be helpful to get clarity on what the general consensus is. It is common for people on both sides of an issue, any issue, to mistakenly believe they have more support than they do. If *I* am misjudging the general community consensus on Flow, I'd certainly want to know. I'd certainly ease up on my comments and actions.
Project Breakfast: There had been zero project activity in fourteen months. If it had been an active project then WhatamIdoing is right that the most appropriate action would have been to discuss it with the active users of the page. There was no one there using Flow, and one one there to request an end to the trial. In my opinion the obvious thing to do was open an RFC to try to draw people in to discuss the question. In my opinion it was perfectly appropriate for the community-at-large to ensure an inactive project is properly maintained for the benefit of attracting and serving future editors who may show up. The consensus of the discussion was that the inactive Flow trial was no longer serving any useful research purpose, and that maintaining Flow on the page had negative value for the future of the project and the community in general. Alsee (talk) 20:49, 13 January 2016 (UTC)
It doesn't matter whether the Flow page has objectively helped the group. What matters is what those editors want to do with it. And, yes, Alsee, I can understand why you assumed that the group was inactive (especially if you didn't know that projects which are actually inactive get tagged that way...), but it still would have been reasonable to post a friendly "Anyone home?" message before posting an RFC in which you request that outsiders impose their POV on a small group. WhatamIdoing (talk) 02:42, 14 January 2016 (UTC)
I agree that active users of a project should get substantial deference on how to run a project, within community-accepted limits. However I think you're coming uncomfortably close to asserting OWNership of a project that no one used in over a year. That is inactive, regardless of whether it is tagged. All pages are fundamentally owned by the community, to serve all current and future editors who might show up. Every Flow page has had activity drop to zero and there were very reasonable concerns that Flow may have contributed to the death of the project. That is a valid global-community-management issue.
I'd also like to note the thin consensus to activate Flow in the first place. Breakfast was converted to Flow based on a consensus of four, two of whom never used Flow once it was activated. The situation was egregious at Hampshire. The WMF declared a consensus existed to convert Hampshire to Flow after a whopping two people Supported and two people Opposed. Staying on topic for this page, a weak consensus is easily reversed. Alsee (talk) 05:13, 14 January 2016 (UTC)
The valid global-community-management issue is whether Flow ought to be present on any production page – which is not the question you asked. The community wouldn't have a valid reason to impose the views of non-participants on the actual participants, over the objections of the participants (assuming, of course, that the actual participants really did object, which is doubtful). Or, to put it another way, you have a good reason to ask them about whether they still wanted Flow on that page, but you did not have a valid reason to ask BethNaught and Fram (to name two firm opponents of Flow, who never participated in that group but still showed up to vote on this RFC) whether WikiProject Breakfast still wanted Flow on that page.
This is "ownership" only in the sense that you have "ownership" of your user space: The person who "lives there" deserves some respect. The community has the right to declare that nobody may do something that seems harmful on their user pages, but it does not have a right to declare that you individually, having committed no offense, may not do what is (theoretically) permitted to anyone else. The community is not supposed to treat individuals or small groups of editors so arbitrarily and capriciously. WhatamIdoing (talk) 06:01, 14 January 2016 (UTC)
Alsee didn't ask me anything, he asked all editors to give their opinion. Note that actual long-time project members asked to disable Flow from that page a long time before the RfC. Note also that editors and admins have lost time only because Flow was used on that page. And finally note that using Flow for your talk page (user or project) is not "permitted to anyone else", contrary to what you imply; and that there is no "you individually" here, this is a group effort, with members, passers-by, admins, and everyone else who may come into contact with it. In your view, someone like Doug Weller (a long time member opposing the use of Flow) may not, "individually, having committed no offense", do what is permitted to anyone else, i.e. use the standard talk page for his project communication, instead of Flow. Please think about what you use as arguments before posting them, it would help if you stuck to the convincing and reasoned ones and dropped the untenable or irrelevant ones. Fram (talk) 07:31, 14 January 2016 (UTC)
"you did not have a valid reason to ask BethNaught and Fram (to name two firm opponents of Flow, who never participated in that group but still showed up to vote on this RFC) whether WikiProject Breakfast still wanted Flow on that page" - I'm assuming that is just poorly worded, but for the record I did not Canvass anyone to the RFC.
And since we keep circling back to the topic of asking the community-wide question, WhatamIdoing would you like to collaborate on a Village Pump RFC? 1: Ask if we want to enable the new opt-in Flow User_talk pages. (I'm opposed, but that question certainly belongs in the RFC.) 2: Sort out expectations for creating/removing Flow pages in general. 3: Whether to keep the three(?) remaining Flow pages on EnWiki. The only one with significant activity is the Flow testing page, which makes that one rather circular in purpose. Alsee (talk) 09:13, 14 January 2016 (UTC)

Why removed from list?[edit]

My request [1] was added on 7 January and removed on 9th without any input from an uninvolved editor. Why? HerkusMonte (talk) 13:37, 9 January 2016 (UTC)

I'm not an expert on this, but it was removed by the maintenance bot, not by an editor, and I rather suspect that it was because the talk page where it was posted was moved to a new name a few hours after you made the RFC request, which caused the bot to believe that the RFC tag had been removed and it thus unlisted it. I'm not sure of any of that, but it seems highly likely. This is, again, a guess, but you can probably get it reposed by removing the current RFC tags (and you only really need one, not three) and putting a new one on that section. Someone more familiar with how the bot works may, however, say this is all wrong. Regards, TransporterMan (TALK) 21:29, 9 January 2016 (UTC)
HerkusMonte, I've re-formatted the section, and it might work better now. Please {{ping}} me if it doesn't get listed within the next couple of hours. WhatamIdoing (talk) 01:49, 13 January 2016 (UTC)

Making thorough pre-RFC discussion mandatory[edit]

BullRangifer has made changes making "thorough" pre-RFC discussion mandatory. I support these changes (with a couple of tweaks I intend to make after posting this), but would note that so far as I know, they are a change, not a reflection of the current state, as noted in the [[WP:DR|Dispute Resolution Policy, "Requests for Comment generally require that at least an effort be made to discuss the matter in question before making the request.", and at the Responding to a failure to discuss essay: "As noted in the Dispute Resolution policy, all content dispute resolution procedures — Third Opinion, Dispute Resolution Noticeboard, Request for Comments (though the requirement is very weak there<ref>Indeed, it is so weak at RFC that it may only be a pointed suggestion, not a requirement..</ref>)" I support them because collegial discussion is one of the foundations of the encyclopedia and allowing dispute resolution with little or no discussion discourages that. Best regards, TransporterMan (TALK) 22:15, 10 January 2016 (UTC)

I agree with strengthening the previous language, although it might be a good idea to acknowledge limited exceptions. If there are good reasons to think an RfC would be necessary, then WP:NOTBURO is relevant. Policy RfCs, for example, especially if written by someone already intimately familiar with the policy and its history. (Or some cases on controversial articles, but in that case they're also much more likely to be frivolous or vexatious.)
I'm not really sure what change would work though, at least not without leaving an opening for wikilawyering, and I expect this would cut down the numbers of poorly considered RfCs. In the meantime, if this model has been successful at DRN I'd support giving it a try. Sunrise (talk) 23:07, 10 January 2016 (UTC)
TransporterMan, thanks for the support, and I welcome any improvements on my fledgling attempt to improve the existing policy. We both feel it was too weak. A "suggestion" has no teeth and disruptive editors will ignore it. Changes should aim to hamper disruptive editors, not normal and proper discussion and local consensus. It is editors who, as soon as they see that they may not get their way, try to make an end run around these processes by prematurely starting an RfC, who need to be stopped by firmer wording. -- BullRangifer (talk) 23:38, 10 January 2016 (UTC)
  • I don't think you can really make it mandatory. Good editors are just going to ignore it when it's appropriate to do so, and it's not likely to prevent bad RFC's from being posted. I don't think there's much you can do to avert the problem of people who "know" they are right, and who mistakenly believe the world is on their side. In many cases the best route is to just let them get squashed by their own RFC.
I was considering suggesting say that it is permissible to take down an RFC once to pursue local discussion and/or pursue agreeable-neutral language, if the RFC has not yet received more than one support (aside from the author). Unfortunately that would probably invite just as much trouble. You can't write good-judgement into policy. There were three times I flat-out took down bad RFC notices. All my takedowns were uncontested, well applied IAR. In one case the RFC author actually thanked me for averting the impending trainwreck.
Are there specific problem cases you could point to? Maybe that will clarify what policy change might help. Alsee (talk) 00:52, 12 January 2016 (UTC)
P.S. In the takedowns I was a non-participant, responding to RFC-feedback-requests. Two of the three were formatted as preemptive closes. The one where I was thanked was a naked takedown, noting why it was going to go badly, with a comment to collaborate on a new neutral RFC question. Hmm, I think I did another naked takedown at village pump, but I don't recall the details. Alsee (talk) 01:19, 12 January 2016 (UTC)
We who work in dispute resolution at 3O, DRN, and formal mediation take down or refuse requests all the time for lack of thorough or extensive discussion and are almost never challenged on it. I recognize that RFCs are a bit different, but I wouldn't be surprised if we got the same result here. One difference, however, that might need to be clearly said here (perhaps in a footnote) is that the RFC takedown should only be done by someone who's not been involved in the dispute or been involved in editing the article or the talk page up until that point. That's almost never a problem at the DR forums, but this might be a bit different. Regards, TransporterMan (TALK) 20:03, 12 January 2016 (UTC)

I'm going to go revert nearly all of this in a moment. I understand and sympathize with the impulse, but what you've written is really not going to work in practice. You've accidentally declared that RFCs cannot be held unless there is a "dispute"; that RFCs cannot be held if you believe that the WP:LOCALCONSENSUS is wrong, that useful RFCs cannot follow confusing ones, and that RFCs cannot be held unless you already have other participants in a discussion. And none of that is true, as all of you know.

You may be surprised to hear me object to this, since I've just been chastising Alsee for opening an RFC at WikiProject Breakfast rather than having a friendly chat with the locals. Your wording would have made his RFC "illegal". But that's actually evidence that these new rules aren't desirable. The problem with Alsee's RFC was the special nature of the page; if he'd done the same thing for any non-WikiProject page in the Wikipedia: namespace, then beginning with an RFC would be the absolutely normal, expected, and appropriate.

Alsee, on your comments about takedowns, I agree with you. We don't even admit that it's possible (although IAR is core policy), because it leads to (has actually led to, more than once) disastrous meta-disputes. The takedowns are almost never done by people like you or me; they're almost always done by the person whose (perceived) POV pushing is the root cause of the RFC. We don't want rules that say woo proponents and COI-abusing editors are always permitted to takedown every RFC that Brangifer starts, not even once (and certainly not once per editor!) because it inflames disputes rather than resolving them. There are philosophical/ethical issues with this omission (not mentioning that IAR applies means that people like us have even more advantages over newbies, which isn't ideal for writing instructions or policy making), but we had a long discussion a couple of years ago about who, exactly, is permitted to withdraw an RFC early or change the contents, and the current rules (which can be massively oversimplified as "don't touch someone else's RFC") were chosen as the least-bad option.

On the general question, I assume that you're concerned about a proliferation of "needless" RFCs. There are several approaches we could take:

  1. We could more clearly state that most discussions don't require RFCs.
  2. We could more clearly encourage prior discussion, e.g., by providing links in the RFC template to relevant talk page sections.
  3. We could reduce the reward for holding an RFC, e.g., by making it more onerous to have the "consensus" formally enshrined in a closing statement, or by changing the standard closing templates to directly state that consensus can and does change or that the closing statement is an effort to describe the result and not a binding rule issued by a judge.
  4. We could decide not to worry about it. For example, we could decide that reaching out impartially to the whole community might actually be a good thing.

If I see an easy way to incorporate some of these ideas, I will try to do that now; feel free to boldly try again, having thought through some of the feedback here. WhatamIdoing (talk) 17:26, 13 January 2016 (UTC)

I agree in principle with having pre-RFC discussion be mandatory, as long as there is no requirement that it come to a conclusion even as to what the RFC should say. If there has to be agreement on what the RFC should ask, the RFC can be blocked by a stubborn editor or civil POV pusher, and sometimes an RFC is the only way to deal with a civil POV pusher. (An uncivil POV pusher can be blocked for incivility.) The comment about RFCs being taken down by POV pushers is well taken. Also, does discussion at third opinion or the dispute resolution noticeboard count as valid pre-discussion? Robert McClenon (talk) 18:01, 13 January 2016 (UTC)
If you're required to have a discussion, then how would you start an RFC on a page that nobody's watching? Could I prevent you from starting an RFC by refusing to engage on the talk page? WhatamIdoing (talk) 19:37, 13 January 2016 (UTC)
Why would you want to start an RFC on a page that no one is watching? If no one is watching the page, then just be bold and edit the page. As to preventing an RFC by refusing to engage on the talk page, that is similar. If one editor proposes an RFC and another editor says nothing, then just go ahead and edit the page. Robert McClenon (talk) 21:18, 13 January 2016 (UTC)
There are always ways to get around refusal to discuss. At Third Opinion, I had a request from a registered editor, who was making an addition to an article and was being reverted by an unregistered editor who wouldn't contribute to the talk page. I couldn't offer a Third Opinion, but I suggested that the registered editor request semi-protection. Robert McClenon (talk) 21:18, 13 January 2016 (UTC)
More generally, why do you need an RFC is there is no discussion? Robert McClenon (talk) 21:18, 13 January 2016 (UTC)
Why would you want to start an RFC even if nobody's watching the page or talking to you?
  1. Maybe because you just wrote the page, you want to have it declared a guideline, and WP:PROPOSAL recommends an RFC? You can't just boldly slap a {{guideline}} tag on a page (not since October 2008, anyway ;-).
  2. Maybe because you know that something needs fixing, but you can't or don't know how to fix it yourself?
  3. Maybe because there's an official policy about being WP:CAUTIOUS, and you believe that getting advice in advance is a good idea in that instance?
In the 'refusal to discuss' issue, you're just not getting it. (This probably says good things about your moral character.  :-) If we say "no RFC until there's a discussion", then you can edit, I can revert your edits, you can post to the page, and I can ignore the attempt to discuss and keep reverting your edits (within the limits of 3RR and other forms of edit warring) – and it'll be "illegal" for you to start an RFC until you can prove that there was "a discussion". "A discussion" requires comments on the same subject from more people than just you. If we require that, then bad actors will sometimes be able to deliberately prevent good-faith, collaborative editors from starting an RFC. This doesn't serve the community or the encyclopedia. If you're stuck with a person who refuses to discuss a problem, then you should definitely be able to start an RFC. WhatamIdoing (talk) 03:00, 14 January 2016 (UTC)
+1 to WhatamIdoing's comments. Excellent points, well said. Alsee (talk) 20:04, 13 January 2016 (UTC)


I will try to address User:WhatamIdoing's concerns, which seem mostly to be about users who deliberately refuse to discuss. With regard to wanting to make something into a guideline, I would suggest discussing at the Village Pump. Also, while the topic of this thread is about making pre-RFC discussion mandatory, does the proposed language actually say that discussion is mandatory, or only that it is strongly encouraged? It seems that WhatamIdoing is very concerned about editors who deliberately say nothing in order to sabotage a change, when I see combative editors as more of a problem. As to editors who revert changes and will not discuss them, there could be language stating that if one editor has attempted to raise an issue on a talk page and there is edit-warring without discussion, that the edit-warring takes the place of discussion in allowing the RFC to go forward. Robert McClenon (talk) 18:40, 14 January 2016 (UTC)
You said that you would suggest starting a discussion at the Village pump. Did you know that the official policy on this subject says to "start an RfC for your policy or guideline proposal in a new section on the talk page"? WhatamIdoing (talk) 05:51, 17 January 2016 (UTC)

The inspiration for several of my (now reverted) edits, which received many "thanks" from other editors, was a disruptive editor who has at least twice "prematurely" started RfCs when they could see that a discussion wasn't going their way, even though a local consensus had formed. These premature RfCs are disruptive and violate the principles of the collaborative editing process.

When I say "inspiration", it's more a case of the "straw that broke the camel's back," since I've seen such misuse of RfCs before, and it needs to be stopped. This was just a strategy used by one disgruntled editor, and it was very disruptive because it derailed all previous efforts and created a paralyzing atmosphere in which no one dared to do anything more.

Here we had a disgruntled editor trying to disrupt the process of collaboration and consensus building so they could get their way. In one case they canvassed a large number of editors and started an RfC elsewhere than the article's talk page. None of the involved participants had a clue what was going on, and the RfC used very misleading wording, painting a horrible picture which no sane editor would approve, so the disruptive editor got a quick majority to block the consensus on the local article talk page. That's why we need to ensure that a good discussion has happened, and that a deadlock is preventing progress. Then an RfC is proper to break the deadlock.

Keep in mind that an often significant disadvantage of bringing in uninvolved editors is that they don't know the circumstances, and rarely perform due diligence investigations. They are easily swayed to make a decision based on incomplete and misleading "evidence" in what may be very complicated proceedings, thus thwarting a local consensus which is just about to finally resolve a whole lot of problems. This bumps everything back to a stone age situation, with all progress blocked by one disgruntled editor who, by prematurely using an RfC, wasn't willing to allow the local consensus to do its work. -- BullRangifer (talk) 03:46, 14 January 2016 (UTC)

BullRangifer, you should add links to that. Without links I reflexively apply a 50% chance that the goodguy/badguy roles are revered. It's also unclear if it could have been dealt with by applying other existing policies, or what policy change would have been effective. Alsee (talk) 05:51, 14 January 2016 (UTC)
Alsee, you can safely trust BullRangifer's story here. He's dealt with a lot of unusually difficult and protracted disputes, and the only that should surprise you is that he didn't run screaming from project years ago.
Brangifer, I need a way to determine what a "premature" RFC is. (The "wrong page" RFC is straightforward, and CANVAS already exists.) But what's "premature" (e.g., versus carelessly written), and how do I keep a good-faith newbie from getting in trouble for it? WhatamIdoing (talk) 06:08, 14 January 2016 (UTC)
WhatamIdoing, I understand the wish to have some reliable way to determine whether the timing is "premature", but that will likely always be a judgment call. The cases I refer to above were instances where the editor chose to not stick with the discussion, but essentially went screaming to mamma for help, because all the other kids wouldn't allow him to change the rules or let him play according to his own rules, to use an analogy from childhood. The analogy isn't perfect, but the idea is that the editor didn't collaborate or honor the consensus, but, upon seeing that a consensus had formed, or in once instance "might" form, against their POV, they just started RfCs which were disruptive, and in one case were very deceptive.
A third instance comes to mind, which was recently shut down before really getting started, because it was so ridiculous that other editors agreed it should be closed. So there are actually three times the editor did this. Sticking to the topic, staying with the discussion, and honoring the consensus when it doesn't go your way (failure to do that sums up IDHT behavior), that's what the editor fails to do, and we need to encourage all editors to really deal with the issues on the talk page, with the other editors there, without crying for mamma to intervene. OTOH, if no consensus can be reached, or there are serious policy violations, that's a different matter, but that wasn't so in any of the cases above. Alsee, I choose not to provide diffs or usernames as that would end up causing a renewed shitstorm and distract from the basic issue here. Their input here is unnecessary and would be unproductive.
My edits here may not have been the best method, but it was an attempt, and I am totally open to discussing better ways to get editors to not use RfCs as part of their IDHT behavior. I would like to see at least a partial restoration of some of my edits, but please improve them. -- BullRangifer (talk) 06:55, 14 January 2016 (UTC)
Your edits are getting people to think about what could be improved here. "Premature" isn't the clearest way to describe this, and "as part of your IDHT problem" will fall on deaf ears, as it were. Maybe we could base a statement on the idea of consensus and collaboration? I don't have an instant solution (perhaps someone else will?) but I think we can improve in this area. I don't believe we can go quite as far as you might wish (on somedays, at least). It's got to work for typical situations, not just the most vexing ones. WhatamIdoing (talk) 18:22, 14 January 2016 (UTC)
Well, I'm glad it's getting people to think about some improvements. Let's not stop with thinking, and let's not let an inability (even if temporary) to make a perfect solution keep us from making imperfect steps in the right direction. No solution will ever cover all situations, but some of my wording could still prevent some abuse of RfCs.
I think restoring "premature" in some manner would help. "Premature" means starting RfC without first attempting a discussion, or to short circuit/sabotage an existing discussion. The idea is to emphasize the primacy of seeking local consensus first. Here was my first attempt.
BTW, maybe that's a typo, but I wrote "their IDHT behavior", not "your"... Face-wink.svg.
Also (totally different topic here), I'm a bit uncertain about the meaning of "new one" in your restoration of "essays". Edit summary: "We actually do use RFCs on essays, e.g., to decide whether to start a new one." Do you mean to start a new essay, or start a new RfC? Since essays are not governed by many of our policies, quite notably NPOV, there is no one "right" version, and dissatisfied editors are encouraged to just write a new essay, rather than try to force an essay to change the POV intended by its author. Editors should seek to improve an essay, not try to change its POV, even if the POV isn't totally aligned with current policies. If they really disagree, they should write their own essay. -- BullRangifer (talk) 15:58, 14 January 2016 (UTC)
I agree with you about the essays, but we have occasional RFCs about whether someone's effort to change an essay is sufficiently divergent to be worth splitting and about whether an editor can be forced to split his POV off a popular essay, onto a new/unread/unlinked/unpopular one. (In fact, the advice at WP:Wikipedia essays on that point was the result of one such dispute.)
Does something like "when a productive discussion is currently underway" sound a bit like the concept you're aiming for with "premature"? WhatamIdoing (talk) 18:28, 14 January 2016 (UTC)
Your diff is exactly the content I agree with and am referring to! I had forgotten it was you who wrote that. It's really good. There is no one "right" version of an essay, and later I added to that.
I'm not sure how it will look, so go ahead and try it so we can see it. It looks like a step in the right direction. -- BullRangifer (talk) 03:35, 15 January 2016 (UTC)
I like your expansion; it should be clear to editors who are sincerely seeking advice on that point and very functional the next time we run into one of those disputes.
I wonder whether you'd like to have a go at working on Wikipedia:Writing requests for comment. It needs some work (it's a solid draft, but not "finished"), and it might give us space to work out a few ideas without risking anything on the "official" page for a while. I'm currently toying with the idea of a section like == Make sure your RFC isn't going to backfire == (only in more formal language, of course). But I'm not sure it would help; I need to think about it. WhatamIdoing (talk) 05:47, 17 January 2016 (UTC)
WhatamIdoing, I think a section like that would add a lot. Please edit boldly! BullRangifer, I'll second the invitation. Sunrise (talk) 00:12, 18 January 2016 (UTC)
I agree. That sounds like a good way forward. -- BullRangifer (talk) 00:19, 18 January 2016 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── BullRangifer says, above, that, in his opinion, "'Premature' means starting RfC without first attempting a discussion, or to short circuit/sabotage an existing discussion." I can only agree with half of that, the "without first attempting a discussion" part. I don't think that there is, or can be, an attempt to short circuit or sabotage an existing discussion by filing an RFC since the very purpose of RFC's is to bring additional editors into a discussion (but see later in this posting about consensus). (As an aside, let me note that in the rest of DR, the purpose of requiring discussion is merely to enforce the collaborative goal of Wikipedia, that people should at least be held to making a reasonable attempt to working out their disputes before seeking help from others. But that's all.) One other thing that we do which is related to the "prematurity" discussion above is that at DRN and MEDCOM we won't take a case where there's already a clear consensus (and, ordinarily, in the situation where there's exactly one editor continuing to bang her/his head against that consensus) on the logic that there is no longer a dispute to be resolved. However, we only do that when the consensus is unmistakably clear. When it's less than unmistakably clear, we'll let the case move forward. I think that we need to be careful here not to create a lot of drama about whether or not RFC's are available because of one or more editors asserting that there is consensus. I'm — mostly — okay with the idea that RFC's shouldn't be available when a discussion has already resulted in an unmistakably clear consensus, but my feeling is that they ought to be available any time consensus is less certain or is still being formed. Best regards, TransporterMan (TALK) 17:25, 17 January 2016 (UTC)

One more thought in a slightly different direction, if we do get a discussion requirement I wonder if we shouldn't exempt policy and guideline creation and modification? We should be encouraging full-community discussion of those changes and though local discussion can modify them, the "high road" is to immediately get the entire community involved and one way to do that is through RFC, along with listing at the Village Pump and at Centralized Discussion. Especially (but not only) with new policy creation just immediately putting up the proposal in the form of a RFC should be acceptable. For changes to existing policy, discussion on the (existing) talk page as a feeler is always a good idea, but for the same reason it doesn't seem to me that it ought to be required. — TransporterMan (TALK) 17:40, 17 January 2016 (UTC)
I agree with User:TransporterMan's comments. What I see is several experienced editors saying that prior discussion should be either mandatory or strongly encouraged, and I see two editors who disagree, because of concerns that prior discussion could be stonewalled. I think that there is a rough consensus in favor of strengthening the language on prior discussion. I think that exempting policy and guideline RFCs is a good idea. Robert McClenon (talk) 18:10, 17 January 2016 (UTC)
That seems like a reasonable summary.
I can see how RfCs about PAG could be started sooner, since the subject isn't about some complicated subject using lots of RS, history, controversy, and background, which requires that the participants have a good understanding of all that, and of all the article's editing history, and all the current and past (archived) talk page discussions. When it's about PAG, it's about what we already have as our background info for doing our work. Yet, some discussion should first occur on the policy's or guideline's talk page. If the discussion goes seamlessly forward, there is no need to bring in the whole community. If it's a minor tweak, then a local agreement should be enough, and no RfC is needed. OTOH, if the discussion only involves two or three editors and is a potentially controversial change, then others should be brought in. That's when RfCs should be used, not before. -- BullRangifer (talk) 00:02, 18 January 2016 (UTC)
As far as stonewalling is concerned, there are ways to break them without RfCs. BRD, IAR, and other DR methods can be used. Often the disruptive editor will end up behaving badly enough to get blocked, whereupon progress can move forward. So, I don't think we should allow stonewalling situations to affect making progress here. There are usually other methods for dealing with stonewalling. -- BullRangifer (talk) 00:02, 18 January 2016 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── As one who believes that prior discussion should be strongly encouraged, if not totally required, I am thinking mostly of articles, not PAG (although, to some degree, it should also apply to PAG, as I just stated above). All DR processes, including RfCs, are basically disruptive, because they create even more complication and often confusion. They should only be used when simpler processes aren't working. We should start by AGF with the local process and local editors who seek to collaborate and establish a local consensus. It's a bad faith move to seek to circumvent that process.

Bringing in many other editors, who rarely perform due diligence, can really screw things up. An article, especially a complicated and/or controversial subject, involves lots of RS, history, controversy, and background, which requires that the RfC participants have a good understanding of all that, and of all the article's editing history, and all the current and past (archived) talk page discussions. Uninvolved RfC participants rarely have that knowledge, and the one who starts the RfC will usually have picked some "weak" spot for the subject, and even if they word the RfC neutrally (also a relatively rare situation), they can thus derail or sabotage a consensus they do not like, or want to prevent. That can really block progress because it is uncollaborative. It is unfair to the other editors.

A recent situation requiring the renaming/moving of an article to a better title became extremely complicated because of spurious RfCs. Because new participants didn't realize that numerous previous RfCs had already ruled out certain possibilities, the rejected possibilities were constantly inserted, and then RfC closers made improper closures. It became a really cluster f###. Lack of background knowledge is the baggage brought by uninvolved editors. When their !votes show evidence of ignorance or that they have not performed due diligence, their !votes should be discounted, and no closer should act without thorough knowledge. It's a very different matter when using RfCs for PAG matters.

To prevent this type of disruption, discussion should be required until it either bogs down or no consensus can be reached. Then, by all means, go for it. Use RfCs and other DR processes. -- BullRangifer (talk) 00:02, 18 January 2016 (UTC)

Assorted comments:
  • I liked TransporterMan's language about making a reasonable attempt, and have therefore duly swiped it for the page.
  • Some editors – usually the lone POV pusher, but not always – really do start RFCs in an effort to disrupt, or at least delay, a decision that they expect to "lose". Some of these RFCs ask questions that are not entirely straightforward, so less-informed editors will sometimes agree that all right-thinking people are in favor of security, peace, and justice without noticing the bit about agreeing that Florida is in Canada, which is the actual thing under dispute.
  • One of these RFCs is bad enough, but sometimes you'll end up with multiple RFCs on the same page, on basically the same topic, started by the same person. This is rare, but can be painful. (Also, it frequently backfires against a disruptive editor, so it's not all bad.) However, we discussed limits a while back, and concluded that the medicine is worse than the disease. We can revisit that (or contemplate WP:TBANs for individuals) if that's gotten significantly worse since then.
  • How to change a policy or guideline is best handled at WP:POLICY. This page should avoid contradicting it (e.g., requiring RFCs despite WP:PGBOLD or prohibiting some RFCs despite WP:PROPOSAL), but otherwise can avoid it.
  • When you talk about "making discussion required", what do you see as a reasonable response if someone starts an RFC without prior discussion?
    Let's say that you are highly frustrated with me. Let's even stipulate that I'm clearly wrong, and that we've been around this block enough times that you have already determined that I'm incapable of reading a source that says "Florida is in the southeastern US" and concluding therefrom that Florida is not in Canada. You revert my claim that Florida is in Canada and start an RFC, in the hope that a dozen editors will show up and say that there is a consensus against Flordia being in Canada. I declare that you "haven't discussed".
    What's next? Do I get to blank your RFC now? Also, do you have to discuss the fact that you want to start an RFC, the exact question you want to ask, or just the general subject matter?
  • The quality of closes by NACs with zero expertise in the subject matter is an ongoing problem. For more than a year, a single NAC has been requesting that about 90% of expired RFCs get a formal closing statement, and a couple of NACs have closed many of them. Most of their closes are either pointless (e.g., officially declaring "it's unanimous" when any editor can see that) or harmless, but the results too often do not reflect an appropriate or nuanced application of policies about sourcing (which, of course, requires knowing something about the subject area). They're also not very good at figuring out which RFCs contain landmines and leaving those to someone with more skill, or at least an admin bit, so they get beat up a lot, too. It's a lose-lose-lose situation, but I don't think we'll be able to stop it any time soon.
    But the reason I mention this is that if you get a POV pusher with a "misleading" question, a handful of commenters who don't know anything about the subject or are being sloppy, and one of these NACs (and odds are pretty high there), then there is a small, but frightening possibility that you will end up with an RFC that declares that Florida is Canadian.
I'm (very) dubious about "requiring" a discussion, but I think we can do more to encourage people not to start RFCs for every single discussion. WhatamIdoing (talk) 03:03, 18 January 2016 (UTC)

Clarifying topics[edit]

I see that the page gives some details on the meaning of the "policies and guidelines" topic. There is another topic that appears to be commonly misunderstood, and I am going to add a similar clarification for that.

"Language and linguistics", under the "Article topics" heading is, it seems obvious to me, for issues concerning an article where the article topic is in the field of language and linguistics. But many people apparently take it to include all issues that involve the wording (language) of a Wikipedia page. This, of course, covers nearly every RfC and is not a useful category.

(I could see the utility of a category for issues that are about technical (not topical) English usage on specific Wikipedia pages, but there isn't one). Bryan Henderson (giraffedata) (talk) 23:18, 26 January 2016 (UTC)

Commenting in the wrong space[edit]

I've noticed that on many RfC, instead of clicking the RfC link and commenting in the article's talk space, people are actually editing the RfC list itself, and commenting there (a la AfD discussions). How about a template for all RfC list pages which states clearly to click the link to comment in the articles talk page (where the RfC discussion takes place) rather than the RfC list itself? See here as an example. Some people are commenting there rather than clicking the links. - superβεεcat  02:49, 28 January 2016 (UTC)

That's a good idea, but I suspect it would not be very effective. The people commenting in the wrong place aren't paying a lot of attention. Indeed, when you go to inappropriately edit that page today, there is a big warning at the top of the page telling you not to do it. Here's a better idea: Modify Legobot so it puts "to comment, click here" at the bottom of every entry. Bryan Henderson (giraffedata) (talk) 23:53, 28 January 2016 (UTC)
Hey, now that's a good idea. Where is the appropriate place to propose that? - superβεεcat  00:52, 29 January 2016 (UTC)
I believe the only person who can implement this is the owner of Legobot, Legoktm. So that user's talk page is where I would go. However, in looking at the history on that talk page, I'm not optimistic that you would get action, if any response at all. Bryan Henderson (giraffedata) (talk) 16:46, 29 January 2016 (UTC)
Yeah, not promising. I'll give it a go; if not, maybe the template idea. - superβεεcat  17:26, 29 January 2016 (UTC)
The thing is, unless I misunderstand, you'd need Legoktm's cooperation for the template idea too. Legobot creates the entire content of the RfC list pages. You can edit the page, but whether you're adding a template tag or adding one of those misplaced comments, Legobot will eventually undo it. Bryan Henderson (giraffedata) (talk) 21:21, 29 January 2016 (UTC)
Yeah, not getting a response. Are there some sort of ignore tags that can be used to keep legobot from meddling? - superβεεcat  19:48, 31 January 2016 (UTC)
You might be more likely to get a response at User talk:Legobot, Legoktm responded to a posting there just today. I agree that it's not a bad idea at all. Regards, TransporterMan (TALK) 21:51, 31 January 2016 (UTC)
Legobot isn't actually meddling; the RfC lists are designed to be created by Legobot; without Legobot, there's no page. Bryan Henderson (giraffedata) (talk) 22:14, 31 January 2016 (UTC)
No, I know, I meant meddling vis-a-vis a template added. Just as legobot doesn't meddle with user-added content in the list (which shouldn't actually be there, hence this discussion).  superβεεcat  03:57, 1 February 2016 (UTC)
We're obviously not communicating here. My understanding is that Legobot generates the entire page, so it can't help but eliminate that user-added content, as well as any template tag we might add. Legobot doesn't edit the page - it generates a whole new one without looking at what was there before. The only thing an ignore tag could do is shut down the generation of the RfC list pages altogether. If you think it works differently, please explain.
Actually, upon closer examination, I'm not sure the problem you brought up even exists. The two cases I see now on this RfC list are cases where the person creating the RfC incorrectly used the RfC template on the subject article's text page. That made Legobot think one of the responses was part of the request text, and that's why one of the responses shows up on the list page. I couldn't find a case in the page history of someone editing the RfC list page. Bryan Henderson (giraffedata) (talk) 04:35, 1 February 2016 (UTC)
Oh good pull, it may be a moot point after all. - superβεεcat  22:34, 2 February 2016 (UTC)

Feedback Request Service[edit]

The page says that, after bot notification:

"there may not be enough editors to get sufficient input. To get more input, you may publicize the RfC by posting a notice at one or more of the following locations ... [including] Talk pages of editors listed in the Feedback Request Service. You must select editors from the list at random; you cannot pick editors that will be on 'your side' in a dispute."

We had a recent situation of an editor apparently "randomly" choosing names from a particular sub-section of the feedback request service, one that had nothing to do with the RfC question. I would therefore like to change this for future RfCs.

If the choice is to be truly random, it should be done by a bot, so the first question is whether we could arrange for a bot to notify names at random from the list, on behalf of a particular editor.

Otherwise, if it's to be done manually, how do we tighten this to ensure that the category choice is more appropriate or that the choice of names is more random? Pinging Coretheapple, Sammy1339 and Nabla, who've been discussing this. SarahSV (talk) 21:20, 2 February 2016 (UTC)

Also pinging Legoktm, who runs Legobot. I believe Legobot informs people randomly about RfCs. SarahSV (talk) 21:24, 2 February 2016 (UTC)

The purpose of this guideline was to allow editors to publicize an RfC that received insufficient attention. SV's suggestion of allowing editors to request that a bot send out random notifications would be an improvement, but better still, perhaps a bot could automatically send out random notifications if there is little or no activity in the RfC during the first few days it is listed. This would address the other issue wherein, under the current rules, editors might selectively decide to send out more notifications whenever the discussion isn't going their way. --Sammy1339 (talk) 21:36, 2 February 2016 (UTC)

I'm hoping Legoktm will be willing to explain what triggers Legobot. I had always assumed it was something along those lines: an RfC that has received no input.
I'm not a fan of random notification. I want people at RfCs who may know something about the topic. It's sometimes worse than useless to have random people arrive, although this depends on the topic; there are times when it can be helpful.
If an editor is to make manual selections from the feedback list, they should at least be required to pick the most appropriate category: appropriate in the sense of more likely to know something about the topic's literature. SarahSV (talk) 21:52, 2 February 2016 (UTC)
Wikipedia:Feedback request service has some details on how it works. The bot doesn't check whether the RfC has received any feedback or not. Legoktm (talk) 22:27, 2 February 2016 (UTC)
Thanks, Legoktm. I was wondering how the random selection works with the bot. For example, does it do this for every RfC, how many people does it notify, and which sub-sections does it choose from? SarahSV (talk) 22:53, 2 February 2016 (UTC)
As long as the RfC is categorized properly and using the right template, then yes, every RfC. My quick read through the code suggests that it will notify as many people are eligible to be randomly notified, there's no hard limit on a per-RfC basis. The sub-sections used are basically determined by the RfC author, depending on what category they put the RfC in. Legoktm (talk) 09:23, 4 February 2016 (UTC)
Legoktm, what would "as many people are eligible to be randomly notified" mean? Does that mean that everyone on the feedback list for a particular category is eligible to be notified? How many of those would be randomly notified, and if the bot is doing that why does anyone do it manually? Sorry to keep asking questions, but I'm completely unfamiliar with this. SarahSV (talk) 19:33, 4 February 2016 (UTC)
  • I was actually surprised to learn about this aspect of the RfC guideline. Had no idea it was possible to solicit input to RfCs in that manner. I thought you had to sit back and cross your fingers. So one part of me says "Yeah! Great!" and another part of me says "This can be gamed." Coretheapple (talk) 15:08, 3 February 2016 (UTC)
    Isn't everything on Wikipedia like that? ;) Legoktm (talk) 09:23, 4 February 2016 (UTC)
  • I think we ought to change the manual aspect of this, because it's too easy to game it. SarahSV (talk) 19:33, 4 February 2016 (UTC)
  • I have to say I'm surprised there is a safe harbor for canvassing, if the canvassees are on the FRS list. Wasn't this taken into consideration at some point? Coretheapple (talk) 21:41, 4 February 2016 (UTC)
  • I also think the manual use of the FRS list should not be allowed, at all (except maybe on some extreme case). By checking the list of manual requests one would still be able to tell the obvious canvassing cases from the obvious non-canvassing cases. Still that practice may help to disguise some clever canvassing cases. On top of that, to me, the advantages of the FRS list, as a responder, are that there is guaranteed statistical independence between the requests and my previous opinions. One surely may think of ways of refining who gets asked to participate in what decision, to get better input for the discussions, and better satisfaction for the respondents, but this one is not bad. Also, the FRS list has a limit parameter. To me the occasional reminder to jump in is especially useful given that sometimes I 'forget' about WP for a while, but, for the same reason, I want a small few per month, not as many as someone else wants to. Manual use of the list breaks that functionality. All in all, it may result in *less* feedback, if we keep the manual requests, because maybe some more users don't want to be handpicked, and more often than their desire. I know I don't, so I removed myself from the list. If it is just me, it is a unnoticeable loss, but maybe there are more...? - Nabla (talk) 18:39, 7 February 2016 (UTC)