Jump to content

Wikipedia talk:Requested moves/Archive 32

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 25←Archive 30Archive 31Archive 32Archive 33Archive 34Archive 35

The utility and accuracy of ranked surveys

Occasionally participants in RM discussions need to choose from more than one alternative to the current title. One way to do this is a ranked survey, where participants rank the choices in order from most favored to least favored. I think the utility and accuracy of such polls is largely unappreciated, and deserves some attention.

In a recent RM at Talk:Chairperson/Archive_3#Requested_move_22_March_2019, which originally proposed Chairman → Chair (officer), the discussion got messy as other choices seemed to be favored. So another ranked survey was started with four choices at Talk:Chairperson#Ranked choice survey. At first glance the result of that survey might not be obvious, but since each participant ranked four choices relative to each other, one could easily determine preferences between any two choices for each participant. Now, what was obvious from that ranked survey is that it was between Chairman and Chairperson. And, again it was easy to see whether each participant favored Chairman over Chairperson or vice versa. For example, I ranked Chairperson 3rd and Chairman 4th, indicating I preferred Chairperson over Chairman, even though Chairperson was only my 3rd choice. The results of doing this simple analysis for each participant revealed that 60% favored Chairperson over Chairman.

Now, for reasons I still don't quite understand, despite attempts to explain this at the closer's talk page, the closer did not recognize this 60/40 consensus favoring Chairperson over Chairman, and neither did enough of the participants in the subsequent month-long MRV to overturn the close or reopen the discussion.

So, after the MRV was closed, there was yet another RM, Talk:Chairperson#Requested_move_8_May_2019, which explicitly proposed Chairman → Chairperson, involving even more people. And the result of that RM, of course, was 60% favored Chairperon over Chairman (a ratio which stayed pretty steady throughout the life of the discussion). That is, the results of the traditional two-option RM survey were practically identical to the inferred results for those two choices in the 4-option ranked survey over a month earlier.

Let's take an example to make this really clear. If the choices are between A, B, C and D, and the results look like this:

  1. B, D, C, A
  2. B, A, C, D
  3. C, B, D, A
  4. C, D, B, A
  5. B, A, C, D
  6. D, C, B, A
  7. D, A, C, B
  8. A, D, C, B

We can see that the favorite is either B or C, but is either favored sufficiently more than the other to establish consensus? What do you think? It's easy to look at this and conclude "no consensus", right? After all B is the first choice for only 3, C and D for only 2. But let's look only at whether each favors B or C over the other:

  1. B
  2. B
  3. C
  4. C
  5. B
  6. C
  7. C
  8. C

So it turns out that 5/8, or 63%, favor C over B. In other words, consensus favors C over B. No need to have another C vs B RM!

In conclusion, I hope everyone appreciates the utility and accuracy of ranked multi-choice surveys for determining consensus between the obvious two top choices of several considered in an RM discussion, and understands how to read them. It's worth a few minutes of analysis to eek out the preferences between any two choices.

I know that these ranked surveys could be even more accurate for assessing consensus if participants would weight their choices accordingly, a method SmokeyJoe advocates. But I think that is more complicated than necessary and it's challenging if not impossible to get people to do it. I'm confident we can determine consensus with sufficient accuracy without adding the complication of weightings to the process.

Pinging some of the active participants and closers in the discussions references above:

@Red Slash:, @Amakuru:, @SmokeyJoe:, @SlimVirgin:, @Winged Blades of Godric:, @Levivich:, @JFG:, @Fyunck(click):, @Calidum:, Netoholic

Thoughts? --В²C ☎ 22:39, 15 May 2019 (UTC)

  • What I'm proposing is a rewrite of the above to be incorporated into new sections of WP:RM and WP:RMCI on rank surveys and how to read them, respectively. --В²C ☎ 22:58, 15 May 2019 (UTC)
  • Polling is not a substitute for discussion. – bradv🍁 23:17, 15 May 2019 (UTC)
    • I would hope that that goes without saying among watchers of this talk page. But, in the end, once discussion establishes strong arguments on both sides, polling is often the deciding factor in RM closes. As important as weighing the arguments is, the vast majority of RM closes are consistent with polling results. Rarely does a close go against the majority "vote". All I'm saying is that you can often eek out consensus from messy-looking ranking surveys (again, assuming there is discussion backing it up). --В²C ☎ 23:46, 15 May 2019 (UTC)
    • Polling is not a substitute for discussion is true, but polling can follow discussion and is very often the only alternative to a "no consensus" result. ―Mandruss ☎ 23:48, 15 May 2019 (UTC)
  • Voting is evil, and ranked voting brings out the worst of it. There are so many tactical games, accidental innocent or contrived. Read Comparison of electoral systems.
For multi-option RMs, I think Score voting is the best.
For every option, give it a score. eg 8/10; "excellent"; "poor but acceptable"; or "No". In practice, only score the viable suggestions. This works well for consensus decision making, because it lends itself to, even implicitly demands, an explanation for the score you give. People can then discuss the reasons for high or low scores for particular options. --SmokeyJoe (talk) 23:55, 15 May 2019 (UTC)
I agree in theory but I think score voting is much too complicated for Wikipedia. Even ranked voting makes some eyes glaze over. I'd support adding some verbiage to policy pages about the proper use of polls. Leviv ich 00:01, 16 May 2019 (UTC)
I don't know how you can think that. Have you read much on evaluated complicated voter preferences? Maybe you just mean that it is easier for a voter to rank candidates. Leave the evaluation of the votes to someone else? That is not how consensus decision making works, it does not leave the evaluation to others.
A>B>C>D tells you nothing of strength of argument, and it makes it too easy for the !voter to not even try to seriously explain.
A = 8/10
B = 7.5/10
C = 5/10
D = 0/10
The above scores each beg an explanation, and each can be individually discussed in isolation. It is harder for the !voter because they have to address every option, but that makes the evaluation by others so much easier. --SmokeyJoe (talk) 01:15, 16 May 2019 (UTC)
Let me rephrase: score voting is too complicated for Wikipedians. For example, we'd need a script to take votes and do the math, because no closer will want to do that by hand (and if they do, there will be math mistakes). If it's open balloting instead of secret balloting, late voters will have an advantage, being able to see the early votes. Extremist blocs (voters who ascribe a 10 to one option and 0 to all others) will be successful in skewing all voting results, which will lead to closers having to discount such votes, which will undermine the entire system in the first place. All in all, too much complication for a volunteer community that is already averse to voting, and where practically nobody has any training or experience in running an election or conducting a poll or survey. You're right in theory that weighted preferences are better than non-weighted preferences for a number of reasons, but in practicality, for this community, I think you're like five steps too far ahead. Consider, for example, the knee-jerk bluelink reaction one gets anytime they mention voting anywhere on this website. Leviv ich 01:42, 16 May 2019 (UTC)
You miss an important point. Do no math. Have people !vote by scoring, I gave example scores out of ten, but accept free text. Adding one persons scores to another persons scores is an algorithm, not consensus. The benefit of scoring every option is that it invites questions on specific scores, which leads to a break down of why people are saying what they say. --SmokeyJoe (talk) 02:17, 16 May 2019 (UTC)
So you're saying use it as a discussion tool but don't add the numbers up to determine the outcome? Like a digital version of the analogue "strong keep", "weak oppose", etc. that we do? Leviv ich 04:03, 16 May 2019 (UTC)
Yes, exactly. eg:
A. Strong support. <rationale for A.>
B. Fairly strong support <rationale for B.>
C. Weak support, OK, but barely <comment about about C.>
D. Strong oppose, completely unsuitable <rationale against D.>
The idea is to elicit an opinion on every viable option. Soon enough, the non-viable options will be recognized as non-viable and ignored. The front runners will become obvious. The presence of near clones neither hurts nor hinders each other, like happens so easily with rankings. The use of numbers is a technique that helps many, though not all, give an objective opinion. What is important is the communication of pros and cons for each option. --SmokeyJoe (talk) 04:16, 16 May 2019 (UTC)
My feeling of scores, out of ten, I can briefly characterize with the following list:
10 Perfection
9 An almost perfect title
8 A very good title
7 Good enough
6 Acceptable
5 Barely good enough
4 Not good enough
3 Bad
2 Very poor
1 Pathetic
0 Completely unacceptable
Different people may ascribe different words for different scores. In favor of this approach is the notion that you are expected to defend your assessment of an option. It is this that makes it not a vote. I think it is very difficult to rate options insincerely if you'll have defend a very low rating of your favorite's biggest threat. --SmokeyJoe (talk) 05:34, 16 May 2019 (UTC)
OK yeah, I could see that being a useful arrow in the quiver to be deployed in discussions when needed. Leviv ich 06:11, 16 May 2019 (UTC)
  • @Born2cycle: thanks for pinging me into this discussion, and you raise an interesting query. I think the main issue with ranked surveys (as has probably already been alluded to above), is that in the absence of any other metadata they do a poor job of identifying whether people actively dislike the alternatives to their first choice, are neutral, or mildly in favour. Thus if you're going to go with rankings, you have to clearly define what they mean, and probably allow people the option of opposing as well as supporting. Or indeed, ranking all options on a scale as above. We kind of have this issue with our politics over here in the UK. Some people are calling for a second referendum on Brexit, but there are actually at least four options potentially on the table (leave with no deal, leave with the agreed deal, leave but remain in the single market, or don't leave at all). Most voters fall into one of two polarised camps - they either want to leave with no deal, or not leave at all. But then again as a second choice, most would pick one of the middle options so perhaps that's the compromise? Or does it simply please nobody? These are the tricky questions that a multi-option survey has to tackle. Cheers  — Amakuru (talk) 16:11, 16 May 2019 (UTC)
    ...so perhaps that's the compromise? Or does it simply please nobody? Some say the hallmark of a good compromise is that it pleases nobody. :-) Leviv ich 16:35, 16 May 2019 (UTC)
    • Thanks, Amakuru. So, I think of the whole point of ranking is to get away from the binary support/oppose thinking. It's presuming there is a continuum from favorite to least favorite, and asking each participant to indicate the order the choices fall on this continuum. It doesn't matter whether you think only the one you list first is acceptable or whether you think they're all reasonable. I believe with enough participation this kind of stuff averages out and ends up not mattering. Not to mention that adding explanatory remarks is just as much part of a multi-choice ranking survey as it is in a a more typical two-choice surveys. For example
      • B,D,C,A - B is most common and best because I believe this is the primary topic per Amakuru, and D is acceptable if we must disambiguate, but C and A both violate recognizability and are unacceptable. --signature
    Also, the raw counts are just one aspect to consider, whether it's multi-choice ranking or a typical two-choice support/oppose survey. I note that when we're doing the raw counts in typical two-choice surveys we typically don't distinguish between positions that strongly oppose the alternative from positions that are merely indicate a preference between two acceptable choices (notwithstanding that sometimes these distinctions are indicated with a "strong" or "weak" qualifier, as applicable, but unless it's really close these distinctions usually don't matter), so the fact that you can't discern similar differences from multi-choice ranked surveys is not a significant relative disadvantage compared to typical two-choice surveys. Though color coding might help accomplish the same effect:
    • B,D,C,A
    But my main point here is not to promote multi-choice ranked surveys, but rather to bring attention to how better to evaluate them when they are used. Based on what happened on Chairman two months ago, and MRV discussion about it, I think valuable consensus-revealing results are too easily dismissed. Again, the fact that the same decisive 60/40 community preference for Chairperson over Chairman was revealed in the ranked survey as was confirmed in the two-choice survey two months later speaks volumes. --В²C ☎ 17:28, 16 May 2019 (UTC)

В²C, I appreciate that you are at least trying to come up with a good solution here. (I mean, I always appreciate you, but I especially want to single you out positively here!) The problem is that we at Wikipedia do not have a good way to decide between multiple (3 or more) viable options, especially when one is the status quo. Voting in the real world between multiple options works because you have to have a winner. Here, our murky "consensus" system means that there might not even be a clear winner in a two-way contest, making 3+ a nightmare. (This is why I explicitly wrote WP:RMCI's section on moves like this to say that if there is a consensus against the article staying, which did not happen at Chairman, the closer should just literally pick one and be done with it. Despite my own words being used against me, I still agree with that.)

Your solution seems to me as basically trying to quantify "strong support" v "weak support" by way of numbers. I don't think that's bad, but I don't think it solves the problem. We already all mentally quantify "strong support" or "weak support" when we close, but really what we're trying to do is to see "is there a logical policy-based reason to move it to X? And if so, are the reasons laid out and agreed to, based on this discussion?" And I ... I don't know if this helps bring us to the right place. Red Slash 01:08, 18 May 2019 (UTC)

Red Slash, thank you. I get what you're saying but I think I haven't been clear. As you know, in the more challenging RM discussions, we're often beyond the basic question of which choice meets policy criteria best, because, frankly, policy often falls short and doesn't give us clear guidance (far too often, IMHO, but I digress). For example, pretty much any time most commonly sought and historical significance disagree we're at that point with regard to whether we have a primary topic, and if we do which it is, which of course affects what the title should be. Remember, the whole reason we're even in an RM is because the decision is at least potentially controversial, which suggests policy is likely not clear (if policy was clear, then there would be no controversy). In such cases there's not much we can do besides tally the votes, and, in fact, that's ultimately what happens. Decisions only go against the majority when the majority side is really devoid of policy basis relative to the minority, which is very unusual. Further, I think whenever we have more than two choices (for whatever reason) it's even more likely that policy is not giving us clear guidance. So the counts often are very important.
All I'm trying to point out here is that in a multi-choice ranked survey where policy is not very helpful it's easy to distill the all-important counts between any two choices that are just as accurate as they would be if those two were the only choices. In other words, anyone whose preference order is, say, C,D,B,A would choose D over B if those were the only two choices, and you can make this B vs D determination for every participant once you decide the only two contenders for consensus support are B and D. So there is no need to have a new B vs D "run off" RM (like we did at Chairman) to determine which is supported by consensus if you already have an n-option ranked survey that includes B and D, along with n-2 others that you have ruled out for obviously not being favored by consensus.
I know we disagreed on the significance of the ranked survey results at Chairman that you closed, but do you really think it's coincidence that we distill almost identical 60/40 preference for Chairperson over Chairman in that 4-option survey as we did in the subsequent Chairman vs Chairperson survey? --В²C ☎ 01:58, 18 May 2019 (UTC)
It's just one data point, but yeah, you're right, it does sure seem like your ranked choice poll was trending in the same exact way as the subsequent clearer move discussion. I will say that the multi-option poll, as implemented elsewhere on WP as well as yours, is complicated and difficult to "score". I could have (and maybe should have) done what you said, though, and kept Original on hold while I weighed Option X versus Option Y. Then if there's an X v Y clear winner, I would compare to the Original as if the original and X were the only two options. I think that's the crucial part--as if the original and the best option were the only two choices. That's where ranked choice would work. (Then you'd end up, let's just say, at the 60-40 split and decide it's either a consensus or not based on the arguments, just as always.) And if there's no good winner between X or Y but both of them beat the Original, then you just pick one and then open up the floor to a new move request, just like RMCI says.
Okay, I could get that, but it's really complicated. But I'd be behind that. Clear communication is necessary, though, and that's something that should be indicated from the very start of a move request. Red Slash 05:26, 19 May 2019 (UTC)

Ah, Red Slash, that's a good point. The current title should always be included as one of the choices in the ranked survey, call it A, and the other options, B, C, D, ..., are then be evaluated against it. So you get A vs B, A vs C, A vs D, etc. Of those alternative B, C, D, ..., the one that fares best (if any) vs A by the biggest margin is the one supported by the most participants, and, barring policy-based arguments to the contrary, is likely the consensus choice. By the way, that ranked survey at Chairman wasn't "mine" (I didn't create it — that was the brilliant work of Levivich). Let's try with that poll and see how complicated it is. Talk:Chairperson/Archive_3#Ranked_choice_survey.

  • Chairman vs Chair (officer) is Choice 1 vs Choice 2.
    • 1 > 2: 8
    • 2 > 1: 10
      • So it's Chairman (8) vs Chair (officer) (10). Consensus prefers Chair (officer) over Chairman, but by a small margin.
  • Chairman vs Chair (role) is Choice 1 vs Choice 3.
    • 1 > 3: 7
    • 3 > 1: 9 (note: some people left out 3 in their rankings)
      • So here again Chair (role) is slightly favored over the Chairman title.
  • Chairman vs Chairperson is Choice 1 vs Choice 4.
    • 1 > 4: 6
    • 4 > 1: 12
      • As noted before, Chairperson is favored over Chairman by a 2:1 ratio, or 66% vs 33%, clearly preferred by consensus.

Is that too complicated? Seems pretty straightforward to me. --В²C ☎ 17:02, 19 May 2019 (UTC)

Talk:Chairperson#Lead sentence v. Talk:Chairperson#Lead sentence ranked survey, to me, very well demonstrates how useful a ranked survey can be (particularly note that it's a two-part ranked survey). The ranked survey has been a far more efficient way of identifying consensus than the discussion that preceded it. Which isn't to say that ranked surveys are a substitute for discussion–they're not–but they're a useful tool following discussion to help crystalize opinion and separate popular options from unpopular options. I have a polisci bachelor's and used to work in politics and polling so this kind of stuff seems very natural to me, but I can see how for people not familiar with voting systems, it can seem complicated (particularly on a website with a generally pro-consensus, anti-polling ethos). I support "spreading" the idea of using ranked surveys as a tool (e.g., by updating PAGs), but I wonder if an essay is necessary that can be linked-to and that will explain how it could work in a discussion (and why it doesn't violate the principles of NOTAVOTE), along with examples of different kinds of ranked surveys (e.g., weighted/non-weighted). Maybe an essay like WP:Discussion and polling methods that talks about discussion, consensus, straw polls, ranked surveys, weighted ranked surveys, etc., for the purpose of "arming" editors with tools that they can use in discussions when appropriate. --Leviv ich 17:22, 19 May 2019 (UTC)
Okay, I created a stub of a stub for the essay, and a talk page for it:
Feel free to work on it there. --В²C ☎ 21:02, 20 May 2019 (UTC)
I've created a draft for text to be appended to several existing policy pages (WP:RM, WP:RMCL, and WP:CLOSE), and have posted it at User_talk:Born2cycle/DRAFT_survey_essay#Draft_text. It includes a proposed template, which I don't have the skills to make myself. Input from all editors is welcome. Safrolic (talk) 21:11, 20 May 2019 (UTC)


Only one method per RM please

I agree with User:Born2cycle, but would just like to issue a caveat, that only one method of survey in an attempt to gain consensus should be used per RM, so that if ranked-choice is to be used, it should be at the outset. Otherwise, there is hazard that it might be raised when a "simpler" method is not turning out as desired, and any new verbiage should be clear on that point. (The hazard is not inherent in ranked-choice; no method of survey should be overturned by another in the same discussion if it's not going the way one prefers.)

This is not a theoretical construct; something like this is going on right now, at this RM at Talk:Genderqueer. (Heads-up: this is a long RM.) A first Survey section gathered !votes in a round of polling and a largely WP:CIVIL RM discussion was held with multiple subsections. Up to approximately two weeks in, things were fine (if long). The RM was then closed as No-consensus, but the close was reversed to allow more comment. Following this, one enthusiastic user renamed the original Survey, added a second survey section near the top with ranked choice voting, and called that one Survey (later moved to the bottom after an objection) and pinged everyone to the new, ranked choice poll. In my view, this second poll should not have happened. This is the real-word situation I wanted to raise.

I don't care which way the RM comes out as long as proper procedures are followed. My concern is, that a ranked-choice alternative might be used in the future as a way of trying to game an RM by achieving a different result than an earlier Survey in the same discussion which appears not to be heading to the conclusion they might hope for. In the case in point, I declined to vote a second time, stating my belief that this seemed to be a kind of Intra-forum shopping.

P.S. While I totally agree with the O.P. in this case, if you're a real voting nerd, then you might enjoy having a look at Arrow's impossibility theorem. Thanks, HTH Mathglot (talk) 07:43, 19 May 2019 (UTC)

I have not looked at that RM at all so the comments are based on your description of it alone. This is similar to what happened at the March RM at Chairman. In general it’s not unusual for a new alternative or alternatives to be proposed during an RM, and for discussion to start about that, sometimes in a new separate section. —В²C ☎ 14:42, 19 May 2019 (UTC)
  • I think ranked formatted surveys should be banned. Too much about them is misleading, and more is prone for misunderstanding. They imply by there mere structure that an algorithm is to be applied, an algorithms fit ill with consensus decision making. Rankings appeals to notions of personal preference without a need to defend the reasons for the ranking. Rankings don’t correlate with strength of argument, and don’t include argument. Rankings work for where a choice must be made, regardless of of the merits of the choices. Ranking options for RM discussions is bad. —SmokeyJoe (talk) 15:03, 19 May 2019 (UTC)
    Do nothing is always a legitimate choice, so you must always choose something in an RM. --Izno (talk) 16:03, 19 May 2019 (UTC)
    Exactly. As long as the current title is one of the choices in the ranked survey, as it always is as far as I know, "do nothing" (effectively) is a choice. For example, "Chairman", the current title at the time, was one of the choices in the ranked survey at Talk:Chairperson/Archive_3#Ranked_choice_survey, and it was disfavored 33% to 66% vs Chairperson. Assessing the level of support by counting votes (an algorithm) for opposing choices is always part of evaluating consensus in RM discussions, though of course other factors are also considered. The "algorithm" for assessing relative level of support between any two choices in a multi-choice ranked survey is only slightly more involved than doing so in a typical 2-choice survey, and, critically, just as accurate, as explained above. I don't understand SmokeyJoe's objection. --В²C ☎ 16:22, 19 May 2019 (UTC)
  • Oppose - completely pointless and time-wasting discussion. Time lost from article space. In ictu oculi (talk) 20:36, 19 May 2019 (UTC)
    Had the ranked survey back in the Mar 22 Chairman RM been used as proposed in this section the community would have avoided two subsequent RMs and an MRV. This is about how to avoid time-wasting discussion regarding issues that could be resolved much quicker and just as accurately as they eventually get resolved. --В²C ☎ 21:24, 19 May 2019 (UTC)
    The ranked survey was used, and it was heading nowhere, as evidenced by the fact the RM closed as no consensus and was endorsed at MRV. The subsequent move succeeded (albeit against my preference) precisely because it was restyled as a simple binary choice between status quo and one alternative. In the end discussions are better than votes, but if you do have to have a vote it's far better to make it a simple one, rather than one which can't be easily measured.  — Amakuru (talk) 21:39, 20 May 2019 (UTC)
    But Amakuru, it was measured, and easily. It showed a preference of Chairperson over Chairman by a 2:1 ratio, 66% to 33%. See details just above in my discussion with that closer, Red Slash. Just because the closer and many MRV participants chose to ignore that survey is not evidence that "it was heading nowhere". --В²C ☎ 23:42, 20 May 2019 (UTC)
    I agree that the survey was still moving, and it was closed prematurely as "no consensus". I should not have been closed as consensus to move, because the algorithms required to resolve ranked choice !votes, such as what B2C is playing with, amount to synthesis and supervoting. The restart did clarify things. Rating all viable suggestions, not ranking, is better. Rating implies rankings, but gives information useful for others to discuss and for development of consensus. Naked ranks do not do that, and are prone to unacceptable effects and even paradoxes. --SmokeyJoe (talk) 00:43, 21 May 2019 (UTC)
    Yes agreed, but even then the ratings are just indications of the kind of thinking the commenter has. The overall close result is not taken by scientific analysis of the survey, but by a holistic look at the discussion in full, and picking apart whether or not any consensus emerged. Binary yes/no votes are an OK way of achieving that, although even then they don't always tell the full story because some !votes are more valid in policy than others. Multiple-choice surveys are worse, and the Chairperson RM was a textbook example of how a targeted proposal stands more chance than a ranked survey, despite the apparent lack of WP:STICK dropping with regard to the original no-consensus close. I don't know if this is a formal RFC, but if it is then I would suggest there is no consensus that ranked surveys should be encouraged. Thanks  — Amakuru (talk) 14:00, 24 May 2019 (UTC)
    Completely pointless and time-wasting comment. Time lost from article space. 142.160.89.97 (talk) 05:06, 26 May 2019 (UTC)

Is this the right section regarding the redirect specific page movies?

Hi, I was wondering if this is the right section for a specific page to be moved regarding different terms but are actually different but somehow automatically mean the same thing despite being technical rather than legally. XXzoonamiXX (talk) 12:10, 20 May 2019 (UTC)

I'm having trouble parsing this- can you tell us which article you want to suggest a move for, where you want to move it to, and what your rationale is? Then we can give you better advice or help you set it up. Safrolic (talk) 15:46, 20 May 2019 (UTC)
Ok my wording is a bit awkward, but I guess this is the right section then. Here's the article I created. While the contiguous United States article did cover the separate definition, it didn't really go far enough. Often times, when people point their computer mouse at the definition, it would say "contiguous" instead of continental, so people would be more interested. Generally, "continental U.S." is so intertwined with contiguous despite clearly not being the same is perverting the actual definition of the word so this really bothers me a bit, especially when it's covered under the "mainland U.S" article. The definition of "continental United States" is clearly outdated when it comes to be automatically referenced to "mainland United States" instead rather than referring to what the word actually means. So I created a new different page defining what "continental" means and go the information further behind the definition. I really want to go deeper and farther, but it's just kind of hard when it doesn't allow me to move the newly-created page from "Continental America" to "Continental United States", even though the two definitions are different and has zero relations with each other, so it feels like people are more interested in "contiguous U.S." (including continental U.S. somehow being intertwined with that term) rather than the actual definition of "continental U.S." XXzoonamiXX (talk) 18:46, 20 May 2019 (UTC)
Okay so, I don't think the two terms are different enough, or separately notable enough, to have two different articles. If you want to describe the inclusion of Alaska and its ramifications in more detail, I think you should start by drafting a new section for the contiguous United States article, and post it on the talk page there for input. The page you created, and the continental United States page, should both redirect to contiguous United States for now- the article you started feels a bit like a WP:POVFORK in its current form. After you make that section, they can redirect specifically to it if appropriate. I've reverted the self-redirect you placed on continental United States. Also, I think that for now, Talk:contiguous United States is a more appropriate place than here to get advice. Feel free to cut and paste this entire section, including my replies, over there if you wish, making clear where the discussion was moved from. Safrolic (talk) 19:41, 20 May 2019 (UTC)
It still doesn't change the fact "continental United States" typed would always be referenced to the "Contiguous" article rather than a specific section, meaning people would always mix continental U.S. with the U.S. mainland despite the terms being actually different. Which is why I felt a different article is necessary. I really rather prefer when people point a mouse at a blue link, it should say something like "continental U.S." which lets people know it redirects to that section of the main article because even it it does, no matter what, it always points at the main article's title. It's very annoying to say the least. XXzoonamiXX (talk) 20:40, 20 May 2019 (UTC)
I've edited the redirect Continental United States so that it points directly to that section of Contiguous United States. - Station1 (talk) 22:48, 26 May 2019 (UTC)

Help needed: Orca/Killer whale discussions

Interstellarity has opened and then closed move requests at Talk:Tilikum (orca)#Requested move 27 May 2019, then at Talk:Granny (orca)#Requested move 27 May 2019, then at Talk:Chimo (killer whale)#Requested move 27 May 2019, and is now looking to reopen the second one: Talk:Granny (orca)#Reopening the move discussion. I'm not sure on the best way forward so could someone perhaps take a look and take whatever action is required? PC78 (talk) 13:23, 28 May 2019 (UTC)

I suggest Interstellarity explain what they did, why, and what they want, and why. I just looked and got very confused by each RM being closed and saying "see X" where X is another closed one saying "See Y", where Y is ... --В²C ☎ 21:45, 28 May 2019 (UTC)
Hello Born2cycle, I originally created this RM. When another editor suggested that all of the titles should be moved for consistency, I closed that discussion and created this RM. When an editor suggested that the titles should be moved to the (whale) disambiguator, I closed that RM and created this discussion. Another editor suggested to move the titles to the (killer whale) disambiguator because of the principle of least astonishment so I closed that discussion. I hope I have provided enough information so we can decide what the best course of action is. Interstellarity T 🌟 01:34, 29 May 2019 (UTC)

Currently we have:

Which is obviously circular and helps nobody. Can somebody who understands what is happening here please clean it up as I'm utterly confused. Thryduulf (talk) 10:05, 30 May 2019 (UTC)

Hello Thryduulf, the reason I kept creating new discussions was that I was going to change the proposed titles to something else. The reason why I closed the move discussions this way was to link to the revised move discussion so people can comment there instead of that move discussion. If you can find the right editor or group of editors that resolve this, that would be great. Interstellarity T 🌟 11:11, 30 May 2019 (UTC)
It looks like you closed the first discussion based off someone's suggestion to use "whale" instead of "killer whale", but you should have just let that discussion run and allowed other users to comment. And then of course in the second discussion there were suggestions from various people (myself included) to use "killer whale" rather than "whale", and so you hastily closed that discussion and tried to go back to the other. Surely you can see how this isn't helpful? If the nominator doesn't know what they want it's only going to confuse others. I think at this point it's probably best to start over which I'll do myself with a fresh nomination. PC78 (talk) 15:18, 30 May 2019 (UTC)
See new discussion at Talk:List of captive orcas#Requested move 30 May 2019. PC78 (talk) 15:33, 30 May 2019 (UTC)
Thank you PC78 for fixing this. I realized that the actions I took on those RMs were inappropriate and other editors got confused about my actions. In the future, before closing a move discussion that I have opened, I will ask someone before doing it. Interstellarity T 🌟 16:02, 30 May 2019 (UTC)

Can a nominator withdraw a request?

Under the rules of an RfC, the person who opened it may close it if it quickly becomes obvious that nobody will support it. The same rule does not seem to apply here. Would I get in trouble if I closed a request of mine as "not moved per SNOW"? The RM in question is at Talk:Shane O'Neill (son of Conn)#Requested move 28 May 2019, and anybody else may close it if they want. Scolaire (talk) 16:26, 30 May 2019 (UTC)

  • I think if you withdraw your proposal, which sees unanimous opposition, it would be completely fine for you to SNOW close it, withdrawn and unsupported. If you are not technically savvy enough for the closing, just withdraw and someone else will close it soon enough.
If, however, a single person comes in with even lukewarm support for the proposal, you may not close it, you should just withdraw your nomination and vote "oppose". WP:NAC closes are not helpful if they botch it. --SmokeyJoe (talk) 05:28, 31 May 2019 (UTC)

When RM closed early - revert or MRV?

When an early close of an RM is controversial, should those who disagree take it to MRV or revert the close per WP:BRD?

Discuss in general below or a specific situation here: Wikipedia:Administrators'_noticeboard/Incidents#Saint_Peter_move_request.

My thoughts:

  1. RMs should be closed early only when WP:SNOW applies or there is apparent strong consensus to close for some reason.
  2. If an early close of an RM is contested it can be reverted, so long as it's done within a day or so of the close. After a few days legitimacy of the early RM closure is assumed to have consensus support.
  3. You shouldn't have to be uninvolved to revert an early close per #2.

What do you think?

--В²C ☎ 21:35, 28 May 2019 (UTC)

You should discuss with the closer and then follow WP:CLOSECHALLENGE if the issue remains unresolved. — JJMC89 (T·C) 05:12, 31 May 2019 (UTC)
  • Relisting, closing, and close-reverting of RMs are all administrative actions. All should be reserved for the uninvolved. The prompt reverting of a close should be reserved for an uninvolved admin reverting an NAC close, stating why the close was in error and not just because it was an NAC close. Discussion with the closer is always a good idea. If still in doubt, or the issue remains contested, take it to MRV.
Talk:Saint Peter#Requested move 17 May 2019 features a few non-ideal things, but little more than one last SNOW close is left to do. --SmokeyJoe (talk) 05:41, 31 May 2019 (UTC)
  • Unsure, agree with #1 that generally at least a week is needed (an hour or so early shouldn't matter), if its closed early it might qualify as being uncontroversial meaning someone can boldly revert it later. I would be careful about reverting closes unless there really bad if you're involved since that's more likely to create problems, instead discussing with the closer, MR or starting a new RM. If a discussion is closed early but its been more than a few days a new RM might make sense (though probably re opening is best) but if consensus hasn't been reached the previous close should be reverted. Crouch, Swale (talk) 17:04, 8 June 2019 (UTC)

Where to hold discussions involving multiple pages

This isn't a new thing, but I've noticed it happening more frequently as of late. For a multi-page move discussion involving an article at the base name and one at related disambiguation page, some users always seem to put them on the disambiguation page's talk page. See Friends and Queens for recent examples. There is currently no guidance at Wikipedia:Requested_moves#Requesting_multiple_page_moves, relating to where these moves should be held. I feel strongly, however, that the discussion should be held on the more widely watched page (likely the article talk page) to ensure greater participation. Thoughts? Calidum 14:18, 8 June 2019 (UTC)

I don’t think it matters where the discussion is actually held... as long as the discussion is PROMINENTLY and CLEARLY advertised on the talk pages of any related articles. Blueboar (talk) 15:00, 8 June 2019 (UTC)
In both cases the bot notified the pages[1][2][3][4] so I don't think there's a problem there since those watching the page will still see it. The only thing was that the bot didn't seem to note my modification of the request but that's not that much of a problem since fewer are going to be bothered about the precise amount of disambiguation and the bot still probably wouldn't have updated the tag even if the RM was on the article. In both cases the request is for disambiguation and to put the DAB at the base name, the need for the articles to be moved to Queens, New York and Friends (1994 U.S. TV series) is a consequence of the ambiguity. Also this avoids cluttering up discussions over improving the article with disambiguation. Generally if I am proposing to:
  • Move a disambiguated article to the base name, I start it at the article (example) in which case moving the DAB to "Foo (disambiguation)" (which is included in the request) is a consequence of the article becoming the primary topic.
  • Move a DAB to the base name and the current PT elsewhere, I start the discussion on the disambiguation page and include moving the current PT elsewhere in the request (example). The need to move the current PT is a consequence of the lack of primacy.
  • Move an article for a reason other than disambiguation and put the DAB at the base name, I start the discussion at the article (not the DAB) and include in the request to put the DAB at the base name (example) in this case its sensible to have the discussion on the article because we're working out what the best name is as well as if there's a primary topic.
  • Move an article to make way for a DAB, there's no DAB to host the discussion so it has to take place on the article (example). Although the Ireland moves that have to take place on Wikipedia talk:WikiProject Ireland Collaboration might work for just 1 page (say moving just Republic of Ireland to Ireland (state)).
  • Move a DAB to create a primary topic redirect, the discussion has to take place on the DAB (example) but a notification on the proposed primary topic's talk page could be added.
  • Move a DAB over a primary topic redirect, I start the discussion at the talk page of the DAB page (the bot notifies the redirect target's talk page) which is the only option (example) which would also be done if moving an article over a redirect that doesn't currently point to the article.
  • Move an article to a base name and the article at the basename elsewhere, I start the discussion on the article being proposed to being moved to the base name (example).
  • Move an article over a DAB, I start the request at the article (not the DAB) but just as a single move noting that the DAB isn't needed (example) the bot still notifies the talk page of the target but doesn't add a notice on the DAB page its self.

In any case with moves to put the DAB at the base name as long is its properly formatted it should be OK wherever the discussion is held since as noted even if a page isn't included in a request but a page targets it in the request the bot notifies it. Some editors wanting to move an article to the base name and the DAB page away use the DAB (example). Crouch, Swale (talk) 16:55, 8 June 2019 (UTC)

In reply to the point about the discussions taking place on the most watched talk page, the article alerts show up for articles that are included in a multi move, see here for example where Ash, Dover District and Woodmancote, Tewkesbury Borough also show up because of the request at Talk:Kingswood, Stroud District#Requested move 24 May 2019. I'd note that in the Friends and Queens moves that the Friends and Queens articles were notified of the discussion but not other topics such as Friendship and Queen regnant that are indirectly affected by the primary topics there so if anything the current system gives undue weight to the current (or proposed PT) even if the discussion takes place on the DAB. Similarly if I propose to move Mercury (planet) to Mercury and Mercury to Mercury (disambiguation) none of the other articles (such as Mercury (element) and Mercury (mythology)) are notified even though there clearly indirectly affected by the move. Talk:Birr#Requested move is an example of where this could have been a problem since at that time the bot didn't notify talk pages of a target that is occupied when the target isn't specified in the move but as noted with Holsworthy now the bot notifies anyway. Crouch, Swale (talk) 17:27, 9 June 2019 (UTC)

What is the tag to move a page or rather request?

So I found a film under it's foreign title La sceriffa, which I then decided to move to it's English title which I have done easily, moved it to The Sheriff (1960 film), which turns out I put the wrong year. So I then was going to move it to The Sheriff (1959 film), only to find out that page is under use, as a redirect to La sceriffa. I want to move it to it's English title under the correct year but can't. Not sure what the request tag is. I did put a request on Wikipedia:Requested moves/Current discussions. But not sure if that was the correct place. (Gee all my years here and this is the first time I had to request that as I usually check to see if that page name was taken, which I did but since I was off by a year I didn't see a problem) Wgolf (talk) 22:22, 10 June 2019 (UTC)

@Wgolf: That page is maintained by a bot, so your edit there was removed automatically. You need to either go to WP:RM/TR if the move request is uncontroversial, or you can follow the instructions at WP:RM#CM to open a discussion on the merits of the proposed move. Iffy★Chat -- 22:26, 10 June 2019 (UTC)

How does the backlog works?

I do not see anywhere in this article how does the backlog works? So everything that enters the backlog may wait there indefinitely? --MaoGo (talk) 12:51, 17 June 2019 (UTC)

Anyone associated with the subject? You mean someone with a WP:COI? They pretty much shouldn’t do anything but make suggestions for things to fix.
If there is unanimous agreement, anyone can do it.
If there is disagreement, and discussion has ceased, and there is a reason to want it done soon, request at Wikipedia:Administrators' noticeboard/Requests for closure.
Very few page renames need doing urgently. —SmokeyJoe (talk) 14:31, 17 June 2019 (UTC)
Thanks for clearing that out.--MaoGo (talk) 14:37, 17 June 2019 (UTC)

Script to close RMs

Hi. Some of you might be aware of User:DannyS712/DiscussionCloser, a script I took over maintaining that simplifies closing discussions. I have added an option for "Requested move" that will use {{RMT}} and {{RMB}} as well as automatically removing the requested move templates. You still have to remember to add {{nac}} or {{RMpmc}} yourself, but I hope the script is useful. --DannyS712 (talk) 10:15, 18 June 2019 (UTC)

I have removed the discuss link in Template:RMassist/core per Dicklyon's opinion in Special:PermanentLink/903320542#ANI notice. This means that requests at WP:RM/TR do not have a discuss link anymore. From now on, it is the original requester's responsibility to start their own move discussion on the talk page. GeoffreyT2000 (talk) 16:02, 26 June 2019 (UTC)

User:GeoffreyT2000 Huh? On what consensus have you done this? Where was the discussion? Listing a technical request for discussion is one of the most common actions resulting from a technical request. Please revert this. Thanks  — Amakuru (talk) 17:49, 26 June 2019 (UTC)
I agree it should be restored in addition the text "This is a contested technical request (permalink)" comes up so users can see that the request was originally posted at RMT. This link is definitely useful and doesn't IMO incorrectly show where it was originally posted due to the permalink. Crouch, Swale (talk) 17:59, 26 June 2019 (UTC)
I have now restored the discuss link. This also means that I do not have to send Template:RMassist/editintro and Template:RMassist/preload to WP:TFD for deletion. GeoffreyT2000 (talk) 19:06, 26 June 2019 (UTC)
Thanks. For the cases where people don't want their name on the move request they can just withdraw or oppose or whatever.  — Amakuru (talk) 20:36, 26 June 2019 (UTC)
Template:RMassist/core has a |discuss=no parameter anyway. Crouch, Swale (talk) 20:42, 26 June 2019 (UTC)
"Listing a technical request for discussion is one of the most common actions resulting from a technical request" is what I would prefer to see changed. When a TR is declined, it would often be better to let the OP post a better rationale, construct a more complete multiple RM, or withdraw, at their option. Sam Sailor suggested an RFC here, but I want to get a quick reaction before considering that. Dicklyon (talk) 17:37, 4 July 2019 (UTC)

For background, see Template talk:RMassist § Why WP:Requested moves/Technical requests is on a sub-page. This feature was implemented in May 2014 upon the request of EdJohnston. Both Ed and Anthony Appleyard used to basically manually do what this template does, before I implemented the discuss link. The |discuss=no parameter was implemented in March 2015 after another editor made a similar objection to the one I see here. See the earlier discussion at Wikipedia talk:Requested moves/Archive 27 § Automated mishandling of a request. It was my hope that admins would honor |discuss=no when used, but there is no guarantee of that. – wbm1058 (talk) 18:19, 4 July 2019 (UTC)

See also Wikipedia talk:Requested moves/Archive 27 § Smoothing the transition from technical to contested requests – wbm1058 (talk) 18:32, 4 July 2019 (UTC)

Move page to Children's Minnesota

Children's Hospital and Clinics of Minnesota changed its name to Children's Minnesota in 2015. I am not autoconfirmed and need help moving the page to Children's Minnesota. Thank you. Kim Kimberlywelch (talk) 01:28, 10 July 2019 (UTC)

Hi there - this isn't the page to request moves, that is done by following the instructions at this page. That said, I've reviewed the request and the updated name is supported by sources, so this request has been  Done. Cheers. Steven Crossin 02:19, 10 July 2019 (UTC)

Couple new shortcuts for "Relisting a requested move", etc.?

Hi, wondering if an editor experienced in this area can create suitable shortcuts for:

Cheers and thanks for considering, Facts707 (talk) 16:17, 5 July 2019 (UTC)

 Done
--В²C ☎ 23:32, 10 July 2019 (UTC)

Military campaigns

There seems to be a desire to rename "Military Campaign" to "Military campaign". This is clearly a controversial issue see for example:

so WP:RM#CM should be used and the should not be carried out as as technical moves or ever just moved via the tabl at the top of an article.

Also the moves are being proposed per MOS:CAPS, but MOS:CAPS has nothing to do with it as that is not a guideline for article titles policy (AT) (the guidance on this issue for article titles is in the AT section "Article title format" (link via WP:LOWERCASE). The lead in that section states "The following points are used in deciding on questions not covered by the five principles; consistency on these helps avoid duplicate articles" and the first sub section "Use sentence case"

As this is a controversial issue, then if "Military Campaign" to "Military campaign" article titles are to be changed, then:

  1. The proposer needs to establish that the is descriptive title and not a name.
  2. If it is a name then the proposer needs to establish what is commonly used in reliable secondary sources.

To do this with the least disruption a WP:RM#CM is needed. -- PBS (talk) 09:13, 28 June 2019 (UTC)

@user:Dicklyon Why are you still using the request technical moves for campaigns when you know that other requests have been contented and as such such requests are controversial? eg

-- PBS (talk) 10:25, 19 July 2019 (UTC)

@user:Anthony Appleyard, user:DannyS712 I am disappointed that you have been moving campaign articles without the usual contested WP:RM. The point of non-contested technical RM was set up for things like obvious spelling mistakes and the like which might affect the ability of a reader to find an article. It was never intended to be a way to bypass controversial moves such as adding or removing accent marks, or capitalisation etc (neither of which nowadays prevent readers ability to search for an artilce). Please revert the moves to campaigns articles that you have made and let user:Dicklyon put in a WP:RM#CM because a seven day delay while editors asses the evidence on whether to move the article does not harm to the project. -- PBS (talk) 10:38, 19 July 2019 (UTC)

@PBS: I have no objections to the moves I made being reverted. Sorry --DannyS712 (talk) 11:49, 19 July 2019 (UTC)
  • @PBS and DannyS712: Which moves do you want me to revert? Anthony Appleyard (talk) 12:28, 19 July 2019 (UTC)
    PBS, your objection in the past was that I invoked MOS:CAPS instead of title policy. You have not commented at the one where discussion was started (Talk:Waterloo_Campaign#Requested_move_18_July_2019). All previous such discussions closed in favor of the move, which follows sources, policy, and guidelines. Nobody has been able to point out a single such move that might be wrong (if they have, please show me). Why do you want to keep re-litigating where there's a clear consensus? Dicklyon (talk) 14:23, 19 July 2019 (UTC)
    Furthermore, the instructions have always said "For technical move requests (e.g. spelling and capitalization fixes), see Requesting technical moves." These are routine fixes to titles that were over-capitalized, contrary to WP:LOWERCASE; on the numerous ones that have been discussed, as well as the undiscussed ones, nobody has presented a reason to treat any of these as proper names; instead, they just say "looks better capitalized", or claim "it's a proper name" without refuting the evidence that sources routinely use lowercase. Do you have anything new to add to those discussions? Maybe starting at the open one where you've been pinged? Dicklyon (talk) 14:51, 19 July 2019 (UTC)
    Finally, you're pissing me off by this kind of out-of-process complaint instead of engaging in the discussions that you insist on having. If you think there's a chance of changing the longstanding consensus about not capping title except for proper names, this is not the place. If you think these are proper names, this is not the place. Come to the RM discussion or let the process work without your speedbumps. Dicklyon (talk) 14:56, 19 July 2019 (UTC)

@PBS and Anthony Appleyard: Here's a proposal for how to proceed. PBS, you make a constructive comment at the one that already went to discussion, as a show of good faith; so far you have not said whether you would support or oppose, or whether you would even consider it controversial in light of the evidence: Talk:Waterloo_Campaign#Requested_move_18_July_2019. Then, you choose a few recent tech moves that you consider to be wrong or that have some reason to be considered controversial, and list them here and say why you think they were wrong or controversial. Anthony, please go ahead and revert when he does, and I will open RM discussions or a multi if similar items. But I don't want to go that way unless someone will point out a reason that all the recent consensus-affirming RM discussions were not enough. Dicklyon (talk) 19:34, 19 July 2019 (UTC)

Second relisting request

Please could an uninvolved editor consider relisting the discussion at Talk:1947–1949_Palestine_war#Requested_move_15_June_2019. The reasons for it justifying a second relisting are: (1) the scope of the discussion was completely overhauled; (2) the topic is complex, has been going for 10 years, and needs more input to reach consensus. Onceinawhile (talk) 09:45, 3 July 2019 (UTC)

This complex move proposal has now been relisted twice three times, and is still open as of today. It's been open for over a month now. – wbm1058 (talk) 16:14, 22 July 2019 (UTC)

unable to move a page

I have created a page for Microsoft Kaizala app as I was impressed by its features that serve business communication effectively. However when I tried to move the page from my user sandbox into Wikipedia it could not be moved.

The page prompted: The page could not be moved, for the following reason: The page could not be moved. a page of that name already exists, or the name you have chosen is not valid. Please choose another name, or use Requested moves to ask for the page to be moved. Do not manually move the article by copying and pasting it; the page history must be moved along with the article text.

So I request you to help me in moving the page with the name Microsoft Kaizala. Kindly suggest the steps on how to publish the page Microsoft Kaizala. Thanking you all. Nagsail (talk) 18:51, 13 July 2019 (UTC) Thanking You all Nagsail (talk) 08:07, 14 July 2019 (UTC)

When it tells you that you can't move it, it points you to WP:RM. In that page, use WP:RMTR if it's nothing controversial, or follow the directions for starting a move discussion. Dicklyon (talk) 14:53, 22 July 2019 (UTC)

Point at the template, not at this page

When I tried to move a page to an existing title, I was directed to edit this page instead of told to use "subst:requested move" template in the article's own talk page. INstead of wasting editor's time, could the prompt be a little more accurate and point at the proper way to achive the move? Editors are disposable here, I know, but it would be a nice gesture. --Wtshymanski (talk) 22:48, 20 July 2019 (UTC)

So here we have two recent reports, one from a very experienced editor, and another from someone new, about the message displayed when a page cannot be moved over a redirect, the text of which is at MediaWiki:Articleexists, which can only be changed by administrators. Please suggest changes to this message. – wbm1058 (talk) 16:59, 22 July 2019 (UTC)

Persian people

Can someone help moderate the move request at Talk:Persian people? An overzealous move proposer is removing good-faith comments from IPs, including me. I don't want to violate 3RR, but as he is removing my comments wholesale (my comments weren't even necessarily opposing the request!), I am just being erased from existence every time he reverts. 125.9.31.50 (talk) 11:24, 22 July 2019 (UTC)

I mean, the guy has only been here for 10 days, but I am asking him to read guidelines, which he is not doing. Meanwhile he is leaving improper warnings like this for others ("expect a permanent ban"). 125.9.31.50 (talk) 11:28, 22 July 2019 (UTC)
I left a warning. Will watch... Dicklyon (talk) 01:15, 24 July 2019 (UTC)

Changed the involved part

I made a big edit to condense the involved part. Everyone knows involved editors shouldn't make decisions - I made it clear who is and is not "involved". Our neverending nightmare over at WP:MRV (a close that seems reasonable except that the closer had closed another request previously) wouldn't have been possible if we'd had clearer COI guidelines here. Feel free to do whatever seems best--I obviously can't own this page. I do think I made it clearer, black and white, and that if we adopt this, we will have crystal clear guidelines on whether or not a closer is involved. Red Slash 17:12, 26 July 2019 (UTC)

I have undone the changes. Changes on this scale should be discussed beforehand, and I encourage you to do so. Concerning the new guidelines, I think they are very inflexible, with "ever" many places, and are also framed and written without explanations why we have these rules. Wikipedia is not a bureaucracy, and the rules should reflect that. More specifically, I have a problems with the possibility to withdraw a request is being removed, and that it is not allowed to close requests that have been unanimously supported. This contradicts the concept that one does not even need a move request in the first place. I have little experience with move requests, and it might be a good idea to adjust this section, so please continue to work on that. However, your proposal does not seem appropriate for immediate implementation. ― Heb the best (talk) 08:03, 29 July 2019 (UTC)
I profoundly (though very respectfully!) disagree--this guideline needs to be rigid and inflexible. There is no excuse for a closer to be WP:involved, ever. It is much much more condensed and concise this way (it's a difference of ~1KB of plain text). I can adjust the things like unanimous support and withdrawing a request. Red Slash 03:13, 30 July 2019 (UTC)
  • Good edits by User:Red Slash, bad revert by Heb the best. They were very sensible small changes to bring documentation up to standard practice. Previous closes should not repeatedly close subsequent requests on the same page, most especially not when contentious. I don't approve of the wordy patronising language "it is important to" and "remember", but these call for copy-editing, not reverting. --SmokeyJoe (talk) 03:47, 30 July 2019 (UTC)
  • Yes, exactly. Good edits by User:Red Slash, unfortunate revert by Heb the best. Agree there is room for some minor adjustments, but overall a great improvement. I support restoring the changes, if they haven't been already. --В²C ☎ 20:21, 30 July 2019 (UTC)
  • Allow me to explain myself in more depth. My issue was the two specific changes I mentioned, all other was just things that popped up while I was here. The two were the exceptions that one is allowed to withdraw a move request, and that one is allowed to close a move request with an unanimous result, despite being a party to that discussion. I see no reason to wait for uninvolved closer in these situations. This stance is based on that an move request is not mandatory, and sometimes a requested move could just have been done without one. The specific example that led me here was Talk:No-deal_Brexit#Requested_move_21_July_2019. Before it was filled, I considered just boldly moving the page, but then a move request was opened, and I then waited for it to complete. When it did, I found it very odd that this policy disallowed me from closing it, despite no-one opposing to the move.
In retrospect, I should probably not have reverted this, but instead just raised this on the talk page and then taken it from there. I think what let me to reverting was a combination of several things. First of, the change was done by a single user, seemingly without prior discussion. I found that such large rule changes should not be done so easily. Secondary, although I did not research it further, the comment on the talk page hinted that these changes was a response to a specific instance, and the way the changes was worded, it seemed like sweeping rule-changes to me. It appeared that the two exceptions was just caught in the crossfire, and I thought well-places exceptions like these should not just be lost so easily.
The revert was always meant to be temporary, to make room for discussion of the (to me) undiscussed changes, to polish them before they were enacted. I am relatively new to Wikipedia, have little experience with both discussion closing and move requests. I am not the one who should debate and decide what are the best rules, you, who know how things work, should do that. I have said what I needed to say, and I think I will just leave you to it now, and you should just go ahead and revert my changes, if that seems like the appropriate way forward. Cheers! ― Heb the best (talk) 21:44, 30 July 2019 (UTC)
Move requests are often mandatory - whenever the move in question is (merely) potentially controversial. So once there is a formal RM, the presumption is that the proposal is potentially controversial, even if the response is unanimous one way or another, and so the RM is considered mandatory. That said, I agree it should still be okay for a proposer to close their own RM if no one has commented yet, or if the opposition is unanimous. No sense in wasting any one else's time on a proposal if the proposer no longer thinks it's viable. --В²C ☎ 16:52, 31 July 2019 (UTC)
@Heb the best: FWIW, I think your revert was perfectly justifiable, and I'm glad it's sparking some discussion. I don't necessarily disagree with Red Slash's changes, but they did strike me as pretty significant in scope, and at least potentially controversial. Colin M (talk) 21:32, 31 July 2019 (UTC)
  • I'm a little nervous about the last 2 bullets listing criteria for being involved:
    • You have ever commented on any talk page in such a way as to make clear your position on the move request (even comments pre-dating the request)
    • Your editing on the page in question or about the page in question makes clear your position on the move request
If the goal is to have "crystal clear guidelines on whether or not a closer is involved", I think these lines fall short. Seems like there could be a lot of subjective interpretation that goes into determining whether someone's prior comments make clear their position on the move request. Is this an issue that has actually come up at WP:MRV in the past, or is it just hypothetical? Colin M (talk) 21:44, 31 July 2019 (UTC)
I see your point and I'm sure Red Slash would agree there is room for improvement there. Suggestions? --В²C ☎ 22:13, 31 July 2019 (UTC)
My first thought would be to just cut those last 2 points. Colin M (talk) 01:18, 1 August 2019 (UTC)

Involved relists

While I generally agree with many of Red Slash's changes (seen here, for anyone looking), I disagree with the idea that an involved user is free to relist (or at least the idea that explicitly allowing it is non-controversial and doesn't require further discussion). From my perspective, relisting should only done by someone not involved. This issue has come up from time to time on this talk page but has never been resolved either way. The previous guidance on resolved relisting can be seen here [5] Calidum 15:01, 31 July 2019 (UTC)

In theory it's conceivable that if someone is not getting the consensus they are seeking they might relist but really... so what? What's the hurry in closing it? I think the idea behind allowing involved to relist is that the potential harm is negligible. Isn't it? --В²C ☎ 16:41, 31 July 2019 (UTC)
IIRC correctly, there have been instances where a user will relist a discussion and then immediately vote. (I'm on mobile now but I can look in the archives for this later). The concern was that there might have been consensus prior to the relist that ran counter to that user's vote. Calidum 16:55, 31 July 2019 (UTC)
Not to be glib, but so what? If just one !vote can change the result, then it probably should be relisted to get more participation. --В²C ☎ 17:11, 31 July 2019 (UTC)
Just to add to this, WP:RMRELIST currently says The decision to relist a discussion is best left to uninvolved experienced editors upon considering, but declining, to close the discussion. Colin M (talk) 21:22, 31 July 2019 (UTC)
Yeah, but it doesn't say why that's "best". I, for one, have no idea. --В²C ☎ 22:13, 31 July 2019 (UTC)
  • The requirements for relisting should be exactly the same as the requirements for closing. Both are administrative actions. Relisting is best done to call attention to something raised late in the discussion, to invite earlier participants to return to comment again. A biased relister can steer discussions towards their bias. --SmokeyJoe (talk) 02:53, 1 August 2019 (UTC)

Red Slash's changes restored

I've restored the changes, except for one tweak: retaining the long-standing caveat in the case where a proposer is allowed to close their own move request if no one has commented yet or opposition is unanimous, as discussed above. --В²C ☎ 17:11, 31 July 2019 (UTC)

By "close their own move request if no one has commented yet" I take you mean to close as withdrawn, not to close any other way. Dicklyon (talk) 22:12, 2 August 2019 (UTC)
I took it to mean no one has commented after seven days. —SmokeyJoe (talk) 06:14, 3 August 2019 (UTC)

Semi-protected edit request on 6 August 2019

Change "Galway Sportsgrounds" to "The Sportsground" as this is the correct branding and style used by Connacht Rugby. Stephenlong89 (talk) 11:41, 6 August 2019 (UTC)

 Not done: page move requests should be made at Wikipedia:Requested moves. Please follow the instructions. —KuyaBriBriTalk 17:47, 6 August 2019 (UTC)

POLL: who should be able to relist an RM discussion?

Let's have a poll on this question: Who should be able to relist an RM discussion?

  1. The requirements for relisting should be the same as for closing.
  2. Anyone, including anyone involved in the discussion, should be able to relist.

Please answer 1 or 2, with optional reasoning. --В²C ☎ 21:10, 2 August 2019 (UTC)

———————————————

  • 2. All relisting does is extend the time a discussion might be open. I see no way for anyone to be able to effect undue influence merely by relisting - anyone should be able to do it. --В²C ☎ 21:10, 2 August 2019 (UTC)
    • That’s not all it does, unless it was a pointless relist. And it doesn’t necessarily extend the discussion. Your inability to see subtle effects of biases, your underlying general problem everywhere, is one reason you shouldn’t be doing it. —SmokeyJoe (talk) 06:18, 3 August 2019 (UTC)
  • 1 – An unbiased/uninvolved editor (with experience in closing, preferably) should be deciding whether it's closable or not. A person with a stake in it might relist in the hope that more time will change the outcome. There's never a need to relist, since the conversation stays open in any case, until it's closed. Dicklyon (talk) 22:11, 2 August 2019 (UTC)
    Assuming that subsequent participants are independent of the person relisting, then if more time for the RM changes the outcome that is a good thing, as a two-week survey with more participants is likely to be more reflective of the community's view than the one-week survey with fewer !votes. Furthermore, previous participants may return to their !vote and decide to change it if new evidence is presented by an involved party. The only time any of this would be dodgy is if the involved party went off and WP:CANVASsed to try to stack votes for their point of view. But that's not permitted anyway, and could be dealt with as a separate issue, whether the person relisted or not. Overall I don't see this argument as a compelling reason to ban involved relists. Cheers  — Amakuru (talk) 14:13, 12 August 2019 (UTC)
  • 1 - Relisting should really be left to editors who are evaluating whether or not the discussion can be closed (and ideally they are closing rather than relisting if they can). I agree with both SmokeyJoe and Dicklyon that that involved editors should not be relisting discussions in any case. While relisting a discussion may seem to be an innocuous move, it could conceivably be used by an involved editor to reset the 7-day clock on a discussion that is trending away from the desired outcome in hopes that additional comments may "save" it. CThomas3 (talk) 11:10, 3 August 2019 (UTC)
  • 1 per Cthomas, Dicklyon and my comments above. Relisting requires assessing consensus. One cannot assess consensus if they are involved. Calidum 00:04, 11 August 2019 (UTC)
  • 2. Any RM discussion should be open to a first relisting by any editor, including the proposer, an involved editor, a newbie IP editor. However, that should be a one-relisting deal. A second (or further) relisting should require a substantially higher burden of assessment. bd2412 T 01:35, 11 August 2019 (UTC)
  • 1 per Dicklyon > "A person with a stake in it might relist in the hope that more time will change the outcome.", I'd rather someone who isn't involved close them. –Davey2010Talk 01:43, 11 August 2019 (UTC)
  • 1. I am shocked that someone would agree with 2. The purpose of any relist is to have some effect, or why do it. —SmokeyJoe (talk) 02:02, 11 August 2019 (UTC)
    • What about the possibility of an RM which garners no participation? In that case, the effect would be to get someone to participate in it at all. bd2412 T 02:30, 11 August 2019 (UTC)
      • Leave it and allow someone else to relist it ? .... Maybe I'm the only one but I wouldn't go out of my way to relist an RM ... There's far more productive things to do with my time. –Davey2010Talk 02:35, 11 August 2019 (UTC)
      BD2412, I'm not sure that an RM that garners no participation needs relisting. It can just fall to the backlog, and then eventually can simply be closed as successful. We state clearly in WP:RMCI that no minimum participation is required. CThomas3 (talk) 01:22, 12 August 2019 (UTC)
      • I have concerns about proposals in areas too technical for the usual RM participants to feel comfortable participating in, which may nonetheless be considered bad moves by experts in the field (who might not regularly visit RM). Also, I think relisting an RM once should be no big deal. There's no deadline. bd2412 T 01:28, 12 August 2019 (UTC)
        BD2412, I completely agree with that, but what is the difference between relisting and letting it sit in the backlog, other than its position on the page? CThomas3 (talk) 04:40, 12 August 2019 (UTC)
        Don't discount the significance of position on the page. A newly listed or relisted proposal is in a position to catch a lot more eyes than one that appears to be already done. bd2412 T 12:18, 12 August 2019 (UTC)
    • If a proposal receives no comment after seven days, feed it into technical requests. If a proposal is contested but has a below-threshold participation, I would support an objective auto-relist/extension, but not an involved person’s discretionary SmokeyJoe (talk) 02:40, 11 August 2019 (UTC)
  • 1 – only uninvolved editors should relist discussions, preferably those who actually tried to close the discussion but couldn't for lack of consensus. – bradv🍁 02:52, 11 August 2019 (UTC)
  • 1 Relists should only be done by an uninvolved editor who has evaluated a discussion and determined that it needs more input before a close. Galobtter (pingó mió) 05:12, 11 August 2019 (UTC)
  • 2, as has always been the case. Relists are cheap, and designed to enhance the debate, so no reason why anyone can't carry one out. A common scenario is that you come across an elapsed RM with unanimous support (or indeed Oppose), but you have a counterargument that hasn't been presented yet. It would be entirely proper to cast a countervote and also relist at the same time, so people have a chance to see your counterargument and have another week to do so. The intention of RM debates is to reach the correct conclusion, not for one side to "win" or "lose". Relists are not cast in stone either, so if an admin really thinks someone has gamed the system then they can always perform a close anyway.  — Amakuru (talk) 06:30, 12 August 2019 (UTC)
    • On the rare occasion that I have seen this done, I am called it out as improper. A late !voter casts what they think is an impressive counter-!vote, and then performs the relist to send the discussion back to the top. It looks like that !voter decides for himself that his !vote is so good that every previous !voter needs to return to consider it, and for another seven days. They are both !voting, and making a judgement about the discussion. This is definitely improper. If the late !voter did indeed make a good point, a qualified closer can make the decision about closing now versus relisting. A !voter is not a qualified closer. --SmokeyJoe (talk) 08:40, 12 August 2019 (UTC)
      • You say it's "improper", as if it's a given, without explaining why. Where is the harm? How does relisting by someone involved inhibit the community from reaching the correct conclusion? --В²C ☎ 17:04, 12 August 2019 (UTC)
        • It's improper because relisting is an administrative action, and all administrative actions should be performed only by an UNINVOLVED editor. The premise here is that the requested move is contested, and so this is serious. The harm is the risk of the relister having undue influence on !voters. Statements by administrators (persons performing administrative functions even if non-admins) carry more weight, and so the motivated editor can GAME the situation by by focusing the discussion onto their POV of whats important. There's also the simple GAMEing harm from the INVOLVED participant relisting strategically to give their !vote maximum exposure. --SmokeyJoe (talk) 12:47, 14 August 2019 (UTC)
  • 2 for first relist, 1 for further ones, per bd2412 and Amakuru. — JFG talk 07:48, 12 August 2019 (UTC)
  • 2 for first relist, 1 for further ones: per bd2412, Ams, and JFG. Ams presented very good reasoning, so did JFG. But there should something to avoid pointless/meaningless relist where there is a clear consensus, and no strong (and/or supported by policy) argument. I will add further opinion/suggestions in not too distant future. —usernamekiran(talk) 11:56, 12 August 2019 (UTC)
  • Different rules for different relists is pointlessly confusing. What should a non RM regular, you know, a content adder, make of it. Someone proposes a move, the discussion is contested and going slightly against them, so they make a new argument and relist it, supposedly to ensure that it won’t be closed now for another seven days? It was OK to GAME it on day 7, why not on day 14? —SmokeyJoe (talk) 00:31, 14 August 2019 (UTC)

Does asking a question make you “involved”?

I might be more willing to close/relist if I could ask questions (or otherwise comment with the intent of generating more discussion). Unfortunately, some people seem to think that leaving any sort of comment equates to being “involved”. Could we get some clarity on this? Blueboar (talk) 14:40, 12 August 2019 (UTC)

I relisted a bunch last night, including one in which I had posted a comment/question. I think I was not involved except in trying to elicit information that might help it converge. It might take some work to figure out which one that was, but I did think about exactly your question as I did it. Dicklyon (talk) 14:43, 12 August 2019 (UTC)
No. I think you have to have a position on the proposal to be involved. --В²C ☎ 17:06, 12 August 2019 (UTC)
  • Asking a pointed original question, yes, it makes you involved, from that point onwards. A qualified closer relisting certainly can ask a question, indeed making a refocusing comment is an excellent reason to relist. A comment-free relist is a pointless relist.
Compare WP:Deletion_review/Log/2019_August_12#JK!_Studios. There is no issue with a relister engaging, but having engaged with participants, that relister probably shouldn’t then do the close. —SmokeyJoe (talk) 11:40, 13 August 2019 (UTC)
I would say no. Prior to some recent changes to the section by Red Slash, the Who can close requested moves section of WP:RMCI was pretty explicit about this: It is fine for a discussion participant to close a requested move... If the closer's participation in the discussion has been limited to clarifying questions, or is otherwise neutral with respect to the proposed move. I think that's still a sensible policy. Colin M (talk) 17:53, 13 August 2019 (UTC)
Yes, it is sensible, but note clearly that is it describing the boundary line. Put a toe over it, engage in debate over the meaning of a question for example, and you should not go on to close the discussion. I would record RMCI to It is fine for a discussion participant to close a requested move... If the closer's participation in the discussion has been limited to clarifying questions, or and is otherwise neutral with respect to the proposed move. The asking of a clarifying question does not excuse you from being non-neutral. —SmokeyJoe (talk) 00:24, 14 August 2019 (UTC)

Technical requests

Discussion moved to here from Wikipedia:Administrators' noticeboard

information Note: I made this modification in order to ensure that all shortcuts from Wikipedia:Requested moves/Technical requests, as well as the instructions from Wikipedia:Requested moves/Technical requests/Instructions are transcluded to the main page. For further information see also here. Regards--Hildeoc (talk) 16:36, 18 August 2019 (UTC)

See Wikipedia talk:Requested moves/Archive 27 § Shortcuts question. – wbm1058 (talk) 23:36, 18 August 2019 (UTC)
Also <noinclude> tags around transclusion of Wikipedia:Requested moves/Technical requests/Instructions – wbm1058 (talk) 02:31, 19 August 2019 (UTC)
Hildeoc I think you will got your answers from those archived sections, if not feel free to ask here. Warm Regards, ZI Jony (Talk) 03:56, 19 August 2019 (UTC)
Back on 18 April 2018, when I wasn't paying attention, someone changed the shortcut for the main WP:RM page. This good-faith edit was incorrect, and broke something that wasn't broken. The shortcut WP:RM#TR redirects to the main RM page, while WP:RM/TR redirects to the subpage. – wbm1058 (talk) 04:23, 19 August 2019 (UTC)
I will further explain how this somewhat complex system works, for the benefit of those editors who are not administrators or page movers. On the subpage Wikipedia:Requested moves/Technical requests, there is a {{clickable button}}, which transludes to that page from {{Wikipedia:Requested moves/Technical requests/Instructions}}. The code div class="sysop-show extendedmover-show" ensures that only privileged users see the button:
?action=edit&oldid=911514327&summary=done+ Clear all requests
Feel free to click the above button, and also to Show preview and Show changes, but if you must save the page when there are open requests there, please do promptly self-revert. Note that using this button opens up an old version of Wikipedia:Requested moves/Technical requests, which is specified by its permanent link. Because of this setup, anytime you make a change to the Wikipedia:Requested moves/Technical requests that does not involve actually making a technical request, you must also change the permalink number specified by Wikipedia:Requested moves/Technical requests/Instructions – and you should only change the "cleared page" when there are no open requests posted to it.
Up until yesterday (or earlier today, depending on your time zone), the button reset the page to the version specified by special:PermanentLink/837158480, i.e. the version of 02:26, 19 April 2018. I changed it to reset to special:permalink/911483219 at 04:36, 19 August 2019 (see diff), and then Hildeoc solved the "extra new lines" problem with this edit, so I made that the new version of the "cleared page". Thanks, Hildeoc.
I hope and trust that everyone/everything is happy now. – wbm1058 (talk) 12:49, 19 August 2019 (UTC)
@Wbm1058: Thank you very, very much for your kind and instructive explanation! For my part, the issue seems settled now. Best wishes--Hildeoc (talk) 13:04, 19 August 2019 (UTC)

Misspelled actress name

An actress named Ketaki Kadam is facing alot of probs on getting verified in social accounts I request the team of Wikipedia to look on to this matter . Instead of " Ketaki " her name is mentioned as "Ketki" in her page.Please make the changes. She is having alot of problems with "a" not being added to her name. https://en.m.wikipedia.org/wiki/Ketki_Kadam Anu1999 (talk) 11:11, 14 August 2019 (UTC)

Her official Facebook page is this https://www.facebook.com/ketakikadamofficial/ And my friend Sydell has personally met Ketaki and the actress told her how much problems she faced for her verification of her instagram account when previously her account was me_ketaki_kadam on Instagram but because of verification problems she changed it to me_ketki_kadam but her real name is Ketaki . Please help her and get this problem fixed .IMDB has alo mispelled her name .Her real name is Ketaki it's because of this media articles that publish wrong names . Please try to understand Anu1999 (talk) 11:10, 21 August 2019 (UTC)

Scripts to do multiple page moves

Hey all,

Aware that there are RM scripts to allow round robin page swaps, but I've not found anything that allows you to do multiple page moves at once. Case in point, I do quite a few, and an RM the other day had about 180 pages in the request, and took a long time to do. Is there some form of user script (I can't find one) that would allow mass moves? Steven Crossin Help resolve disputes! 12:08, 21 August 2019 (UTC)

Bot which maintains the page not working?

It appears that the bot is not running which removes items from the Backlog and moves items from the Backlog which are relisted. Does it need to be re-started? --User:Ceyockey (talk to me) 02:55, 22 August 2019 (UTC)

Michigan murders was moved to Michigan Murders

I was involved. I wonder what some uninvolved experienced closers think of this closure:

--В²C ☎ 17:25, 26 August 2019 (UTC)

  • It seems... defensible to me. What a messy request and a messy situation, though. I think if you're unsatisfied, a books search proving that it is generally described in sentence case (well, besides Michigan, of course) would be effective. I just did a search now and found nothing in that direction, though. Red Slash 17:56, 26 August 2019 (UTC)
  • I was involved as well, but I think it was a good close. By my count...
  • 8 editors expressed an opinion.
  • 6 editors explicitly expressed an opinion on "Michigan Murders" (everyone but B2C and SmokeyJoe)
  • of those 6, 5 were in favour of it (though BarrelProof's support was not enthusiastic: I think "Michigan Murders" would be an improvement, but might not be the best option.) Only Wugapodes explicitly rejected the title, saying "Alt-capitalization does not help [the ambiguity problem]".
  • 3 editors (including BarrelProof, as nominator) supported the originally proposed new titles.
  • 1 editor (B2C) supported the then-current title, and, that !vote notwithstanding, I would say there was pretty solid consensus around BarrelProof's claim that the old title was ambiguous or misleading.
(I know a close is not a headcount, but I don't think there were any !votes that should have been discarded as patently illogical or not based in policy.) Given the level of agreement around "Michigan murders" not being a good title, I think it would be weird to close as No Consensus and leave it there. You could say it was a WP:NOGOODOPTIONS situation, but I also don't think it's unreasonable to say there was rough consensus for Michigan Murders. Colin M (talk) 20:05, 27 August 2019 (UTC)
  • I think a better option would have been to close this request and start a new one to move it to "Michigan Murders." That said, I think the close was reasonable enough that is doesn't warrant a trip to WP:Move review. Calidum 20:11, 27 August 2019 (UTC)
    • I thought at most it might be worth a discussion on the closer's talk page, but wasn't even sure about that, which is why I came here. I thought some sentence case prescriptivist might take objection. --В²C ☎ 20:29, 27 August 2019 (UTC)
  • It's another case of the adventurous tendency of NAC-ers not being a net help. You don't know whether to respect the close! Consequential follow-up processes will consume more admin resource than leaving for an admin to close. Admins are vetted for, among other things, the closing skills: knowledge of policy, ability to read consensus, and temperament. As a consequence of the qualification direct or indirect, their closes are respected, and so are efficient. --SmokeyJoe (talk) 01:04, 28 August 2019 (UTC)

Inter Milan

This article has been listed for the 5th time in 6 1/2 years.

The most recent decision to rejected the request stated that "Based on the previous discussions, it seems unlikely that such consensus will arise without either a relevant change in policy or evidence of a significant change in the way to which the team is referred" There has been no policy change or amendment to the way in which the team is referred.

Now, I thought I had read somewhere that repeated requests without a change in basis by the same group of editors was considered disruptive. As ever, it isn't possible to find links when needed and I admit that being on the leave alone side of the discussion might mean my understanding is tainted by wishful thinking :). Any experienced advice about repeated requests would be appreciated. Leaky caldron (talk) 08:41, 30 August 2019 (UTC)

Move of 2018–19_Sudanese_protests to Sudanese Revolution will need admin rights

This RM Talk:2018–19_Sudanese_protests#Requested_move_22_August_2019 seems uncontroversial - full consensus to shift to Sudanese Revolution. The source page is move-protected, so admin help from an uninvolved admin to do the move and close the discussion is needed here. Boud (talk) 21:58, 4 September 2019 (UTC)

Is there a tool to fix links after a move. Here's what I want. Given a move of A to B, A now redirects to B:

  1. Tool is given two inputs: current title (article B) and previous title (redirect A)
  2. Tool does a "what links here" on previous title (A).
  3. For every page returned in Step 2: substitute references to [[A]] with references to [[B]].
    • For example, if A=Foo and B=Bar, we want to substitute references to [[Foo]] with references to [[Bar]].
  4. Should handle these cases too:
    • substitute references to [[A|'''A''']] with references to [[B|'''B''']].
    • substitute references to [[A|''A'']] with references to [[B|''B'']].
    • Moving to parenthetic disambiguation:
      • For example: if A=Foo and B=Foo (film), we want to substitute references to [[Foo]] with references to [[Foo (film)|Foo]]
      • Note: this automatically substitutes references to ''[[Foo]]'' with references to ''[[Foo (film)|Foo]]'', which is fine.
    • Moving from parenthetic disambiguation:
      • For example: if A=Foo (film) and B=Foo, we want to substitute references to [[Foo (film)|Foo]] with references to [[Foo]], and...
        ... substitute references to [[Foo (film)|''Foo'']] with references to ''[[Foo]]''. (note where the quotes move)

Does such a tool exist? --В²C ☎ 23:46, 13 August 2019 (UTC)

This should not be done automatically, as there will be cases where the Foo link will be wrong, and changing these to Foo (wrong) automatically (when the target should be Foo (correct)) would make the problem worse. For the Foo to Foo (film) example, if you're turning Foo into a disambiguation page, then I use WP:DABSOLVER to fix the links to the disambiguation page. For Foo (film) to Foo, then there is no reason to change the links as they'll redirect to the correct place, and if the move gets reverted, then they'll be pointing to the correct place without needing to fix the links again. Iffy★Chat -- 11:52, 14 August 2019 (UTC)
Iffy's comment makes sense to me - in the most common case where the move just leaves behind a redirect, no action is necessary, per WP:NOTBROKEN. However, in the case of a usurpation (e.g. an RM like this), you really would need to change all the links to the usurped title, and I agree, it seems like a tool would be helpful here. I'm not aware of such a tool existing - maybe people use AWB and the like?
I also agree with Iffy that doing it fully automatically would be bad, per WP:CONTEXTBOT. e.g. imagine we move Adrenaline → Epinephrine, and then our tool changes some text from injectable adrenaline (also known as epinephrine) is used... to injectable epinephrine (also known as epinephrine) is used.... It's easy to imagine lots of other ways this could go wrong. But a semi-automatic tool that generates candidate edits which the user can review and then apply (or modify) seems useful. Colin M (talk) 18:36, 14 August 2019 (UTC)
FWIW, I closed an RM recently that entailed a mass rewriting of >100 wikilinks. I listed it at Wikipedia:AutoWikiBrowser/Tasks and someone had fixed them all with AWB within a few hours. Colin M (talk) 23:27, 12 September 2019 (UTC)

WP:RMCI bloated with opinions

WP:RMCI is bloated with opinion. WP:RMNAC is an old example. WP:NOGOODOPTIONS is a new example. These opinions, whether or not good, are not instructions, and do not belong on a page titled "Wikipedia:Requested moves/Closing instructions". Also, much of the opinion has been added without discussion. I propose to move non-instruction opinion to a new page, Wikipedia:Requested moves (advice), tagged as an {{essay}}.

The existence of Wikipedia:Simple RM closing instructions is an indicator that WP:RMCI has bloated. I don't think RMCI should be condensed anywhere near that far, but it should be condensed to unambiguous instructions. --SmokeyJoe (talk) 06:05, 2 October 2019 (UTC)

As far as I can tell the opinions at RMCI generally accurately reflect consensus of experienced closers. It's pretty well watched. So when people try to add stuff that does not reflect consensus, it tends not to hold up. So, it's not a mere essay (which does not necessarily reflect consensus). Yes, I agree it goes beyond instructions and is guidance too, but if we were to limit it literally to the instructions necessary for closing, yeah, that would be just Wikipedia:Simple RM closing instructions. So once you accept that advice and guidance is to be included, I think it's fine as it is, and expect it will continue to evolve. That said, if anything in there is not consensus-supported, it should be fixed. --В²C ☎ 18:06, 8 October 2019 (UTC)
There is a lot there that is not "consensus supported", merely that someone thought something was a good idea to write. WP:Bloat. I am objecting. In the first instance, the argument is not that the ideas are necessarily bad (although some is), but that instructions should be directly actionable and concise. The solution cannot be Wikipedia:Simple RM closing instructions as that page leaves out important things. --SmokeyJoe (talk) 23:44, 8 October 2019 (UTC)

Starting a RM with a probable WP:NOGOODOPTIONS

I'm preparing a move of climate change (an article about climatic changes in general) to another title (f.i. climate variability and change) per WP:PRIMARYTOPIC (Prep on User:Femkemilene/sandbox). Preliminary discussions indicate that while there seems consensus for a move away from climate change, it will be difficult to get consensus for A) whether an article about climate change in general should exist and B) what its title should be. With many possible titles floating about, I'm worried about keeping the discussion on point and getting towards a conclusion. Any tips for structuring the discussion to get to a consensus? Femke Nijsse (talk) 13:16, 8 October 2019 (UTC)

The whole point of any RM should be to present an argument that a particular proposed title meets WP:CRITERIA better than the current title. So definitely do that. Explain why the proposed title is better in terms of each of the criteria. Also be clear about what is to happen to the Climate change title: DAB page? redirect? To what? New article? Which one? And again justify in terms of WP:CRITERIA and WP:PRIMARYTOPIC, as applicable. If you think others might want to discuss deletion of the article, then just say any such discussion belongs at AfD and should at least wait until the RM is resolved. --В²C ☎ 17:51, 8 October 2019 (UTC)
If I were God of the Wiki, the article currently at Global warming would move to Climate change  — Amakuru (talk) 18:00, 8 October 2019 (UTC)
Thanks for the replies!
@Amakuru, I agree, and that is part of the motivation to have climate change renamed into something sensible. A second discussion (by either me, or somebody else) will start in which we'll propose a rename of global warming. Here again, there are a lot of proponents for different titles (climate change, human-caused climate change, human-caused global warming and climate change). With some support for the old title, I give it only a 50% chance we'll move, unless we have a consensus.
@SmokeyJoe & Born2cycle: I'll give it one more shot with getting consensus for a different title. We've been discussing this for six weeks actively and 6 months passively and I fear consensus just won't come. People are getting tired of talking and I wonder whether launching the formal discussion might help people be more open as we all have the same goal (move away from the current title). Femke Nijsse (talk) 07:00, 9 October 2019 (UTC)

Twinkle now supports basic Requested move nominations

The latest Twinkle update has a new feature in the XfD menu allowing editors to nominate pages for RM; you can thank User:SD0001 for the stellar work! I'd imagine folks might want to wait to add it to the instructions on this page, but in the meantime do let me know if there are any issues I missed. ~ Amory (u • t • c) 18:01, 20 November 2019 (UTC)

Discussion at Template talk:RMassist#Show_redirects

 You are invited to join the discussion at Template talk:RMassist#Show_redirects. Ahecht (TALK
PAGE) 17:40, 3 December 2019 (UTC)

Close and dash?

Any thoughts on adding something to the closing instructions about closers having to remain available to address any questions and concerns about a close for some reasonable time after the close? I presume we all agree that closing an RM moments before a 6-month-long wikibreak is ill advised, but can we tighten that down some? Would it be reasonable to require checking for notifications on your talk page at least every day or two for a week or two after a close? And what about failure to respond to such questions/concerns? Can a close and dash be grounds for a revert without going through a Move Review? --В²C ☎ 22:22, 3 December 2019 (UTC)

No to all of that. There are certainly reasons to overturn a move closure, but the closer not answering questions is not among them. Parsecboy (talk) 22:32, 3 December 2019 (UTC)
Really? Athough closers don't have to be admins, closing discussions is arguably an "administrative" function, and I don't see why WP:ADMINACCT shouldn't apply to all RM closers: Administrators are accountable for their actions ..., as unexplained administrator actions can demoralize other editors ... Subject only to the bounds of civility, avoiding personal attacks, and reasonable good faith, editors are free to question or to criticize administrator actions. Administrators are expected to respond promptly and civilly to queries about their Wikipedia-related conduct and administrative actions and to justify them when needed. Since this already applies to admins who close, shouldn't non-admin RM closers also be "expected to respond promptly and civilly to queries about their [closes] and to justify them when needed"? If so, then the question is, what to do when the closer does not meet these expectations? That's why I suggest a revert of the close is justified. I mean, if the closer is unwilling or unable to "respond promptly and civilly to queries about their [closes]", why not revert the close and let someone else close it? --В²C ☎ 01:20, 4 December 2019 (UTC)
It seems like a bad idea to condone reverting closures simply on the grounds that the closer hasn't responded quickly enough to satisfy a particular questioner. ╠╣uw [talk] 09:58, 4 December 2019 (UTC)
Is this a problem that comes up often? I don't feel like it's significant enough that it justifies the WP:CREEP cost of adding more rules. Also, the requirement to be responsive to messages within 24 or 48 hours seems excessive to me. Except for a few very rare cases (a controversial move of a high-profile page), there's no harm in waiting a few days for a response before going to MRV. WP:NODEADLINE and all that. Colin M (talk) 01:53, 4 December 2019 (UTC)
  • Unilateral reverts of closed RMs? No. That sounds like the pre-MRV days when RM closes were insufficiently respected. Admins may revert (or counter sign) NACs (but not due to them being merely NACs) and otherwise challenges are entertained at MRV. WP:ADMINACCT-failures, including not being available to explain a close, if repeatedly done, should mean a WP:AN thread chastising the closer. —SmokeyJoe (talk) 12:39, 4 December 2019 (UTC)
    So if you inquire or complain about one of my closes on my talk page, I can just ignore it? Okay; good to know. --В²C ☎ 18:03, 4 December 2019 (UTC)
    If you did, my option is to escalate at MRV. Maybe my whinge was frivolous. However, if MRV sustained my challenge, I would seek to have you banned from closing discussions, not the first time though, but if it was becoming a pattern. ADMINACCT is important, and applies to non admins playing an admin role. However, unilateral reverts of closes is damaging to the process, and MRV exists as the forum to challenge closes. I note that I have found you to have always been very good at responding to inquiries or complaints about your closes. —SmokeyJoe (talk) 20:41, 4 December 2019 (UTC). I suggest that one week should be the expectation for responding to the inquiry or complaint. —SmokeyJoe (talk) 20:43, 4 December 2019 (UTC)
    But the first step in the MRV process, which is pretty heavy weight, is to contact the closer on their talk page. What is their incentive to address questions/concerns if the questioner's only recourse to a non-response is to start a bulky MRV? What's so bad about a justified-by-lack-of-response unilateral revert? It just means that somebody else - hopefully willing and able to respond to inquiries - will have to close it. Most RMs are cut and dried and will close the same way regardless of who closes. But for the gray area ones - the ones most likely to be questioned - those are the ones where closer availability and explanation is most important. Why go through an MRV simply because the closer was unwilling or unable to respond (since it's likely a response would eliminate the need for an MRV)? Why encourage closers to not respond? I get the resistance to unilateral reverts of RM closes, I certainly wouldn't want that, but it's easy to avoid in what I'm proposing: closers respond to inquiries about their closes. That's not unreasonable, is it? --В²C ☎ 21:00, 6 December 2019 (UTC)
    No one's encouraging closers not to be responsive. They should be, and in my experience they are. Your question was whether we need rules about it added to the closing instructions. Personally I don't think we do. ╠╣uw [talk] 22:26, 6 December 2019 (UTC)
    Okay. --В²C ☎ 23:05, 6 December 2019 (UTC)

Nothing is 'support' or 'oppose'

If there is no 'support' or 'oppose' the requested move proposal, how should I do? May I cancel it? -St3095 (talk) 07:12, 6 December 2019 (UTC)

If you created the proposal and no one has yet replied, you can delete it. If someone else has created the proposal, you should definitely not cancel it. Station1 (talk) 08:07, 6 December 2019 (UTC)
@Station1: So, will I delete the proposal, including level 2 header? -St3095 (talk) 08:54, 6 December 2019 (UTC)
I assume you're asking about Talk:Jung Yun-seok. I've deleted it for you. If that's not what you want, just revert my edit there. Station1 (talk) 16:52, 6 December 2019 (UTC)
@Station1: Thank you, Station1. You have already removing my requested move proposal. ←click this blue link to see what you last edited! -St3095 (talk) 01:12, 7 December 2019 (UTC)

Moving from sandbox

I have an old draft of an article in my sandbox that, at some point, I would like to move to main space. At the bottom of my sandbox, however, is material (a family tree) that is related to another article, and that predates the article draft I would like to eventually move. Is there a way to move the draft with its edit history, without the prior material? Or would the only way be to move all the material at once, and then delete the unrelated portion (which would then remain in the previous versions, accessible through "View history"). Thanks, --Usernameunique (talk) 17:55, 9 December 2019 (UTC)

Since you're the only person to edit your sandbox, I don't see any special reason to keep its edit history. I would just cut and paste the relevant source code directly into a new article in mainspace. That way the family tree will have never appeared in mainspace and will not have to be deleted. Station1 (talk) 22:37, 9 December 2019 (UTC)
Or,as a variation, rename your sandbox to, say, sandbox1, then copy/paste the latest edits (without the family tree stuff and anything else you don't want) into a new sandbox, and go from there. --В²C ☎ 23:51, 9 December 2019 (UTC)

Move Over Redirect

Hello, I am with the New Pages Patrol and often encounter new articles that are poorly titled. I frequently move such pages to correct titles because I have basic Page Mover authorization. But accordingly, I also frequently encounter situations in which a simple move is impossible because of an old redirect, then I must come here and make a request for a technical move. (And the folks here always get it done quickly.) I am wondering if I could do such move-over-redirect actions myself and if so, which permissions are required. If only Admins can do it, I have no need to take it that far and will simply bring requests here as before. Thanks. ---DOOMSDAYER520 (Talk|Contribs) 20:45, 12 December 2019 (UTC)

The permission that allows for this is Wikipedia:Page mover. Iffy★Chat -- 20:49, 12 December 2019 (UTC)
I already have that permission, so I guess what I really need is practice on doing it. Next time the matter comes up, I will ask for more specific help. Thanks. ---DOOMSDAYER520 (Talk|Contribs) 21:05, 12 December 2019 (UTC)
User:Andy M. Wang/pageswap allows you to make WP:ROBIN page swaps (which lets you swap a page and a redirect around) easily. Iffy★Chat -- 21:14, 12 December 2019 (UTC)

Locked

What is the point of locking this page for editing to autoconfirmed users if one of its intended uses is to allow unregistered and new users to request a move? "He opened a pub, but people kept visiting it," as we say in Czechia... --93.91.252.108 (talk) 21:27, 13 December 2019 (UTC)

You don't request potentially controversial moves on Wikipedia:Requested moves. Please make the move request on the talk page of the article you want to move.
You may make technical requests on the page Wikipedia:Requested moves/Technical requests, which currently isn't protected. – wbm1058 (talk) 21:56, 13 December 2019 (UTC)

Confusing point in "potentially controversial"

In the section that appears as "Requesting controversial and potentially controversial moves", it has the following point:

  • *there has been any past debate about the best title for the page;

I could interpret this either as:

  • It's potentially controversial if there's been some notable debate in the past

-- or, possibly --

  • It's potentially controversial if there's been no discussion.

If both interpretations are intended, shouldn't they be separate points?

Can we better clarify the distinction? --A D Monroe III(talk) 19:29, 18 December 2019 (UTC)

  • Is there an equivalent of WP:BEFORE for this? Penistone Line was moved today "for consistency" (and then reverted), yet there's a two year old talk: thread on this where the same move was rejected, because these names are not consistent (some have reasons why they're capitalised). Should those both requesting a move, and actioning a move, check for similar discussions before one of these "non-controversial technical moves"? Andy Dingley (talk) 22:09, 8 January 2020 (UTC)
    Yeah, that was a mess-up. Tony1 apparently forgot that he had participated in my RM discussion about that back in 2017, and thought it looked non-controversial (which I can see, since the evidence is strong that lowercase dominates for Penistone line). So, mistake was made. How often does this happen? I wouldn't think putting more burden on the tech movers to check such things would be a better solution than leaving it up to watchers to object and fix. But yes the proposer should check; I've been guilty of missing such things a time or two myself, but I do usually remember to check. Dicklyon (talk) 01:15, 9 January 2020 (UTC)
  • I didn't recall participating in the RM three years ago. I saw that "line" is lowercase in almost all of the many siblings listed in the navbox at the bottom of the article, and thought: no brainer. Tony (talk) 01:24, 9 January 2020 (UTC)
    And I agree: no brainer. Yet as Blueboar points out, it is considered controversial because it has been debated before. Let's discuss it again, and maybe the strong evidence will convince people this time. Dicklyon (talk) 01:27, 9 January 2020 (UTC)
    • I hate to say it, but experience tells me that almost any move involving “decapitalization” should be considered potentially controversial. Capitalization seems to be one of those issues that is continuously debated. Blueboar (talk) 01:58, 9 January 2020 (UTC)
      • Agree. Title changes concerning styling or disambiguation should be never considered suitable for bold moving, unless done by the article creator on a recently created page. Even if there is a directly applicable line of a guideline, because that is evidence of policy-practice mismatch and policy-practice mismatches require getting light of a discussion. —SmokeyJoe (talk) 02:07, 9 January 2020 (UTC)
        • My impression is different. Probably 98–99% of my downcasing moves never get a comment, even those that need to come here for a technical. Most articles get created with caps because editors don't know better. Dicklyon (talk) 02:09, 9 January 2020 (UTC)
          • What if we excluded all articles of less than six months, created by editors of under 500 mainspace edits? At NewPagePatrol, and AfC acceptances, it is normal to fix the title. —SmokeyJoe (talk) 02:14, 9 January 2020 (UTC)
          • "Probably 98–99% of my downcasing moves never get a comment, "'
That's because of the volume you move, not because they're uncontroversial. Please don't ever assume that an inability to keep up with you is some acquiescence to them. Andy Dingley (talk) 11:43, 9 January 2020 (UTC)
Agreed. And agree with SJ: Any move for style changes should be considered potentially controversial (requiring an RM discussion unless it’s a revert of an undiscussed move). —В²C ☎ 16:53, 9 January 2020 (UTC)
Note... My saying that style moves (such as decapitalization) are controversial does NOT necessarily mean they are “wrong”... something can be correct and yet still be controversial. Blueboar (talk) 17:16, 9 January 2020 (UTC)
Agreed. What's "wrong" is moving for style reasons without discussion (because any style move is potentially controversial), not necessarily the move itself. --В²C ☎ 18:30, 9 January 2020 (UTC)
The theory that my many moves were wrong due to their quantity rather than their quality, and the theory that moves without controversy are "potentially controversial" just because they involve style, have been discussed and rejected elsewhere. A handful of anti-MOS voices want to say that a move motivated by the guidelines in the MOS are controversial, but that idea has never had much traction. Of course, sometimes they are controversial, and we discuss them, but those aren't the ones we're talking about for which the technical/uncontroversial process is used. Dicklyon (talk) 21:12, 9 January 2020 (UTC)
Well, certainly if MOS guidance potentially conflicts with usage in reliable sources then there is definite controversial situation to discuss. But to use the example you gave above, Soufrière Hills volcano, here we have reliable sources like USA Today[6], Science Trends[7] and BBC[8]using Soufriere Hills Volcano or Soufrière Hills Volcano, and, so, you were out of line filing a technical request, let alone moving it yourself unilaterally. --В²C ☎ 21:29, 9 January 2020 (UTC)
Well, the MOS seldom "conflicts" with sources. In the case of the volcano example, that's not anywhere near consistently capped in sources, and the MOS suggests avoiding unnecessary caps. There's no conflict in that just because some sources have a different style that caps it. Dicklyon (talk) 22:19, 10 January 2020 (UTC)

Oh, look, I fixed one within 6 months of its creation. Would it have been less good if I hadn't found it for a few more months? Dicklyon (talk) 06:04, 11 January 2020 (UTC)

  • Of course it is more good to fix errors sooner than later. It would be more good of you to post an explanation, whether on the talk page, or the article creator's user_talk page, and to be sure to include a link to the most relevant guideline. --SmokeyJoe (talk) 02:10, 14 January 2020 (UTC)

Join the discussion of possible removal of the process Technical move request

https://wiki.riteme.site/wiki/Wikipedia:Village_pump_(proposals)#Proposal:_Removing_Technical_Move_Requests_Process — Preceding unsigned comment added by Regice2020 (talk • contribs) 21:24, 15 January 2020 (UTC)

New technical requests: Place at the top or bottom of the list?

The instructions for uncontroversial technical requests are in a hidden comment, and say:

  • Insert the following code in the appropriate section, filling in page names and reason:
  • {{subst:RMassist| current page title | new page title | reason = reason for move}}
  • ---- and enter on a new line, directly below

That is, newer requests are placed at the top, like XfD. This is not particularly enforced, although seems to be mostly followed. As noted above, Twinkle now supports basic Requested move nominations, and follows those instructions at WP:RM/TR. Ammarpad requested a change to that behavior, asking Twinkle to place newer requests at the bottom, like RfPP or AIV. As such, I figured I'd open a section here to see if those instructions should change. ~ Amory (u • t • c) 16:12, 16 December 2019 (UTC)

Note that as well as the text "directly below" in the comment, the page's edit notice Template:Editnotices/Page/Wikipedia:Requested moves/Technical requests says "insert the following code at the top in the appropriate section" – wbm1058 (talk) 17:09, 16 December 2019 (UTC)
  • The instructions are clear about placing newer requests at the top, and seem to be followed. I see no reason to change. --В²C ☎ 17:06, 16 December 2019 (UTC)
    Not necessarily, I've wondered about this myself and have done it sometimes at the top and sometimes after. "Directly below" could mean directly below existing comments or at the top). Crouch, Swale (talk) 18:41, 16 December 2019 (UTC)
    We could change "directly below" to "directly below this line" to avoid any ambiguity. Station1 (talk) 02:10, 17 December 2019 (UTC)
    Agree, WP:CFDS says "PLACE NEW NOMINATIONS AT THE TOP OF THIS LIST, BELOW THIS LINE". And its usually less difficult to work that out since items there tend to stay for 48 hours so show up in order while those at RMT are removed after being moved which is not normally more than a few hours. Crouch, Swale (talk) 08:12, 17 December 2019 (UTC)
    If anyone does change it, just let me know so I can update Twinkle! :D ~ Amory (u • t • c) 01:57, 22 December 2019 (UTC)
  • I am the one who made the initial request, but after the initial objection I made it clear I don't want discuss this any further (because frankly I see the isssue not worth wasting time over) However I am commenting again since Amory mentioned me here. My reason of making the request (thinking it was just trivial) seems to be shaped with my workflow. Whenever I open the page I use to start from the topmost listing (which may have been placed just a minute before). If there are many entries for the day, the one at the bottom may spend several hours before being actioned, because of more and more newer requests that are being added. It also occurred to me at the time that the new behavior (listing at the top) started in few weeks/months back as before that most newer requests were placed at the bottom of existing requesting with very few exceptions, (I have not verified this with the page history, but I quite believe it's so). In addition, in many similar boards requests are placed at the bottom of existing request not top, to give few examples WP:RFP and WP:AIV. That was basically what prompted me to seek for the change. To repeat what I said, I don't think there's any benefit in discussing this further, I'd just adjust to the new style. – Ammarpad (talk) 23:28, 17 December 2019 (UTC)
  • I have made this change, namely updating the comment to say directly below this line (emphasis added), as well as a further comment also recently added regarding newlines and accessibility (see conversation at WT:TW. Please let me know of any additional changes or tweaks so I can update Twinkle. ~ Amory (u • t • c) 11:57, 31 December 2019 (UTC)
I notice the comment/instructions got changed back. So people (including me) got confused and put newer entries at the bottom of the list. I changed the comment to be clearer. Also I notice several people put blank lines between entries (2 blank lines in one instance), when the comment/instructions CLEARLY say no blank lines. So maybe people just don't read.
I also don't understand why people are making these requests from IP numbers (i.e. they're not logged in) for moves where the target page is a redlink. Just log in and they can make the move themselves. Maybe we could put a helping notice to that effect as well in the comment/instructions. LisztianEndeavors (talk) 15:10, 23 January 2020 (UTC)
Many IP editors don't have accounts. Some don't want accounts, but even if they open one, they can't move pages until they're confirmed. Station1 (talk) 21:32, 23 January 2020 (UTC)

ElectrifAi

"Please change the name of this article to ElectrifAi. Reason: The name has changed in 2019. Citations: https://www.prnewswire.com/news-releases/electrifai-a-global-leader-in-practical-ai-and-machine-learning-announces-new-ceo-and-launch-of-industrys-first-open-source-platform-300884394 :https://www.design-engineering.com/electrifai-launches-ai-industrys-first-open-source-machine-learning-platform-1004033460/" ZorbaKiki (talk) 21:34, 26 January 2020 (UTC)

@ZorbaKiki: This is not the right talk page for your request. --Izno (talk) 02:57, 27 January 2020 (UTC)

When technical requests are contested...

When technical requests are contested... what usually happens is it gets converted into a regular RM. That sounds good but this is often problematic. First of all, when someone makes a technical request in good faith they assume there is no potential controversy and therefore don't fully explain the reasons for the move. So when it becomes an RM there usually is no strong argument. I find this problematic for two reasons. First, as someone looking at an RM request with weak or no argument I tend to oppose. Secondly, if I'm the person who made the initial technical move request, I don't want it converted to a regular RM request if it's contest. I want it rejected and for me to be notified. Then I could look at and consider the reason given for contesting/rejecting. That might tell me something I overlooked and that the move is not worth proposing - why waste any more time on this? But if I still think it should be moved then I can prepare a proper RM, that day, later in the week, or perhaps months later.

So what I'm proposing is that when technical requests are rejected due to being contested (whether you or someone else is contesting), just delete them and notify the person who made the request. Let them decide whether to even pursue it as a regular RM, and, if so, how to present it. --В²C ☎ 01:30, 17 December 2019 (UTC)

  • How often does this happen? Every contested technical request should be taken as a TROUT. If you are making technical requests without serious consideration of possible reasons for contesting/rejecting, then you are not using sufficient consideration and should wind back on doing technical requests. That said, I think I agree that, by default, a rejected technical request should be flicked back at the nominator, not auto-made into a formal RM. I think it could/should be left to the discretion of an WP:RMTR#Contested technical requests admin-clerk. --SmokeyJoe (talk) 01:56, 17 December 2019 (UTC)
  • This sounds reasonable to me. I've participated in a fair number of RMs that were born out of contested technical requests and they do tend to begin in a confused state for the reasons you mention. One little complication: an unscrupulous (or confused) editor who has a technical request bounced might just wait a while and then file it again. If they're lucky, no-one will notice, and it might succeed on the next try. Whereas if it got converted into an RM, that would create a permanent record of the previous request. I don't think this is likely to be a significant problem, but just playing devil's advocate. Colin M (talk) 02:08, 17 December 2019 (UTC)
  • Born2cycle, see Template:RMassist#To opt out of discussion, if the request is contested. There have been requests in the past to make |discuss=no the default, and force editors to specify |discuss=yes if they want their contested requests automatically converted, but these proposals have been rejected. Search the archives. And I agree that every contested technical request from a highly experienced editor like you should be taken as a TROUT. – wbm1058 (talk) 05:31, 17 December 2019 (UTC)
    • Even if, for example, it's a technical request to revert a recent undiscussed move filed at Wikipedia:Requested_moves#Requests_to_revert_undiscussed_moves? --В²C ☎ 17:44, 17 December 2019 (UTC)
      • I'll assume you're referring to Cinema of Georgia. Yes, that one was a little awkward. Ideally the earlier discussion at Film industry in Georgia (U.S. state) would have been filed as a multimove discussion, but it's not unreasonable to take from Film industry in Georgia needing disambiguation that Cinema of Georgia would also need disambiguation. So the two admins here could have been less bold, but they weren't blatantly unreasonbly bold in their administrative decisions. It's not a good look to see you reverting two admins, even if technically you are procedurally correct. Show a little patience and let a discussion run for a week or two if necessary, even if the discussion is technically being hosted on the "wrong" title, it should be no big deal. I don't think there should be any "first-mover advantage" in cases like this, so it really shouldn't matter that much what title the article is sitting on during "discussion week". A little less reverting may lead to more feelings of good will. – wbm1058 (talk) 21:11, 17 December 2019 (UTC)
  • If all contested requests are automatically removed that would just create another problem, inexperienced users may just continue listing the article, I have seen this already. I believe the current behavior is fine, experienced users should already know about |discuss=yes and use it to suppress the link if necessary. So no change is needed here. – Ammarpad (talk) 22:54, 17 December 2019 (UTC)
  • Totally agree with В²C. When making a technical request I make my rationale telegraphic so that it fits in the automatic edit summary of the move. If I had wanted to start an RM, I would have done so and taken the time to provide a fuller explanation. Also, I'm really uneasy with the way contested requests are normally handled, with the original RMT simply pasted into the format of an RM request. At the very least, this creates a talk page post ostensibly signed by an editor who did not make that post (and a minor point: given that the technical request's original timestamp is used (which is usually several hours before the time the RM has been initiated), then the RM will appear to have been running for a bit longer than it actually has). And yes, I've been using RMT for years and it has never occurred to me to look up the template's talk page and it has never occurred to me that there could be a switch that can turn off the default behaviour, at the least because I never would have expected the default behaviour to be what it is. – Uanfala (talk) 03:08, 8 January 2020 (UTC)
    • I've just added a mention of |discuss=no to the hidden text at RMT [9], though I don't think this solves the fundamental issue. – Uanfala (talk) 03:18, 8 January 2020 (UTC)
      • It was removed, probably accidentally. I restored it. It's a good idea. Station1 (talk) 10:02, 8 January 2020 (UTC)
        • This has been removed yet again, almost immediately after you've added it. The reasons why this happens: the text at the top of the RMT, transcluded from Wikipedia:Requested moves/Technical requests/Instructions, has a button, invisible to everyone except sysops and pagemovers, that clears the requests, and this clearing is achieved by restoring an old revision of the page. I think I've fixed that now [10].
          I'm wondering though, if a more substantial change to the boilerplate text might not be in order. See, the instructions don't documented this practice, and if anything they lead you to not expect it. It's got three bullet points: how to list a request, how to object to a request, and how to start an RM if you request is contested. The presence of this third point sends the message that it's up to you to start an RM, and that makes it even more surprising to see your technical request turned into an RM as part of standard clerking. – Uanfala (talk) 21:48, 26 January 2020 (UTC)
  • I've thought about this a little bit more, and I'm finding this practice of automatic conversion to RM even more baffling than before. I can't think of an analogue in other processes on wikipedia. Take deletion, for example. If you tag a page for speedy deletion, or if you prod an article, and then someone objects, then what they'd do is remove the tag and notify you. They wouldn't automatically convert your prod into an AfD, would they? Sending contested techincal requests to RMs makes sense only if the original proposer is a sporadic editor and you don't expect them to be around when their request is challenged. I really can't see why this should be done in any other circumstances.
    And I really don't buy the argument that experienced editors shouldn't make technical requests that will be challenged. The naming conventions can be complex and it's not unusual for a moderately experienced editor to believe something to be a straightforward uncontestable application of a guideline, when in fact there would turn out to be another guideline that overrides that (think of the exceptions to the exceptions to the exceptions when it comes to the capitalisation of French operas). And it is equally likely for the objection itself to be raised out of unfamiliarity with the guidelines: RMT is not patrolled only by seasoned admins, but by newbie pagemovers and by the requesters of the moves themselves. I did have a request contested some time ago by an anonymous editor who believed the cleanup following up on the move wouldn't get done; I had forgotten about this request and I wasn't notified when it got turned into an RM, so when I did come across it a bit later I was totally creeped out at seeing my signature after an RM I had not started. – Uanfala (talk) 22:09, 26 January 2020 (UTC)
  • @Uanfala: please review past discussions as outlined at Wikipedia talk:Requested moves/Archive 32#No more discuss link on technical requests – wbm1058 (talk) 03:16, 27 January 2020 (UTC)

Template won't allow me to request a move

I am trying to request that Ifedohlapo/sandbox be moved back to User:Ifedohlapo/sandbox, but the template won't allow me to submit the request, giving a "current page title is invalid." error.
I know the "current page title is invalid", that is one of the reasons (along with it not being ready for mainspace) that I want the article moved
Can someone please

  1. Move the article back to User:Ifedohlapo/sandbox
  2. Fix the template so that when asking to move an article with an invalid name, it does not refuse to register the request

Thank you - Arjayay (talk) 13:31, 29 January 2020 (UTC)

I've swapped the pages for you, will look in to the template to see what caused the issue. Iffy★Chat -- 13:44, 29 January 2020 (UTC)
Not sure what issue you were having, as I wasn't able to replicate the issue when previewing Main => User requests at WP:RM/TR. Iffy★Chat -- 14:33, 29 January 2020 (UTC)

Requesting close

Can someone take a look at what is (I think) not a difficult close at Talk:Novel coronavirus (2019-nCoV)? It would be good to move past the current request so that a new one can take place (if needed). Dekimasuよ! 00:56, 31 January 2020 (UTC)

Speedy close needed

Only about a week after closure (with near-unanimous support, after revised !votes) of Talk:Syrian civil war#Requested move 15 January 2020, someone has re-RMed it at Talk:Syrian civil war#Requested move 30 January 2020 with no new arguments of any kind, just recycling the same ones. This is out-of-process and is obvious WP:PARENTSHOPPING for a "better" closing admin, to WP:WIN. It's suspicious that a rapid-fire series of support !votes (making WP:JUSTAVOTE comments that simply reassert the arguments that failed last time without addressing why they failed) has magically appeared, after nothing like that kind of support only a week ago. WT:MILHIST was not canvassed (or even notified with studious neutrality), so where did this clan of over-capitalizers suddenly materialize from? E-mail coordination? Hard to be sure. But the tendentious proof by verbosity pattern is noteworthy: "If I just keeping saying it, I must be right."  — SMcCandlish ☏ ¢ 😼  06:25, 1 February 2020 (UTC)

  • Agreed. The process if people disagree with the move or missed it for some reason, is to talk to the closer requesting a relist, and if they refuse and you still disagree with them, to go to WP:MRV. Reopening the same RM in the other direction is almost never appropriate. That said, I was quite vocal in support of the lowercase title at the 2016 RM so some might consider me involved. I'll therefore just join this request for a speedy procedural close.  — Amakuru (talk) 07:25, 1 February 2020 (UTC)
    Yeah, it's not about which direction is being argued, it's that it's immediate rehash with no new information or rationale. We have processes for controverting closes, and WP:BATTLEGROUND isn't it. I'd forgotten (because I focus on content not contributor and thus tend not to try to remember usernames) but see also the participation of the opener of the new RM in the RM just before it: the editor has as self-declared "Jesus, not this again" attitude, of their mind already being made up to favor capitalization no matter what policies or sources indicate for the specific case in question. This is WP:GREATWRONGS / WP:SOAPBOX pushing of "capitalize Military Stuff for Being More Important" nonsense (the editor seems to edit nothing but military material), and the "linguistic" arguments advanced by this person are embarrassingly wrong (like even 7th-graders generally know better) as well as being circular-argument WP:IDHT stuff (repeated again today; no matter how many times you explain something to this editor it just goes in one ear and out the other). This may be some kind of ESL matter, I'm not really sure, but it's clearly a competence one of some kind or another, and it's not a proper use of RM.  — SMcCandlish ☏ ¢ 😼  18:39, 1 February 2020 (UTC)
 Closed — JJMC89 (T·C) 03:25, 2 February 2020 (UTC)

Backlogged request appeal

Hi there. Wondering if an editor who's able to close requests can take a look at Talk:Writers Guild of America Awards 2019#Requested move 23 January 2020. Thanks very much. -- Wikipedical (talk) 00:55, 4 February 2020 (UTC)

Anyone can close it, but there's a lot of work to be done on that one, so maybe people are reluctant to jump in. If you voluteer to do the work, I or someone else can write the obvious simple close. Most of the moves are easy (to redlinks), and if some aren't you can request them at WP:RMTR citing the close; the RMTR template makes the job trivial for a mover. Dicklyon (talk) 01:26, 4 February 2020 (UTC)
 Done — JJMC89 (T·C) 04:50, 4 February 2020 (UTC)

Bug in bot?

This request is currently listed under Wikipedia:Requested_moves#Possibly_incomplete_requests:

However, the request listed there is a multi-page request which includes moving Objectivism to Objectivism (disambiguation) (which currently redirects to Objectivism). So the "... and is not requested for move" part above is incorrect, and I think this request is improperly listed there and indicates a possible bug in the bot. --В²C ☎ 17:33, 5 February 2020 (UTC)

I believe it's an error too. I removed it to see whether the bot would restore it and it did. The function to check for this was recently added (in January), so maybe Wbm1058 should reassess that check. 05:50, 9 February 2020 (UTC)

There's also a somewhat related issue at Talk:Max Rose (politician). The bot apparently thought the request was malformed because it proposed to move the article to Max Rose and eliminate the dab page altogether[11] rather than move it to Max Rose (disambiguation). Someone tried to fix it by changing the proposal into a multi-move request,[12] but now it incorrectly looks like the nom is asking for the dab page to be moved instead of deleted. Station1 (talk) 07:35, 9 February 2020 (UTC)

Help! RM Backlog has over 125 entries!

Request early resolution on '2019-nCoV acute respiratory disease' rename

Hoping that an admin can review the move request for Talk:2019-nCoV acute respiratory disease § Requested move 12 February 2020. There appears to be a firm consensus for the topic title to be changed with slight disagreement between these three options. The most popular option is 'Coronavirus disease 2019'.

These are the three options discussed. Hopefully they're close enough that an admin can decide.

  • Coronavirus disease 2019
  • Coronavirus disease 2019 (COVID-19)
  • COVID-19

- Wikmoz (talk) 05:54, 14 February 2020 (UTC)

The doubled title would be deprecated, and I am involved, but I concur that this is worth looking into. I'd also suggest imposing a temporary moratorium on future move requests once the current requests are closed at Talk:2019-nCoV acute respiratory disease and Talk:2019 novel coronavirus. Dekimasuよ! 08:31, 14 February 2020 (UTC)
Please note that although Talk:2019-nCoV acute respiratory disease has been removed from this list based upon an WP:IAR close, the title discussion has been reintroduced as an WP:RFC that isn't listed on the requested moves page. I'm not fond of the venue change, but at any rate please consider participating at Talk:2019-nCoV acute respiratory disease#RfC: What should the new name for this article be?. Dekimasuよ! 02:13, 15 February 2020 (UTC)
recycle Reopened The original RM was reopened and additional editor input has been received. Are there any uninvolved admins left to review and make a WP:NOGOODOPTIONS choice based on the discussion? - Wikmoz (talk) 06:30, 17 February 2020 (UTC)

Omg could this page get more complex?

I’m trying to do a simple move:

Template:RMassist must be used on Wikipedia:Requested moves/Technical requests. Gleeanon409 (talk) 04:59, 27 February 2020 (UTC)

But the page is complex enough that Visual Editor always opens the wrong section. Any help appreciated! Gleeanon409 (talk) 04:59, 27 February 2020 (UTC)

Seems like this request has now been taken care of here. - Station1 (talk) 08:48, 27 February 2020 (UTC)

It seems that permalinks are no longer linked in move reasons for requests at WP:RM/TR. This makes it harder to find where the move came from, because users would now have to dig through the history of the technical requests subpage.

Compare the histories of Chief Minister of Sabah and Scottish Asian, and you will notice the difference. GeoffreyT2000 (talk) 15:36, 25 February 2020 (UTC)

The links were created using {{REVISIONID}}, which is disabled. It results in a '-' instead of the revision ID. — JJMC89 (T·C) 04:48, 26 February 2020 (UTC)
See Change {{REVISIONID}} from number to "-" in wgMiserMode, which was installed by the MediaWiki 1.35/wmf.21 update:
— wbm1058 (talk) 16:09, 28 February 2020 (UTC)

Migration guide

Edit summary permalinks for advanced user actions

On Meta-Wiki, it is common to use {{REVISIONID}} in combination with {{fullurl:}} to give privileged users a way to quickly perform an action with the edit summary already pre-configured to reference the current version of the page. For example, when fulfilling a request from another user.

This feature has been accommodated with a small JavaScript snippet, that can be used in templates via class="tpl-permalink-reason". An example can be found at Meta-Wiki JS and m:Template:Checkuser.

— wbm1058 (talk) 16:55, 28 February 2020 (UTC)

@Wbm1058: Has this snippet been installed on the enwiki, or is it only on Meta? How would that solution work for Template:RMassist/core where we have to encode the revision ID into the preload section of a URL? --Ahecht (TALK
PAGE) 18:41, 28 February 2020 (UTC)
I haven't looked into it yet, but will if none of the other technically-oriented editors who've worked on this beats me to it. This new solution will require all admins and page-movers who work at technical requests to install a special script. {{REVISIONID}} is not a template; it's a "magic word" recognized by the MediaWiki software. – wbm1058 (talk) 18:54, 28 February 2020 (UTC)
Page movers and administrators installing a script isn't a solution, since the REVISIONID needs to be inserted into the URL by the user submitting the edit request, who is likely an unpriveledged user or an IP editor. --Ahecht (TALK
PAGE) 19:06, 28 February 2020 (UTC)
No, that's not how it works. Look at the page history of Skydive Hibaldstow. The permalink for that move points to the same edit by IceWelder. The moves by the admin/page mover generate the permalinks, and all 13 of these moves will permalink to the version of the technical requests page that was live when the pages were moved. – wbm1058 (talk) 19:30, 28 February 2020 (UTC)
I may need Interface administrator rights to optimally implement this. See Wikipedia:Interface administrators' noticeboard#MediaWiki:Group-user.js for a related discussion. – wbm1058 (talk) 16:26, 29 February 2020 (UTC)

Early rename

Is there a technical reason against continuing a discussion to its full course after a bold move has been performed by someone not aware of the discussion, without the need of a revert and the most likely subsequent second move. See Denys Shmyhal Agathoclea (talk) 08:25, 6 March 2020 (UTC)

No there's not and that has been done many times. It's just a matter of common sense and agreement of participants. But sometimes it may be moved back regardless to avoid the current title getting advantage due to WP:FAIT. So it depends. – Ammarpad (talk) 08:41, 15 March 2020 (UTC)

RM Withdrawn - cleanup needed

Here I have posted a RM (using {{subst:requested move}}). However, later I decided to withdraw the proposal (to reconsider the change). I could not find a process for this. I manually nullified the talkpage template [13].

My request: this needs cleanup too (a simple revert?): [14], the in-template notice.

I don't know about other effects to clean up. It looks like this project page (here) is clean: [Wikipedia:Requested_moves/Current_discussions#March_13,_2020]]. -DePiep (talk) 10:57, 15 March 2020 (UTC)

Updating rationale after request

There is no guidance. Can the nominator update the rationale after making the request? —Michael Z. 2020-03-17 13:34 z

You can always edit anything, this is Wikipedia But usually you should just add a comment directly below the nominating statement. Red Slash 23:41, 20 March 2020 (UTC)

Help me

Dear sir,

I create an article in my draftspace about a female leader and when it get completed I tried to move it to article page but there someone previously uses her name and redirects her name to new name (his husband's name). And, They both are diffrent person. (Husband and wife) but wife's name is redirected to husband's article.


Help me sir. Sturdyankit (talk) 23:44, 26 March 2020 (UTC)

It doesn't appear that she (Draft:Heena Shahab) meets WP:NPOLITICIAN as she has never been successful in an election. The article is also written in very poor English and doesn't appear to be suitable for mainspace. In places I cannot work out what is actually meant by the text. Number 57 00:04, 27 March 2020 (UTC)
@ClemRutter, Shyamal, Airplaneman, and Barkeep49: Probably worth you seeing the comments above as you have been contacted directly by the same editor. Number 57 00:06, 27 March 2020 (UTC)
I saw the request for help and have not had capacity to look into this; thanks for the ping Number. Best, Barkeep49 (talk) 00:11, 27 March 2020 (UTC)
@ClemRutter, Shyamal, Airplaneman, and Barkeep49:Okay never mind i asked you for help i'm new here. I was having trouble.By watching Wikipedia's guidelines, reading blogs and youtube tutorials, I learn how to edit.All of you are editing from 14-15 years and are fully experienced. I thought no one would reply, that's why I messaged you all together I love to write Wikipedia, I saw in User Guideline that an admin can fix my problem and there was mentioned talk to the admin or experiences users for help, so I have selected all of you from the admin list and message.But you guys made fun of me.Sturdyankit (talk) 02:45, 27 March 2020 (UTC)
Sturdyankit, no need to never mind. I am always happy to help new editors :). I have had a chance to look at the draft now. I can tell a lot of care and effort went into drafting that article. Have you looked at WP:NPOL? This details the criteria we use to evaluate politicians. It's unclear to me that she passes this. Best, Barkeep49 (talk) 03:49, 27 March 2020 (UTC)

Help requested

I'm posting here to request help on a move that has already taken place. Not being an MOSNAME expert I'm trying to bring more eyes to a discussion at Talk:CMG Guanghua Road Office Area. If more experienced folks could check out the facts and weigh in there it'd be appreciated. Tiderolls 18:52, 31 March 2020 (UTC)

Semi-protected edit request on 2 April 2020

Hello, I would like to move the page for UncommonGoods to Uncommon Goods. The company has been rebranded and is no longer recognized as UncommonGoods. This can be verified on their official website, uncommongoods.com

 Not done: this is the talk page for discussing improvements to the page Wikipedia:Requested moves. Please make your request at the talk page for the article concerned. —KuyaBriBriTalk 16:44, 2 April 2020 (UTC)

Boilerplate text for adding new entries

I don't know whence the boilerplate text is generated, but it includes the four-tilde signature placeholder after the {{subst:RMassist}} (at least for technical requests). But the template automatically adds the signature, so this is unnecessary and wrong (and the instructions say not to add a signature, for this reason). Can we remove it from the boilerplate? 62.165.198.73 (talk) 04:18, 20 April 2020 (UTC)

New rules I propose for WP:RM

  1. Only a registered Wikipedian may initiate a proposed move.
  2. Only a registered Wikipedian may make the first oppose vote.

Any thoughts on similar proposals?? Georgia guy (talk) 01:00, 30 March 2020 (UTC)

  • I expect unlikely to be agreed to. At a minimum, an IP with any edit history with the article or related articles would have to be exempted. I support the idea that IPs must not be allowed to be MOS-warriors, but on an article the title is the most important content, and IPs are the most important content contributors. —SmokeyJoe (talk) 03:16, 30 March 2020 (UTC)
  • Anyone should be able to make a suggestion to improve an article, and the reasons behind opposing a move are more important than who opposes it. Further, IP editors are unable to perform moves themselves, so they have no real choice but to request assistance. Therefore, I don't think this should be implemented. Dekimasuよ! 04:09, 30 March 2020 (UTC)
  • I don't see any benefit to such a rule and am not aware of any problems caused by IP contributors at RMs. Station1 (talk) 06:07, 30 March 2020 (UTC)
  • Placing restrictions on users based on the fact they are IPs requires that the overwhelming number of IPs pose a problem for WP in this regard, and that there is no other viable solution. No evidence of this has been presented. Also, per WP:VOTE, arguments are given weight, not counting user votes anyway; I find it difficult to see how this could be a problem. --A D Monroe III(talk) 21:09, 31 March 2020 (UTC)
  • No. Reasons matter. Who presents them doesn’t matter. —В²C ☎ 06:07, 14 April 2020 (UTC)
  • Oppose, for reasons given above. Mathglot (talk) 11:36, 14 April 2020 (UTC)
  • Oppose:
  1. As stated above, IP editors cannot move articles, so they (we!) have no other way of improving Wikipedia in this aspect.
  2. Why should an IP editor be allowed to support a move (or other comment) as the first !vote, but not oppose it? Does proposing an alternative title constitute an oppose !vote? The proposal biases the process in favour of moving articles to the suggested title, unless a registered editor sets the ball rolling. It would be fairer to say "Only a registered Wikipedian may make the first !vote". But why does it matter what order the !votes are !counted?
Incidentally, as an IP editor I try to make clear in the discussion whether I am the same editor when my IP changes (or more than one IP editor contributes to a discussion). That reduces confusion that might otherwise be considered disruption. 62.165.198.73 (talk) 04:27, 20 April 2020 (UTC)

Reconsidering the 7-day waiting period

The current practice seems to be that requested moves are always required to remain open for 7 days except in the most blatant WP:SNOW cases. I regularly see this causing harm. In cases where the outcome is clear but not quite SNOWy, it wastes editor energy reaffirming a consensus that already exists, delays the move to a better title itself, (for the most active talk pages) clogs up the talk page, and pollutes the article by keeping a notice at the top. See this conversation for an example of these concerns, or consider the move moratorium that recently had to be implemented at one very active page because this process broke down. The fundamental problem is that, while seven days may be a good rule of thumb for medium-traffic articles, it is often too long for high-traffic articles and too short for low-traffic ones. I propose that we remove the 7-day requirement and let RMs be closed as soon as consensus becomes clear or it becomes clear that further waiting is unlikely to lead to a different result. - {{u|Sdkb}} talk 10:46, 22 April 2020 (UTC)

  • Nah... It often takes several days for editors to notice a move request and to respond. I have participated in many discussions where it initially appeared that consensus had formed for (or against) a move... only to have the consensus change half way through the week, as more editors responded. Blueboar (talk) 11:14, 22 April 2020 (UTC)
  • Sorry, no. I quite agree with Paine Ellsworth comments on ANRFC that Talk:Nova Scotia killings#Requested move 20 April 2020 is not a good example of a snow closure because there is significant opposition. At a point in time NickCT counted 42 support, 10 oppose, 4 other. In other words, about 18% of participants oppose. That's not even close to a SNOW closure. Discussion is ongoing and may help to determine a more appropriate title than the one proposed to avoid any need for future move discussion. And calling a maintenance template "pollution" is an opinion that is not universal. The coronavirus situation is an entirely different kettle of fish and such extraordinary cases should not be used as basis for generally applicable policy and guidelines. older ≠ wiser 11:19, 22 April 2020 (UTC)
Should be longer ...10 days..our academic editors are not here fulltime and they are the ones we need to hear from. Side note ongoing RfC should not be archived till over....template shoulds use the pin option.--Moxy 🍁 16:02, 22 April 2020 (UTC)
  • Strong support - This is particularly important for current events articles. Yes, I realize that WP is WP:NOTNEWS, but often when there are articles about late breaking events, those articles are initially given stupid names. It's important that RM's are able to rapidly change those names. Otherwise, we just end up looking stupid. @Bkonrad: - So 80% isn't consensus for you? You realize that's far more agree than is achieved on virtually any subject? How much agreement is necessary? What's your standard? It's not enough to simply sit there and say "that's not good enough". You've got to define what is good enough NickCT (talk) 16:39, 22 April 2020 (UTC)
  • Strong oppose for the reason mentioned by Blueboar. I think this is especially true in the case of parent articles. A relative few editors can create a local consensus resulting in a move. After that editor who only realized there was a move discussion after the fact now must gain a consensus for reversal. We aren't in a hurry and personally I would rather move discussions have a RfC like 30 day window. Springee (talk) 17:31, 22 April 2020 (UTC)
    • @Blueboar and Springee: - Weird that people focus on what's right for editors rather than what's right for readers. Remember folks, non nobis solum. You guys realize having bad names stuck on articles can make us look dumb, right? NickCT (talk) 17:36, 22 April 2020 (UTC)
      • If it's a bad name then SNOW is likely going to cover it. I'm thinking about "Car" vs "Automobile". Hard to argue that "Automobile" was an embarrassing name. Conversely, how often do we have an embarrassing name that isn't addressed via SNOW? Springee (talk) 17:40, 22 April 2020 (UTC)
        • @Springee: - See Talk:Nova_Scotia_killings#Requested_move_20_April_2020. NickCT (talk) 17:49, 22 April 2020 (UTC)
        • @Springee: - I mean, I agree with you/Blue in the sense that in "normal cases" 7 days seems like a good guideline. But I think there are certain cases (e.g. current events) where 7 days is just too slow. NickCT (talk) 17:52, 22 April 2020 (UTC)
          • I’m seeing some very thoughtful replies (and some good alternative suggestions) in that RM. It is definitely not a SNOW close. My analysis is that most people agree that the current title is flawed, but no consensus has formed (yet) on what the new title should be. It seems like a good example of a situation where we DON’T want to rush the process, and let a firmer consensus form around one of the suggested alternatives. Blueboar (talk) 18:07, 22 April 2020 (UTC)
          • @NickCT: I'm not sure that Nova Scotia killings is such a "stupid" name as to need to circumvent a full discussion. Yes, it should be moved, which name is best may not be completely clear at this point of the discussion, but I see nothing so stupid about the title that it causes any genuine problems. A "stupid" title that would need fixed expeditiously would be something factually incorrect or biased. older ≠ wiser 18:15, 22 April 2020 (UTC)
            • @Bkonrad: - I'm not sure the title is "stupid" so much as it's just "bad", which seems clear from the discussion. We look stupid when we consistently have bad titles for current event articles that we can't rapidly change. To be clear, I agree with you that there may not be consensus on "which name is best", but there does seem to be consensus that the current name is not good. NickCT (talk) 18:44, 22 April 2020 (UTC)
              • @NickCT: I don't see where Paine Ellsworth indicated there was such a requirement. He stated he did not think it met standard for a SNOW close and that the RM should be let to run the normal course. Stop making this into something it is not. older ≠ wiser 15:21, 23 April 2020 (UTC)
                • @Bkonrad: - You replied to the wrong comment. He said there was consensus, but we shouldn't close b/c we must wait 7 days. How is that not equivalent to saying there is a requirement that we wait 7 days? NickCT (talk) 18:58, 23 April 2020 (UTC)
  • Support relaxing the seven-days requirement for clear SNOW-y closes. Maybe allow them to be called after five days. BD2412 T 18:13, 22 April 2020 (UTC)
  • Just for the record, there is no "requirement" that discussions must stay open for 7 days and they are often closed more quickly when consensus is clear and further discussion is not productive. It is largely up to the discretion of closing editors. However, editors who close a discussion early risk being whacked with a wet trout or worse. older ≠ wiser 18:20, 22 April 2020 (UTC)
    • @Bkonrad: - So what's this comment? NickCT (talk) 18:47, 22 April 2020 (UTC)
      • @NickCT: It looks like a perfectly reasonably comment. Do you have a more specific issue about that comment in the context of my comment above? older ≠ wiser 11:53, 23 April 2020 (UTC)
        • @Bkonrad: - Oh come on. You just said there is no requirement. The comment says there is. Are you wrong or is this person wrong? NickCT (talk) 14:37, 23 April 2020 (UTC)
          • @NickCT: Sorry, but I don't see what any contradiction or why you are making such a issue out of it. Paine did not say there was a requirement. Period. He said WP:SNOW did not apply (as many here have agreed) and declined to close the RM prematurely. older ≠ wiser 21:45, 23 April 2020 (UTC)
            • @Bkonrad: - I'm just fascinated by your interpretation of English. If someone said to you, "You shouldn't drive more than 50 mph on this road", you wouldn't take that to mean there was a required speed limit? NickCT (talk) 22:19, 23 April 2020 (UTC)
              • @NickCT: Except that is not even close to being equivalent to what Paine said. older ≠ wiser 22:23, 23 April 2020 (UTC)
                • @Bkonrad: - "we should wait until the move request has run at least seven days" NickCT (talk) 22:48, 23 April 2020 (UTC)
                  • @NickCT: Um, right and what about that says requirement to you? After declining the SNOW, this is nothing more than allowing the RM to follow the standard course. It says nothing about seven days being a requirement in any sense other than it being the normal course of affairs. older ≠ wiser 00:23, 24 April 2020 (UTC)
                  • @Bkonrad: - You're serious? So how is it that "you should do X" in one context means there's a requirement to do something and in another it's "following the standard course". Sorta contorted.... If someone accepts there's consensus to do something, but declines to do it b/c of some rule, they're clearly following a rule. A requirement. NickCT (talk) 02:30, 24 April 2020 (UTC)
                  • @NickCT: You're confusing a requirement with editorial discretion. RMs are often closed before running full seven days when the outcome is certain and further discussion unproductive. It may be a certainty that the Nova Scotia article will be moved, but there was no certainty as to the best name and productive discussion was ongoing, hence no reason to close early. I fail to see how that is so difficult for you to comprehend. older ≠ wiser 09:05, 24 April 2020 (UTC)
                    • @Bkoonrad: - Look, I don't care whether you call it "editorial discretion" or "following the standard course", or whatever. The contradiction you're not explaining is why you, when presented with two sentences phrased in a very similar way, would interpret one sentence to be relaying a "requirement" and the other to be relaying something else. I think you recognize the contradiction you've got yourself into here and are just being willfully obtuse. NickCT (talk) 17:00, 24 April 2020 (UTC)
                      • @NickCT: No, I'm really quite mystified as to why you're going on about this. There is no contradiction that I can see. What I see is you misconstruing statements. But neither of us appear to have anything new to say, so I will not respond further. older ≠ wiser 22:45, 24 April 2020 (UTC)
  • Moral support per WP:NOTBURO but oppose any substantive change to guidance. The proposal is essentially a restatement of WP:SNOW. I support closing discussions when the outcome is obvious, regardless of the timeframe, but in general 7 days is a good rule of thumb and consistent with nearly every other process on Wikipedia. Some people only edit on weekends, and a 7 day period ensures they can weigh-in on borderline cases. If it's day 5 and obvious, close it. If it's day 7 and no opposition, close it as move (kinda like an uncontested AFD can be deleted as a PROD). But we should keep the benchmark at 7 days. — Wug·a·po·des​ 07:33, 23 April 2020 (UTC)
  • Against scrapping - I just see this causing more angst than it might avoid. If we need to example SNOW a little better that's fine, but while it does cause some irritation, it also avoids it. I'm firmly against NickCT's reasoning that jumping sooner in current affairs articles either because we'll look stupid or because most of the reading could be within that week. Better to be somewhat worse in the short term than fail to get the right long-term call; and we don't make our decisions off page views - that method lies chaos. I don't know if it's in the formal guidance, but one semi-common method I've seen in some instances like that where a title is really wrong is to propose an interim title along with starting the page move discussion, and try to get a SNOW consensus on that while the full discussion is occurring. Nosebagbear (talk) 09:56, 23 April 2020 (UTC)
Moving to my intended section Nosebagbear (talk)
  • Oppose I think giving wider discretion to close early is not a good idea. It's already accepted that in obvious cases (WP:SNOW) early closes can be made. Seven days is a decent time period for a range of contributors. RMs sometimes have a glut of !votes at the start from editors involved in a pre-discussion, who are often in agreement, which is then followed by outsiders who give a different viewpoint. I think allowing early closes risks a form of LOCALCONSENSUS developing and I can see it resulting in excitable (and involved) editors closing discussions because they're currently at 5–0 in support or something. Number 57 12:04, 23 April 2020 (UTC)
  • Oppose per Number57. WP:SNOW and WP:IAR already exist to cover exceptional circumstances, but having three supports and no opposes after five days does not mean it should be moved by default. The seven day period allows all views to be aired, and having the formal "expired" and "backlog" sections at WP:RM also allows closing admins a chance to dissent or relist if they think there's something not quite clear.  — Amakuru (talk) 15:17, 23 April 2020 (UTC)
  • Question in a case where the concern is the original title is not obvious is there anything stopping someone from creating a redirect based on the proposed title? For instance if right after a notable event someone creates an article with an early title The bad example scandal. After a few days some editors feel The controversial example is the better title based on an assumption that it will be more prominent in web searches. While the title is getting discussed is there any harm in setting up a redirect? The controversial example -> The bad example scandal? If the redirect is successful then the redirect could be reversed. Does this basically address the concern with waiting the full 7 days? Springee (talk) 22:08, 23 April 2020 (UTC)
    @Springee: I moved your question to this section since it wasn't about the notice template. To reply, I'm not sure how redirects affect search results, but I think the concern is more often about having titles be conveying the right impression and things like that than about making it easier to find the article. And the concerns about wasted energy, a polluting notice, and a cluttered talk page all still apply. {{u|Sdkb}} talk 22:30, 23 April 2020 (UTC)
  • Nope nope nope. Consensus changes. People are always checking their watchlist every day. I've seen 8-2 votes end up as 9-7... haven't you? Not only that, but it's subject to abuse. Vote is 5-0 after two days, somebody comes along and SNOW closes it because they want to lock down that result. Whether it would have ended up 7-6 after the full seven days we can't know, but I've certainly seen turnarounds like. What's the hurry? Herostratus (talk) 19:24, 24 April 2020 (UTC)

The notice template

I've made this into a proposal at the template page. To keep discussion centralized, please direct future comments there. Thanks! {{u|Sdkb}} talk 00:10, 26 April 2020 (UTC)

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.

Throwing out a question here: Is the notice template added to the top of articles with a RM appropriate, and if so, is it appropriately bold? Let's keep in mind WP:READER — for us, it's a useful "hey, there's a discussion you might want to join", but for the 99% of users who are there to read, not edit, it's a big distracting object that says very little. (Sure, it might be a little informative in some cases, but certainly not enough so to warrant placement more prominent even than the first line of the article.) It's not analogous to proposed deletion notices or {{Current}} notices, which provide an important caution to readers about the reliability of the article they're about to read. It seems more analogous to having an RfC on the talk page, and we don't tag every page with an RfC with a notice saying "hey, this article has an RfC; go to the talk page to participate". So, should we remove it, or if not, at least change its design to be less prominent (more like, for instance, the template merge nomination template, although probably not that tiny)? {{u|Sdkb}} talk 20:38, 22 April 2020 (UTC)

Readers are potential editors and likely have specialized topic knowledge that RM gnomes may not. Unlike RfCs which typically involve esoteric policy implications and often are project internal, RMs affect the primary textual symbol by which readers identify a topic. For this reason, RMs typically hinge on what title readers expect to find the page at (WP:RECOGNIZABILITY and WP:COMMONNAME) and the people best able to help us gauge that are readers searching for the topic. The tag is also useful information for readers as it warns them of a potential change to the article location. Like with AFD tags which warn the article may disappear entirely, RM tags warn readers that in a week they should expect to find the page in a different location. On a practical note: I have seen many IPs on talk pages contributing helpful comments and have never seen an IP on a talk page complaining about the banner. I'd be fine with aesthetic changes to the banner, but would strongly oppose removing it. — Wug·a·po·des​ 07:33, 23 April 2020 (UTC)
@Wugapodes: I went ahead and made a few basic improvement tweaks to the template that should be uncontroversial. I'd like to go further, and you can see a draft in the sandbox here, but I'd like to be able to use the "small" parameter without forcing such a narrow width. Do you know of any way technically to do that? I asked on the module page. {{u|Sdkb}} talk 19:36, 23 April 2020 (UTC)
@Sdkb: Per Wikipedia:High-risk templates#Rationale and Wikipedia:Template editor#When to seek discussion for template changes, you really should not edit automatically substituted templates without explicit consensus for the change. I've partially reverted with this series of edits. To your question, I can't offer much advice since I'm not sure what the end goal is. I would encourage you to wait for more discussion on whether and how we want to change the RM banner aesthetics. — Wug·a·po·des​ 20:07, 23 April 2020 (UTC)
@Wugapodes: I like the changes you made, which now streamline the "please do not move until" part as well. I'm not sure that that caveat line is needed now: it was before since "It has been requested that the title of this page be changed. Please see the relevant discussion" made it possibly seem like the move was wanted but just needed implementation, whereas the current "A request that this page title be changed is under discussion" can't be misinterpreted that way. Moving requires autoconfirmation, and hopefully everyone autoconfirmed will know to at least check the talk page before just doing it. That's why I wrapped it in the small tag, and are proposing getting rid of it in the sandbox version. Does that sound like the right thing to do? And re the technical question on width, the goal is to prevent the template from going onto too many lines for longer titles. {{u|Sdkb}} talk 22:23, 23 April 2020 (UTC)
  • No. No evidence of "harm" has been shown. Discussions don't have to stay open seven days, they can be closed earlier if consensus is clear. "Consensus is clear" correlates strongly with "a good reason". In the absence of a good reason to close early, seven days is preferable because it caters for once a week editors. --SmokeyJoe (talk) 08:16, 23 April 2020 (UTC)
@SmokeyJoe: - can I check whether you did the same thing as me, and meant to put this in the above section? Nosebagbear (talk) 10:35, 23 April 2020 (UTC)
  • Mnmh, guess not. I see the point, but its just a little template... it doesn't impinge that much on the reader's attention, i suppose. There is the downside you noted, but maybe an upside too... it's not broken so I don't see a need to fix it. Herostratus (talk) 19:28, 24 April 2020 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Feedback requested at German rearmament

Need more eyeballs, so hoping this placement is okay. Your feedback would be appreciated at a requested move at Talk:German rearmament. Thanks, Mathglot (talk) 02:00, 8 June 2020 (UTC)

RM's for all primary-topic moves?

The section WP:RM#CM has the following rather unusual text:

use this process before moving any existing page with incoming links to create a disambiguation page at that title

While the rationale is obvious – primary topic changes involving major articles can stir massive controversies, and creating a dab page at a title formerly occupied by a major article entails that a non-trivial clean-up operation will follow up – it's much less obvious why this prohibition on bold moves should apply to cases that don't involve major articles. A fair number of these moves are performed every day, and as anyone who keeps an eye for newly created dab page will probably confirm, these are almost always open-and-shut cases. I think this sentence should simply be removed to match current practice and common sense. Or should we all change our ways now and start filing RMs every time there's a need to move an article about an Iranian village or a Pokemon character? – Uanfala (talk) 01:38, 22 April 2020 (UTC)

Fix the incoming links first, then the issue goes away. Dicklyon (talk) 00:52, 10 June 2020 (UTC)

Redlinked target pages

I noticed that the Elapsed listings section does not show any redlinked target pages, and instead shows all target pages with "redirect=no" regardless of whether they exist or not. Perhaps, this might be because of "too many expensive parser functions", similar to what happens with "#ifexist". GeoffreyT2000 (talk) 04:45, 7 June 2020 (UTC)

Wikipedia:Requested moves/Current discussions populates both Category:Pages with script errors and Category:Pages with too many expensive parser function calls. I'll see if I can fix that. – wbm1058 (talk) 02:48, 10 June 2020 (UTC)
From Show preview – Warning: This page contains too many expensive parser function calls. It should have less than 500 calls, there are now 705 calls. – wbm1058 (talk) 03:21, 10 June 2020 (UTC)
From the bot console report from a recent run, there were 707 pages requested to be moved. Just the single RM at Talk:History of the Jews in Abkhazia#Requested move 5 June 2020 accounts for 293 of them, enough to push over the limit. This accounts for a significant slowdown in the bot's processing time – right now it needs nearly all of its 15-minute window to finish. – wbm1058 (talk) 03:31, 10 June 2020 (UTC)
{{subst:no redirect}} removes the page from both of these MediaWiki-populated tracking categories but doesn't solve the problem as those over the 500 call limit are not correctly substituted. The good news is that I'm already reading these pages as part of the logic for determining where to put notifications of requested moves, so I should easily be able to fix this in the bot's coding.  Working on it. – wbm1058 (talk) 12:33, 10 June 2020 (UTC)
 Fixed by bot v 7.34 – now the expensive parser function count is 229, well within the limit of 500. – wbm1058 (talk) 14:38, 10 June 2020 (UTC)

Requesting speedy closure

Hi, everyone. Where do I request a speedy closure of an out-of-process move request started three days after the previous move request? Surtsicna (talk) 17:01, 21 June 2020 (UTC)

Creating a flowchart

I think we should create a flowchart that describes what needs to be considered before requesting an RM. It would help me and other editors make RMs that are likely to succeed. I would like to know your thoughts on this. Interstellarity (talk) 13:10, 23 June 2020 (UTC)

" indeed, elsewhere on Wikipedia, NACs are not recommended,"

I have no beef with this sentence from Non-admin closure. However, it links to NACPIT which does not provide the expected explanation (or deeper discussion) regarding "elsewhere" on Wikipedia. In fact, I can't see NACPIT discussing the issue at all. Why the link there? CapnZapp (talk) 18:18, 16 June 2020 (UTC)

I deleted it. It's dubious, and anyways irrelevant to NACs on RMs.—Bagumba (talk) 06:51, 24 June 2020 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia_talk:Requested_moves/Archive_32&oldid=1262148786"