Wikipedia talk:Requested moves/Archive 30

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

STALE close

If a RM is made and there is no comment beyond the proposal and creators response within 7 days, would the nomination be considered WP:STALE and could be safely closed by anyone? The C of E God Save the Queen! (talk) 07:56, 28 May 2017 (UTC)

  • I think no comments after 7 days means the request was noncontroversial, and the nominator may close it as unopposed. --SmokeyJoe (talk) 10:26, 28 May 2017 (UTC)
  • I think in this case the closer should first evaluate the argument and it the proposal is consistent with the naming conventions and the relevant guidelines, they can close it as unopposed. If it isn't, they should leave an "oppose" !vote and let someone else decide it. I don't think such cases are any different from other RMs. And I don't know I see the relevance of WP:STALE, which is a guideline about drafts, not discussions. – Uanfala (talk) 10:49, 28 May 2017 (UTC)
  • Best practice is to relist for a week, and try to draw attention to the request in an appropriate forum such as a main article for the topic or a relevant WikiProject talk page. It's especially important to be careful for side topics which don't get many eyes on them regularly: an improper name can linger around for months or years before getting corrected; the move request is a good opportunity to resolve the issue with community input. — JFG talk 15:34, 28 May 2017 (UTC)
  • No comment ones that you know from experience to be in a non-controversial area and are in line with policy and naming conventions should basically be treated like a post at RM/TR. If its in an area that is controversial like anything at all railroad/metro/using trains to get around related (which I will never understand) or transliteration of non-Latin scripts, relisting is best. Same goes for bulk move requests which by their nature aren't going to be uncontroversial. TonyBallioni (talk) 18:26, 28 May 2017 (UTC)
    • I meant where the creator opposed the merge and no-one else comments. Is it appropriate to remove the template after seven days as no consensus similar to AFD? The C of E God Save the Queen! (talk) 07:15, 29 May 2017 (UTC)
      • Generally it would be relisted using {{relisting}}. TonyBallioni (talk) 07:30, 29 May 2017 (UTC)
      • Generally, relisting is pointless. Wikipedia:Publicising discussions offers alternatives. Where someone proposes something, someone else (eg the creator) opposes, and nothing else for seven days, that sounds like a candidate for WP:3O. --SmokeyJoe (talk) 07:34, 29 May 2017 (UTC)
        • You and I pretty strongly disagree on that. From anecdotal evidence relisting does in fact often draw new comments to the conversation pretty quickly after it is done, and is better than letting it sit in the backlog for a few weeks with no more comments. I'd agree that relisting is often overused but the hypothetical described here is the perfect candidate for a relist after a few days sitting in the backlog with no comment. This is not to say that the alternatives can't also be done, but relisting would not neccesairily be bad to do as well. TonyBallioni (talk) 15:30, 29 May 2017 (UTC)

@User:The C of E If an user makes a request with an RM. It is either because the user can not move the page themselves, or because they think it is controversial or potentially controversial. Therefore the nominator ought not to close it but wait for another editor to close if for them.

@JFG and TonyBallioni, I think it is totally unnecessary to relist it, instead it should be closed and unless the closer has reasons for opposing the move for policy reasons, it should be moved. This is after all what the tab at the top is for. Moving a page is not like deleting one. If someone comes along later they can always request a move back or a move to an alternative page title. -- PBS (talk) 12:09, 3 June 2017 (UTC)

I'm with Tony on that: from practical experience, relisting often does result in meaningful commentary which helps evaluate the request properly. I'm against multiple relistings, though, except in cases where consensus looks very hard to evaluate, while a "no consensus" outcome looks sub-optimal. Example: when editors mostly agree that the article should be renamed, but two pretty good move titles are defended and both are valid from a policy standpoint; in that case I would do a relist with a clarification request on choosing one of the two proposed titles, pinging back all participants so far. — JFG talk 12:25, 3 June 2017 (UTC)
  • Out of curiosity... could you link to the RM in question? Perhaps some of us know the topic and could opine on the move request... thus giving you more opinions upon which to actually make a close. Blueboar (talk) 12:46, 3 June 2017 (UTC)

Rename my father's page

My name is Curtis Felt. My late father, Dick Felt, has a wiki page generated by some source, not by me or my family. My father's nick name is being targeted by vandals and I'm getting tired of it. His birth name is Richard George Felt. "Dick" was a nickname given to him when it was common to use for Richard. However, it's use today is more associated with a male body part and as a derogatory slang word. I would like to have his wiki page title changed from Dick Felt to Richard Felt to cut down on search engine hits that would prompt people to vandalize this site. Your site takes great effort to remove uncivil comments from pages, and i appreciate that. Thank you for your consideration. Curtis Felt (talk) 00:41, 19 June 2017 (UTC). Done. --SmokeyJoe (talk) 01:09, 19 June 2017 (UTC)

More undiscussed "technical requests"

Yet again, "technical requests" are used to sneak through an undiscussed and inappropriate rename (Mace (weapon) to Mace (bludgeon)). Maces aren't simple bludgeons, they're substantially somewhat sharp, developed as an armour-piercing weapon. Also this form has clear primacy as the primary topic for "weapon", the pepper spray and missile being references to it.

We need to stop these. At the very least, a rename like this ought to require tagging on the article first, not merely on this page. Andy Dingley (talk) 09:58, 11 May 2017 (UTC)

Yeah, reasonable point. One could patrol the RM/T board and pull any that you don't agree with, I guess. I assume that if you see a technical move you disagree with, it is automatically no longer an undisputed technical move and you could remove it. Probably you'd want to notify the poster so she could file a contested RM.
User:Anthony Appleyard made the move; you could ask him what he was thinking. The move request was made by an anon IP User:65.94.169.56 whose first edit was today; that alone would give me pause. This editor seems to be working on various titling issues, splitting and moving pages etc., and I'm not sure that that's a great idea for a brand-new IP on her first day. Herostratus (talk) 10:43, 11 May 2017 (UTC)
Makes sense User:Anthony Appleyard, although its a 1) kind of involved reasoning by 2) an anon IP, so I dunno if I would have done it. By "involved reasoning" I mean it's not like "article name is misspelled" or slam-dunk stuff like that. OTOH every move that doesn't have to go to contested RM is one less timesink and can be undone. So, judgement call.
User:Andy Dingley is this a regular thing, or just occasional? It it's just occasional that something goes thru that might be contested, I wouldn't worry about it too much. The assumption is that admins' judgement can be trusted generally. It's possible that admins should be advised to be more stringent. Herostratus (talk) 11:36, 11 May 2017 (UTC)
  • This is a regular thing. Labelling a move "technical" as a way to dodge discussion centred on that page and the people most familiar with the subject.
I don't know what the best page name for "mace" is. Maybe it's bludgeon, maybe it's medieval weapon (and is that medieval, mediaeval or mediæval?), maybe it's simply weapon. It's an awkward question, it warrants discussion. There will be other opinions. That is how we are supposed to work. As a "technical" request to move away from an obvious overlap, I can understand why those implementing RM/TR would pass it through. As a subtle naming question, it should never have been filed as "too trivial to even think about".
"Monitor RM/TR" - How? This is a page across the whole of WP. Even if watchlisted, I cannot see the traffic through it. I do however have many pages watchlisted that do end up getting TR moved, which is then the first I see of it. Also, the time issue: filed at 6am, carried out just after 8am, barely two hours. Now that's admirable processing efficiency, but it's also a great way to guarantee no discussion or challenge.
Here's the latest one [1], filed just after Mace was carried out and then also executed about two and a half hours later (so even when I checked RM/TR this morning looking for these, it hadn't been listed then). This is a total car crash. Not even a rename, this is a merge. A bad merge. A merge that absolutely needs to be discussed first. The history of battleships is long, complex and has a substantial and international breakpoint at 1906 and the launch of the first Dreadnought. There is a good reason why those before were named with a back-formation as "pre-dreadnoughts". To merge away this distinction is a big change, very obviously not a mere "technical request", certainly not one to be pushed through with no mention on the pages affected, no time to even see it at RM/TR. Andy Dingley (talk) 16:39, 11 May 2017 (UTC)
Andy Dingley, what's the title that was merged? I can't figure that out, can you? I just see "MERGE" in the edit summary but no attribution for the page merged. wbm1058 (talk) 20:00, 11 May 2017 (UTC)
Oh, I see now. List of pre-dreadnought battleships of the Royal Navy. They should put {{merge}} tags up and discuss. Someday maybe I'll get a merging system up that's more like requested moves. We seem to have two kinds of editors (1) those that want someone else to merge; they put up the template and it may sit there for years before it gets tended to. (2) those who want to merge it themselves; they often just do it without posting notices, or only briefly post the tags for a day or two before they do it. Would be nice to find a happy medium. wbm1058 (talk) 20:09, 11 May 2017 (UTC)
so we have two points of failure here, as this is clearly a request to reverse a previously executed page split. Both the requesting editor and the admin performing the request did not check the logs and find the previous move. These are scenarios that we try to avoid. wbm1058 (talk) 20:25, 11 May 2017 (UTC)
I am the editor that requested the move. I accept fault for not checking for previous merge requests, but I should also like to say that there was a very short time from me posting my request to move List of dreadnought battleships of the Royal Navy to List of battleships of the Royal Navy before Anthony Appleyard (talk · contribs) moved the page. As for not following instructions on Wikipedia:Merge (namely starting a discussion), I had (incorrectly, happily) figured that absolutely no one was watching given that my peer review for List of sunken battleships has gone unnoticed for about two months, so I just filed a request to move and then set to work in the linked Google Document. As for the dour comment about the merge being a "car crash," please note that I did I make an effort to also merge the information from List of pre-dreadnought battleships of the Royal Navy. However, this was limited to one table that didn't get moved to the Google Doc (I figured it was a done deal) because I was currently attending high school. Before this gets more heated, I would like to apologize for my rash action and request a civil discourse. –Vami_IV✠ 21:24, 11 May 2017 (UTC)
It's all right User:Vami_IV. We're just searching for an optimal general procedure, not attacking this one move in particular. You did fine, its alright. One problem is that this page maybe provides insufficient guidance for you and other editors in your position. To that end, I'm suggesting below language that would provide more guidance. Herostratus (talk) 15:15, 12 May 2017 (UTC)

Right. Well, I guess to watch the page, you could just go to WP:RM and click on the technical-moves section. This requires a positive action rather than waiting for a notification, but if an editor made it part of their regular routine, it would only take a few seconds each session to check, and perhaps a couple minutes to move inappropriate requests. This is a kludge though.

For this to work, we would probably have to add an admonition on the order of "admins should not peform technical moves until X hours have elapsed since the request", with X being 24 or 72 or whatever.

Alternatively, perhaps we should tighten up the guidance, adding the bolded language shown below to the top of the "Requesting technical moves" (text bolded to show the change, not intended to be bolded on the actual page):

"If you are unable to complete a technical move, request it below. You should never request a technical move if you consider that the move could be contested on reasonable grounds. Instead, see the procedure below for requesting potentially controversial moves. Administrators are advised to reject requests for technical moves it they suspect that the move could be contested on reasonable grounds

How's that? Herostratus (talk) 15:12, 12 May 2017 (UTC)

I like the way the instructions on the main WP:RM read right now. We can only do so much to inform relatively inexperienced editors of the nuances of our page-moving guidelines. We should expect that a certain number of this kind of request will always come in as new editors join the project, or editors with modest experience begin moving pages for the first time. Where I think we can improve guidance is at Wikipedia:Requested moves/Closing instructions, which has relatively little to say about technical requests. Especially with the expansion in rights to page movers. Page movers and admins should assume good faith, but at the same time check the talk pages and logs, and use better judgement. They should be our line of defense to minimize the number of technical requests that get reverted. Trust that the requester believes their request is not potentially controversial, but, at the same time verify that it is not potentially controversial. wbm1058 (talk) 15:57, 12 May 2017 (UTC)
OK. I don't see why we shouldn't tell requestors "You should never request a technical move if you consider that the move could be contested on reasonable grounds", but fine. So OK Wikipedia:Requested moves/Closing instructions is directed toward closers (which for technical requests is jut admins) rather than requestors. The last sentence of the first paragraph doesn't make sense... it says "Where technical moves are contested, move the listing to the contested technical requests section" but how do you know it's contested? You know if somebody has already moved it to the contested technical requests section, right? (Unless somebody messaged you on your talk page about it or something.) So how about changing this advice to closers:
Where technical moves are contested, move the listing to the contested technical requests section.
to this:
When you encounter a technical move request that seems contestable on reasonable grounds, instead of closing it, do X.
I'm not sure what "do X" is supposed to be... what do admins do when they come across a sketchy technical request:
  • Just remove it, or
  • Move it to "contested technical requests"?
It has to be the former, right? The latter would require you to create a requested-move section on the talk page, right? And what would you say, not being familiar with the subject?
But the former, doesn't that mean the request (which may well be perfectly fine and improvement to the Wikipedia) just goes into the bit bucket? That seems imperfect also.
I mean, right now I see there's a technical request to move Instruction set to "Instruction set architecture" which is a very different thing and a major change to an important article. The request points to a talk page thread which is very long and techical, and is a back-and-forth between two editors, in which the idea of having two separate articles ("Instruction set" and "Instructions set architecture") is mooted but rejected (I guess). They rewrote the lede to say "Instruction set architecture" instead of "Instruction set", but still... is this really a case where its not even worth discussion? Other watchers of the page have no idea that this page is about to be moved... they might be hopping mad if it goes through.
And yet, what am I supposed to do,? Just remove it? Move it to a contested status and open a requested move discussion "I have absolutely no idea about this subject, but please discuss"? Either seems poor. I'm not an admin but rather just a drive-by watcher. Am I allowed/encouraged to just remove technical requests? Herostratus (talk) 08:27, 17 May 2017 (UTC)

When the section technical requests was set up I opposed it. I see no reason why those need to be expedited. I think it was better to have just a requested move process. There is little reason why a change in capitalisation is so important that a move can not wait a week while the RM process runs it course. -- PBS (talk) 09:16, 17 May 2017 (UTC)

The "Noncontroversial proposals" section was added on 6 October 2006 (diff) and here is the link to the discussion on in making this change in the archives -- PBS (talk) 09:59, 17 May 2017 (UTC)

OK well 2006 is 11 years ago, so it is certainly accepted procedure.

And so hmnh I see regarding the above example that User:Anthony Appleyard accepted the technical request and moved "Instruction set" to "Instruction set architecture"... this may be OK on the merits, but... before making the move the editors changed the lede from

"An instruction set [is] blah blabh blah... it defines the valid instructions that a machine may execute".

to

An instruction set architecture... defines everything a machine language programmer needs to know in order to write a machine language program for that computer. It is also referred to as architecture or computer architecture. ... defines [the] the data types... [etc, and] the instruction set".

and the page move locks that in...Which fine, and it may be a big improvement (who knows?), but it is surely more than a spelling correction. If some of the people watching the page don't agree with this change, what are their options? Move it back and initiate a WP:RM discussion? This suggests that WP:BOLD and WP:BRD are indeed operative for page moves, at least for technical requests... which seems to go against the discussions above.

Maybe its supposed to be like WP:CSD, where one person makes the request but an admin reviews it and decides? Does this happen? We need User:Anthony Appleyard or other admins to describe what their mindset is in approaching technical moves... is it, like CSD, "I agree, so it shall be done"? This is quite a bit of rather arbitrary admin decision power over a content question, isn't it? Of course admins are especially vetted, but aren't considered supereditors for content purposes.

The big questions I have are simple and I still don't have, but need, the answers:

  1. If an admin comes across a technical request that they guess might benefit from discussion, what is the usual procedure -- just remove it, or move it to "contested technical requests", or what?
  2. If I, as a non-admin page watcher, see a technical request that I guess might benefit from discussion, what is the usual and/or recommended procedure? 1) delete it, 2) move it to "contested technical requests", or 3) do neither since I'm not an admin and it's not my job... maybe attach a note to the request? Herostratus (talk) 16:42, 17 May 2017 (UTC)
  • And now we've lost Nyloc nut, right against WP:COMMONNAME. Is this right to impose unilateral naming changes some special privilege only granted to the single-digit IP editors? (Who still know to use shibboleth terms like "peacock language"?) Andy Dingley (talk) 17:15, 17 May 2017 (UTC)
  • @Herostratus and Andy Dingley: As regards instruction set and instruction set architecture, I remember programming in machine code way back on an Atlas (computer), when machine code text consisted only of numbers and no letter code words for instructions, when a computer filled a room, and laptop computers and desktop computers were only science-fiction. And on several various computers since. (I still remember that on the Atlas, 117 meant "write a value into a store address".) On Wikipedia I have clicked the "discuss" option on many uncontroversial-formatted move requests which looked queryable. Anthony Appleyard (talk) 20:27, 17 May 2017 (UTC)
Machine code, Jesus. Hats off. Herostratus (talk) 20:49, 17 May 2017 (UTC)

More undiscussed "technical requests" (part 2)

  • Why is it still so important to give hit-and-run IPs a route to secretly rename an article? Other editors are expected to discuss through talk:, and will be reprimanded if they don't. But if you know the RM/TR trick, anything can get moved and there is neither check, discussion nor even visibility. Andy Dingley (talk) 20:51, 17 May 2017 (UTC)
  • There are some IPs who request very plausible technical moves (even some who have a different IP every time) so moves shouldn't be declined just on those grounds. The role of an admin closer is to guess whether a certain move is likely to be questioned, and is a sort of a filter to keep obviously harmless requests from needing to wait patiently for action in the queue of formal move discussions. I would generally look at the article talk before doing a move, to check for any whiff of past controversy, or any past move discussions. If a move asks for a title that is against policy or guidelines, I would simply decline it and (usually) leave a message on the requester's talk. If it's just an arguable case I'd click the 'Discuss' button and let a normal move discussion occur. User:Herostratus, If you personally disagree with a technical move request and are willing to make your opposition known, you could just click the 'Discuss' button yourself and then enter an Oppose vote in the move discussion. EdJohnston (talk) 21:36, 17 May 2017 (UTC)

@Herostratus "OK well 2006 is 11 years ago, so it is certainly accepted procedure." That does not mean it has to be kept. It still has the same problems it had originally had, so what are the advantages of keeping it? -- PBS (talk) 08:11, 18 May 2017 (UTC)

@PBS: I don't understand all the issues here, but I've been using "Uncontroversial technical requests" somewhat extensively for many months (just ask Appleyard!) to help implement the WP:JR change that eliminated commas before Jr. and Sr. It generally takes me about an hour to build a group of 7 that I can't move myself. After the moves, I spend another 15 minutes on post-move copy edits. There are hundreds if not thousands of these left to do, of which perhaps half are "technical". Are you suggesting that I should be required to start an RM for each of these cases? ―Mandruss ☎ 11:25, 18 May 2017 (UTC)
@Mandruss: To facilitate such regular activity, you should get the WP:page mover right. — JFG talk 11:44, 18 May 2017 (UTC)
@JFG: Briefly scanning that page, I'm not sure that would help. It says it would allow me to move without leaving a redirect. I want to leave a redirect, lest I break existing links that have yet to be modified. ―Mandruss ☎ 11:51, 18 May 2017 (UTC)
@Mandruss: The point of moving without a redirect is to first clear the title you want to move to. Typically that title is already occupied by a redirect to the "wrong" title that you want to change, and has a few edits so you can't just roll over it. So you first move "Foo" to "Foo (obsolete)" with no redirect, then you perform your desired move from "Foobar" to "Foo" (with redirect), and finally you mark "Foo (obsolete)" with {{db-g6}} (speedy deletion) for an admin to clean up. More complex scenarios are also feasible, so that you never need admin help to perform any necessary title changes. — JFG talk 11:59, 18 May 2017 (UTC)
@JFG: Yikes! Is there a script or other tool that does all that with one click? If not, I'd want to continue to share the workload with the admin corps (who also should be interested in implementing community consensus). If there were too much complaint about that I'd just let it go and consider that I've done my bit toward this conversion. To date the admin corps has been very helpful; Appleyard has made a couple of inquiries as to how much is left but hasn't complained per se; one other admin said he was happy to help out; no feedback that I'm aware of from any other admin. ―Mandruss ☎ 12:10, 18 May 2017 (UTC)
@Herostratus and EdJohnston: The trouble with automating history-merging is that so many odd cases turn up, and the talk pages and subpages and talk subpages, including archives, of the pages which are to be merged, and any pre-existing deleted edits which are sitting under any of these or under the article, become a minefield. Anthony Appleyard (talk) 18:48, 18 May 2017 (UTC)
@Mandruss: Yes, you can use User:Andy M. Wang/pageswap.js which performs the necessary moves to swap two titles. You'll still have to change the redirect target and the lead sentence. — JFG talk 12:25, 18 May 2017 (UTC)

OK I get it. I moved a couple of technical requests to contested-technical. Process is a little kludgy and underdocumented. Couple questions I have:

  • Is it kosher to to just open the move discussion without commenting? I would think so.
  • I don't get the purpose of or understand the difference between the "Contested technical requests" section and the "Current discussions" section. If it's a contested technical request it's perforce a current discussion (right now Yolka (singer) is in both sections, which seems confusing). Would it be more streamlined to remove the "Contested technical requests", or is there a reason to segregate them? Herostratus (talk) 13:40, 18 May 2017 (UTC)
The 'contested technical requests' section is probably a leftover from past disputes. The disadvantage of using that method is that any comments that people leave tend to disappear, unless explicitly copied into a real move discussion. But it could have an advantage. It may help to get early attention to move proposals from people who have WP:RM/TR watchlisted but might not notice the real move discussion. Any system that increases the number of comments on a move proposal is likely to be a good thing. EdJohnston (talk) 14:04, 18 May 2017 (UTC)
I always copy such comments across, when I change a queried move request into a real move discussion. Anthony Appleyard (talk) 04:59, 19 May 2017 (UTC)
@Herostratus: Yes, you can open the move discussion without voicing an opinion. You just "smell" the move might not be a slam-dunk, so you ask participants to discuss. That's what we should do when patrolling those technical requests. That's what I did for Yolka just today, then I added a comment after looking at the article and noticing the utter lack of sources or wikification.
@EdJohnston: The "contested technical requests" is indeed helpful for RM patrollers, but I think it's always better to push those to a real discussion, because that will be advertised on the article itself, so people who are either reading or editing the topic can immediately chime in. Before 2016, move requests were only visible on the talk page and on the centralized forum, so they had fewer opportunities to meet a pair of eyes. Now, given enough eyeballs, all bugs are shallow. — JFG talk 16:21, 18 May 2017 (UTC)
  • @Mandruss: I would see those as technical requests. They ought to link to whichever MOS argument finally settled the issue. If any particular page has a problem with that conclusion, then they will need to raise it back at that discussion. The difference is that it's an issue which has been discussed, albeit centrally, and it's assumed that all pages will be consistent. Maybe some aren't: maybe someone had a tribute act stage career as "Sammy Davis, Jr." with precisely that punctuation and for that case it matters. But in general, the question was a WP style one, and that's now sorted. The ones I'm complaining of are pure one-offs, where there hasn't been such open discussion. Andy Dingley (talk) 14:47, 19 May 2017 (UTC)

"whichever MOS argument finally settled the issue." There is no consensus for any MOS guideline to dictate article titles that is done through the article title policy and its naming conventions. -- PBS (talk) 14:50, 22 May 2017 (UTC)

What is the advantage of having an expedited section for technical requests? Why not just have one requests section? Those pages that are not contentious will be moved after the usual time it takes from moves to work through the system. It fails safe, unlike the current method of having two streams (one of which is expedited) which as this section attests can fail and cause problems. -- PBS (talk) 14:50, 22 May 2017 (UTC)

@PBS: Sounds like a really good suggestion! People who perform mass moves generally have the "page mover" privilege anyway, so there should be very few "technical" moves that can't be performed immediately and need intervention. — JFG talk 16:49, 24 May 2017 (UTC)
"Silence implies consensus" is there anyone who objects to wrapping the section technical requests and controversial requests back into one section? If so, why? -- PBS (talk) 08:56, 3 June 2017 (UTC)
Anyone have anything to say? If I will remove the section? -- PBS (talk) 20:12, 14 July 2017 (UTC)

Request early close for Trump Tower: A Novel to move to Trump Tower (novel) as non-controversial

Discussion at Talk:Trump_Tower:_A_Novel#Requested_move_20_June_2017

Request early close for Trump Tower: A Novel to ---> Trump Tower (novel).

I've thought about it and it's not really a big deal.

We are now unanimous in support of the move.

I was the only one opposing it, so no longer controversial.

Please can someone move it early, and close the move discussion at Talk:Trump_Tower:_A_Novel#Requested_move_20_June_2017 ?

Thank you ! Sagecandor (talk) 02:33, 21 June 2017 (UTC)

Moving page Speaking Archaeologically

Dear Team Wiki,

My name is Shriya Gautam and I am the founder of an archaeological study group based in India called Speaking Archaeologically. Three days ago, our IT team tried to host our page on Wiki, listing the platforms we are on, and the goals and objectives of the group, as well as the memberships we allow. All this was backed up using citations and references relevant to the content, including e-journal and web-links.

However, our account was banned on the pretext that the username was "too organisation-like." We have now swapped our account but you won't let us paste the content we had used.

Please, get back to us at the earliest so, that the problems can be resolved.


Archaeologysoldier (talk) 10:48, 28 June 2017 (UTC)Shriya Gautam

Your article is currently at Draft:Speaking Archaeologically, and I'm inclined to say that it is sufficiently supported by reliable sources. wbm1058 (talk) 13:15, 28 June 2017 (UTC)

Requesting a page move for a discussion in a section already in progress

There is a page where an RfC to move a very controversial page name has been initiated (ISIL). This needs to be converted into an RM process because the RM process has better instructions on how to close and a much better process for handling the inevitable questions that follow closes of move for this page.

I can remove the RfC header (easy), but how do I add a RM header to the top of an existing section new that there is a new template and process for adding it to the bottom of the page. -- PBS (talk) 20:12, 14 July 2017 (UTC)

RfC: Labeling page mover closures

This guideline may be affected by an RfC opened at Wikipedia talk:Page mover#RfC: Labeling page mover closures. Please comment there. — JFG talk 23:51, 17 July 2017 (UTC)

Requesting closure at Talk:Lysergic acid diethylamide

Hi. I would like to make a request for an editor who did not participate in the move survey to please close the disussion at the above page. Thank you. SparklingPessimist Scream at me! 21:25, 18 August 2017 (UTC)

This RM has been closed. wbm1058 (talk) 16:05, 19 August 2017 (UTC)

Requesting closure at Talk:Uncaged, Vol. 1

Hello. I'd like to request closure on a requested move in the Talk page above. An editor has gone ahead and made the moves uncontroversially. jd22292 (Jalen D. Folf) (talk) 00:32, 14 August 2017 (UTC)

This RM has been closed. wbm1058 (talk) 12:31, 23 August 2017 (UTC)

Moves back to draft space from mainspace

Today there have been several requests at WP:RM/TR by TakuyaMurata‎ to move his drafts to different names or return mainspace pages to draftspace. ErikHaugen and myself declined these requests and did not create procedural RMs: my reasoning is that this seems to be a draftspace dispute, and the return of articles to draft once an experienced editor has published them to mainspace is typically only handled through AfD, and things that are already at MfD should likely be handled there.

I am pinging all the people who have been involved with this as well as some of the regulars at RM/TR for their opinions @Legacypac, Hasteur, Anthony Appleyard, Alex Shih, EdJohnston, RileyBugz, SkyWarrior, and JJMC89: all of your thoughts on how to handle such requests in the future would be appreciated. TonyBallioni (talk) 20:20, 25 August 2017 (UTC)

  • Support Tony's approach including the warning he dropped on Taku's talk page for reverting the declines and a Block if Taku uses RM again. Legacypac (talk) 20:31, 25 August 2017 (UTC)
  • It seems to me that a controversial move should be preceded by some discussion. All I was trying to do was undo the controversial move; it seems a double-standard that one controversial was allowed and the other isn't. This is very bad precedent. -- Taku (talk) 20:36, 25 August 2017 (UTC)
  • I agree with TonyBallioni that such articles, once moved to mainspace, should be contested via the proper channels, viz. PROD, AfD or CSD. Admin discretion to re-draft is of course reserved to handle potentially controversial cases. — JFG talk 20:38, 25 August 2017 (UTC)
    • But that raises the question: what if a draft was moved to a mainspace in the bad faith? How am I supposed to undo it other than making a request here? For now, I have put requested moved at the talk pages of the wrongly-mainspace-d articles. -- Taku (talk) 20:50, 25 August 2017 (UTC)
      • In my view you should nominate the articles for AfD explaining why they are inappropriate for mainspace and request it be draftified in lieu of deletion. When several experienced editors believe these articles should be in mainspace, and it is inappropriate to send them back to draftspace via RM. TonyBallioni (talk) 20:53, 25 August 2017 (UTC)
        • That doesn't seem right since I don't think they need to be deleted so AfD isn't a place for this. I don't think there is any right place for this type of the discussion. I agree that if several editors thought a draft shouldn't be moved be in the mainspace, then the view of the creator of the draft should supersede theirs (since the draft belongs to the whole community). I'm not sure if that's the case here. Anyway, I have requested RM at the talkpages so we can find out what the editors think. -- Taku (talk) 21:01, 25 August 2017 (UTC)
@TakuyaMurata: You do not WP:OWN the articles you have created. Work collaboratively and watch them improve. If you want control over what you publish, Wikipedia is not for you; get a blog. — JFG talk 07:58, 26 August 2017 (UTC)
  • Endorse the rejections of requests as out of order. We've played the game where where TakuyaMurata wants to hold on to a collection of pages they created over 2 years ago for various reasons. We've played the game where TakuyaMurata objects to pages that are well above the mainspace inclusion threshold being placed into mainspace to the point of moving them back to draft namespace and causing improper Cross Namespace redirects (Article namespace should never redirect to Draft or User namespace, but Draft and User namespace can redirect to main namespace to either preserve historical linkages or to funnel volunteer effort to mainspace pages or sections). We've also played the game where TakuyaMurata argues for a delay to let them work on the pages, which rings false when they were informed of the overall conern of the pages in May of 2016 and in June of this year. TakuyaMurata has also argued that the deadline should be 2020 or 2030. This is patently unacceptable and part of the reason why there is an Administrator's Noticeboard thread where I have laid out the case significantly for TakuyaMurata's willful misuse of Draft namespace, Ownership problems, and general failure to hear consensus. For these reasons I note the following:
    1. No editor owns any page on Wikipedia as you irrovacably release content to the community at large
    2. Holding pages back in draft namespace until they are perfect in the eyes of their creator is disruptive to the purpose of wikipedia (WP:5P1)
    3. Pages languishing in Draft namespace to be improved "some day" is disruptive to the purpose of (WP:5P1)
    4. Ownership is an anethema to the concept of collegial editing. Hasteur (talk) 02:19, 26 August 2017 (UTC)
  • Also I object to TakuyaMurata's personal attack on me in what if a draft was moved to a mainspace in the bad faith? of 20:50, 25 August 2017 (UTC). They assume that what I did was in bad faith. I took a look at every one of those pages and asked myself the simple question: Does this have at least a 50% chance of surviving in mainspace? If it does, it gets promoted to mainspace so that other editors can see it and make improvements. If it doesn't I consider the various tools we have for resolving the issue ("Merge and Redirect", MfD, and CSD:G13) and apply the one that provides the best outcome to Wikipedia's purpose). Hasteur (talk) 02:24, 26 August 2017 (UTC)
This is new. Why is Taku objecting to seeing his work in mainspace? If there is something wrong with the page, fix it already! Taku needs to be blocked so the community can clean up these Drafts undisturbed. Legacypac (talk) 04:21, 26 August 2017 (UTC)
  • I think there are two separate questions. 1.) Should these articles remain, or should they be moved back to draft or deleted? (answer: probably not remain) 2.) Is it ok to keep relisting something in the "technical requests" section when someone has objected to it? (answer: No, it is not, please do not do that anymore Taku.) Yes, removing things that someone has seen fit to create (or as in this case move to mainspace) can be a drag. That's how we roll, for better or worse. Thanks, ErikHaugen (talk | contribs) 04:54, 28 August 2017 (UTC)

Page movers implementing a primary topic

A scenario that isn't specifically covered at WP:RMCI. I started a discussion at WT:Page mover#Page movers implementing a primary topic. – wbm1058 (talk) 23:27, 8 September 2017 (UTC)

Catholic Church naming conventions RfC

There is currently an RfC at Wikipedia_talk:Naming_conventions_(Catholic_Church)#RfC:_should_this_page_be_made_a_naming_convention asking if the proposed naming convention for the Catholic Church should be made an official naming convention. All are welcomed to comment. Notifying here because we've been getting a lot of RMs on this recently. TonyBallioni (talk) 21:36, 3 October 2017 (UTC)

Suggested revision to WP:RMNAC

This bit:

All closures of requested moves are subject to being taken to review at WP:Move review (WP:MR), but the mere fact that the closer was not an admin is not sufficient reason to reverse a closure.

conflicts with general NAC treatment (aside from RM in particular); anyone is free to revert a boneheaded NAC. It's not even clear that the wording above is intended to prohibit that, but it is definitely sometimes interpreted that way. The reason to revert a boneheaded NAC is because it was boneheaded, not because it was NA.

Because of the special technicalities involved, this should probably say something like:

All closures of requested moves are subject to being taken to review at WP:Move review (WP:MR). Additionally, anyone may revert an NAC that has not already resulted in a move, given good reasons to do so. The mere fact that the closer was not an admin is not sufficient reason to reverse a closure. If a move has already resulted, the MR process must be used.

The bit that immediately follows that already explains the technical considerations.

This would obviate the need to open tedious MRs for obvious cases of bad closes (e.g. clearly ignoring of the actual consensus, or closing with a statement that makes it unmistakable that the closer is WP:SUPERVOTING to change what the outcome would have been had a neutral party closed it).  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  05:25, 2 October 2017 (UTC)

  • Oppose because while there are RMNACs that are wrong, we actually much more frequently get cases of inexperienced users to the RM process simply undoing a perfectly valid close. Even at AfD, only an admin can reopen the close (see WP:NACD). RM non-admin closers are actually generally much better than the AfD ones in my opinion (though, of course, I am a bit biased in this regard.) Part of this I think is that most of us have the technical ability to implement any close. Others are that it is a lot less "glamorous" than AfD is, so we usually only get somewhat experienced users. TonyBallioni (talk) 05:33, 2 October 2017 (UTC)
    AfD has nothing to do with anything I'm talking about; I'm thinking of RfC NACs, across virtually every topic and internal process on the system. I step into AfD less than 10 times in a year. If it has it's own "NAC subculture" that's well and good, but comparing that subculture to the subculture here is kind of out-of-band; this is about RM NAC subculture compared to the general WP-wide one. Inexperienced users undoing a valid close affects all NACs (even AfD; they just get reverted). If a noob reverts "a perfectly valid close" at RM, then that doesn't qualify as "given good reasons to do so". There can't be a good reason to so if the close was perfectly valid, by definition.  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  10:00, 4 October 2017 (UTC)

Relisting request

I am an interested party and would like to request a relisting of the RM discussion at Talk:Chishmy (urban-type settlement), Chishminsky District, Republic of Bashkortostan. The original RM was closed, then reopened but was not relisted for further input at that time. Thanks. —  AjaxSmack  17:53, 9 October 2017 (UTC)

@AjaxSmack: My bad, sorry. Relisted here now. Alex ShihTalk 18:54, 9 October 2017 (UTC)

Coding for RM

Can someone give an easy example on the page of what coding to use for an RM? The examples are a bit complicated. And on the RM page itself, there is an easy example for uncontroversial coding right on the coding of the page, but not for a "controversial" RM, maybe add it there too? Thanks. Randy Kryn (talk) 14:38, 22 October 2017 (UTC)

i.e. Made a nomination a bit ago, must have got the coding wrong although I can't figure out how, and my reasoning comments weren't picked up by the bot so aren't on the RM page. Randy Kryn (talk) 16:22, 22 October 2017 (UTC)
How is the template documentation unclear? If you just need straightforward examples you can copy-paste to fill in with real data, try these:
Single and multi-page cases
{{subst:Rm|OldPageName|NewPageName|reason=Your rationale here.}}

{{subst:Rm
|current1=OldPageName1
|new1=NewPageName1
|current2=OldPageName2
|new2=NewPageName2
|reason=Your rationale here.}}
}}

Parameter {{{1}}} a.k.a {{para|current1}} is optional as long as the Rm template is used on the talk page of that article.

In each case the Rm template will both create a heading for you and add your sig (unless you use optional parameters that tell it not to). The easiest way to use these is to edit the entire talk page, put the template at the bottom, do "Show preview", copy-paste the auto-generated, dated RM heading name into the "Edit summary" form field, and then save the page.

Hope that helps, and feel free to use this example stuff as part of documentation here or elsewhere.  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  02:59, 23 October 2017 (UTC)
@Randy Kryn: forgot to ping you.  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  03:00, 23 October 2017 (UTC)

Is this page a policy, guideline, information page...?

It doesn't have a template identifying what kind of page it is. Thinker78 (talk) 15:33, 9 November 2017 (UTC)

Not all project pages do. This page acts as a central location to streamline the process for requesting and discussing the renaming of articles. So, I guess you could call it a process page. There's even a template for that, Template:Wikipedia processes, but it isn't widely used. I don't see the necessity of putting it on this page, but I'll wait for other regulars to chime in.--Aervanath (talk) 21:12, 9 November 2017 (UTC)
We did use {{Process header}}....filing in what was needed...but most pages dropped this formate years ago.--Moxy (talk) 23:01, 9 November 2017 (UTC)
@Aervanath:But what level of authority has about what it says that editors should do? Thinker78 (talk) 23:05, 9 November 2017 (UTC)
None. It simply describes the RM process, and is equivalent to WP:AFD. Move can ordinarily be done boldly without the need for advanced permissions, only the ones where it is likely to be controversial need to come to RM. TonyBallioni (talk) 23:08, 9 November 2017 (UTC)
@Thinker78:: As TonyBallioni says, this page is not, itself, a policy or guideline, nor should it really be categorized as an information page. This page was split off from the Village Pump (many years ago, before I started participating), to act as a central clearinghouse for notifying the community of move discussions. Use of the procedures on this page is not mandated by policy, but they are a useful tool to aid the community in standardizing our method of resolving disputes with regard to changes of article titles. However, if there is no dispute, the procedures are not needed.
tl;dr: This page derives its authority from repeated and standardized use by the community, but it is not part of any "level of authority".--Aervanath (talk) 01:12, 11 November 2017 (UTC)
@Aervanath: Be warned, though, that habitual failure to use RM for potentially (or actually) controversial moves – especially of large numbers of article, like imposing one's preferences on an entire category – has been known to lead to WP:ANI threads and even fairly long term move-bans. So, it's not always an entirely optional process, even if theoretically should be. It's not so much that RM has "authority"; more than it's a norm that the community has been known to enforce if things get out of hand.  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  05:46, 11 November 2017 (UTC)
The templates do all the work of listing a page here for you, so there's no good reason not to use this process for possibly-controversial moves. power~enwiki (π, ν) 05:50, 11 November 2017 (UTC)
For what it's worth, use of this page for potentially controversial moves is already mandated by policy, although this page is not policy itself. From the policy page Wikipedia:Article_titles#Considering_changes: "Any potentially controversial proposal to change a title should be advertised at Wikipedia:Requested moves, and consensus reached before any change is made."--Aervanath (talk) 11:17, 11 November 2017 (UTC)
"Should" is a recommendation not a mandate. Many things in policy are not mandates. No one is community/administratively sanctioned for occasional moves that turn out to be and were predictably controversial, only when they do it habitually or on a disruptive scale.  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  18:21, 12 November 2017 (UTC)

WP:RM/TR "Clear all requests" button

Apparently there's a button somewhere that resets WP:RM/TR to an empty state, and in the process reverts the improvement that I did. See where I put it back, and discussion at User_talk:Philg88#Section_header_at_WP:RM.2FTR with the guy who pushed the button but doesn't know how it works. Can someone review this, and find the code and make it better please? Dicklyon (talk) 20:24, 13 November 2017 (UTC)

I think I fixed it. It was just a button that edited an old blank version of the page - I updated it to use your current blank page id instead. You might need to clear your cache to see the results. --SarekOfVulcan (talk) 21:05, 13 November 2017 (UTC)
Thanks! You have great hidden magic. Dicklyon (talk) 06:12, 14 November 2017 (UTC)

I'm not exactly a fan of the section header, Dicklyon. If someone wanted to move an RM from uncontested to contested, they could just use the general "Edit source" button. This new section header isn't needed. SkyWarrior 01:23, 15 November 2017 (UTC)

It's helpful though. "Needed" and "desirable" are not synonymous. It actually verges on "needed", however, because without it, there is no way to edit the two sub-sections at once from the main Wikipedia:Requested_moves page (probably the average editor use case, even if it's not the RM admin typical use case).  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  17:14, 15 November 2017 (UTC)
It's needed when you're at WP:RM. There's no way to get to the transcluded page's edit source button from there. Dicklyon (talk) 21:58, 15 November 2017 (UTC)

Relisting

I'm back from a few months away and I'm wondering what the general opinion was about relisting at RM. My impression (no stats to back it up) is that relisting is becoming increasingly common, especially relisting a specific discussion for a second or even third time. I have always thought that every relist gets diminishing returns and a rough rule of thumb should be to only relist a second time with a very good reason and almost never relist a third time. While it's good to have the backlog area clear, there is generally no harm in having a handful of 'hard' discussions in there – it draws attention not only from potential closers but also people willing to chime in with their opinion and possibly help get the discussion towards a consensus.

Anyway, that's my thoughts. What are yours? Jenks24 (talk) 02:16, 4 November 2017 (UTC)

Same as with any consensus discussion: is there a new rationale (new logic, sources, etc.)? If not, then it's just rehash. An exception is for discussions that failed to come to a consensus, and might come to one later, though even with those it is always best to bring something new to the table.  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  07:49, 4 November 2017 (UTC)
Never mind that; I misunderstood the question as about "listing again", i.e. opening another RM on the heels of a prior one.  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  13:40, 5 November 2017 (UTC)
Per Wikipedia talk:Requested moves/Archive 29#Relisting obscuring a backlog I implemented Wikipedia:Requested moves/Current discussions/Table in May. It tracks how many RMs have been relisted. Currently 23 discussions have been relisted. Their current list dates are highlighted in pink at the bottom of that table. – wbm1058 (talk) 12:10, 4 November 2017 (UTC)
I think relisting once can be very helpful. Twice I prefer only when I think it is likely that extending the discussion will actually bring more voices. If a consensus isn' clear after the initial relist, a no consensus close should be the norm in my view unless there is a reason to think extending the conversation again will do any good. TonyBallioni (talk) 20:07, 5 November 2017 (UTC)
I just typed out a full paragraph, and then realised that TonyBallioni said exactly what I wanted to say in less than half of my word count.--Aervanath (talk) 01:49, 11 November 2017 (UTC)
  • I think relisting is only useful if it is meaningful, and it is only meaningful if the relister makes a meaningful relisting comment. Eg attempting to focus the discussion, or to draw attention of early participants to a later made important point. An explanation of why it is not ready to close. That said, the sortable table removes the downside. It’s not nearly as bad as at CfD, RfD or TfD where relisting removes the discussion from the original page watchlisted by the earlier participants. —SmokeyJoe (talk) 09:02, 26 November 2017 (UTC)

Help with Bold move

Someone moved Mini to Mini (1959-2000), a bold move which overrides a similar request from five years ago. I tried to revert it so that the discussion can take place yet again, but cannot revert it for some reason. I would be thankful for some assistance.  Mr.choppers | ✎  06:09, 26 November 2017 (UTC)

I've reverted it. Pretty epic mess there – took me quite a while to find the actual article as none of the links or redirects went to where it had actually been moved to (Mini (1959–2000)). Number 57 06:27, 26 November 2017 (UTC)
Thanks a lot. The bold mover also apologized nearly immediately which is unusually nice.  Mr.choppers | ✎  17:29, 26 November 2017 (UTC)

How do I change the name of an article?

Can someone help me how I change the name of a specific article? Bryggeriet Vestfyens Arena must be renamed Odense Isstadion. JonasJepsen (talk) 19:00, 29 November 2017 (UTC)

Done. wbm1058 (talk) 04:34, 30 November 2017 (UTC)

Possible information conflict

I performed an edit to reflect what the no consensus policy actually says, but now the information after that edit doesn't correlate very well with the change, because it departs from the previous statement, which was wrong because WP:NOCON didn't say what the statement said -at least it doesn't say that currently. I think then the info after my edit should be reworded or deleted, unless someone knows of a no consensus policy that says that if there is no consensus on a move, an article title that has been stable for a long time is kept, and if you know, please link to said policy and edit accordingly. I have to mention that I'm aware of WP:TITLECHANGES, that says " If an article title has been stable for a long time, and there is no good reason to change it, it should not be changed. Consensus among editors determines if there does exist a good reason to change the title", but doesn't specifically mentions what happens when there is no consensus and the title has been stable. Thinker78 (talk) 18:49, 27 November 2017 (UTC)

Sure it does; "it should not be changed".  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  02:15, 28 November 2017 (UTC)
I'm not sure what you are saying or what the issue is here. WP:THREEOUTCOMES is how we close RMs. If there is a tension between that and the page on consensus, then THREEOUTCOMES would prevail because it is the method that is used by all of the regular RM closers, and our Wikipedia policy is descriptive, not prescriptive. TonyBallioni (talk) 02:19, 28 November 2017 (UTC)
WP:THREEOUTCOMES doesn't specifically say what happens when there is no consensus. Thinker78 (talk) 20:53, 30 November 2017 (UTC)

Is it controversial to revert a controversial unilateral move?

Let's say a user unilaterally moves some article to a new title, without going through RM, even though it is a controversial move (maybe it's a borderline primary topic situation, for example). Does reverting that unilateral controversial move count as a controversial move requiring a week+ long discussion to see whether consensus can be established to support the revert? What about no consensus ever being established for the initial unilateral move?

It seems to me that it should be acceptable to include reverts of contested recent unilateral moves in the "uncontested technical moves" section. That is, even though the revert is also known to be controversial, if it's to revert another controversial move that should have gone through RM in the first place, that should be okay.

Or, if the immediate revert is not done, and neither consensus to keep the move nor to revert the move is established in a subsequent RM proposal to revert the move, then the initial move should be reverted (for not having consensus support).

For example:

  1. Foo is unilaterally moved to Foo (thingy) and Foo (disambiguation) is moved to Foo
  2. A user disagrees with this but is unable to undo the moves for technical reasons.
  3. User files a technical request to revert (since she can't do it).
  4. Technical request to revert the move is not done because the revert is considered controversial despite the initial unilateral move also obviously being controversial; request is moved to regular RM section.
  5. Discussion ensues. Two weeks later, no consensus either way due to lack of consensus about whether Foo thingy is or is not the primary topic.

Questions:

  • Should the moves have been reverted at Step 4?
  • At the "no consensus" closure of the RM discussion, should the original article about the thingy remain at Foo (thingy), or be reverted to Foo (and the dab page moved back to Foo (disambiguation))?

Consider: In any discussion only a tiny fraction of the community is participating. The whole point of defaulting to the status quo when no consensus is found in a given discussion is to err on the side of assuming community consensus supported the status quo. In this case, even though consensus for Foo the thingy being the primary topic by those involved in the discussion could not be found, aren't we supposed to err on the side of the previous established consensus (prior to the unilateral move)? That Foo the thingy was the primary topic per community consensus? By the same token, should that move have been executed in Step 4 as requested? Why or why not?

Actual example from today of a contested technical request to revert a unilateral controversial move [2]. Original unilateral move was reverted nonetheless[3]. (thankfully)

Here's another recent actual example (discussed above) of a revert of a unilateral move: Talk:Mini#Name_of_this_article:_Mini_.281959.E2.80.932000.29_instead_of_Mini

--В²C ☎ 05:19, 30 November 2017 (UTC)

  • Words, and the variety of possible interpretations of the same words.
In your section title, the two "controversial"s have different meanings, depending on how you choose to read it.
What's the real question?
I don't think WP:BRD is meant to apply to page moves. Do not test for non-controversial by doing bold page moves.
If someone has asserted a non-controversial page move, and moves the page, and someone else subsequently disagrees, either person 1 deserves a WP:Trout, or person 2 is a WP:TROLL. Revert the move. Allow person 1 to start a WP:RM. If it is snow approved, person 2 was a WP:TROLL. If the WP:RM is well contested, person 1 gets a {{Trout}}. If after discussion there is a consensus for the move, convert the {{Trout}} to a {{minnow}}. If consensus is found to oppose the move, convert the {{Trout}} to a {{WHALE}}. --SmokeyJoe (talk) 06:27, 30 November 2017 (UTC)
Interesting fish story. I've started an RM on the Ringside move that B2C reverted; I think he fits the Troll description in your model, but we'll see. Dicklyon (talk) 07:00, 30 November 2017 (UTC)
Here's another way that a reverted undiscussed move might get resolved: User talk:Gjs238#Tributary naming. Dicklyon (talk) 07:06, 30 November 2017 (UTC)
Reverting a move is generally disruptive, IMO, as a title, unless obviously wrong for some core policy (WP:V, WP:NPOV, WP:NOR), isn't going to cause any damage to Wikipedia by itself. Move requests in that scenario which close as "no consensus" should probably cause the page move to be reverted, and I think this is how RM discussions generally operate. --Izno (talk) 13:47, 30 November 2017 (UTC)
I'm okay with that except my impression is that RM discussions that result in "no consensus" usually end up leaving the title unchanged - where it was as a result of the contested unilateral move. If "no consensus" decisions in these cases did reliably end up with reverting the original move, then I would not be bringing up this issue. Maybe we could say something to this effect at the Closing Instructions? --В²C ☎ 17:28, 30 November 2017 (UTC)

I updated the Closing Instructions to reflect what we all seem to agree upon above [4]. Any objections? Please edit/adjust as you see fit. --В²C ☎ 17:37, 30 November 2017 (UTC)

I've reverted: there are still only three outcomes. The addition of a reversion no consensus is pointless as the steps for this are already explained elsewhere in the closing instructions. It is not a different outcome: it is the same. The question is how the closer decides to implement that lack of consensus. Adding a 1/2 category does nothing to clarify the situation. If there is a closer who you think is making mistakes on their judgement, talk with them about it, and if you still disagree, take it to a move review. Please don't make the best running closing process on Wikipedia more complex when it isn't needed. TonyBallioni (talk) 17:45, 30 November 2017 (UTC)
Also, pinging some of our other regular closers here @Amakuru, Jenks24, and Cuchullain:and apologies for not helping out more with closings of late. I've been busy with paid editing issues.) TonyBallioni (talk) 17:54, 30 November 2017 (UTC)
Not sure I understand the problem this is meant to resolve. I have seen cases where technical requests were submitted to revert moves that were denied, and where the technical request closer then started an RM back to the previous title. That's not how it should work and it generally confuses people, but that's more an issue on the part of the closer than on the part of the process.--Cúchullain t/c 18:13, 30 November 2017 (UTC)
There are is one main issue and two ways to address it being discussed. The main issue is unilateral controversial moves that cannot be reverted for technical reasons. One way to address them is allow requests for such reverts in the uncontested technical reverts section. Another way to address them is to make a formal RM to revert, and the question is what to do when such discussion results in "no consensus". Now, I did just find this being discussed in the Closing Instructions, but it's buried as the last paragraph of Wikipedia:Requested_moves/Closing_instructions#Determining_consensus. Whether it's added the way I did or some other way, I think it should be more prominent and obvious. As to whether there are three or four outcomes, TonyBallioni, I think it's really two or four. There are two decision outcomes (consensus or no consensus), and each decision outcome may result in one of two move outcomes: moving or not moving. --В²C ☎ 18:22, 30 November 2017 (UTC)
No consensus is an outcome that can have two possible results: maintaining the stable title (through not moving or reversion) or moving to a title that the closer thinks is the least bad because there is a consensus that the current title should go. Reversion is the same as not moving: we go with the stable title.
Re: unilateral moves, list them at WP:RM/TR for consideration. If it has become the stable title, it'll likely become a new RM, and if there is no consensus it will stay put. If it is recent enough not to have been the stable title, an admin should revert it without an RM. The question here is what the stable title was. TonyBallioni (talk) 18:34, 30 November 2017 (UTC)
You're preaching to the choir. What you describe is exactly what I want and expect to happen. The only issue is about where this policy is clearly documented. --В²C ☎ 19:04, 30 November 2017 (UTC)
Its documented in RMCI in "Determining consensus". I've added a bullet point to the main RM page to make it clearer there [5]. TonyBallioni (talk) 19:11, 30 November 2017 (UTC)
I mentioned finding that reference in "Determining consensus" just above, in my 18:22 comment. Are you reading what I'm saying? Thanks for the added bullet point. I'll review now. --В²C ☎ 19:29, 30 November 2017 (UTC)
The wording is great but I think it makes more sense to have it in the Lead rather than in the section about commenting in discussion. I moved it accordingly. [6] [7] --В²C ☎ 19:40, 30 November 2017 (UTC)

Yes, sorry, putting it in the lead is correct. My mistake. I did see it in your above comment, and was just pointing out that we already do have it discussed in RMCI, and I think that document is fine for now. Sorry if it didn't seem that way. Hopefully putting it on the main RM page as information about what current practice is will make this more clear. TonyBallioni (talk) 19:45, 30 November 2017 (UTC)

All good. Thanks. I think this will really help rectify issues quickly when they occur. Hopefully it will also help inhibit some from continuing to engage in disruptive and obviously controversial unilateral moves... --В²C ☎ 20:23, 30 November 2017 (UTC)

In ictu oculi - this is where the discussion and agreement can be found for the change[8] you reverted[9] ("edits to guideline and policy related pages should be discussed and agreed") and I un-reverted[10] ("This edit has been discussed and only restates more visibly what the agreed practice already is"). Thanks. --В²C ☎ 21:22, 30 November 2017 (UTC)

But I rather think you haven't got agreement and are doing as you said you would do with your "get used to it" edit. Let others edit policy pages, why not. Much more enjoyable to work on article space. In ictu oculi (talk) 21:27, 30 November 2017 (UTC)
It's not even my edit, IIO - I just moved a bullet from the discussion comments section to the Lead sub-section because it's more appropriate there (did it separate moves because they're physically separate pages). And the words reflect a view that everyone in this discussion has expressed. Please stop making unilateral page moves. --В²C ☎ 21:49, 30 November 2017 (UTC)

My personal opinion: if someone makes a good faith request to revert a unilateral move from the last say three months (time period a bit arbitrary I admit), then it should be actioned, regardless of what you the admin reviewing it think of it. Then you can notify the editor who has made the initial bold move and they can start a RM from a 'clean' position, i.e. the closing admin does not have to try and work out what is the status quo title in the event of a no consensus close. The only exceptions I can think to this general rule would be BLP issues, articles that have suddenly become very high traffic due to a news event, and titles that are blatantly incorrect (i.e. fails WP:V). It has been a source of frustration for me over the years that some of the people who monitor RM/TR – and generally do a great job at a largely thankless task – approach this issue in a somewhat ad hoc manner, where they will revert moves they personally disagree with but refuse to revert moves they agree with and instead start a RM. If we could have crystal clear process on this I think it would makes things easier for people who use RM/TR from both requester and actioner perspectives. The way I envision it, we will occasionally see reverts to titles that are obviously not going to hold up at RM because they e.g. go clearly against a naming convention. But occasionally having one week at a slightly subpar title is a small price to pay for everyone involved in the process to feel like they are getting natural justice. Jenks24 (talk) 00:57, 1 December 2017 (UTC)

  • Well said. Do you think the edit made to Wikipedia:Requested_moves/Lead today[11] per the above discussion will help us get there? --В²C ☎ 02:15, 1 December 2017 (UTC)
    I also agree with Jenks24, and the addition of the new text makes sense. It is indeed frustrating when RMTR admins start a discussion on a controversial bold move from the new title, rather than reverting it first, and I think we should try to instil the notion in regulars there that unless the long-term title is unclear, the move should always be reverted and a move request started from the previous stable title. Obviously some WP:COMMONSENSE has to apply too - if the move seems really obvious despite being from a long-term title, it would be unhelpful to revert it and let it sit at the clearly "wrong" long-term title for another week. Those cases would be the exception though, and certainly things like Ringside don't fall into that obvious category. Finally, in some cases the person objecting to the bold move is unfamiliar with the convention that we're discussing here, and starts the move request in the opposite direction. In those cases, unless it's spotted very quickly and nobody has participated yet, it's probably best to leave the reverse RM open on the understanding that a no consensus close results in the move going ahead. Thanks  — Amakuru (talk) 09:04, 1 December 2017 (UTC)
    Generally agreed, as long as "if the move seems really obvious despite being from a long-term title, it would be unhelpful to revert it and let it sit at the clearly 'wrong' long-term title for another week" is taken seriously. E.g., I moved a bunch of animal breed articles several years ago to comply with WP:ATDAB policy. Two or three editors manufactured a "controversy" about it, RM admins refused their request to revert all the moves, on the basis that the full RM would probably conclude in favor of the moves, and it did, and two years later the same kinds of moves are still routinely met with consensus (I always list them for full RM despite being routine, because the same parties from back when are apt to continue to claim they're "controversial" – just happened again yesterday even after an RM concluded against their preferred parenthetic disambiguation – and I like building a large precedent pile anyway). I would not like to see that kind of a RM admin common sense second-guessed. More often than not, yes, a revert of a controversial undiscussed move should proceed even if it is itself controversial, on the basis that, site-wide, the default is to revert to status quo ante the dispute, whatever the dispute is (the only categorical exceptions are WP:OFFICE legal matters imposed on top of this, like certain WP:COPYVIO and WP:BLP issues). This is the heart of WP:BRD. But we shouldn't feel forced to do that when doing so is clearly a terrible idea in the exact context in which it's requested. Cf. WP:NOT#BUREAUCRACY.  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  07:04, 2 December 2017 (UTC)
I agree with Jenks et al. If a (recent) move was undiscussed and someone has cause to challenge it, the move should be reverted before an RM is started, regardless of what the RMTR closer thinks of its merits. It gets confusing when RMTR closers start an RM from the undiscussed new title, back to the stable one. I'd support adding some language here to clarify.--Cúchullain t/c 20:54, 2 December 2017 (UTC)

relist mark on WP:RMCD

@Wbm1058: When User:Jenks24 relist request moves with adding Relisted, RMCD bot did not mark these discussion as relist on WP:RMCD. Hhhhhkohhhhh (talk) 11:00, 2 December 2017 (UTC)

Wasn't sure what you were talking about for a minute, but I think you mean that underline in "(Discuss)". I can just start using the relist template if that makes it easier; I can get set in my ways and saw no reason to change before now. Jenks24 (talk) 11:17, 2 December 2017 (UTC)
Yes Hhhhhkohhhhh (talk) 11:23, 2 December 2017 (UTC)

The bot looks for an exact match to --'''''Relisting.''''' to allow for that word to be used in a move rationale without mistaking it for a relisting. The template is a handy way to conform to the specified syntax. I could make the search string less unique, at the risk of finding false-positives. – wbm1058 (talk) 15:47, 2 December 2017 (UTC)

So, how to fix it? Hhhhhkohhhhh (talk) 15:51, 2 December 2017 (UTC)
Make this edit; "relisted" used to be the commonly used term – in June 2016 it was changed to "relisting". As I said, I could make the bot more flexible in recognizing different relist forms, but the current setup ensures consistency in usage. Making the bot recognize which items were relisted and which were not was needed to implement the table format which lists them in order of original submission, per request from editors concerned that relisting obscured the long-running requests. There's been an ongoing debate over the usefulness of relists. wbm1058 (talk) 16:25, 2 December 2017 (UTC)
OK, I'm working on some quick fixes to allow some minor variants, such as either "relisting" or "relisted". wbm1058 (talk) 16:56, 2 December 2017 (UTC)
In this request, Paine Ellsworth used "relisted". After I tweaked the bot to recognize either "relisting" or "relisted", it picked that one up. I see that an option for custom text was added to the template in November 2013 by Steel1943. I'm going to tweak the template to only allow two options, unless there are any more options anyone prefers to use, in which case I can consider supporting other options. wbm1058 (talk) 17:24, 2 December 2017 (UTC)
Not sure there's a need to change anything, wbm1058. The bot picked up my "relisted" when I made it, since I used Steel1943's parameter (I happen to prefer "relisted" over "relisting", a soft, weak -ing verb). And I can remember using that parameter to make a comment about the discussion now and then. Jenks24 could use that param pretty easily, also, don't you think?  Paine Ellsworth  put'r there  17:46, 2 December 2017 (UTC)
No, Paine, the bot didn't recognize that as a re-list until I just tweaked it. Note the subtle change in this diff. More noticeable and significant is this diff which lowered its position in the table. I've updated Template:Relisting and its documentation. – wbm1058 (talk) 18:29, 2 December 2017 (UTC)
Ah, I see the subtle differences now. So glad you're staying up with it, and thanks to Hhhhhkohhhhh for the initial heads up! Happy Hollidays!  Paine Ellsworth  put'r there  19:04, 2 December 2017 (UTC)
Already done. It wasn't a big deal at the time; it only became a problem when we wanted to distinguish between original listing and relisting dates. The bot needs specific keyword(s) to look for, though a more artificially human-intelligent bot could do better at making the distinction. wbm1058 (talk) 20:05, 2 December 2017 (UTC)

I'm taking the rest of the weekend off. I might make further tweaks Monday to allow for simple italic relistings rather than require boldfaced italic. wbm1058 (talk) 20:13, 2 December 2017 (UTC)

You mean we can do that? take time off? Hey I've got some planning to do!
I've placed a cautionary note in the template documentation about the bot application. Happy Holidays to all!  Paine Ellsworth  put'r there  20:53, 2 December 2017 (UTC)
Thanks, But I just looked bot source, if someone not added -- on the relist discussions, the bot will not mark these discussion as relist on WP:RMCD Hhhhhkohhhhh (talk) 01:36, 3 December 2017 (UTC)
To editor Hhhhhkohhhhh: I just checked the first four relistings on that page and they've all been marked as relisted. The two hyphens, --, are added automatically by the {{Relisting}} template directly following the <small> tag:
<small>--'''''{{<includeonly>subst:</includeonly>#ifeq:{{{1|+}}}|{{{1|-}}}|Relisted.|Relisting.}}''''' ~~<includeonly></includeonly>~~</small><noinclude> {{documentation}} </noinclude>
 Paine Ellsworth  put'r there  08:06, 3 December 2017 (UTC)
@Paine Ellsworth and Wbm1058: Yes, I saw it. But someone relisted on Talk:Twitch.tv and on Talk:2015 Thalys train attack and on Talk:Ball Diamond and on Wikipedia talk:Facto Post mailing list and the bot still not mark these discussion as "(Discuss)". Hhhhhkohhhhh (talk) 09:23, 3 December 2017 (UTC)

Fixing dab links

Should it be incumbent on the closer of a requested move discussion to fix any dablinks that may arise from their close? E.g. when the consensus is to move Example to Example (example) and Example (disambiguation) to the recently vacated Example, creating a lot of dablinks to fix. My thinking has always been (as both a closer and nominator) that it is the responsibility of those supporting the RM, especially whoever proposed it, to fix the dab links rather than the person who happens to read the discussion and assess the consensus. If the closer wants to help out, great – but it should not be part of what is required. Closing a requested move discussion is already a more time and labour expensive exercise than closing any other consensus-finding process on Wikipedia that I can think of, and insisting that the closer fix in some cases hundreds of dablinks on top of what they've already done seems a severe disincentive to closing discussions.

For the discussion that prompted me to start this topic see Talk:Bark (botany)#Requested move 27 November 2017. Pinging Narky Blert who I disagreed with there and also R'n'B who recently reverted an edit I made to change a redirect to point to a dab as a result of an RM close (see Family Channel) – I take it they will have a different opinion to me. Jenks24 (talk) 09:49, 7 December 2017 (UTC)

It's too early in the day for me to make a reasoned contribution. For now, I'll just say that I believe the relevant guideline to be WP:FIXDABLINKS; and that I have notified the project Wikipedia:Disambiguation pages with links of this discussion, see Wikipedia talk:Disambiguation pages with links#Fixing DAB links. Narky Blert (talk) 10:43, 7 December 2017 (UTC)
The page move is just one step of a wider process of renaming the article. Moving the page whilst leaving wikilinks pointing at the wrong target is usually worse than not doing the move. WP:FIXDABLINKS doesn't clearly pin the responsibilty to any one individual but I also feel that it's the responsibility of the RM's supporters. I can't blame the closer here, as they're just helping the proposer to achieve their aim, by providing a neutral opinion and perhaps by using admin tools not available to the proposer. Perhaps the RM close boilerplate should include a polite reminder that incoming links need to be fixed and even a helpful WhatLinksHere wikilink. Certes (talk) 11:47, 7 December 2017 (UTC)
As an addendum to Certes' suggestion, perhaps the closer could {{ping}} the support voters in the closure notice, or post a standard message on their talk pages. They are likely to know the topic; and some fixes can be tricky, or need a fair bit of reading-up. Narky Blert (talk) 18:58, 7 December 2017 (UTC)
That's a good suggestion. I have occasionally pinged editors in the past to fix up dablinks, but I've never made a practice of doing it. Jenks24 (talk) 07:06, 8 December 2017 (UTC)
  • Closers of RM discussions are generally expected to be more tech/WP-savvy than the average participant in the RM discussion. This means that they should fix the things that do require such savvy: ensuring incoming redirects are pointed correctly (but not fixing any double redirects) and fixing links in navigational aids: navboxes, dab pages and hatnotes (the closer should suss out which articles are likely to have hatnotes linking to the moved page). I don't think closers should be expected to do any more than that though. And I don't imagine a reasonable way of enforcing the requirement of fixing dablinks onto any one party in this process. Yes, dablinks are an inconvenience for readers, but there's nothing "broken" about them, fixing them is not a high-priority task. Given how successful the DPL project has been so far, they're soon going to run out of dablinks to fix: so we do have quite some spare capacity in this respect. – Uanfala (talk) 15:06, 7 December 2017 (UTC)
Is there an archive of recently closed RM discussions? That would allow another level of review, and allow some users to specialize in this area (fixing incoming links, that is). Bradv 15:15, 7 December 2017 (UTC)
I am in agreement with Uanfala about what a closer is expected to do. Brad, there is no proper archive unfortunately. I watchlist Wikipedia:Requested moves/Article alerts which is a decent substitute. Jenks24 (talk) 07:06, 8 December 2017 (UTC)
  • I tend to agree with Certes; it's not the closing admin's responsibility to fix the incoming links, but it would be a good practice for them to postpone the move until the proposer(s) of the move have cleaned up the links. It's not just WP:FIXDABLINKS that exhorts them to do this; also, Mediawiki:Movepage-moved, the page that appears after you have completed a move, asks that the mover fix incoming links to disambiguation pages. An admin who is using their tools to perform a move would certainly be acting appropriately if they asked the proposer(s) to confirm that this step has been taken before completing the task. --R'n'B (call me Russ) 20:30, 7 December 2017 (UTC)
I agree with R'n'B. Any editor who makes an action which breaks 100+ or 1000+ links (or even 1 link) should not just walk away.
(As an aside, I recently turned a redirect into a DAB page, fixing the 60-odd incoming links first. It was unusual in that every single one of the links to that redirect was wrong in one way or another.) Narky Blert (talk) 00:09, 8 December 2017 (UTC)
  • (Rubs sleep out of eyes.) Voting.
WP:DABLINKS currently reads, "Before moving an article to a qualified name (in order to create a disambiguation page at the base name, to move an existing disambiguation page to that name, or to redirect that name to a disambiguation page), click on What links here to find all of the incoming links and repair them."
I would prefer: "Before moving an article to a qualified name (in order to create a disambiguation page at the base name, to move an existing disambiguation page to that name, or to redirect that name to a disambiguation page), make sure that all incoming links have been repaired. They can be found at "What links here" on the article.
That formula does put an extra load on page-moving admins; who, like all admins, are over-worked. But, it doesn't require that they themselves do the clean-up before the move.
"What links here" updates at once; but it is often cluttered with Talk:, User: and Wikipedia: links, which rarely need fixing. The cleanest way I know of to locate bad links to a specific DAB page is this tool. Narky Blert (talk) 01:04, 8 December 2017 (UTC)
If the moves are "Foo → Foo (qualifier); Foo (disambiguation) → Foo" then another option is to run WP:DisamAssist on Foo (disambiguation) and "Disambiguate links to primary topic" before the move. That's also a good way to find links I forgot to put in the dab page. Certes (talk) 01:29, 8 December 2017 (UTC)
When I follow the installation instructions at WP:DisamAssist, I get a message that there's an error so maybe I don't really want to save. What's up with that? Dicklyon (talk) 03:55, 8 December 2017 (UTC)
@Dicklyon: Temporary error due to the subst stuff. Can just use something like this directly in common.js:
// Cleanup links to disambiguation pages (run it at the DAB page in question)
importScript('User:Qwertyytrewqqwerty/DisamAssist.js'); // Backlink: [[User:Qwertyytrewqqwerty/DisamAssist.js]]
 — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  09:32, 8 December 2017 (UTC)
  • How does one fix hundreds of links prior to the move without using AWB? As a concrete example, see Talk:Ryan Newman (disambiguation) which looks likely to be closed as moved. I am the nominator there and will clean up the links using dab solver once it's been moved, but I have no way of doing so beforehand except manually which doesn't seem practical for what looks to several hundred links (hard to know exactly due to navboxes). Even the link provided by Narky Blert only seems to list links to a dab page, not prior to a move taking place. And even if this was a straightforward matter, I wouldn't really want to go to the effort of fixing the links before it has been closed as moved – you never know how a RM will play out. Is it really a disaster if they are fixed within 24-48 hours? Jenks24 (talk) 07:06, 8 December 2017 (UTC)
DisamAssist could work there. I just ran it on Ryan Newman (disambiguation) to fix links to Ryan Newman. I diverted one link to the actress and one to a baseball player (redlink); the rest are (or could very plausibly be) for the driver. (More evidence for a primary topic?) Fortunately, the dab page format already assumes that the page move has happened, so I could have changed the links with just 1,000 clicks. Exceptionally, I'd say it's almost safe to get a bot onto the job this time. Certes (talk) 11:44, 8 December 2017 (UTC)
I have been naughty on occasion and created a dab first, then fixed the links. But that was for backwater pages with a dozen links which I cleaned up within a few minutes. I certainly wouldn't object to people doing that, though if it will take as long as 48 hours then some indication that it's happening would be useful. Certes (talk) 11:46, 8 December 2017 (UTC)

Rapid renominations

What do we do when a move request is closed after discussion, and then an identical proposal is made within a short period of time? Should they be speedily closed? If not, should participants in the previous recent discussion be notified (as an exception to canvassing)? Should the previous discussion be taken into account by the closer? I've run into this situation twice recently, at Talk:Thomas M. Davis and currently and more importantly at Talk:Richard B. Spencer. - Station1 (talk) 17:09, 8 December 2017 (UTC)

If the move request is identical to the previous request, Move review exists and should be used. If the request is different, there is no reason it can't be proposed, and it should be allowed to continue unless it is disruptive. Remember that consensus can change, sometimes rapidly. Bradv 18:44, 8 December 2017 (UTC)
Right, but what do we do when Move Review is ignored? In the case of Talk:Thomas M. Davis, Move Review was not used and the same editor who proposed the first move proposed an identical move a couple of weeks after the close. In the case of Talk:Richard B. Spencer the close did go to Move Review and was upheld, but a different editor (who participated in the first discussion) then proposed an identical move about 6 weeks later (after 2 intervening proposals that were different). In these cases, where the request is not different, do we (a) allow discussion to proceed as usual, ignoring previous discussions and/or move reviews, (b) speedily close, (c) notify previous participants, (d) allow discussion to proceed but take into account comments in the previous recent discussion, or (e) other? Station1 (talk) 07:12, 9 December 2017 (UTC)
Move review is usually for when the discussion is closed against consensus. In the case of the first RM, all the !votes opposed the move, so the close was fairly clear. For some reason, in the intervening 6 weeks, the next RM had almost all support !votes, so the close there is fairly obvious too. Move review would not overturn either of these results based on the discussion. In many cases it comes down to the strength of the nomination statement, and the strength of the arguments made within the discussion. These can, and should, result in a different outcome. Bradv 15:17, 9 December 2017 (UTC)

Uncontroversial technical requests of previously contested moves

RE https://en.wikipedia.org/w/index.php?oldid=815317718

Tom Wolf (politician) (currently a redirect to Tom Wolf) → Tom Wolf (move · discuss) – Tom Wolf, which is simpler and easier to link to, already redirects to the article's current title, Tom Wolf (politician). Page would have to moved over a redirect. Scanlan (talk) 03:58, 14 December 2017 (UTC)

performed by TonyBallioni (talk · contribs)

04:00, 14 December 2017 (diff | hist) . . (+39)‎ . . N Tom Wolf (politician) ‎ (TonyBallioni moved page Tom Wolf (politician) to Tom Wolf: Requested by Scanlan at WP:RM/TR: Tom Wolf, which is simpler and easier to link to, already redirects to the article's current title, Tom Wolf (polit...)

I would think that if an RM was previously proposed and was unsuccessful, that it should be ineligible for listing as an Uncontroversial technical request. While in this case, I would not contest the move again (previously, he was a mere candidate), I think in principle quiet (Talk:Tom Wolf is very quiet) uncontroversial technical requests should not be entertained when the previous RM was unsuccessful. It is damaging to community respect for RM procedures. --SmokeyJoe (talk) 06:58, 14 December 2017 (UTC)

Generally speaking, I agree with the principle that an article with a previous RM should be considered "potentially controversial". However, this particular RM was over 3 years ago; I think that at some point it is reasonable to think it may no longer be controversial.
Like any moves made as a technical request, though, it should be reverted immediately if anyone objects.--Aervanath (talk) 11:16, 14 December 2017 (UTC)
I prefer to say: If anyone objects, it shouldn’t have been requested. The other thing I find odd is that no post is made to the talk page. I think there should be a talk last post at the time of the request. —SmokeyJoe (talk) 13:56, 14 December 2017 (UTC)
I also generally agree in principle, but in this case, the RM was to move Thomas W. Wolf to Tom Wolf, which was closed as no consensus in March 2014 with the caveat "This should not preclude moving the page to another suitable title, such as Tom Wolf (politician), if such a move has consensus." In May 2014, an apparently uninvolved editor moved the article to Tom Wolf (politician). That move was the questionable move that should have been reverted if there was no consensus, even though done in good faith, but apparently no one objected. The recent move was simply to reverse a redirect, which is normally considered uncontroversial, so I think proper under the circumstances. (I'm assuming, of course, that the Tom Wolf redirect was not just recently re-pointed to Tom Wolf (politician) to game the system.) Station1 (talk) 07:43, 15 December 2017 (UTC)
Seems like a lot of a verification work, and a WP:AGF issue. Are all the RM admins willing to go dig around in talk pages before honoring RM/TR requests? And how effective would that be, given that bot notification on talk pages of articles subjected to multi-page RMs is a relatively new feature? If you go back all that far, there'll be many cases of prior failures to come to consensus that one would not detect. Another issue is that many failed RMs from 2014 or whatever later become uncontroversial after a later series of RMs of similar titles. The AGF issue is RM/TR works on the basis that we assume the requests are legit; we don't force verification of it. Frequent use of the revert-undiscussed-moves section is reversing previous RM/TRs that were in fact controversial, so we already have a perfectly fine process for dealing with it. If for some reason some INVOLVED admin refused to honor a valid TR reversal request, we have other remedies like MR and AN, but this situation doesn't ever seem to arise. So, I see the "solution" but I don't see that it addresses to an actual problem, even if it were universally correct that "an RM [that] was previously proposed and was unsuccessful ... should be ineligible for listing as an Uncontroversial technical request". Anyway, lots of things "should be" on Wikipedia that we don't enforce to make them so, per NOT:BUREAUCRACY and the like.  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  03:42, 16 December 2017 (UTC)
  • I'm not sure if I was pinged or if it didn't go through, but since I did the move in question (and most people here can't see the edit history), I'll explain: at the time of the last RM, the Tom Wolf was a redirect to Thomas Wolf, a disambiguation page. In 2015 it was changed to a redirect to the governor of Pennsylvania. It remained stable as such for two years. Our typical rule is that redirects of the primary topic should not redirect to a disambiguated topic. Since it had been stable for over two years, I assumed it was non-controversial, and went ahead and executed the move. If someone wants it revert, I would be happy to do so and restore the previous history at that title. I typically agree that if a previous RM has failed, it is best to go again, but given that this was already the de facto primary topic for more than two years, I went ahead and moved it again in line with our typical style guidelines. TonyBallioni (talk) 00:10, 18 December 2017 (UTC)
    • Thanks Tony. I guess, what I want to do, is leave feedback that I wish that there would be some post on the article talk page, when that page is old, it has had a failed RM proposal before, and something thinks it can now be moved non-controversially. Talk:Tom Wolf displays a RM that failed to find consensus to move to its current title. Finding it now moved with no explanation on the talk page is usually a sign of an out-of-process bold move. The deletion log entry ("04:00, 14 December 2017 TonyBallioni (talk | contribs) deleted page Tom Wolf (G6: Deleted to make way for move)") is not much of an explanation. --SmokeyJoe (talk) 00:32, 18 December 2017 (UTC)
      • Yes, good point. Something that skipped my mind at the time: for what it is worth, when G6ing from the move menu, there is no choice in the deletion summary. My typical assumption is that the explanation in the move log by the requester is enough, and this one mentioned that the redirect already existed. If this comes up again and I move, I'll definitely drop a note, but typically we just send these back to a new RM. This one was just weird because of the history of that redirect. TonyBallioni (talk) 00:41, 18 December 2017 (UTC)

Next steps

So the move discussion that I initiated at Talk:Arden railway station, Melbourne was closed as no consensus. I want to make it perfectly clear from the outset that I have no issue with Bradv or his close, so by my understanding move review is not an appropriate forum. However, I think it's important in this situation where the name of the entity in question has actually changed (both officially and in RS) that we at least get a consensus on the issue for the good of Wikipedia, even if that consensus is not to move.

What is the next step to take here? FWIW, if I renominated for a move I'd make the nomination for Arden railway station, Melbourne to North Melbourne railway station (Arden), since in the weeks since the original nom the press and official sources have adopted this disambiguator. Or is the best step a more widely publicised RFC with multiple options? Triptothecottage (talk) 22:48, 17 December 2017 (UTC)

Actually, the next step is to do nothing... at least for a few months. A “no consensus” defaults to keeping the old title ... and it would be considered disruptive to raise the question again until a reasonable amount of time has passed. While you wait... create a list of reliable independent sources that use the new name (when you do raise the question again, a solid list of sources will help demonstrate that the new name is commonly accepted). Blueboar (talk) 00:01, 18 December 2017 (UTC)
@Blueboar: Thanks for the helpful response. Last thing I want is to be (or be accused of being) disruptive. Triptothecottage (talk) 04:33, 18 December 2017 (UTC)

Discuss

Hi, Random question - Is there any reason as to why the underline in "Discuss" is under the "scu"? .... It looks odd ?, Thanks, –Davey2010 Merry Xmas / Happy New Year 23:00, 24 December 2017 (UTC)

It's a subtle indicator that the bot has recognized that the discussion was relisted. I didn't underline the whole word because that would conflict with the behavior when you hover your pointer over the link... that extends the underline to the full word. If there is a preferred way to make this indication, such as a superscripted r I could make that change. Or I suppose I could remove the indication from the main "currrent discussions" list and just keep it in the table. – wbm1058 (talk) 14:10, 25 December 2017 (UTC)
It's a useful indication for those who know about it, and it's a curiosity to those who don't know about it. I just added a quick blip about it in the relisting section.  Paine Ellsworth  put'r there  18:21, 27 December 2017 (UTC)

Link doesn't work?

The link for "Uncontroversial technical requests" doesn't seem to work. I want to move the article 'Moto Gymkhana' to 'Motogymkhana' as that is the official name of the sport. X10 (talk) 10:44, 30 December 2017 (UTC)

I'm not sure which article you want to move. Moto Gymkhana is a red link. Gymkhana is an Indian term which originally referred to a place of assembly. Gymkhana (motorsport) is an event also known as "car rodeo"; see also Motorkhana. THIS LINK should take you to the page for submitting "uncontroversial technical requests". You edit that subpage. I can't tell which link you're referring to that "doesn't work"; everything looks fine to me. Hope this helps. – wbm1058 (talk) 17:25, 30 December 2017 (UTC)

Proposal at MediaWiki talk:Movepagetext#Proposal to add reference to Wikipedia:Requested moves

Note: I have made a proposal to add a reference to Wikipedia:Requested moves to the page move dialogue, at MediaWiki talk:Movepagetext#Proposal to add reference to Wikipedia:Requested moves. Please feel free to weigh in there. Cheers! bd2412 T 19:01, 1 January 2018 (UTC)

Reversal of undiscussed category moves

I'm thinking those should be permissible here, in WP:RM/TR, rather than being sent to CfD (there is no WP:CFDS criterion for reversing undiscussed category renames, so they'll always end up being lengthy discussions when they should simply be reversible as out-of-process. Given the formality of WP:CFD, where even "speedy" renames take a week, there basically is no condition under which going around renaming categories on a whim is okay, even if you're capable of cleaning up after it. If something is, say, a foul-mouthed attack category, that's just a speedy deletion candidate, not a speedy renaming one. It basically just should not be happening.  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  12:32, 6 January 2018 (UTC)

Then shouldn't a speedy rename criteria for reverting undiscussed moves be there? Not exactly sure how RM/TR can handle those sort of requests.. Galobtter (pingó mió) 12:59, 6 January 2018 (UTC)

Requesting to move Algeria-Turkey relations to Algeria–Turkey relations

I think I want to request to move this page into this, however there are some problems. Just hard to get in though. How to do it and how to move? Sincerely (User talk:ZaDoraemonzu7) 20:25, 16 January 2018 (UTC+8)

Algeria–Turkey relations was merged and redirected to Foreign relations of Algeria#Turkey on 18 October 2017.
A WP:content fork was started at Algeria-Turkey relations on 16 January 2018.
I'll perform a history-merge. – wbm1058 (talk) 13:26, 16 January 2018 (UTC)  Done wbm1058 (talk) 13:51, 16 January 2018 (UTC)

Merging move requests

We currently have a group of 5 RM discussions that all have the same set of comments because they're all on the same issue. Is there a process that allows merging them into a multi-RM discussion, or do I need to repeat myself on every one?

And judging by the names, I'd guess a bunch more where these came from. Dicklyon (talk) 01:06, 20 January 2018 (UTC)

I pinged the 5 involved and told them I'm starting a new multi-RM, which I have now done; hopefully none of them object and we can just delete the old 5. Dicklyon (talk) 03:31, 20 January 2018 (UTC)

@Dicklyon: Yeah, I was going to point you to Template:Requested move#Multiple related move requests, which is probably how I would have done it to begin with. Just "delist" the old ones IMO, fix the article-space RM template, and note how the users commented on the old ones in the context of the multi-RM. --Izno (talk) 03:34, 20 January 2018 (UTC)

National records in Olympic weightlifting

I think per WP:LISTNAME, articles in Category:National records in Olympic weightlifting should be moved. Example: "Albanian records in Olympic weightlifting" → "List of Albanian records in Olympic weightlifting". Anybody up for it? --Pelmeen10 (talk) 18:30, 19 January 2018 (UTC)

I think the current naming scheme is pretty clear, since it's unlikely anyone will be expecting a non-list article at those titles. However, if you would like to move them, I doubt anyone will object. Be bold and move a few; if anyone objects, discuss it. If no one objects, you can do the rest.--Aervanath (talk) 21:35, 21 January 2018 (UTC)
Yea, I know. It's quite time-consuming. Category:National records in track cycling also has the same problem. Maybe I do it in the near future. --Pelmeen10 (talk) 22:55, 22 January 2018 (UTC)
What would be the benefit of doing that? Only 8 out of 84 pages in the category use the "List of..." format (of which 3 were moved to the title), so there seems to be a de facto consensus for the current names. Station1 (talk) 00:21, 23 January 2018 (UTC)
Actually, the other national records (swimming/athletics etc, see the rest of the records here) were later moved for the same reason. --Pelmeen10 (talk) 18:16, 23 January 2018 (UTC)
In that case, I agree with Aervanath's comment. Station1 (talk) 00:59, 24 January 2018 (UTC)

Requesting a technical move when a "discussion" is already open?

See this. I really shouldn't have opened the RM in the first place, since if I did a thorough check I would have noticed that the only reason I couldn't perform the move myself was that the page was moved by another editor a few months back. When I did I pinged the editor who had moved the page, and they supported my proposed title, but the following day a non-admin relisted it because it was "just starting to be seen by others" (even though the only outside comment had been specifically invited and was a support); it seems extremely unlikely that anyone will oppose even now that it has been relisted, but now I'm worried that another non-admin will come along and close it as "no consensus to move to proposed title" -- it seems outlandish, but so did a non-admin relisting an unopposed technical request to allow for more discussion. Hijiri 88 (聖やや) 22:09, 25 January 2018 (UTC)

I would have asked the non-admin to remove the relist. Then they or someone else could close it appropriately. I've moved the article in question. — JJMC89 (T·C) 04:54, 26 January 2018 (UTC)

This process is botched

The RM process is botched. Only a few editors bother to go onto article talk pages; that means that only a few users contribute to RM discussions. Let XFD handle move discussions; that part of Wikipedia actually has !votes involving more than 3 users. KMF (talk) 01:37, 23 January 2018 (UTC)

They need to be separate because deletion issues are usually a higher priority than move issues. That is, whether an article should continue to exist is more critical than what it should be titled. We don't want to mix the two. That said, we could make the RM process more like the XFD process, by having discussions in a centralized location rather than at each article talk page. Of course, the main reason to not have XFD discussions on article talk pages does not apply to move discussions: discussions would be lost upon deletion; that's not the case for RMs, of course. But you're saying we're likely to get more participation if we had RM discussions elsewhere? Maybe you're right. What's the typical daily XFD count vs RM count? --В²C ☎ 02:07, 23 January 2018 (UTC)
My impression is that RM discussions tend to disproportionately attract input from a small number of RM regulars. I guess this works well for cases involving consistency with the more general naming conventions. I don't think this normally works so well when the underlying issue is a content question. Enlisting more participation will definitely be helpful in the latter case. I'm not sure if changing the location of these discussions is going to make a difference; unless there are dedicated topical log pages where discussions will get transcluded? but that's sort of redundant to what the article alerts do anyway. I think one possible course of action is to try to involve individual editors in specific cases, for example by sending talk page messages to the major contributors of the article or to participants in related previous discussions. – Uanfala (talk) 02:24, 23 January 2018 (UTC)
Typically not the case, actually. Yes, there are a handful of people who do comment on most things, and a handful of us who close, but that is the same as XfD. In most project areas that are at all active, you will get comments from people who are involved in the content area. Having a mix of RM regulars with no particular feelings about the content area along with content specialists is one of the things that makes the RM process work very well. TonyBallioni (talk) 02:33, 23 January 2018 (UTC)
Yeah, it works so well that I avoid it whenever I can. – Uanfala (talk) 02:42, 23 January 2018 (UTC)
Then you seem to be part of the problem you are complaining about. TonyBallioni (talk) 02:44, 23 January 2018 (UTC)
I guess we might have been exposed to different subpopulations of RM regulars. A more or less representative discussion for my experience so far is what's currently going on at Talk:Hebrew language#Requested move 28 January 2018. This is the kind of silliness that I'm used to seeing at RM discussions. – Uanfala (talk) 05:04, 29 January 2018 (UTC)

Over time, I've gradually increased the number of notifications sent out by my RMCD bot... to relevant WikiProject talk pages, when they aren't subscribed to article alerts... to talk pages of the targets of the requested move, when those exist and aren't redirects... to the top of the articles themselves. Perhaps sending talk page messages to the major contributors of the article is the last frontier for RMCD bot-generated notices... I'm not sure how much that would help, but I'll keep that idea on my back burner... unless there is a groundswell of demand for that. Personally, I contribute my share of participation in this area, but if I took the time to comment on every RM discussion, I wouldn't have much time left to get anything else done. And a lot of my "anything elses" are areas where there is even less participation than there is at RM. And regarding XFD, I very rarely take time to participate there. wbm1058 (talk) 18:06, 23 January 2018 (UTC)

I agree with TonyBallioni above when he says what makes the RM process work so well is the mix of RM regulars and those involved more with the content of the article whose title is being considered. That said, I'd say the mix already favors the content interests more than it should. I see more and more short-sighted decisions that don't take into account consistency with our broadest principles (WP:CRITERIA and WP:PRIMARYTOPIC). So, I would not favor extending the notice audience... But maybe a centralized location for RMs would help with consistency... Then any content editor notified about some one RM proposal would be taken to a page displaying all of the active RM proposals and discussions, and would get that exposure accordingly, instead of just looking at the one proposal on the article's talk page without any broader context. I kind of like it. --В²C ☎ 19:13, 23 January 2018 (UTC)
Isn't this page (WP:RM) the "centralized location for RMs"? That's what it's intended to be... if we transcluded every full discussion onto WP:RM it would be a real heavyweight, page-load-time wise! WP:AFD doesn't have every deletion discussion on it. Each discussion is on its own separate page, e.g. Wikipedia:Articles for deletion/Squishies. What would be the point of making Wikipedia:Requests for move/Squishies instead of just making a new section on Talk:Squishies? wbm1058 (talk) 21:19, 23 January 2018 (UTC)
Point taken, but there is a difference. When I go to Wikipedia:Articles_for_deletion/Log/2018_January_23 because of one deletion proposal I see the content ALL the discussions from today. Are RM discussions inherently longer than XfDs? --В²C ☎ 22:19, 23 January 2018 (UTC)
See Wikipedia:Requested moves/Log/2018 January 23. That just shows the first five, but the bot could write the full report and dynamically update it. Helpful? – wbm1058 (talk) 04:38, 24 January 2018 (UTC)

WP:TfD a better place for template re-titling discussions?

This was triggered by this move review of the RM of {{refimprove}}. There is nothing wrong with the RM process for articles. However, I am open to the idea that there should be a different process for templates, since that's an entirely different set of standards. The assertion that WP:RM was also for templates seems to originate in this edit from 2006, and I couldn't find the discussion that led to that, if there was one. It seems to have been accepted without comment at the time, possibly because it was a very natural outgrowth of the technical aspect of the pre-RM state of affairs, which was "if you can't move it yourself, find an admin and ask them to move it". However, these days the vast majority of requested moves are decided on WP:Article titles-related factors. I wonder if WP:Templates for discussion wouldn't be a better place for template re-titling discussions. Cheers, --Aervanath (talk) 08:20, 26 January 2018 (UTC)

  • Support sending all template renames redirects depreciations and deletions to WP:TfD. Templates have technical complications and subtleties not incommon with articles or project pages, and Naming Criteria were not written with any intention to apply to templates. To have renames, but not redirection or deprecation under another process doesn’t make a lot of sense. —SmokeyJoe (talk) 08:39, 26 January 2018 (UTC)
    • Template redirects are still discussed at WP:RfD. – Uanfala (talk) 13:56, 26 January 2018 (UTC)
      • True, but for templates that are already redirects (and are thus not templates but redirects in templatespace). Functioning, currently used templates get discussed at TfD. If you want to convert a used template into a redirect, I don’t think it is normal to go to RfD, and I think it is less than optimal to go to WP:RM. —SmokeyJoe (talk) 06:11, 27 January 2018 (UTC)
  • Strong oppose. I'm convinced that move review, and this entire section really, began simply because KATMAKROFAN didn't like the result of the RM. The issue wasn't with the move discussion, or the process behind it, or where it's located, but rather with the fact that it wasn't advertised, and therefore few people actually saw it. WP:RM should be the place for all move discussions, articles or not, not elsewhere simply because one user didn't like the result of a discussion. The solution isn't moving the discussion elsewhere; rather, it should be to advertise the discussion in relevant places. The same thing would happen if this was moved to TfD and the discussion wasn't advertised.
TL;DR: this process isn't botched; KMF just didn't like the result of the discussion. Have another discussion at WP:RM in 6 months (per the close at the move review), and advertise it more. SkyWarrior 19:03, 3 February 2018 (UTC)
Hi SkyWarrior, while you're right about what sparked this main section, the proposal to transfer to WP:TFD came from me, and I was not involved in the original discussion. I've wondered for a long time why template renaming should be in the same forum as article renaming, since they are based on entirely different principles. There aren't really any template naming guidelines. The TFD regulars, who deal with templates all the time, would most likely be far better judges of what the various templates should be named than the editors who frequent the WP:RM process.--Aervanath (talk) 20:04, 3 February 2018 (UTC)
Still strongly oppose moving move discussions from here to wherever. WP:RM was created for a reason: to request a move of a page. This should apply not just to articles, but to project pages, essays, templates, categories, etc. as well. This page isn't called "Requested move of articles", just "Requested moves", and it should stay like that. And just because a small group of editors may have a better knowledge on a subject over another small group of editors should not be a reason to move processes. We can easily just ask them to join the RM discussion, as it should've gone in the first place. SkyWarrior 20:15, 3 February 2018 (UTC)
I’ll add this here, but I actually think throwing this to the TfD regulars would be a strong negative of this proposal. The crowd that is there tends to focus on use and the technical areas of Wikipedia. RMs on the other hand focus on what we think someone would call something, which is just as useful for templates as it is for articles. TonyBallioni (talk) 20:24, 3 February 2018 (UTC)
  • Oppose TfD tends to be filled with an even smaller subset of the community than RMs do, and the rules there make substantially less sense to the average user than those at RM do. The RM process is straightforward, attaches the conversation to the talk page for future editors to easily find, and above all, isn’t broken in this regard. I see no reason to change. TonyBallioni (talk) 20:10, 3 February 2018 (UTC)

Bot text formatting

Sorry if there is some technical limitation and this has been discussed in the past. Is there a reason the bot has formatted the number of relisted discussions like this — (Discuss)ions —with parentheses, capitalization, and part of the word underlined? It looks like this has been in place since the addition to the page last May, but I presume changing it requires changes to the bot. Dekimasuよ! 21:30, 30 January 2018 (UTC)

To clarify, I understand the formatting in the list itself, just not in the header. Dekimasuよ! 21:46, 30 January 2018 (UTC)
This was discussed a while ago, see Wikipedia talk:Requested moves/Archive 30 § Discuss
I did it that way in the header so that would serve as the "key" to explain why the partial underlining is done elsewhere. I'm open to suggestions of better ways to make the indication for bot-recognized relistings. – wbm1058 (talk) 22:58, 30 January 2018 (UTC)
Thanks. It threw me off at first, but I've gotten used to it now. Dekimasuよ! 19:34, 5 February 2018 (UTC)

Requested move 5 February 2018

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review. No further edits should be made to this section.

The result of the move request was: not moved. Clearly not happening. (closed by page mover) SkyWarrior 17:40, 11 February 2018 (UTC)

Wikipedia:Requested moves → Wikipedia:Proposed moves – The title is consistent with Wikipedia:Proposed mergers. 192.107.120.90 (talk) 19:14, 5 February 2018 (UTC)

  • We also have Wikipedia:Requests for history merge, Wikipedia:Requests for undeletion, Wikipedia:Requests for mediation, Wikipedia:Requests for adminship, Wikipedia:Requests for permissions, Wikipedia:Requests for comment, Wikipedia:Requested articles, etc., so consistency does not seem to be a clear factor in favor of moving the page. As is true for most of those examples, the processing of technical requests using tools/permissions is involved in many actions here. Further, technical requests often don't require the discussion a "proposal" would imply. Note that this was also suggested ten years ago, and although I closed that discussion as "no consensus," under the way the page is currently run it would have been closed as "consensus not to move"/"not moved." Dekimasuよ! 19:32, 5 February 2018 (UTC)
  • Support - I realize it might be a painful change but I think it probably worth it. After all these "requests" are proposals (unlike some of the examples from Dekimasu which are literally requests (like RFCs are actually requests for comments - someone is requesting others to comment. But here what someone is doing it making a title change proposal. In fact, "Proposed title change" might even be better. While technically what we're doing is a "move", conceptually we're just changing the title of an article when we do that. In any case, making it clearer than these initiatives are proposals would be an improvement, I think. --В²C ☎ 23:29, 5 February 2018 (UTC)
Well, we are also changing the URL, that is moving the content to a new web page, so semantically "move" is correct. oknazevad (talk) 02:28, 6 February 2018 (UTC)
  • Oppose no need. Works fine as is. Would require us to change nomenclature as well, which is a negative. TonyBallioni (talk) 23:46, 5 February 2018 (UTC)
    • I see too many of these treated as requests rather than proposals. Sometimes the proposer will not even bother specifying a reason for the move, often leaving only a lame one. I think calling them proposals will lead to, well, better proposals. --В²C ☎ 23:56, 5 February 2018 (UTC)
      • Meh, as a semi-regular closer here, I've never found RMs wanting for that. If it's a bad proposal, we don't move it. I see no reason to shake this up. TonyBallioni (talk) 00:26, 6 February 2018 (UTC)
  • Oppose. I LOVE Wikipedia! A request to move the Requested moves project page (or maybe we can call it a proposal?). I call them "requests", "debates", "discussions" AND "proposals" when I close RMs. I agree with TonyB. I'm not crazy about turning RMs into PMs. No, let's not. This does not need fixin', no not at all.  Paine Ellsworth  put'r there  01:39, 6 February 2018 (UTC)
    • @Paine Ellsworth: These can't be PMs; PMs, or should I say WP:PM's, are proposed mergers; Since Wikipedia:PM has targeted Wikipedia:Proposed mergers since 2005, retargeting that redirect without breaking edit summaries is probably next to impossible. Steel1943 (talk) 03:04, 6 February 2018 (UTC)
      • Thanks for thinking that through, Steel1943! I've worked night jobs most of my life, so "PM" doesn't make me sleepy like it may do with others. I'm more likely to yawn and nod off in the AM. (heh) Good thing they don't want this page renamed to "Better Moniker"!  Paine  03:40, 6 February 2018 (UTC)
  • Support. Despite a knee jerk initial “no, random disruption”, then, meh, I find I agree. A proposer must actively propose the move, not passively request. This is the culture, and is a good way to work, so lock it in. —SmokeyJoe (talk) 01:59, 6 February 2018 (UTC)
  • Respectfully submit that a "request" is just as "active" an action as a "proposal", perhaps even moreso since one is not just "proposing" but actually "asking" for something, in this case a page move. You should go with your initial instincts, SmokeyJoe!  Paine Ellsworth  put'r there  02:07, 6 February 2018 (UTC)
  • Maybe it will be plenty good enough to note that accepted synonyms for RM include “Proposed Moves” and “Promposed Renames”. —SmokeyJoe (talk) 07:22, 6 February 2018 (UTC)
  • I'm going to go ahead and oppose per this thread. Part of the reason Wikipedia:Proposed mergers doesn't work very well (and came close to being labeled historical) is that it's hard to require someone to make substantive editing changes to the pages involved. There's not a process that's easily followed from one article to another. On the other hand, this is a well-established step-by-step process that involves fulfilling or declining requests. Requests are made by people who can't make moves themselves (they don't have the correct tools, or they already involved in a discussion and have expressed their opinions), and uninvolved editors with technical capabilities take care of them. While this page now functions as a clearinghouse for people who want to participate in move discussions, it has always also acted as a holding pen of requests from people who actively need some sort of technical assistance or minor mediation. Dekimasuよ! 02:59, 6 February 2018 (UTC)
  • Oppose. Firstly, this may be the most meta discussion in the history of Wikipedia. It's also one that was bad back in 2007, so it may behoove us to look at that discussion for insight as to why the current title is used. And the points made by the other opposers already in this discussion are all accurate. All that said, I see no compelling reason for the amount of systematic disruption this would cause. Like, at all. oknazevad (talk) 02:28, 6 February 2018 (UTC)
  • Oppose. I realize that the following may sound silly, but it's my opinion: I cannot support a proposition to move this page to a name which the first letter of the first word does not start with an "R". That, and the shortest shortcut for the venue's new proposed name is "PM"; well, WP:PM redirects to Wikipedia:Proposed mergers. That, and this move requires a whole lot of miscellaneous work changing several hard coded incoming links to the venue's current name. And, I can imagine that this move, in one way or another, affects Wbm1058's bot RMCD bot. It may look like a simple move with just a title change on the outside, but in reality it's asking for editors and bot operators to make a substantial amount of changes and edits to accommodate a move that isn't even necessary to improve the functionality of Wikipedia itself. So, since this request is essentially a cosmetic change to the name without any actual benefit to Wikipedia, no thanks. Steel1943 (talk) 02:59, 6 February 2018 (UTC)
  • Oppose per Steel1943. Also, is it meta that I found this discussion while checking the listings at RM? Yes, yes it is. Lepricavark (talk) 03:04, 6 February 2018 (UTC)
  • Oppose as proposed, but I generally endorse the idea of a rename, but this one isn't it though for me. Prefer something more direct akin to "Move requests". -- Netoholic @ 04:57, 6 February 2018 (UTC)
  • Oppose I see no compelling reason to move this page, per Oknazevad. Nihlus 06:09, 6 February 2018 (UTC)
  • Oppose If moved, Bot code and shortcut will be changed heavily, and I like Requested move name. Hhhhhkohhhhh (talk) 06:23, 6 February 2018 (UTC)
  • Oppose A solution to a problem that doesn't exist in the first place. Lugnuts Fire Walk with Me 09:29, 6 February 2018 (UTC)
  • Oppose actually, strong oppose: A: current title is consistent. We have RfA, RfC, requested articles, requests for permissions (WP:PERM), and whatnot. B: For a moment, even if we consider that we need to move it to "proposed moves", then the "post move clean-up" would be tremendous like user:Steel1943 suggested above. And he explained only one part. I dont see any reason to hog so many resources of bots, humans, and servers for this move. And in the first place: whats the need to move? —usernamekiran(talk) 09:36, 6 February 2018 (UTC)
  • Nope What shortcut will be used then? Seriously. Can't use WP:PM...then WP:RM will be confusing. Lot of other changes for WP:IFITAINTBROKE.. Galobtter (pingó mió) 09:40, 6 February 2018 (UTC)
  • Oppose – why change it when it is working just fine? See comment by Usernamekiran. The current title reflects consistency. CookieMonster755✉ 14:21, 6 February 2018 (UTC)
  • Well, Paine Ellsworth has asked me to reopen this..I don't see the point but neither do I have a great desire/time right now to argue. Galobtter (pingó mió) 08:42, 7 February 2018 (UTC)
The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

Allowing for multiple choices

Determining the community's top choice for the title at Sarah Jane Brown has been challenging for a number of reasons, for years. I'm hoping to propose a multi-choice approach to get this resolved, once and for all. My approach is in draft form right now, and would appreciate some input and suggestions. See Talk:Sarah_Jane_Brown/table. Thanks --В²C ☎ 00:56, 7 February 2018 (UTC)

  • We already allow this. More so in RMs than in any other community process. Though I find the table format you’ve proposed to be confusing. TonyBallioni (talk) 01:01, 7 February 2018 (UTC)
    • Yes, we do that. And one other thing that we sometimes do is close an RM disregarding the option that has achieved consensus on the grounds that it wasn't formally included in the nomination. – Uanfala (talk) 01:07, 7 February 2018 (UTC)
      • You really shouldn't disregard a consensus option just because it wasn't formally included. WP is WP:NOTABUREAUCRACY, and most closers respect that. Dohn joe (talk) 01:22, 7 February 2018 (UTC)
      • None of the regular admin closers do this, and I doubt many non-admins would close such a complex RM. TonyBallioni (talk) 01:26, 7 February 2018 (UTC)
        • I didn't see a way anyone could determine what the preferred choice was from that discussion, which is why I withdrew my original "traditional" proposal. As to what I'm proposing being confusing, I have three possible approaches. I think the third (Alternative 2) is simplest: you get to allocate 10 points among the choices any way you want, except you can't assign more than 4 to any one of them. This forces at least three picks (4, 4, 2) and should provide enough granularity to make a most-preferred choice, obvious. But I'm open to suggestions/comments. Thanks. --В²C ☎ 01:42, 7 February 2018 (UTC)
          • That is a terrible method, highly susceptible to chatic results due to clones and irrelevant alternatives. You can sink things you don’t want, it is easily gamed. I will try to re-explain the scoring method later. —SmokeyJoe (talk) 02:57, 7 February 2018 (UTC) See Talk:Me_Too_movement#Requested_move_22_January_2018 for a recent attempt (not used, the next edit was the close). —SmokeyJoe (talk) 03:04, 7 February 2018 (UTC)
  • This is basically a modified form of approval voting. These discussions are not votes, and should not be approached as such.--Aervanath (talk) 21:50, 7 February 2018 (UTC)

The reception for having participants edit a table was less than lukewarm. That's abandoned. Instead, I'm proposing we list the choices and have people express their preferences and reasons accordingly. Details here: Talk:Sarah Jane Brown#Next step? Better? Thanks. --В²C ☎ 22:09, 7 February 2018 (UTC)

My god... we started arguing about the title of that article over 10 years ago... and we are STILL arguing about it? That has to be a record of some sort. Blueboar (talk) 01:26, 9 February 2018 (UTC)

Settling long-unsettled titles is my specialty! I hope this current RM will settle it once and for all. Please weigh in! --В²C ☎ 01:39, 9 February 2018 (UTC)

For the record and for future reference, what Francis Schonken did there is probably the best way to go. He simply created a separate subsection for each candidate title, so everyone could comment on each candidate separately. It seems to be working and definitely the approach I'll take in future similar situations, once a reasonable list of candidate titles titles has been established. I think the closer will have a reasonable chance at finding consensus without pulling out too much hair. --В²C ☎ 20:16, 9 February 2018 (UTC)

That seems to be working out so far. It probably has the best chance of ending in some sort of consensus. I still don't envy the closer.--Aervanath (talk) 19:48, 11 February 2018 (UTC)

Panel of 3 RM admins needed

I would like to request that three uninvolved admins with plenty of RM experience form a panel to properly close the 12-choice multi-section cluster I helped create at Talk:Sarah Jane Brown#Requested_move_8_February_2018. It should be ready to go in a day or so. First three to sign up here "win"? --В²C ☎ 01:43, 15 February 2018 (UTC)

By the way, I think this deserves a panel of three because the debate about this title has been brewing for a decade, many have contributed, the answer is unclear, and it's important we get a well-thought-out and thus hopefully more likely to be respected decision. I think having three people hash it out has a better chance of accomplishing that. --В²C ☎ 01:56, 15 February 2018 (UTC)

Closers: Determining CONSENSUS rather than "consensus"

If we distinguish finding WP:CONSENSUS and "consensus" as follows:

  • Finding WP:CONSENSUS means determining community consensus about the proposal by weighing the arguments in the RM discussion based on how well they are grounded in policy, guidelines, conventions and usage in reliable secondary English sources, including dismissing the pure WP:JDLI ones entirely.
  • Finding "consensus" means determining the consensus of the participants by counting raw !votes.

I think it's safe to say that in most RMs it doesn't matter. For example, to randomly pick the first proposal in the Elapsed section right now, we have Talk:Billy_Harrison#Requested_move_22_February_2018, a strong policy-based proposal from Roman Spinner, and four !votes concurring. A typical no-brainer. The "consensus" is clearly in support of the proposal (in fact it's unanimous), and of course all policy-based points favor the proposal too, so it's reasonable to determine that the consensus of the community also favors the move.

Because in most RMs determining "consensus" of the participants and CONSENSUS of the community turns out to be the same, it's easy to conflate the two, and get in the habit of determining "consensus" instead of CONSENSUS. Let's face it, determining "consensus" is much easier and it feels natural. I mean, if, say 7 out of 10 oppose a proposal, how can you find the proposal being favored by the community? Well, you can, and should, if the only three !votes based in policy are the ones supporting it.

Distinguishing finding CONSENSUS and "consensus" is of course especially important in RMs where "consensus" and CONSENSUS are in conflict, which can happen for a variety of reasons, but usually involves WP:JDLI arguments with WP:NPOV totally ignored. Some excellent examples of this phenomenon are six of the seven RMs at Yoghurt that preceded the eighth one in which the proposal to move to Yogurt finally succeeded. In each of those earlier six in which the closer found "no consensus" the opposition was riddled with JDLI arguments which should have been discounted if not dismissed entirely in determining community CONSENSUS. In fact, the closer back in RM #2 (2006) actually did that, but was reverted 2 weeks later by another RM relying on "consensus" of the participants based on counting !votes rather than CONSENSUS of the community based on weighing strength of arguments. That particular dispute was unnecessarily stretched out for eight years thanks to closer after closer being reluctant to determine CONSENSUS overriding the "consensus" of those participating.

A more recent and perhaps more egregious example is the string of dubious closures at Sarah Jane Brown, including the one this week, in which again the closers deferred to the blatant NPOV-violating opposition to the "wife of ... " disambiguation that incorrectly claims "Sarah Jane Brown" to be WP:NATURALDIS (it's not because of the dearth of usage of SJB in reliable sources) and finds the "wife of Gordon Brown" parenthetic disambiguation to be inappropriate, offensive, etc., an obviously non-neutral stance, but unable to cite anything from reliable sources supporting this view. But these sources are riddled with examples identifying her in exactly those words, or very similar ones. And so the dispute there too remains unresolved, postponed again by a terrible decision based on "consensus" rather than WP:CONSENSUS.

But this isn't about SJB. My goal here is simply to bring this issue to the attention of closers, and to remind us all of what it says at Wikipedia:Requested_moves/Closing_instructions#Determining_consensus:

Consensus is determined not just by considering the preferences of the participants in a given discussion, but also by evaluating their arguments, assigning due weight accordingly, and giving due consideration to the relevant consensus of the Wikipedia community in general as reflected in applicable policy, guidelines and naming conventions.

In my opinion, that's not quite strong enough, because it suggests both should be given equal consideration. And that may be true in theory, but in practice, I think closers are far too reluctant to override consensus of the participants by consensus of the community "as reflected in applicable policy, guidelines and naming conventions", whenever there is a conflict. And that's why we have ongoing unresolved disputes like Sarah Jane Brown.

Thanks, --В²C ☎ 17:28, 1 March 2018 (UTC)

  • As I said on my talk page re: this style of argument, just because you interpret community consensus to mean one thing, doesn’t mean you are right. It is the job of RM participants to determine how to best apply the policy to the specifics of a given article. When people make valid arguments interpreting a policy one way, we don’t simply discount them when there is disagreement with the interpretation. TonyBallioni (talk) 18:23, 1 March 2018 (UTC)
    • Disputes about policy interpretation are definitely the issue in some RMs. That was not the case in this one. No one was arguing that WP:NATURALDIS should, or even could, be interpreted to support "Sarah Jane Brown"; they just asserted it. The supporters of SJB just ignored that it's supposed to be in common use in reliable sources, and that SJB clearly was not. No one argued that there was policy opposing "wife of..." , much less how to interpret some particular policy to support it. No policy was even cited to support that view (disagree? cite it). This was not a dispute about policy interpretation - this was a dispute about whether to follow policy or to ignore policy and just count raw !votes even if they were contrary to NPOV. --В²C ☎ 19:00, 1 March 2018 (UTC)

I'd like to point out that I've been on the other side. After consensus was found at Sega Genesis, there was still some unrest about the title, and so I initiated and wrote most of this FAQ to help everyone understand how we go that title and why: Talk:Sega_Genesis/FAQ. Check it out. This helps establish that the title is on firm ground with the community and, I believe, is much better than imposing an artificial moratorium on further proposals. A similar effort was made at Talk:Yogurt/yogurtspellinghistory. In other words, the proper way to build consensus and stable titles is with policy based argument and persuasion. It works. Counting raw !votes only works when the result happens to coincide with WP:CONSENSUS, which, for better or for worse, is most of the time. But in these special cases, a different approach is required.

By the way, here is a list of RMs with currently stable titles that went through a series of failed RMs before finally succeeding in a change to a stable and undisputed title:

Most of these could have been settled much earlier, sometimes years earlier, had the earlier closers paid more attention to CONSENSUS and policy than to consensus of the participants as indicated by counting raw !votes. --В²C ☎ 21:58, 1 March 2018 (UTC)

  • An alternative reading is that until you let belligerent disgruntled malcontents have they way, they will continue their belligerence. Some of the above moves were mistakes, Hillary Rodham Clinton, Las Vegas, Nevada, they previously had better titles. HRC has resumed publishing as Rodham, and being recognised as HRC[12]. Yogurt was a failure of the community to implement the simple principle of WP:RETAIN from the beginning. The "yogurt principle" is self consistent circular logic that misses the point of how consensus decision making works. The B2C strategies are bullying. He will continue to agitate until his POV wins, and if ever the community gives in, he calls it proof he was right. SJB was never my preferred alternative, I always preferred (nee Macaulay) and (born 1963) to it, but in every SJB RM since RM6, no alternative has ever been agreed to by the community as preferable to SJB. This appears at odds with COMMONNAME policy, which speaks to the COMMONNAME policy being overly strongly written, not accurately describing practice. It does not mean that the community needs to be subjected to endless belligerence until the few titling policy black letter obsessives win. A bullying culture is one in which the biggest get their way, eventually if not easily. A consensus bases community has its discussion, accepts the compromise, and moves on. --SmokeyJoe (talk) 22:53, 1 March 2018 (UTC)
It is also important to remember that NONE of the provisions outlined in WP:Article titles are “black letter” things... they are broad goals that we hope to achieve, but understand may not be. The policy itself notes that choosing the best title may require giving more weight to one goal and less weight to another. WP:AT is probably the single most FLEXIBLE policy we have... intentionally so. there are exceptions to every “rule”. Blueboar (talk) 23:28, 1 March 2018 (UTC)
The community disagrees with you about a lot of things, including your opinion on Hillary Clinton and Las Vegas. But it's appreciated. I worked my butt off helping the community find consensus on most of these, and I really resent the bullying characterization. People say things that don't make sense to me, and I respond with questions and explanation If you think that's bullying, that explains much. --В²C ☎ 23:11, 1 March 2018 (UTC)
I just went and reviewed the Talk:Hillary_Rodham_Clinton/April_2015_move_request decision certified by Callanecc Mdann52 and Euryalus . I forgot what an excellent job they did of weighing arguments based on how well they were based in policy (something you don't seem to value you very much). Stellar. TonyBallioni, you might want to review it; it exemplifies the depth of analysis and policy consideration I expected in your close. --В²C ☎ 23:17, 1 March 2018 (UTC)
The HRC close was good, that's agreed. I disagree with how the proponents voted. But I accept the process. I think you and a few others should accept that the community has ratified SJB, and let it go forever, pending only significant new information. The recent SJB close couldn't have been closed any other way, barring discretionary word choice. --SmokeyJoe (talk) 23:24, 1 March 2018 (UTC)
User_talk:TonyBallioni#Sarah_Jane_Brown is an example of bullying. Pinging a closer and telling him to go review an allegedly better done job is patronising and bullying. The closers should not have to defend themselves like that. --SmokeyJoe (talk) 23:28, 1 March 2018 (UTC)
Bullying? Unless you think I'm "using superior strength or influence to intimidate (someone)", I don't think that word means what you think it means. Pray tell, what is this "superior strength or influence" you think I have? I sure would like to know! Anyway, HRC->HC was closed with "consensus to move". SJB->? was closed with "no consensus". That's not ratification. --В²C ☎ 23:33, 1 March 2018 (UTC)
A supermajority supported it. "Ratify" is my word. I think the closers were conservative, I think the discussion shows a rough consensus to not move. The talk page thread quickly became harassment and intimidation, meeting the definition of bullying. It may not be an extreme example, but it meets the definitions. MRV exists to dispute closing decisions. Your pinging of a closer and telling him to go read a better close, that crosses the line, harassment, attempted intimidation, bullying. The end result of such activities will be to discourage future closers from acting. It is not extreme, yet, but I'm calling it. --SmokeyJoe (talk) 23:45, 1 March 2018 (UTC)
Okay... Note to self: Smokey thinks encouraging others to learn from exemplary closes is intimidation. (rolleyes) --В²C ☎ 00:00, 2 March 2018 (UTC)
I think the SJB close was exemplary, and that it is unreasonable to tell the authors (not even the main author) to go learn how to close. --SmokeyJoe (talk) 00:02, 2 March 2018 (UTC)
It's no surprise that you find the SJB close to be exemplary, given your low regard for community consensus as reflected in policy and guidelines you often demonstrate, like in your recent opposition to redirecting Second Amendment to Second Amendment to the United States Constitution based on a peculiar use of "systemic bias" that has nothing to do with WP:SYSTEMICBIAS, not to mention your total disregard for WP:PRIMARYTOPIC and WP:PRIMARYREDIRECT and open disdain ("terrible way") for the widely accepted use of page view counts for determining primary topic. --В²C ☎ 00:34, 2 March 2018 (UTC)
The last SJB discussion involved a very large number of diverse participants, more in number and diversity than the authorship of your favourite policy and guideline sections. Therefore, the SJB discussion should be taken as representing community consensus. Many arguments were put, and some, such as "The SJB title implies to the reader that SJB is her common name" did not gain much traction. This calls for rewording of the policy, not overriding a well participated discussion due to your reading of the letter of policy. NB. I think I am well positioned to be fair here, that argument did gain traction with me, and the discussion in the end did not align with my first two preferences. (Its the selective reading of PRIMARYTOPIC and looking ONLY at pageviews that is "terrible".) --SmokeyJoe (talk) 00:42, 2 March 2018 (UTC)
  • (edit conflict) In broad terms, B2C is correct that RM closers need to take into account the larger consensus, as represented by policies, guidelines, and their own experiences on Wikipedia. The local consensus cannot be allowed to override clearly established community guidelines and policies. However, it is not clear to me that this is the case in any of the RMs mentioned in this discussion. There is room in this encyclopedia for legitimate disagreements about how various policies and guidelines should be interpreted. You are allowed to think that those with opposing views are incorrect, but it is not acceptable to dismiss them out of hand just because they disagree with your interpretation of policy, or how to apply it. The reason for this entire process to exist is to sort out these disagreements. Sometimes we can sort them out, and sometimes we can't. Sometimes the local consensus SHOULD override the larger consensus; there are exceptions to every rule.
  • Regarding B2C's behavior, I don't think "bullying" is the correct word. However, bludgeoning and badgering are applicable terms. Also, it may be time to Drop the stick and back slowly away from the horse carcass.--Aervanath (talk) 00:47, 2 March 2018 (UTC)
  • @Born2cycle: I don't like the Hillary Clinton decision. I see that as a mistake, because she clearly uses Rodham, except as her "political" name. But I'm not there agitating about it or losing sleep. The problem is that you won't accept community decisions and keep going until you get your own way; then, if that works, you trumpet it as a "success". SarahSV (talk) 02:55, 2 March 2018 (UTC)
    • SlimVirgin, I appreciate what you'e saying, though it saddens me that you see it that way. It's not about getting my way. I don't even have a way - except to bring titles in line with what the community has decided via policy and guidelines (see my user page, which is dedicated to this theme). When a title is repeatedly challenged and only moved after a number of attempts, and then no more serious attempts are made to move it back, that should tell you something: Now it's finally at a stable title consistent with community consensus. And when nothing essential changed from the attempts that failed to the one that finally succeeded, that should tell you something too: that the basis to move the article existed just the same at the time of the first failed attempt as it did at the final attempt that succeeded... so why didn't we recognize that the first time? What is it about our process that allows these disputes to go on and on without resolution, when the stable title, policies and corresponding arguments were available to us from the beginning? I think it's because participants all too often ignore NPOV and offer JDLI or WIKILAWYERed rationalizations of arguments that at best look like they're based on policy (but aren't really), and closers pay too much attention to consensus of participants and not enough to CONSENSUS of community (weighing arguments based on policy and guidelines). What's your theory? Anyway, as to Hillary Clinton, she's most notable for her political identity, so it makes sense, on WP, to use that name, not to mention that she's much more commonly referenced in reliable sources as HC, not HRC. This is WP:COMMONNAME 101, and it should have been recognized from the outset. --В²C ☎ 03:21, 2 March 2018 (UTC)
      • It's not about your way, from your perspective agreed. You have merely adopted as a mission to implement policy, and to do it as objectively as possible. The problem is your subjective interpretation of objective. Also, you don't recognise your own biases. "I don't even have a way" is an asserted absurdity and proof of failure to recognise your own biases. It's easy to see bias in others. The bias you have is a black-letter narrow reading of polices and guidelines. The apparent contradiction between the current reading of WP:COMMONNAME and the article title SJB must cause you pain. Your behavioural problem stems from you need seeing as "bludgeoning" your own hardline dogged commitment to enacting what you think is a good idea. The absolute worst policy to read black-letter style is WP:Consensus, and this obviously causes you problems, as is evident for example in your two contrasting dot points at the head of this thread. "Consensus is ascertained by the quality of the arguments given on the various sides of an issue, as viewed through the lens of Wikipedia policy" is simply not reducible to black letter statements. --SmokeyJoe (talk) 03:50, 2 March 2018 (UTC)
  • I don’t fully accept B2C’s idea that there is such a clear cut distinction between “WP:CONSENSUS” and “consensus”... Yes, a closer. should give more weight to policy based arguments, but that does not mean we give no weight at all to simple !votes. Quantity has a quality all its own. And some policy based arguments can actually be misinterpretations of policy (and thus can be given no weight at all). Finding “WP:CONSENSUS” requires taking “consensus” into account. It is an art more than a science, and there is no simple algorithm that can be followed. Blueboar (talk) 11:50, 2 March 2018 (UTC)
  • So what you mean is that the closer should interpret the debate in your favour regardless of the weight of arguments or opinion. How about: no.
I want to address "Big Ben" specifically. This was crowbarred through based on the common misnomer, but the article right now is incorrectly titled in that it opens "Big Ben is the nickname for the Great Bell of the clock at the north end of the Palace of Westminster in London[1] and is usually extended to refer to both the clock and the clock tower.[2][3] The tower in which Big Ben is located is officially called the Elizabeth Tower; originally just the Clock Tower, it was renamed in 2012 for the Diamond Jubilee of Elizabeth II." The article then goes on to talk mainly about the tower. These are two subjects in a single article, which actually should now be at Elizabeth Tower because the dominant topic is still the tower and the clock, not the bell. The fact that Americans have no idea that the tower and the bell are not one and the same is largely irrelevant, since the sources, especially following the renaming, are absolutely unambiguous in drawing the distinction. The article should be at Elizabeth Tower and Big ben should be a redirect to the section n that article, because that's what redirects are for.
So B2C is inordinately proud of moving something to an objectively incorrect title after years of agitation, and this is somehow supposed to be a point in his favour. It's amusing given his insistence that SJB is not an "official" name, since in this instance whereas we previously had no official name (it was just "the clock tower"), now we absolutely do. Guy (Help!) 12:29, 2 March 2018 (UTC)
It's not in my favor; it's in favor of the community's policies. I'm not responsible for how the public and reliable secondary sources conflate the tower and the clock. I didn't invent COMMONNAME policy on WP to reflect such usage, no matter how "wrong" it may be. If you don't like it, then build a consensus to change the policy. But don't blame the messenger. --В²C ☎ 16:57, 2 March 2018 (UTC)
  • By the way, JzG, curious, I checked the Talk page there to see what the latest RM was. To my surprise it was this month. I was not involved in that latest RM there(how did I miss that?), to move Big Ben to Elizabeth Tower. It was opposed by all participants, unanimously. Why? Because the clock and the tower is most commonly referred to as "Big Ben". Every single participant, either explicitly or implicitly ("for reasons stated above"), cited COMMONNAME in their reasoning. That's in my favor? Only because I happen to agree with the community. To use this case as an example in the list I provided above of something that is "incorrectly titled" now is farcical. Oh, but it's just me "interpreting" policy differently and incorrectly. Yeah, right. Thank you for making my point better than I have. In the past enough editors who favored a subjective assessment of what is "the correct name" for the subject of the article, a position not supported by any policy, and contrary to NPOV, rather than following usage in sources per COMMONNAME, managed to persuade a closer that there was a lack of participant consensus to move to Big Ben (Talk:Big_Ben/Archive_2#Requested_move_1). The situation then was very similar to the Sarah Brown RM discussions: closers swayed by participant "consensus" resting on JDLI arguments, and not weighing arguments properly as based in policy to determine community WP:CONSENSUS. The next RM did result in a move to Big Ben Talk:Big_Ben/Archive_2#Requested_move and it has a great closing explanation from PBS, who determined CONSENSUS rather than "consensus". The relevant policies have not changed significantly since then. The relevant usage in sources has not changed since then. But now we have a title that is clearly supported by policy - so good luck "fixing" that. --В²C ☎ 19:33, 2 March 2018 (UTC)
  • Nice job misrepresenting the lack of unanimity there. --SarekOfVulcan (talk) 20:19, 2 March 2018 (UTC)
    • You mean the one !vote to split? That's hardly support for the proposal. --В²C ☎ 20:27, 2 March 2018 (UTC)
      • You mean, my proposal to have the article about Elizabeth Tower be named Elizabeth Tower? That's exactly support for it. --SarekOfVulcan (talk) 20:31, 2 March 2018 (UTC)
        • Sorry! I was not counting the proposer, who is (almost) always presumed to support the proposal. If you count the proposer then unanimous opposition is practically impossible and is essentially meaningless. So what I think is reasonably meant by unanimous opposition, and certainly what I meant, is everyone (but the proposer, of course) opposed it. --В²C ☎ 20:41, 2 March 2018 (UTC)
          • Goodness. One post ago, you admitted there was support for my position, and you're already back to the "unanimous" claim. Do you even listen to yourself???? --SarekOfVulcan (talk) 20:48, 2 March 2018 (UTC)
            • You made me look up "hardly" - no, I used it correctly. It means "true to an insignificant degree". Saying something is "hardly support" is saying it's not significant support, which means, practically speaking, it's not support, which is what I intended to convey (if my intent is of any interest). But now we're into semantic nitpicking areas. --В²C ☎ 20:56, 2 March 2018 (UTC)
The RM was not advertised, and the comments were based on fallacious reasoning. The article is objectively mistitled. The official name of the tower that is the subject of the article is the Elizabeth Tower, and this was widely discussed during the Jubilee. It's quite possible that non-English people may not know it, but even then, that's not a reason for using the wrong name. It's not for Wikipedia to tell the Palace of Westminster that they have the name of their clock tower wrong, and we have redirects that would completely solve the problem of people looking for the wrong thing. Most people name the Berenstain Bears incorrectly. We don't. We follow reliable sources, and in this case, the more reliable, authoritative and current the source is, the more likely it is to get the name of the tower right, because such sources care more for accuracy than our COMMONNAME-obsessives. Where COMMONNAME=WP:WRONGNAME, we should follow reality, not the common error. We do this all the time in areas where large numbers of crappy sources say one thing and smaller numbers of robust sources say another. Thus we don't say that vaccines cause autism, homeopathy works, or the earth is flat. Guy (Help!) 19:54, 2 March 2018 (UTC)
Wow. The RM was advertised like all RMs: at WP:RM and on the article as well as on the article's talk page. We follow most common usage in all reliable English sources, not just uses in some subjectively selected "most reliable" sources cherry-picked by JzG. You should know that, and respect it. It's sad that you don't. Just like you don't seem to recognize and respect the reason that we don't say vaccines cause autism, homeopathy works, or the earth is flat: because reliable sources don't say that. --В²C ☎ 20:12, 2 March 2018 (UTC)
Yes, advertised to the tiny cadre of people whose interest is moves, but I have that article on my watchlist and it never showed n my feeds. Point remains: the title is objectively, as in provably and from authoritative sources, wrong. I find it laughable that you, who have repeated RMs in some cases for over a decade until you get the answer you want, should be chiding me for not respecting this one. Guy (Help!) 20:58, 2 March 2018 (UTC)
Well, there must be a bug in the watchlist notifications then, because any edit to the article or the talk page should have alerted you to that RM. In any case, I'm glad you asserted the current title is "objectively wrong". We should be able to find some common ground here. The assertion that something is objectively wrong (or right) implies an underlying standard by which to determine right or wrong in that context, does it not? So by what standard do you declare that title is "objectively wrong"? I submit the appropriate standards for determining the "objectively right" (or wrong) title for a WP title are WP policies and guidelines... can we agree on that? Now, please identify which of those WP policies and guidelines demonstrate that the title is "objectively wrong". I further contend that WP rules like WP:COMMONNAME and WP:OFFICIAL indicate the opposite: the title is objectively right. --В²C ☎ 21:23, 2 March 2018 (UTC)
In case you hadn't worked it out by now, I care less than nothing for the endless WP:TLA parade you trot out in order to try to force debates your way. The objective fact is that the article is about the tower, and the tower is called the Elizabeth Tower. The name Big Ben correctly applies only to the bell, and what you are doing is insisting that Wikipedia follow common errors rather than objective fact. That is precisely the same approach taken by antivaxers and fans of every kind of quackery, and I have no patience with it. We should defer to objective fact and explain common misconceptions, not the other way around, as is currently the case with this article. Guy (Help!) 13:27, 4 March 2018 (UTC)

The Self-Driving car analogy

The other day I was listening to a talk about how Google self-driving cars work and someone asked about scenarios not anticipated in the software. The answer was very interesting, and, surprisingly, I think it applies to WP title decision-making. The idea is that they don't anticipate every possible scenario, but instead distill general principles of driving that can be applied effectively in any scenario, including scenarios not yet anticipated. The resistance to making title decision-making algorithmic based on the notion that it can't be algorithmic, though driving in infinitely unpredictable traffic can be, is absurd. We too can distill general principles - call them policies - and apply them objectively to all titles. If we have situations where the polices don't give us a clear-cut answer, then we've identified a problem in our policies. A self-driving car can't suddenly stop in traffic because its algorithms produce a muddled decision. If during testing they encounter such a situation, they address it by fixing the underlying principles. We should be doing the same. --В²C ☎ 17:10, 2 March 2018 (UTC)

It is impossible even in principle for a set of policies to anticipate all possible circumstances. Expecting them to is a fallacy, and all the more so on a project in which "ignore all rules where warranted" is itself part of the rule-set. Albeit in a different context, see my essay here, and better still see the article I link to at the end of the essay, here, for more thoughts. Newyorkbrad (talk) 17:47, 2 March 2018 (UTC)
Much of the public's skepticism about self-driving cars stems from the belief that "It is impossible even in principle for a set of [driving principles] to anticipate all possible circumstances", and yet self-driving cars must do exactly that. The reason is that that they're not actually doing that. That is, it's not a matter of anticipation of all possible circumstances, but a general preparedness for all kinds of circumstances, including unexpected ones. That's exactly what self-driving car and title determination algorithms have in common. The insistence that this is impossible is just an excuse to not even try. It's a self-fulfilling prophecy. Luckily self-driving car engineers don't have this mentality. Sadly, all too many WP editors do. --В²C ☎ 18:39, 2 March 2018 (UTC)
[13]. power~enwiki (π, ν) 18:46, 2 March 2018 (UTC)
So we should ignore all rules when it allows you to get your way, but follow the rules when it allows you to get your way. And given that your principal activity on Wikipedia is obsessing over articles that have the "wrong" title, we should do it sooner to avoid all the effort you have to put in, right? See m:MPOV. Guy (Help!) 19:54, 2 March 2018 (UTC)
What? Again, I don't have a way. I understand that titles don't matter much. My interest is in a process that results in titles without conflicts (just like self-driving cars rely on a process that results in reaching destinations without collisions). And I'm not normally a proponent of not following rules, unless it's part of the process to improve a rule, which includes explicitly invoking IAR, and even then usually for policy-based reasons. I address this in my FAQ. User:Born2cycle/FAQ#Change_guideline_first. This is similar to self-driving car algorithms that are revised after an event during testing where the algorithms required a human driver to take over. Just like the goal in self-driving cars algorithm development is to never (or practically speaking, almost never) encounter a situation where human intervention is required, the goal in title decision-making rules should be to never encounter a situation where an RM is required. --В²C ☎ 20:37, 2 March 2018 (UTC)
"...titles don't matter much." Great. So if the title of that biography about that woman with a very common name (common, as in a name shared with lots of other women, inherently causing traffic accidents amongst those women) doesn't matter very much, why do we need to have so many discussions to decide that title, and need to call in a team of elders to close the discussion? "My interest is in a process that results in titles without conflicts (just like self-driving cars rely on a process that results in reaching destinations without collisions)." We already have such a process. It's called disambiguation. Hatnotes and disambiguation pages, when functioning properly allow readers to avoid collisions. Sarah Brown is such a roundabout. Readers drive around that roundabout until they see the link pointing to their desired article, at which point they leave the roundabout and follow that link. Does it really matter that much what the sign on the roundabout says, as long as the short description accompanying the link "(born 1963), charity director, wife of former British Prime Minister Gordon Brown" is sufficiently clear? Is our system perfect? No, it's not, or Category:Articles with redirect hatnotes needing review would always be empty. We could use a few more volunteers to help keep that category cleared, as we haven't yet developed a bot (the wiki version of the self-driving car) to work that category. – wbm1058 (talk) 22:05, 2 March 2018 (UTC)
When I say "titles don't matter much", and to stick with the driving analogy of this section, what I mean is it doesn't matter much in the same way that whether we drive on the left or right doesn't matter much. But we have to pick one. That is important. We pick left or right driving for efficiency and to avoid collisions. Similarly, we pick common name, or official name, to avoid RMs. Or at least it should avoid RMs (just as driving on the right helps avoid collisions). Just as left or right driving side doesn't matter, but settling on one or the other never-the-less does, picking common name or official name doesn't matter either, but settling on one or the other never-the-less does. Some of could drive on the left and other on the right, but the result would be inefficient and lots of collisions. We could use official names for some and common names for others, and decide on a case-by-case by who-knows-what criteria, as many seem to favor we do, but the result would be inefficient and lots of RMs, just like driving on both sides of the road would be. If titles ultimately don't matter much, why not just pick one and stick to it? That's ultimately my point here. Why use common name for half or 90% or but official name for the other half or even 1%? Why not just always use the most commonly used name, period? --В²C ☎ 22:26, 2 March 2018 (UTC)
Lame analogy: Drive on the left: Sarah Brown. Drive on the right: Brown, Sarah. The name is the same. Only the form that it is rendered is changed. Adding a parenthetical or a middle name changes the form. Both the UK (drive on the left) and America (drive on the right) have roundabouts, which are functionally equivalent. wbm1058 (talk) 22:39, 2 March 2018 (UTC)
Ahem. We parked at Sarah Jane Brown. Why can't you stick to it? wbm1058 (talk) 22:42, 2 March 2018 (UTC)
We can't just always use the most commonly used name, because our system requires unique titles, and commonly used names, like "Sarah Brown", are far from unique. – wbm1058 (talk) 22:50, 2 March 2018 (UTC)
That's like saying we picked driving on the left on Oak St, even though we picked driving on the right on all other streets. Why can't you stick to it? Choosing a special rule for Sarah Jane Brown, or rather ignoring the WP:NATURALDIS rule of using commonly used names in reliable sources forms for natural disambiguation, is akin to using a special drive-on-the-left rule for Oak St. It's not even a recognized exception case, like driving on the left is okay on one-way roads is in our analogy, or parenthetic disambiguation is in our titles. There is no "driving on the left is okay on one-way roads" natural disambiguation exception using very rarely used names. Now, if we can determine that we really need a special case here, as there are no other options that are in compliance with the rules, we should update the rules accordingly. But we do have options. There are several parenthetic disambiguations that are perfectly in line with our rules. We just have to figure out how to get the community to select one. And when any one of those options is available, sticking to a title that is clearly unsupported by the rules like "Sarah Jane Brown" is, the closers should be focusing on picking something more in line with those CONSENSUS rules, as well as "consensus". --В²C ☎ 22:56, 2 March 2018 (UTC)
We just have to figure out how to get the community to select one. This might be the most arrogant thing I have ever read in regards to a move discussion. The community does not have to do anything in regards to a requested move: the presumption is that it will stay at a stable title: the obligation is on those wanting a move to achieve consensus. There wasn't even consensus a move was needed (and please don't go on the CONSENSUS vs "consensus" distinction: people considered your arguments and made counter arguments. This was also a community-wide RM advertised at CENT and BLPN which means that it had wide input from beyond the normal RM crowd who writes the guidelines, which almost certainly makes it more reflective of actual community consensus on the interpretation of the naming policy in this case than the small crowd who are RM regulars.) The community has consistently rejected a move for half a decade. In the other cases you could argue whether or not it was the specific title that caused people to reject it but this RM had probably every title available, and they still preferred the status quo: per the close, I think that there was a slight consensus to keep the stable title, not necessarily a consensus that it was the best, but a consensus that it would work and that repeated RMs were disruptive. Please drop the stick here. TonyBallioni (talk) 23:32, 2 March 2018 (UTC)
That's ridiculous. We're talking about what to name Oak Street, not what side of it we drive on. If someone moved that street to the wrong side, Oak Street (disambiguation), we have rules for getting it back to the correct side. See WP:MALPLACED. I'll remind you that it was your October 2014 edit that changed the simple concept of "natural disambiguation" from "an alternative name that the subject is also commonly called in English" to one commonly used in "reliable sources". You were called out on your concept of "COMMONNAME" back in August 2011. Presumably we have a reliable source for Brown's middle name. This is not a made-up name, and I would hesitate to tell anyone to their face that their middle name was an "obscure" name. If we don't allow middle initials and names for disambiguation, we take too many options off the table. The problem your self-driving article titling bot is having is finding which of (campaigner), (activist), (executive), (spouse), etc. is most commonly used in reliable sources. We just have to figure out how to get the community to select one. What you mean is, you can't get your self-driving car to get out of the roundabout. – wbm1058 (talk) 23:57, 2 March 2018 (UTC)
Wbm1058, there aren't any significant rules about naming streets; there are significant rules about article titles, just as there are significant rules about which side of the street to drive on. That's the aspect they have in common that makes that analogy appropriate. That addition of reliable sources is merely a clarification and should go without saying. The key part there is "commonly used in English", which "Sarah Jane Brown" is not, and that's demonstrated by the dearth (though no longer total absence it used to be) of sources that refer to her that way. It's no where near meeting the "commonly used in English" hurdle, but this is not the place to be (re) arguing that RM. --В²C ☎ 00:21, 3 March 2018 (UTC)
Commonly called in English. Everyone who has a middle name may be commonly called by that middle name, as in common English, especially when necessary to distinguish that person from someone else with identical first and last names. There should be no requirement for inventorying and counting occurrences in reliable sources. That's OK for determining the first choice in title, if there are no conflicts, but this breaks down badly as a disambiguation requirement. How many reliable sources call her Sarah Brown (born 1963)? wbm1058 (talk) 00:47, 3 March 2018 (UTC)
No, plenty of people have middle names for official records or whatnot but are NOT commonly called by that full (including middle) name, and Sarah Brown is one of them. Of course we would not expect to find parenthetic disambiguation like Sarah Brown (born 1963) used in sources, or that would be natural disambiguation too. The whole idea is we use either the most commonly used name for a topic, or, if not available, then an alternative less commonly used (but still commonly used) name, or if not available, then parenthetic disambiguation (which is not expected to be found in sources verbatim, though the description within parentheses should be a way the topic is commonly described in sources). --В²C ☎ 00:56, 3 March 2018 (UTC)
It might be an interesting exercise to inventory the sources actually used in the article. Just looking at one, Daily Mail says Sarah Brown, wife of former prime minister Gordon Brown. That translates to the parenthetical Sarah Brown (wife of former prime minister Gordon Brown) which we would shorten to Sarah Brown (wife of Gordon Brown) if her husband did not require disambiguation. But, of course, this runs into the issues of "political correctness" and whether or not the Daily Mail is a RS. LOL. wbm1058 (talk) 01:03, 3 March 2018 (UTC)
Indeed. I'm pretty sure most of the people who argued against "Sarah Jane Brown" did so because they went through the brief exercise to determine it was never used, or almost never used, in sources. Further, most people who looked at how she is described in sources, find that it's pretty much how the Daily Mail does; and more reliable sources do the same. I can't speak for those who favored SJB, because I couldn't tell what most of them based their positions on. It seemed like they just assumed oh that's her middle name (or that's her other given name in British parlance, apparently), and so it's reasonable to use it. No basis in policy that I could see. --В²C ☎ 01:19, 3 March 2018 (UTC)
And another RS, The Guardian, calls her Sarah Jane Macaulay. Did she lose her middle name as well as her last when she married? In any event, there's a source using "Jane". wbm1058 (talk) 01:27, 3 March 2018 (UTC)
Some people might take this concept of counting sources to such an extreme as to deny moving her from Macaulay to Brown before it's been demonstrated that a majority of sources have conformed to using her new name. It may take some time before the number of sources using "Brown" surpasses those which have used "Macaulay", you know /sarcasm wbm1058 (talk) 01:38, 3 March 2018 (UTC)
Yes, that one reference from almost 20 years ago has been brought up for years - yes, apparently she was known as "Sarah Jane Macaulay" back then, but that's before she became notable (as GB's wife). For whatever reason no sources (except records) ever referred to her as "Sarah Jane Brown", she is simply not called by that name, much less commonly called by that name. I should add that what made this RM particularly complicated and challenging was not only the NATURALDIS issue with SJB, but also the vehement visceral opposition many had to the most logical choice ("wife of" - as you note above). I think this muddied the "consensus" read as well. Many people's opposition to "wife of" was so vehement they didn't care what problems there might be with SJB - in their minds it was clearly preferable to "wife of", and so they never seriously looked any deeper (I'm surmising). I had hoped the multiple choice format of the RM would help us work this out, but it did not work as well as I had hoped. It was just too complicated to have to open a dozen or so separate sections to weigh in on all the choices, and many didn't bother. I get it. If you don't appreciate the issue with SJB, the whole thing is going to seem like a big nuisance. But really, since opposition to "wife of" was not based in policy, it was really a violation of NPOV to oppose it, and I think those !votes should have been discounted accordingly, as well as the support votes for SJB. What would be left as a result of such a weighted analysis of the !votes, I'm not sure, except it wouldn't have been to retain SJB. --В²C ☎ 01:41, 3 March 2018 (UTC)
@Born2cycle: re: no source ever calls her Sarah Jane Brown, see Getty Images: "Portrait of British politician Chancellor of the Exchequer (and future Prime Minister) Gordon Brown and his wife, Sarah Jane Brown, as they pose outside their home ..." SarahSV (talk) 02:58, 3 March 2018 (UTC)
Thanks, but I don't think gettyimages counts as a reliable source. Could be an intern who checked Wikipedia for her name (which is possible and an important reason to not use names of subjects by which they are not commonly referred). In any case even if this one source was the London Times it would still be just one source; no where near meeting the “commonly called” NATURALDIS hurdle. —В²C ☎ 06:55, 3 March 2018 (UTC)
I am becoming seriously pissed off with your relentless denialism. Her name is Sarah Jane Brown, that is an objective fact. We have an absolutely authoritative, 100% reliable official source, Companies House. You know this, yet you somehow pretend it does not exist. Guy (Help!) 13:31, 4 March 2018 (UTC)
TonyBallioni, this whole section isn't even about that particular close (though it is the most recent example I know of the general issue this section is about), but others keep bringing it up. I'm just responding/clarifying. No stick! As I noted before, there is no doubt that most participants there preferred the status quo. Like I keep saying, that's the "consensus". What I'm trying to persuade other closers about, apparently with very little success, is that we could have justifiably ended multi-year disputes like this and all those in the list above if we looked more closely at the arguments relative to their basis in policy, rather than just the preferences, and closed accordingly. This is especially true in large RMs where we are likely to have many participants who are not very familiar with title policy, guidelines and conventions, nor very experienced with title changes. That's how and where they learn about these policies. To continue with the driving analogy, we don't look at beginner driver behavior to decide what the rules should be. As to the undisputed fact that the community has consistently rejected a move for half a decade, that was the argument at many of the RMs in the list above, including at Yoghurt, only there it was eight years, and the move was even more specific (from Yoghurt to Yogurt). But if you go back to any of those other RMs where the community supposedly rejected "Yogurt", you'll see that "consensus" does indicate apparent rejection, but a closer evaluation of the arguments per basis in policy indicates CONSENSUS did favor the move. And, sorry to say, same with your close (and the previous ones at SJB). But look, this is just an argument. You are free to disagree, dismiss, or whatever. It's an issue I've been trying to raise long before this article. Please don't take it personally. --В²C ☎ 00:21, 3 March 2018 (UTC)
TonyBallioni, you’re free to disagree?! The gall! B2C’s dellusions are universally disagreed with. —SmokeyJoe (talk) 02:11, 3 March 2018 (UTC)
We just have to figure out how to get the community to select one. No, we just have to figure out how to get a small number of people to stop obsessing over moving the article away from a title that is 100% verifiably accurate, unambiguous and where there is no evidence it is considered a problem at all other than by them. B2C, your arrogance is incredible. You're basically saying that the whole of the rest of Wikipedia has to find a solution to a problem that most of them don't consider to be actually a problem, and do so to your personal satisfaction, otherwise you will keep bringing it up again and again and again and again and again and again and again and again and again and again and again and again and again. Guy (Help!) 13:37, 4 March 2018 (UTC)

Policy-based rationale for Sarah Jane Brown

"...still be just one source; no where near meeting the “commonly called” NATURALDIS hurdle."

This is flat-out wrong. An incorrect interpretation of

Natural disambiguation: Using an alternative name that the subject is also commonly called in English reliable sources, albeit not as commonly as the preferred-but-ambiguous title. Do not, however, use obscure or made-up names.

She is commonly called Sarah Jane Brown, albeit not as commonly as Sarah Brown. There is no "failure to pass a hurdle here". Title characteristics (e.g. "naturalness") should be seen as goals, not as rules. Stop insisting that they be seen as rules. It may be necessary to favor one or more of these goals over the others. This is done by consensus.

Yes, she is less commonly called by her full name, much less commonly than she is called by just her first and last name. Because of this relatively weak case for natural disambiguation, a serious attempt was made to find a parenthetical alternative. Examination of sources leads to looking at Sarah Brown (wife of Gordon Brown), or "spouse", for consideration. This has been strongly rejected, for reasons I think you should understand. Similarly, Sarah Brown (born 1963) has also been rejected, though not as strongly. Taking a look at the Sarah Brown (disambiguation) page, the defacto parenthetical that would be acceptable would be Sarah Brown (charity director, wife of former British Prime Minister Gordon Brown), but this is weak on the conciseness criterion. Unfortunately, unlike some of the past spouses of Prime Ministers of the United Kingdom, she has no title like Countess, Duchess, Viscountess, Marchioness, or Baroness which would disambiguate. The British don't use "First Lady"; that role may be filled by Prince Philip. Someone made a pointy edit that bluntly shows why the community is having trouble with solely disambiguating based on some variant of "charity director" or "campaigner". Note that no other Prime Minister's spouse's name has parenthetical disambiguation. Having failed to find an acceptable parenthetical that doesn't seriously impair other criteria, the community has, perhaps reluctantly, fallen back on the natural disambiguation as the best of the less-than-ideal options. Should another woman named Sarah Jane Brown become sufficiently notable to challenge this one for primary topic status, well, we'll wait to deal with that problem until it actually arises. – wbm1058 (talk) 15:35, 4 March 2018 (UTC)

This is what I was referring to in my comment in the next section (see below)... there are policy based arguments to support ALL the various opinions at the Sarah Brown move discussions. It’s choosing between these policy based arguments that makes it difficult to close. Blueboar (talk) 16:20, 4 March 2018 (UTC)
Come on guys. You can say Hillary Clinton is also “commonly called” Hillary Rodham Clinton (and this was never disputed - that one was about ‘’which’’ of HC or HRC was more common). But until this last RM there were ‘’zero’’ examples of sources using SJB, and now in this last one there were a few finally found and cited (which I initially missed) but the actual number cited is still under five, none of which are in actual reliable secondary sources like reliable news sources or books, or the sources used in the article, and is practically nothing compared to the ‘’tens of thousands’’ of sources referring to her as SB. To say that she is “commonly called” SJB is to not differentiate “commonly called” from “called at all by someone somewhere”. It makes no sense, and it flies in the face of the obvious. She is simply not recognized as SJB, and anyone who doesn’t realize this is still missing the whole point of the decade-long opposition to SJB as the title, and probably hasn’t spent any time seriously considering this objection. In other words, google it yourself. You’ll see what I mean very quickly. —В²C ☎ 19:07, 4 March 2018 (UTC)
Clinton, as Jerusalem below, is an apples–oranges comparison. She is PT for HC so that option wasn't taken off the table. The issue with Clinton was that her preferred name (and thus the name used by RS who tend to use the subject's preferred name) changes over time to suit her (political) purposes. You will be hard-pressed to find an apples–apples case that follows the same decision logic as this SJB case. Any natural disambiguation which is a person's full name is valid if you can cite one reliable source (primary or secondary) and no contradictory sources contesting that name are found. This idea that you need to go to Google and start counting sources in order to use a person's full given name as the tile of their biography is ridiculous. Maybe we need an RFC on the titling policy to drill that home. If you look very deeply at all at how marginally notable people with common names like Smith and Jones are disambiguated, I think you will find that to be the case in practice. Granted, we don't prefer using the full names of people where the full name isn't often seen in print, but there is no requirement to take this option off the table. As I pointed out above, this "requirement" to count uses stems from a change you boldly made to the policy, which was protested at the time, but which hasn't, until now, been formally !voted on. wbm1058 (talk) 19:43, 4 March 2018 (UTC)
Just noting one example. Shirley M. Jones. Editors familiar with a 1970s American TV series will understand why the middle initial is necessary. Shirley Jones (politician) is a red link (one article links to that). Two sources. Illinois Blue Book likely gives her full name as such directories usually do. The obituary also provides her full name as obits generally do, but primarily uses just "Shirley Jones". There is no basis for the middle intial being the "COMMONNAME" by your "count the sources" rule. I assert that this sort of thing is common practice, and the policy is not strictly interpreted the way you believe it should be. – wbm1058 (talk) 20:38, 4 March 2018 (UTC)
@Wbm1058: ordinarily what you say here might hold true, but in this case, Sarah Jane Brown is not a common name for the subject, so it is not eligible for consideration under NATURALDIS. There are only a very small handful of sources out there using that name, so it does not satisfy WP:COMMONNAME at all. Thanks and I hope that makes some sense.  — Amakuru (talk) 21:07, 4 March 2018 (UTC)
Also, the title Sarah Jane Brown is problematic for two other reasons - WP:CONSISTENCY and WP:RECOGNIZE, and in some ways these go hand in hand. When a person is ambiguous, and are not generally known by a middle name or initial, our convention, which we apply with very few exceptions, is to use their normal FirstName LastName, with a parenthetical disambiguator. The fact that we do this, means that for anyone vaguely familiar with this convention, they know that if they see a Sarah Jane Brown, then that's not the Sarah Brown that they know of, because if it were, we'd call her Sarah Brown (foo). Furthermore, "Sarah Jane" is a common given name, which evidently is *not* the given name of this Mrs Brown, since Jane is her middle name. This further hinders readers when it comes to recognizing that the article in question is regarding the wife of Gordon Brown. It looks more like some lady named Sarah Jane, whose surname is Brown. This may seem like nit-picking, but the CONSISTENCY and RECOGNIZE criteria on this page were put there for a reason, and they are generally acknowledged to make things clearer for readers.  — Amakuru (talk) 21:14, 4 March 2018 (UTC)
That argument was put in the RM. Also previous RMs since RM#6. Why did it not get much traction, not persuade many other participants? —SmokeyJoe (talk) 21:48, 4 March 2018 (UTC)
I don't really know why not. Do you know? As far as I can tell the attempt to move to a parenthetical failed mainly because there wasn't a suitable one available for this particular subject. Well that's fair enough I suppose, but that being the case I wish people would expressly acknowledge that this is a WP:IAR case, because of the unique circumstance of there being no suitable disambiguator for her, rather than attempting to justify the present title as being somehow acceptable. The way I see it, the current title is bad, but it may just happen to be the least bad (as interpreted by a majority of participants in RMs). I could live with that, even though I think personally that something like (born 1963) would be less bad. What I can't live with is this false assertion that the current title is good, and meets our policies, because it really doesn't. Not by the letter of CONSISTENCY, RECOGNIZE and NATURALDIS anyway.
But either way, let's not throw the baby out with the bath water and start rewriting policies because of this. Even if those policies don't work in this one instance that's not a reason to change them. I still maintain my assertion that if Sarah Brown were a famous mathematician, and that's why she was famous, we wouldn't even dream of calling her Sarah Jane Brown, there'd be an overwhelming consensus for Sarah Brown (mathematician), and the policies and precedent would support that. Thanks  — Amakuru (talk) 23:07, 4 March 2018 (UTC)
Wbm1058, agreed. Apples and oranges. That’s why I didn’t compare them. I just gave an example of someone “commonly called” by a certain name. Let me put it this way: If SB is commonly called SJB, just how much more obscure would the sourcing have to be for her to NOT be “commonly called” SJB? Did you know not one single book refers to her this way? Not one! How is that “commonly called”? This is not a policy interpretation issue. There is no reasonable way to interpret “commonly called X” as referring to someone never called X in books, magazines or reliable news sources. Shirley M. Jones is totally different. The main article referenced in that article uses her middle name - not even one SB article reference uses J or Jane. —В²C ☎ 07:43, 5 March 2018 (UTC)
  • Folks... this really isn’t the place to reargue the move.... what is important in this discussion is that there were several options available, ALL of them backed by policy provisions. What made this case so difficult was that we (as a community) could not agree on WHICH policy provision outweighed the others. Each of us had (and still have) opinions on that. My point is this: It wasn’t that we “ignored the rules”... it was that we couldn’t figure out WHICH rule to follow. Blueboar (talk) 23:21, 4 March 2018 (UTC)
  • Born2Cycle... this really isn’t the place to reargue the move..... There, fixed that for you, Blueboar. --Calton | Talk 03:12, 5 March 2018 (UTC)
    • Others keep bringing up the move and you’re blaming me? Why? —В²C ☎ 07:22, 5 March 2018 (UTC)
STOP - My comment was directed at everyone. Blueboar (talk) 08:17, 5 March 2018 (UTC)
  • Born2Cycle: you opened -- and have been prolonging this bitchfest. You know, your normal behavior.
  • Bluboar: Except, of course, you're wrong. The issue was settled, and there is basically one editor "rearguing the move". Hint: his name begins with "B" and ends in "orn2Cycle". --Calton | Talk 08:57, 5 March 2018 (UTC)
And the rest of us have been responding to B2C... in detail... thus continuing the “bitchfest” in the other direction. I am asking us to stop.
B2C started this in an attempt to make a broader point about closing.... we don’t have to agree with that broader point, but we can discuss that broader point without focusing on (and rearguing) the Sarah Brown case. Blueboar (talk) 11:35, 5 March 2018 (UTC)
Exactly, and I regret getting sucked into the SB aspects. That said, this subsection has been revealing to me. I didn't think anyone interpreted "commonly called X" to apply to someone never referred to as X in any of the extensive sources used in the article about the subject, or in any reliable books or news sources. --В²C ☎ 16:30, 5 March 2018 (UTC)

The Jerusalem Day example

For anyone who may be interested, this example from 2009 (Talk:Jerusalem_Day#Requested_move) demonstrates what a CONSENSUS overrides "consensus" decision looks like. This one sentence from the close tells it all:

The nays outweigh the yays in number but the arguments in support are based in guideline and those relied on in opposition are in large part outside of guideline; were debunked and yet repeated without change; are based in classic examples of fallacious arguments we even have pages here describing (often in the context of deletion arguments); and most critically, pertinent evidence was provided which was never met by any counter evidence.

I think it's likely that this wise close by Fuhghettaboutit averted multiple repeated attempts to move and its place in the list above. There was one more attempt to move back, in 2016 (Talk:Jerusalem_Day#Requested_move_11_January_2016), but it was shutdown by "consensus" as well as CONSENSUS, which is exactly what I see happening every time CONSENSUS is recognized to trump "consensus" like this. --В²C ☎ 00:38, 3 March 2018 (UTC)

  • I don't think we can really compare the Jerusalem Day example and the Sarah Brown example... the JD move hinged on a very simple question: was there a COMMONNAME or not? Once it was determined that there was, everything boiled down to policy based arguments vs non-policy based arguments. It becaame fairly easy to close. In the SB example, however, we had policy based arguments vs competing policy based arguments. For that article, it was determined that there was a COMMONNAME... but we could not use it because it was ambiguous. The endless RM discussions were about what to do next... yet even here, the discussions were policy based... we had to keep revisiting the issue because there were disagreements over how to interpret policy (it essentially boiled down to a disagreement over how to disambiguate - something that the community disagrees on, and which changed from RM discussion to RM discussion, making it very difficult to close). Blueboar (talk) 15:32, 3 March 2018 (UTC)
  • Agreed. They can’t be compared. Note that no comparison was made, so I’m not sure why you’re pointing this out. It’s simply an example of an RM decision where the closer found CONSENSUS of the community to be in support even though the “consensus” of the participants opposed. —В²C ☎ 12:21, 4 March 2018 (UTC)
My apologies... since you posted the JD example right after a lot of discussion of the SB example, I thought you were trying to draw a comparison. Blueboar (talk) 12:40, 4 March 2018 (UTC)
The previous section - comparing complexities and suitability to algorithmic approaches of title decision making and decision making while driving was also not about SB, though SB was raised as an example and discussed. —В²C ☎ 12:59, 4 March 2018 (UTC)

Back to the broader point

Perhaps against my better judgement as at this point my confidence in settling this is shattered...

...the closers deferred to the blatant NPOV-violating opposition that incorreclty (sic) claims "(name redacted)" to be WP:NATURALDIS... Again, I fail to understand how using a person's full first, middle and last name as indisputably documented and confirmed by primary sources expresses a "point-of-view" about that person. Titling a biography using a person's own name is about as neutral as you can get, with perhaps very few exceptions. In contrast, when a person is known for A, B, C and D we are expressing a point-of-view about that person when we title it with parentheticals like (A), (B), (C), (D), (A and B), (A and C), (A, B and C) or (A, B, C and D).

  • All encyclopedic content on Wikipedia must be written from a neutral point of view (NPOV), which means representing fairly, proportionately, and, as far as possible, without editorial bias, all of the significant views that have been published by reliable sources on a topic.
  • A good Wikipedia article title is no longer than necessary to identify the article's subject and distinguish it from other subjects.

How do we balance this conflicting advice and have an article title that is both concise and NPOV? I can't think of a better way in a BLP than to just use their full name.

I think I hear Blueboar (two subsections above). Try to keep this section theoretical, as specific examples aren't helping with understanding this. – wbm1058 (talk) 15:05, 5 March 2018 (UTC)

Balancing the various goals laid out at WP:AT is often difficult. We intentionally have not said which goal takes precedence over the others (although, in practice, we do tend to give more weight to Recognizability, as determined through COMMONNAME... but even then there are exceptions). B2C is not wrong in saying that that closers should pay more attention to policy based arguments (what he calls CONSENSUS) over simple !votes (what he calls "consensus")... but his argument is incomplete, because there is no guidance on what to do when the various sides in a move debate all have policy based arguments. Often, the best a closer can do is determine which policy based argument has the most support (as far as that specific article/topic is concerned). To make thing harder, the support for any one policy based argument can shift when there are multiple RM discussions about the same article title. A LOT depends on who shows up to discuss it. In that context, counting heads may be the best we can do. Blueboar (talk) 15:40, 5 March 2018 (UTC)
Not sure how any of this gets to the broader point, which I don't even see touched on here. Anyway, I apologize for my poor wording. The "NPOV-violating opposition" refers to those who are opposed to the "wife of ..." disambiguation. There is no basis in policy or usage in reliable sources to oppose this disambiguation - the only basis is a point of view about that wording - not a neutral point of view since it is the predominant way she is described in reliable sources. As near as I can tell, the claim that SB is "commonly called" SJB and is therefore NATURALDIS primarily comes from this NPOV-violating opposition, apparently because they feel much more strongly about not having that "wife of ..." disambiguation then whether use of "Jane" actually meets the NATURALDIS "commonly called" criteria. I hope that clears it up. --В²C ☎ 17:31, 5 March 2018 (UTC)
So it is found that (A) is the predominant disambiguation/identifier used in sources. That doesn't immediately lead to (A) being a NPOV title, because (A) alone doesn't include all of the significant views published about the subject, if a minority of sources identify the subject as (B), (C) or (D). – wbm1058 (talk) 17:55, 5 March 2018 (UTC)
I'm not saying any particular title is an NPOV title. I'm saying a certain POV objection/argument to a particular disambiguation of a title violates NPOV, because that POV has no basis in a neutral assessment of views as expressed in reliable sources. If there were cited opinions expressed in reliable sources about the inappropriateness of describing people as "wife of ..." or "husband of..." when their spouses are better known, then there might be an NPOV objection/argument to the "wife of..." disambiguation. But, as far as I know, this POV is not supported in sources; certainly have not seen anyone cite any such support. Anyway, that's why I refer to those who oppose the "wife of ..." disambiguation as "the NPOV-violating opposition". I'll clarify my original statement accordingly. --В²C ☎ 18:24, 5 March 2018 (UTC)
We have a tradeoff between the iffy NPOV of a parenthetical title and the iffy "commonness" of a first-middle-last-name title. In that case, if you give equal weight to each of those criteria, then the fall back when there are valid arguments for both may be counting raw !votes. – wbm1058 (talk) 18:20, 5 March 2018 (UTC)
That title with an NPOV-violating objection to its disambiguation was not the only alternative to the UNnaturally disambiguated status quo title being considered. I just think it was important for the closers to recognize and understand the dynamic and effect of the NPOV-violating objection to the "wife of..." disambiguation in the discussion - I don't think they did. This is why I keep saying I wish the closers had looked deeper, and I think they had the duty to do so, to determine actual WP:CONSENSUS. --В²C ☎ 18:28, 5 March 2018 (UTC)

I think the discussion here has run its course, as it's getting repetitive and we can't keep a high-level discussion about (A) from degenerating into something more specific.

FYI. Discussion continues at Wikipedia talk:Disambiguation#Criteria for determining whether someone is "commonly called X" for WP:NATURALDIS. – wbm1058 (talk) 13:14, 6 March 2018 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Requested_moves/Archive_30&oldid=1088306842"