Wikipedia:Village pump (proposals)/Archive 163

Refbegin and refend templates
These templates shrink the size of the reference material (cites, references, bibliography, etc.) at the bottom of an article, mimicking the format used by many academic journal and books for this type of stuff. Not bound by the limitations of paper and the corresponding need to cut printing expenses, do these actually add any value to articles on Wiki? I would argue not and I believe that they actually impose a cost on visually impaired readers.

The guidelines in MOS:SMALLTEXT in the MOS:ACCESS page state: "Reduced or enlarged font sizes should be used sparingly", but I believe that using refbegin and refend should not be considered as falling within that category. Footnotes, etc., for most articles are generally fairly minimal, but I've seen Featured Articles with over 200 footnotes and dozens of books and journal articles cited so they can actually be pretty substantial in high-quality articles. Why are we making them harder to read? What value are we adding by doing this?

What would be the downside of eliminating refbegin and refend entirely? The only thing that I can see is that the formatting of some sections will revert back to the baseline format as the additional parameters controlled by those templates are column number and hanging indents. I feel sure that some enterprising programmer can figure out a way to control those parameters outside the reflist template for those editors enamored with those formats. There may well already be such things already being used, although I wouldn't know because I don't about either of those things. Thoughts, comments?--Sturmvogel 66 (talk) 21:50, 29 October 2019 (UTC)
 * See refbegin and refend Wug·a·po·des​ 21:59, 29 October 2019 (UTC)
 * We could probably just change MediaWiki:common.css so that the font size is 100% rather than removing a widely transcluded template. Wug·a·po·des​ 22:02, 29 October 2019 (UTC)
 * True, but is that actually a good reason to keep it? Why have a template that's actually not doing anything? Seems rather inelegant and a waste of processor time (even as cheap as that is nowadays). While I don't think that it would take long to add a task to remove them to a bot, I'll concede it might take a while to remove them from all the pages that it's used on.--Sturmvogel 66 (talk) 23:57, 29 October 2019 (UTC)
 * It also adds columns and hanging indents if specified (see the documentation at refbegin). If the only thing objected to is the font size, we don't need to create busy work when our problem is resolved by changing 90% to 100% at MediaWiki:common.css. Consensus for that change can be built here, but deleting or merging a template should be done at WP:TFD as Pppery points out. However unless there's another better template that creates ref columns and hanging indents, it'll be hard to develop consensus to merge or delete (see WP:TFD #2). Wug·a·po·des​ 04:13, 30 October 2019 (UTC)
 * Actually, even better, it uses Template:Refbegin/styles.css for its css which any template editor can change. If there's consensus in a couple days place Edit template-protected on the template talk with a link to this discussion, or ping me and I can do it. Wug·a·po·des​ 04:23, 30 October 2019 (UTC) Oh wow even better, there's an undocumented parameter that lets the list be full size rather than 90%. We can just swap the default behavior and make small text opt-in. Wug·a·po·des​ 04:26, 30 October 2019 (UTC)
 * I would support swapping the default behavior of the template. Parsecboy (talk) 16:07, 30 October 2019 (UTC)
 * While the purist in me objects to such a lack of elegance, the practical side says "whatever works easiest, baby".--Sturmvogel 66 (talk) 16:51, 30 October 2019 (UTC)
 * As a Wikipedian with ageing eyes I "20 mule team support" the move to a 100% font size :-) MarnetteD&#124;Talk 22:08, 29 October 2019 (UTC)
 * This should be at WP:TFD, not here. * Pppery * it has begun... 00:05, 30 October 2019 (UTC)
 * We should probably have size reductions as a choice in preferences, eg some skin for those that have trouble reading small text, or a preference option, and another that behaves like the current allowing smaller text. Sure you could use a custom .css, but that is beyond most people's capability to write. Whenever I see an unbalanced tag I remove it. It is quite often used in tables, or infoboxes to specify a date or some qualification. Graeme Bartlett (talk) 00:13, 30 October 2019 (UTC)
 * Leave things be; they've been good enough since 2006 and shouldn't be a matter of individual caprice. Keith-264 (talk) 15:46, 30 October 2019 (UTC)
 * This is not an argument; that you've done something one way for a decade is not evidence that said thing is good (or bad); it is merely evidence that you've done the thing that way. I'll try asking here: what benefit does making text smaller provide to readers? Parsecboy (talk) 16:07, 30 October 2019 (UTC)
 * @ Parsec: who made you the judge? I'll humour you by asking a simple question. "How many people have complained that they can't read bibliographical details under refbegin-refend?" Regards Keith-264 (talk) 09:48, 31 October 2019 (UTC)
 * Anyone with a fundamental understanding of logic can tell you the same. It would perhaps shatter your mind the number of times in an average work week where I'm confronted with the argument "but we've always done it this way" and have to repress the urge to respond "well that ain't the damn policy, is it?". And as for your ridiculous counter (as if you imagine there to be some complaint department that tracks such things), if you'd bothered to read this very discussion, you'd see that some here have complained. Parsecboy (talk) 12:45, 31 October 2019 (UTC)

@Parsec, the question is "How many people have complained that they can't read bibliographical details under refbegin-refend?" do you have an answer? Regards Keith-264 (talk) 14:51, 31 October 2019 (UTC)
 * Not much concerned about how it is done, but I see no benefit in small text. It is hard for some of us to read. &middot; &middot; &middot; Peter Southwood (talk): 16:26, 30 October 2019 (UTC)
 * The size change that refbegin makes is also made across the board for all references using &lt;references/>. If all references have consensus, then so does refbegin. If we really want to have this discussion, I expect you should have a full-on RFC changing the default size for references. I anticipate no-consensus. (I question whether the style switch for size in refbegin is valid--we should limit style variation on this point.) --Izno (talk) 16:34, 30 October 2019 (UTC)
 * You're probably right, but I'm trying to get a feel for the arguments against. Right now they seem to be mostly IDONTLIKEIT.--Sturmvogel 66 (talk) 16:46, 30 October 2019 (UTC)
 * And nobody seems to be engaging the accessibility guidelines.--Sturmvogel 66 (talk) 16:53, 30 October 2019 (UTC)
 * 90% is the understood minimum size on Wikipedia and was arrived at some time ago by quite a bit of hub-bub precisely because it was deemed to be the best consensus between accessible and inaccessible but preferential/lots of references in limited space. --Izno (talk) 01:19, 31 October 2019 (UTC)
 * Hi, I was trying to find that discussion without luck. It would certainly have a huge bearing on this discussion. Regards, Cinderella157 (talk) 21:02, 1 November 2019 (UTC)
 * This discussion has a decent summary of the early days for referencing specifically. Here's the 2010 discussion making &lt;references/> size consistent with reflist (smaller), so it must have happened somewhen inbetween. --Izno (talk) 02:33, 2 November 2019 (UTC)
 * I never noticed that before. You can see an example at Andrei Tarkovsky. "Notes" uses &lt;references /> but "Bibliography" uses the refbegin/end pair. The text size is the same between the two. I think I'd have to oppose changing this specific template without wider discussion on reference text size in general. I'm a little more optimistic about finding consensus; I think the accessibility point is an important one, and don't see a compelling reason to keep it small other than aesthetics. Wug·a·po·des​ 17:31, 30 October 2019 (UTC)
 * But the default way to present references, in the various cite book, cite journal, etc. templates, does not reduce the size. In most articles, the size of the full references is 100%, so why are we going out of our way to reduce the size of some of them? Parsecboy (talk) 19:15, 30 October 2019 (UTC)
 * Those do not decrease their font-size precisely because it is known they will predominantly appear inside reflist/refbegin/&lt;references>; no, their use as in a bibliography or similar is the predominant appearance. And, errors/maintenance messages that appear in these templates  decrease in size (95%). --Izno (talk) 01:19, 31 October 2019 (UTC)
 * Do you have any evidence for that? For either, actually; the creation of the cite templates predate either of our editing here, and earlier versions (like book reference) are even older. In the early days, there were relatively few footnotes and most references were simply in bulleted lists (all that to say that neither of us were around for the discussions over these templates, and even if what you say about the predominance of one formatting style is correct, you ought not confuse how we do things now with why things were set up originally). As for error messages in the templates, I don't think you're right; see here for instance. Parsecboy (talk) 12:45, 31 October 2019 (UTC)
 * , now long, long deprecated, does not appear to have ever specified font-size. Beginning with, the rendered citation was wrapped in a  tag.  The descendants of that template and all of the other cs1|2 templates do not modify font-size except for the rendered subscription- and registration-required annotation (now deprecated and will be removed) and the value assigned to format.  For these parameters, font-size is set to 95% in Module:Citation/CS1/styles.css.  All other font-size for these templates is inherited from the enclosing block.  In this case,  font-size is specified in MediaWiki:Common.css and  font-size is specified by Template:Refbegin/styles.css.  cs1|2 error messages are wrapped in  tags (not sure where that class is defined – here, I think).  Because the   class makes big red error messages , css in Module:Citation/CS1/styles.css resets the cs1|2 error message font-size to 100%, the same size as the text used in the rendered citation.  Thereafter, cs1|2 font-size for the citation-proper and any error messages is controlled by enclosing markup.
 * —Trappist the monk (talk) 16:57, 31 October 2019 (UTC)
 * For illustrative purposes, the quantity of articles using a CS1/2 template is ~3.9m, which is an absolute majority of the current ~6m articles. The quantity of articles using a CS1 template and using reflist is in the realm of 3.6m. It's another 0.2m or so using &lt;references/> and CS1. I daresay that's a convincing ratio of all articles that are using something with small text on it. As for not being here, you can see above where/why the text got small. As for "we've always had it small", you can also see above that is not the case in those discussions. (I did not make this argument, nor in fact did I argue for one side or the other.) As for CS1/2, no, I can basically guarantee that text was never changed because it would clearly have fallen afoul of WP:ACCESS, because a reflist or similar is where the majority of CS1/2 citations are. (I can get into position territory here but I'll decline in the interest of supplying information :).) --Izno (talk) 02:50, 2 November 2019 (UTC)
 * Aye, but those searches don't tell us what you think it does. On the first page of results, I see the Cruiser article, which formats its references the way I was talking about - short cites in the reflist section and full references at 100% size. Parsecboy (talk) 09:15, 2 November 2019 (UTC)
 * Why would the number of people complaining be relevant? If the size of the text is a problem to some it is a problem worth looking into. The other side of it is what advantage does the smaller text provide? &middot; &middot; &middot; Peter Southwood (talk): 15:03, 31 October 2019 (UTC)
 * Because Keith doesn't actually want a debate; he wants to stonewall and this nonsense is classic sealioning. Parsecboy (talk) 18:27, 31 October 2019 (UTC)
 * Sturmvogel asserts "I would argue not and I believe that they actually impose a cost on visually impaired readers" I would like to debate facts not assertions. I think one person so far has endorsed Sturm's view. Do you struggle to read biblio details? Keith-264 (talk) 15:08, 31 October 2019 (UTC)
 * Yes, one person in this unpublicized discussion says that it's a problem for them. So, at the very least, one reader is disadvantaged by the current format. That's a issue because that one person stands for an unknown number of other readers who aren't aware of this discussion. Let me turn your question around; how will you personally be inconvenienced if the format is changed to 100% text? Other than aesthetically, that is, 'cause that appears to be at the foundation of your argument, however much you cloak it in "that's the way that we've always done it". That's logically fallacious and does not stand when even a single person has admitted readability problems because of the smaller text. You need to address the accessibility guidelines, which are the basis for my entire argument, but you have entirely failed to engage with them thus far. How and why do you believe that the current format for refbegin/refend do not fail the guidelines? It's a simple question, deserving of an direct answer.--Sturmvogel 66 (talk) 16:06, 31 October 2019 (UTC)
 * Still waiting for an answer.--Sturmvogel 66 (talk) 10:18, 2 November 2019 (UTC)


 * I too find small text unhelpful (at best) and downright obstructive much of the time. My eyesight is quite good for a man of my age (49), or so my optician tells me. I don't need glasses to read most books. DuncanHill (talk) 16:11, 31 October 2019 (UTC)
 * Two people say it's too small and one infers that many others do too; I think we need something a little more scientific before accepting a change to the status quo. PS I'm a dashing 57. Keith-264 (talk) 16:16, 31 October 2019 (UTC)
 * In a discussion that is not publicised, and does not mention text size or accessibility in the header. "I can read it so it isn't a problem that we should do anything about" is not a great argument. DuncanHill (talk) 16:24, 31 October 2019 (UTC)
 * Isn't the village pump a place for publicising something? If not, get off your backside and publicise it; show me how and I'll help. This is beginning to look like pathetic excuses on (poorly focused) stilts. PS I've been short sighted since I was an early teen, read with varifocals and have never had trouble reading reduced scripts. I haven't come out against a change, merely a capricious one. Did I mention that I was a dashing 57? I'm also debonair. On a technical point, does it have to be all or nothing or can Wiki be arranged for individual preference? Keith-264 (talk) 16:55, 31 October 2019 (UTC)
 * Does Parsec actually have a point or is he whining again? Keith-264 (talk) 19:40, 31 October 2019 (UTC)
 * And here we are, again, trying to derail the conversation with personal attacks. Your stonewalling is pretty transparent, Keith; drop it, or we'll be heading to ANI. Parsecboy (talk) 11:48, 1 November 2019 (UTC)
 * Yet again you claim the victim role and try to frame the debate as hostile; if you don't like retaliation, stop provoking. Simples. I'll set the example. If you make a substantive point I will reply but I will take no more notice of the extraneous comments. My question was simple, "how many people find the biblio details hard to read?" Two or three so far. I suggest WP:STICK Keith-264 (talk) 13:45, 1 November 2019 (UTC)
 * What you're doing is classic WP:SEALIONING; your question is BS and you are well aware of that fact. Answer this. Parsecboy (talk) 14:10, 1 November 2019 (UTC)
 * The number of people complaining is a measure of the necessity of a change, particularly when there is a lack of consensus. This was perfectly civil but when I mentioned it here  you got uncivil rather quickly, instead of waiting for other editors to venture their opinions like me. Keith-264 (talk) 14:22, 1 November 2019 (UTC)
 * How many people have complained somewhere besides this thread that you or I don't know about? How many people have had trouble reading the print and haven't said anything? What you're asking is an unanswerable question, and I'm sure you know that. Oh, and here's a thought for you: if in this short discussion, a few people have complained about it, how often do you think it's a problem for the readers who will never see this discussion to tell you they also have trouble with small text?
 * As for the rest, post a diff where I said something uncivil. If you can't handle being called out for dodging questions, maybe try answering them. And if you don't want to be accused of stonewalling, maybe don't engage in behavior that an objective person might reasonably describe as stonewalling. Parsecboy (talk) 14:37, 1 November 2019 (UTC)
 * Why don't you ask around like I did? I thought that after what you disclosed on the Tel el talk page asking on the milhist board was your next step. I got fed up waiting and did it for you. Look how you responded. I humour you here by answering your loaded question and you write "how often do you think it's a problem for the readers who will never see this discussion"? Why don't you do the work like I did on the milhist board, instead of sniping? Keith-264 (talk) 16:03, 1 November 2019 (UTC)
 * Um, why do you seem to think that Sturmvogel and I are the same person? This is the second time you've conflated the two of us. (And no, you have yet to respond to any question I've seen directed your way [by me or anyone else] in a direct manner; do you see why I label this behavior as stonewalling? Do you see how this is clearly unproductive on your part?) Parsecboy (talk) 16:22, 1 November 2019 (UTC)
 * Your presumption in trying to be judge and jury in your own cause does you no credit. I suggest that you change your approach. What do you want re: refbegin refend? Keith-264 (talk) 17:49, 1 November 2019 (UTC)
 * It would be helpful if you responded to points made, though it seems you have no interest in an actual debate, despite your repeated utterances to the contrary. I suppose I ought to stop trying to squeeze blood from that particular stone. I'll answer your question with one of my own: why do you think yourself entitled to answers when you refuse the same to others? Parsecboy (talk) 18:07, 1 November 2019 (UTC)
 * Propose renaming section - I suggest "Keith-264 derails all attempts at debate". It still won't mention font size or accessibility, but it would be more accurate. DuncanHill (talk) 18:23, 1 November 2019 (UTC)
 * I suggest you get a life; as for PSB he's still sulking so I'll leave it there. Keith-264 (talk) 19:10, 1 November 2019 (UTC)
 * I truly don't care whether the references have  or  . Somebody else can vote on that. But I do feel strongly that any templates that allow customizing it on a per-page basis should have that feature removed. ―cobaltcigs 05:37, 2 November 2019 (UTC)
 * Why, though? Lots of things are customized on a per-page basis, including most things to do with references. Why is this specific thing different? Parsecboy (talk) 15:05, 2 November 2019 (UTC)

So let's suppose the following: Both users would be rightfully pissed to have their settings nullified. ―cobaltcigs 18:23, 2 November 2019 (UTC)
 * specifies a default size of  for references.
 * overrides it to  because she just fixes spelling and doesn't care about refs.
 * overrides it to  because he's hard of seeing and often clicks the wrong things by accident.
 * Both users independently stumble upon  which contains some crap like  (based on a 3–1 vote by members of some WikiProject that neither of them (and none of us) have heard of).
 * That's not what we're talking about. The idea is to swap the default behavior of the templates so that the reduced size is opt-in. Parsecboy (talk) 12:42, 4 November 2019 (UTC)

Apropos my comment above, I'm not wasting any more time on this; if anyone wants to change the status quo, the burden is on them to make a case. No-one has so the matter rests. Regards Keith-264 (talk) 12:04, 2 November 2019 (UTC)
 * That you refuse to see the argument that several of us has advanced is irrelevant (and only goes to further demonstrate your bad faith here); it's really quite simple: the size reduction does zero good (as you yourself have tacitly admitted by refusing to provide any benefit to it) and it causes harm to some readers. That's all we really need to justify the change. Parsecboy (talk) 15:05, 2 November 2019 (UTC)
 * From what I can see, the reduction in size is applied, either directly or indirectly to pretty much all of what is considered "non-readable prose" - ie captions, TOC, info boxes and references etc. In the case of reference templates, they are intended to be used with with RefBegin, which does more than just reduce the size of the text. So, there is more than just one windmill on the field of battle.  If one perceives size to be a problem, then the solution lies outside of EN WP (at MediaWiki) but any change will affect every Wiki project?  Consequently, this is probably not the place to argue the point without involvement of all of the (potentially) affected stakeholders.  I would also suggest that an "opt out" option to then make everything the same size might be an equally valid alternative to the "opt in" option being suggested. Another alternative might be to add a toggle where the text appears. Yet another, we could scale everything up by 111% so that 90% would then be equal to the current normal text size. I also just noticed that the default editor also uses a "reduced" font size. Regards Cinderella157 (talk) 22:37, 8 November 2019 (UTC)
 * Reference text size style is specific to the English Wikipedia. It's specified in MediaWiki:Common.css which is a local page in the MediaWiki namespace. The relevant css is the reflist class which mw:Extension:Cite uses so that each project can specify its own styling. Wug·a·po·des​ 07:49, 9 November 2019 (UTC)
 * Thankyou, but is that also true of all of the other cases identified? Regards, Cinderella157 (talk) 08:03, 9 November 2019 (UTC)
 * PS I take it then, that no other wiki platforms use MediaWiki:Common.css? Cinderella157 (talk) 08:06, 9 November 2019 (UTC)
 * I'm sure they do, but they use their own copy. We use https://en.wikipedia.org/wiki/MediaWiki:Common.css, the Chinese Wikipedia uses https://zh.wikipedia.org/wiki/MediaWiki:Common.css etc. Phil Bridger (talk) 08:13, 9 November 2019 (UTC)
 * A change to the reflist class wouldn't change the other instances of reduced font size that you mention. Captions, TOC, and infoboxes use their own CSS classes. Changing the definition of the reflist class would only affect text inside refbegin and refend tags or generated by (as a page mover) when acting move requests here: Category:Wikipedia files requiring renaming.  -  FlightTime  ( open channel ) 20:05, 21 November 2019 (UTC)
 * Support per above. Could we also have a help page that clearly explains when a redirect should and should not be suppressed? --Guy Macon (talk) 21:06, 21 November 2019 (UTC)
 * Support - Part of the rationale on Commons was that Commons didn't have any page mover, and so had no user group whatsoever that has suppress redirect unbundled from the sysop toolkit. But having said that, it makes no sense that file movers should have to apply for page mover in order to suppress redirects on files, when page mover doesn't have anything to do with files. It appears to be an unintentional interaction between these two rights based on the happenstance of how we unbundled the individual bits.  G M G  talk  21:11, 21 November 2019 (UTC)
 * I posted a while ago at Wikipedia talk:Page mover about the fact that, when moving a page, a note is shown that says file movers (who are also page movers) should suppress redirects by default if the file isn't heavily used. Strongly oppose until the guidance that is shown at Mediawiki:movepagetext follows the policy that the community has established; we shouldn't grant file movers this ability without making it clear when redirects should be suppressed. --DannyS712 (talk) 21:14, 21 November 2019 (UTC)
 * What about Mediawiki:Movepagetext is wrong? Looking at it now it seems to say that redirect suppression should only be done according to policy. Wug·a·po·des​ 00:37, 22 November 2019 (UTC)
 * the relevant part is only shown in the file namespace - use "view source" DannyS712 (talk) 00:38, 22 November 2019 (UTC)
 * Didn't know it did that! On the one hand, given that filemovers have been doing that already, I'd say suppressing redirects in that case is already de facto policy. On the other, I think it's worth making explicit when redirects should be suppressed (Even if there are ultimately IAR cases). Probably worth just adding it to WP:PMRC as #10 and having the MediaWiki page point to it without changing the guidance. Wug·a·po·des​ 00:57, 22 November 2019 (UTC)
 * I went ahead and . Will probably get reverted, but the discrepancy between PMRC and MW:movepagetext will be resolved one way or another. Wug·a·po·des​ 01:20, 22 November 2019 (UTC)
 * Support It's annoying to end up creating redirects whose titles were just errors. It's clear that file movers don't always remember (or can be bothered) to ask for them to be deleted. However, it must be made very clear when to suppress redirects, as per the comment above. Peter coxhead (talk) 21:24, 21 November 2019 (UTC)
 * Is this happening sufficiently to bother? Our FM's can just have PMover access added which includes this permission, no? — xaosflux  Talk 21:54, 21 November 2019 (UTC)
 * Great idea. -  FlightTime  ( open channel ) 22:03, 21 November 2019 (UTC)
 * (or anyone else) why are file mover and page mover separate anyway? Wug·a·po·des​ 23:04, 21 November 2019 (UTC)
 * They grew from separate batches of users that were looking to get things done, both were spin-offs from the admin toolkit. — xaosflux  Talk 23:36, 21 November 2019 (UTC)
 * If it (hypothetically) takes 45 seconds for a sysop at PERM to grant page mover to a file mover (being generous), then all they need to do is save 45 seconds worth of work and it's a net positive. That's a pretty low bar.  G M G  talk  23:18, 21 November 2019 (UTC)


 * Support for the reasons listed only. —Locke Cole • t • c 23:40, 21 November 2019 (UTC)
 * Bundle File movers should just get all the things page movers get. Looking at User_access_levels I think it will give file movers the ability to move category pages, move subpages, suppress redirects, and override the title blacklist. Those all seem useful for file movers and I don't really see why these perms are separate other than as a historical artifact. Wug·a·po·des​ 00:41, 22 November 2019 (UTC)
 * if we want to go this way, just rename "page movers" back to "Extended Movers", give them movefile, deprecate filemover and move all the users to extendedmover. Creating duplicate user groups with the same bundle of permissions isn't a good idea. — xaosflux  Talk 00:49, 22 November 2019 (UTC)
 * Or without needing any programming changes, just add all the members to eachothers groups. — xaosflux  Talk 00:50, 22 November 2019 (UTC)
 * I'd prefer recreating extended mover and deprecating file mover, but I guess either would be fine. Wug·a·po·des​ 00:55, 22 November 2019 (UTC)
 * "page mover" is just local branding for "extendedmover", just FYI. — xaosflux  Talk 02:00, 22 November 2019 (UTC)
 * Support File titles don't seem to be as controversial as article titles. As the permission already implies a level of trust, providing the additional option seems appropriate. Andrew D. (talk) 12:15, 22 November 2019 (UTC)
 * Support, I can see no great reason to keep these separate. BD2412  T 05:37, 23 November 2019 (UTC)
 * Unless I'm very much mistaken, we can't do this without also granting them suppressredirect for non-files, too. At that point, bundling makes more sense. —Cryptic 06:13, 23 November 2019 (UTC)
 * Support per OP and also support consolidating page mover and file mover into one rights group. - MrX 🖋 01:02, 26 November 2019 (UTC)
 * Support, but only with an increase in filemover scrutiny/vetting. This has come up before and the proposal was defeated, because the bar is much lower for filemover than for pagemover.  If you make these permissions essentially equivalent (and there's no magic sauce that limits a filemover's newly-granted redirect suppression ability to only work on files), then the criteria for getting the filemover bit have to go up to match the clue and trust levels we expect of pagemovers.  — SMcCandlish ☏ ¢ 😼  20:08, 27 November 2019 (UTC)
 * Oppose This proposal is either creating doomed-to-be-left-unenforced social rules (if you try to set policy to restrict file-movers who aren't page movers from suppressing redirects from non-files), or extending the file mover user group too far outside of its intended scope (if you don't). Neutral on bundling file mover and page mover into one group. (Neutral on a hypothetical technical restriction of the right to only apply to file pages, which I don't think is possible) * Pppery * it has begun... 20:15, 27 November 2019 (UTC)

Extended discussion
Some statistics:
 * There are 297 page movers
 * There are 405 file movers
 * There are 75 users that are both page movers and file movers

Users:

In regards to the suicide disclaimer debate
I took a look at the debate. Shouldn't we be helping a lot more people if we put in a suicide banner? Regardless if they are wikipedians or not — Preceding unsigned comment added by New340 (talk • contribs)
 * It would help a lot of people to put many different kinds of messages in Wikipedia articles; drug addiction help, anti-suicide messages, domestic violence help, and so on. Where do we draw the line as to what messages are appropriate for a project that is supposed to be an encyclopedia? 331dot (talk) 12:23, 20 November 2019 (UTC)

When it turns in don't try this at home. It will work until it starts getting unneeded, as in its obvious. Another thing, most people who visit Wikipedia don't go on the projects, they just look at the articles so it would be test of we add them.
 * As the person who started the original discussions and was dissatisfied with the actual solution that was implemented, although my personal views are that they should have added a Suicide Disclaimer telling those are suicidal to get help, the hatnote they have now may be the best solution for most wikipedians. If you look at the original discussion and look at Steven Crossin’s conclusion of the debate, this is what he says:


 * ”I then refer to the alternate compromise proposal, to link to Suicide prevention in the hatnote, which was suggested by Doc James and supported by some of the editors that were opposed to the crisis hotline proposal, and also by editors that overall supported a change and commented in this discussion later. While this may not be a perfect solution, it has the most agreement out of all options in this discussion.“


 * Thus, I feel like we should not have a Version 2.0 of this discussion until a few years time when circumstances change, as if we discuss this again after the debate that literally took place just 5 months ago, nothing will come out of it. The majority of the people had already decided this. Neon 11:01, 30 November 2019 (UTC)