From Wikipedia, the free encyclopedia

RFC re changing "should" to "must" in first sentence

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


There has been a substantive change to this widely used template [1] based on a discussion held on a different talk page that did not have wide participation. In order to assess if the change is widely supported by the Wikipedia community at large, I am starting a greater discussion here. The RFC question is:

  • Does the community support the change in this template from "...should normally follow..." to "...must normally follow..." -- Jayron 32 12:06, 21 May 2014 (UTC) reply

Please input your feelings and rationale below:

Support "should"

  1. The old wording "should" better captures Wikipedia's ethos of no firm rules, and of discussion and consensus taking primacy over rules and bureaucracy. -- Jayron 32 12:06, 21 May 2014 (UTC) reply
  2. "Should normally" is better than "must normally" - the latter implies a discrete set of exceptions more strongly than the former. All the best: Rich  Farmbrough16:21, 21 May 2014 (UTC).
  3. I waver on this, but we should probably stick with "should". "Must normally" seems to be a little bit of doublespeak to me. If there are exceptions, then why say "must"? The other factor is that our policies are not really written in an airtight, authoritative manner. This is often intentional. If there is a distinction between guideline and policy, it's fuzzy at best. If I repeatedly make bad CSD decisions after being informed of the problem, I could face personal sanctions. But likewise, if I repeatedly brought a bunch of clearly notable articles to AfD, I'd probably face sanctions as well, even though I'd "only" be violating WP:DISRUPT and ignoring WP:N, both guidelines. One could argue that WP:DISRUPT is miscategorized as a guideline, but even if that's so, it highlights the fact that our current documentation doesn't really reflect a good hard distinction between the two. Gigs ( talk) 20:21, 21 May 2014 (UTC) reply
  4. In my view, "should" is sufficiently strong. "Must", even when paired with "normally", conveys a level of strictness beyond that which actually exists.
    In particular, newcomers ideally should adhere to policies in most instances, but they aren't expected to read and understand all of them before editing. They're encouraged to be bold and do their best, with experienced editors correcting their errors and bringing the relevant issues to their attention. The "must normally" wording could be interpreted to mean that any deviation outside exceptional circumstances (even one stemming from unfamiliarity with a policy) is forbidden, resulting in a chilling effect. It's much better that users dive in and learn from their mistakes. — David Levy 17:42, 22 May 2014 (UTC) reply
  5. Should because WP:IAR is policy and if we write must, then we create circular logic. "You must ignore all rules" and then you must ignore WP:IAR thus you have to follow WP:IAR which then requires you to ignore WP:IAR and so on and so forth. But really because policies need to be fluid and open to interpretation as well as having the ability to be set aside if they are wrong. Policies cannot account for every exception and "should" gives us the room to wiggle.--v/r - T P 19:18, 22 May 2014 (UTC) reply
  6. Second choice after neither, as WP:IAR means "must" would be deceptive at best. —/ Mendaliv/ / Δ's/ 22:37, 22 May 2014 (UTC) reply
  7. Support The use of the word “must” implies that policy should absolutely be followed 100% of the time and that a deviation from policy, no matter how justified, is always bad. This implication goes against such established policy as ignore all rules and Wikipedia is not a bureaucracy, as well as common sense and community consensus. I much prefer the use of the word “should.” The word implies that policy should be followed as a default. However, it is less binding than the word “must” and, when paired with the word “normally”, implies that there are in fact situations when policy should not be followed to the letter. This is much more in line with Wikipedia editing standards. Spirit of Eagle ( talk) 05:46, 23 May 2014 (UTC) reply
  8. Per Jayron32, Rich Farmborough, Spirit of Eagle. Killer Chihuahua 01:16, 24 May 2014 (UTC) reply
  9. Should is clearer. The phrase "must normally" is self-contradictory. -- Ypnypn ( talk) 17:23, 27 May 2014 (UTC) reply
  10. Support per Ypnypn. "Must normally" is an oxymoron, since "must" leaves no room for exceptions. We've created a situation in which this template is functionally meaningless, and the only way to fix it (aside from reverting) is to prohibit rule-ignoring and require all policies to be followed to the letter every time. And why would we want to do that? The good of the project is much more important than following policies to the letter all the time. Much better to revert to a meaningful statement. Nyttend ( talk) 18:03, 27 May 2014 (UTC) reply
  11. Support per David Levy and Eagle. "Must" would not be consistent with one of our pillars, WP:IAR. There actually are a few cases (IAR notwithstanding) where "must" may be appropriate (e.g., obey copyright laws) but these situations can use the word "must" on a case by case basis. Rlendog ( talk) 15:29, 28 May 2014 (UTC) reply
  12. Support - I support the pillar and policy of IAR and the word change weakens this. Carrite ( talk) 17:39, 1 June 2014 (UTC) reply
  13. "Must normally" is a contradiction; "must" implies "always". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:10, 1 June 2014 (UTC) reply
  14. Support just on linguistic grounds. Must normally are juddering against each other: one is high-level imperative; the other works against that. Should is medium-high-level imperative, and idiomatically as well as logically appropriate. Tony (talk) 03:52, 9 June 2014 (UTC) reply
  15. Support should, based on WP:IAR and that Wikipedia does not have any firm rules. Thanks, Lixxx235 Got a complaint? 22:55, 10 June 2014 (UTC) reply
  16. Weak support on pragmatic grounds. I would mark it "second choice," but for the fact that I don't believe that "must normally," which would be my first choice, has any chance of prevailing. "Normally" alone is insufficient. We can muddle along with the status quo just fine. Regards, TransporterMan ( TALK) 12:56, 11 June 2014 (UTC) reply
  17. Support per WP:IAR, and per the fact that policies are not necessarily thinking through all possible conceivable edge cases. Also "must normally" is self-contradictory. No problems to fix in the current wording.-- cyclopia speak! 02:10, 14 June 2014 (UTC) reply
  18. Support should - that's the wording used elsewhere, fits to the no-hard-rules and WP:NOTBUREAUCRACY and to apply using reason and common sense. Markbassett ( talk) 06:53, 14 June 2014 (UTC) reply

Support "must"

  1. Policies carry weight that guidelines do not. Policies include WP:CIVIL, WP:BLP, WP:NPOV, and even WP:IAR. Guidelines include all the other norms (other than essays) that we follow but not as ironclad law. Chris Troutman ( talk) 19:15, 21 May 2014 (UTC) reply
  2. These policies are enforced as a 'must' and this would help greatly. I think making this clear will help reduce disputes on WP by strongly stating that these policies are considered a 'must' with few exceptions. There is always the possibility to change the policy, and there is the piped link to ignore all rules. -- LT910001 ( talk) 05:08, 22 May 2014 (UTC) reply
  3. Support. If it's not must, then it's not a policy, but just a guide. Lugnuts Dick Laurent is dead 12:05, 24 May 2014 (UTC) reply
  4. "Must normally" is not a contradiction, but leaves room for exceptions in less-than-normal cases.  Sandstein  18:27, 28 May 2014 (UTC) reply
  5. Second choice. Our policies may not be applicable to a given situation, but compliance is not actually optional. For better or worse, "should" is actually interpreted as "you don't really have to" by a significant minority of editors. IAR does not permit you to reject NPOV. WhatamIdoing ( talk) 05:58, 29 May 2014 (UTC) reply
  6. It's a policy, not a suggestion. And it contains the necessary caveat of "normally" for exceptional cases. -- Holdek ( talk) 20:54, 31 May 2014 (UTC) reply
  7. This would certainly cut back on the number of new editors baited into WP:WIKILAWYERING, and as a result, likely improve editor retention... — {{U| Technical 13}} ( etc) 19:41, 8 June 2014 (UTC) reply

Support neither

"This page documents an English Wikipedia policy, a widely accepted standard that all editors must normally follow. Changes made to it should reflect consensus."

  1. Fits better "policy is descriptive not prescriptive". If editors don't normally follow, the policy is obviously wrong. The should/must introduces an imperative tone at odds with "community consensus" and "no firm rules". Should/must language begs "or what?". Should/must language belongs with enforceable mediation solutions. -- SmokeyJoe ( talk) 06:18, 22 May 2014 (UTC) reply
  2. Well, I like this suggestion and for the reasons SmokeyJoe gives. (BTW the juxtaposition of "must" and "normally" seems very strained to me). Thincat ( talk) 16:01, 22 May 2014 (UTC) reply
  3. First choice. Policies and guidelines are descriptive. SmokeyJoe is absolutely correct. —/ Mendaliv/ / Δ's/ 22:36, 22 May 2014 (UTC) reply
  4. Second choice. Hadn't thought of this option, but like it. -- Jayron 32 23:48, 22 May 2014 (UTC) reply
  5. Distant second choice. While I agree in principle with the rationale, I'm concerned that this might read as too optional, leading to problems and arguments ad infinitim. Killer Chihuahua 01:17, 24 May 2014 (UTC) reply
  6. SmokeyJoe is correct and his proposal fits WP:NOTLAW best. Andrew ( talk) 10:26, 24 May 2014 (UTC) reply
  7. My choice. I echo "or what?". This has the tone of a good faith voluntary obedience. We are volunteer editors after all, but of course, if we misbehave badly enough someone will call us to account. However, we have no General Statutes law book, such as in state or local government, to drag out and thusly handcuff an editor to drag before a magistrate. Fylbecatulous talk 20:09, 26 May 2014 (UTC) reply
  8. Per SmokeyJoe. -- King of ♠ 05:00, 29 May 2014 (UTC) reply
  9. First choice. I'd also be satisfied with something like "that editors are expected to follow", as that describes not merely the fact that people do follow them, but that you can expect problems if you don't follow them. WhatamIdoing ( talk) 05:53, 29 May 2014 (UTC) reply
    I actually like your suggestion a lot. Count that as my first choice. -- King of ♠ 02:34, 31 May 2014 (UTC) reply
  10. Per SmokeyJoe. Policy should describe common Wikipedia practice and community norms. This is the best wording to suit that. It makes it clear that you should probably follow the rules, but the rules aren't firm and can be changed by consensus. Mz7 ( talk) 03:58, 31 May 2014 (UTC) reply
  11. This one; "must" and "should" are both implying an obligation, with "must" implying that obligation more forcefully; however, it is more an expectation that those aware of policies will follow them rather than an obligation. Bending, breaking, or ignoring a policy in itself is not grounds for a sanction - it is the circumstance, the reason, and/or the continuance that concerns the community. If this option gains consensus, then it would be appropriate to update wording at Wikipedia:Policies and guidelines. SilkTork ✔Tea time 10:43, 31 May 2014 (UTC) reply
  12. Support because it avoids the problem entirely and I think it is a more accurate description of the way that policies ought to be viewed. (would choose should if this is not accepted, but definitely do not want must) Zell Faze ( talk) 19:58, 1 June 2014 (UTC) reply
  13. I prefer the "editors are expected to follow" version, but this is fine. Neither should nor must really do much for me. There is an expectation that editors will follow policies, however. It makes sense to describe policy in terms of the community's acceptance, and it also makes sense to warn users that they will face opposition when they choose to ignore it. NinjaRobotPirate ( talk) 23:22, 4 June 2014 (UTC) reply
  14. Short, elegant and true. It is not something you are forced to do, it is something we all do. - Nabla ( talk) 11:49, 10 June 2014 (UTC) reply
  15. I like this version too. We could even drop the superfluous and possibly inaccurate "all". All the best: Rich  Farmbrough03:08, 16 June 2014 (UTC).
    Agree with the dropping of "all", as superfluous, inaccurate, tending to hyperbolic rhetoric. These tags should be simple and concise, written to help newcomers, not loaded to support majority domination. -- SmokeyJoe ( talk) 03:45, 16 June 2014 (UTC) reply

Threaded discussion

The discussion now exists in the archive Wikipedia talk:Policies and guidelines/Archive 13#Is a guideline different to a policy?. Mz7 ( talk) 20:53, 27 May 2014 (UTC) reply
  • I suggest discarding the "must normally" option at this point. -- SmokeyJoe ( talk) 00:01, 23 May 2014 (UTC) reply
  • Lugnuts wrote: "If it's not must, then it's not a policy, but just a guide." This is precisely the sort of misunderstanding that we need to avoid promoting.
    Both guidelines and policies have exceptions. By the same token, neither policies nor guidelines are optional and subject to deliberate defiance on a whim. No matter which label appears, the advice should be followed unless doing so impedes Wikipedia's improvement or maintenance.
    The actual distinction between policies and guidelines is documented at Wikipedia:Policies and guidelines. "Policies explain and describe standards that all users should normally follow, while guidelines are meant to outline best practices for following those standards in specific contexts. Policies and guidelines should always be applied using reason and common sense." — David Levy 21:52, 26 May 2014 (UTC) reply
  • I'm attracted to the idea that discussions over non-standard behaviour will turn to "Is what this editor is doing good or bad" and opposed to "Is what this editor doing supported by policy". Policy, per se, is not a good reason. Ideally, policy as written, is self-evidently a good idea. Not all policy is written to this standard. Policy, as written, should be informative with regard to practice, and terminology, enabling bystanders to judge whether an editor's behaviour is producing a good outcome. Policy should be subservient to the product, as per Wikipedia:Product, process, policy. -- SmokeyJoe ( talk) 03:12, 27 May 2014 (UTC) reply
    If a policy is written well, applying the advice contained therein will be sensible most (but not necessarily all) of the time. On its own, "because the policy says so" is a poor rationale, but it's helpful to examine why the policy has been written a certain way (i.e. what factors led to such a consensus) and determine whether these reasons apply to the matter at hand.
    In other words, the two questions that you cited aren't mutually exclusive; we should ask ourselves "Is what this editor is doing supported by policy?" and "Is what this editor is doing good or bad?". If the answers don't jibe, we can consider whether this constitutes grounds for revising the policy or for simply making an exception. The mistake is relying solely on whether something is supported by policy. — David Levy 03:44, 27 May 2014 (UTC) reply
  • Yes. -- SmokeyJoe ( talk) 03:50, 27 May 2014 (UTC) reply
  • Agreed. Yet it is often hard to know the "why". I think policy (and guideline) pages would be better server having some kind of "cite your sources" policy. At least pointing to relevant discussions (like this one) so that anyone can get a grasp of the "whys" and the "why nots", and moreover be confident that the current policy text is not just whatever the last editor decided to write down but actually the result of a discussion (and how long, how old, by how many, etc.) - Nabla ( talk) 11:55, 10 June 2014 (UTC) reply
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Suggestion to remove "should" from first sentence

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


During the above RfC a suggested wording change to drop the word "should" may not have been clear. The proposal was this: "This page documents an English Wikipedia policy, a widely accepted standard that all editors should normally follow. Changes made to it should reflect consensus" A later suggestion to also drop the word "all" was supported, but came very late. As such there was no clarity on support for that particular suggestion. So I think it's worth considering the proposed wording changes in isolation from the must/should debate. Is there support/opposition for the following wording:

This page documents an English Wikipedia policy, a widely accepted standard that editors normally follow. Changes made to it should reflect consensus

The words "all" and "should" have been removed, leaving the notice wording neutral, informative and factual, with the only obligatory wording being the final sentence, which is the active part of the notice.

This is set up as a simple support or oppose discussion for this template, though it will have implications for the wording on Wikipedia:Policies and guidelines, so this discussion is linked from Wikipedia talk:Policies and guidelines. 05:10, 8 August 2014 (UTC) SilkTork ✔Tea time 13:00, 23 June 2014 (UTC) reply


Hmmm, a little bit WP:ILIKEIT-y... Forbidden User ( talk) 13:03, 8 August 2014 (UTC) reply
  • Oppose and this should be advertised wider, you don't change policies with discussions on template talk pages without even an RfC. As to the question what happens about 'should' I would point to WP:Policies and guidelines#Enforcement. They are not totally optional. There are consequences and they are spelled out and that is community consensus. Dmcq ( talk) 08:56, 25 June 2014 (UTC) reply
That's a rather strange reason, given that nobody has any plans to promote this template to policy status. However, I'm happy to have more people join the conversation. WhatamIdoing ( talk) 00:13, 17 August 2014 (UTC) reply
  • Oppose How unclear is the present wording? "Editors normally follow" sounds like a trend describtion more than an instruction. This template is used to infrom/instruct users on the function of templates. Forbidden User ( talk) 13:03, 8 August 2014 (UTC) reply
  • Oppose. I cite the "descriptive, not prescriptive" principle frequently. It means that we put things in writing to document what we do (as opposed to doing things because they're written down), not that we must avoid conveying that anything is required. The tag's purpose is to explain that editors should comply with policies in most situations, not to make a "neutral" statement that this typically occurs (with no indication that it's non-optional). I agree with Forbidden User that the proposed wording comes across more as a trend description than it does as guidance. — David Levy 21:04, 8 August 2014 (UTC) reply
  • Oppose The use of the word "should" indicates that there is a strong expectation that policy be followed (except in cases where it is appropriate to ignore all rules). If we remove the word "should", then the description makes policy sound like something that editors just sort of happen to do. This does not do justice to the importance of policy, so the word "should" should stay. Spirit of Eagle ( talk) 04:13, 10 August 2014 (UTC) reply
    • It depends on your perspective. "You should do this–but you don't have to." "People should tell the truth–but they don't." Telling people that all the other editors are doing it, however, is actually a pretty good way to get people to comply. WhatamIdoing ( talk) 00:13, 17 August 2014 (UTC) reply
  • Oppose per Cunard and Spirit of Eagle. The stronger wording should be retained so that it doesn't mislead editors into thinking that policies are completely optional. Otherwise, there is no distinction between policies and guidelines, IMO. Kaldari ( talk) 07:30, 11 August 2014 (UTC) reply
    I'll note that Template:Guideline also contains the word "should" in this context. Its text simply places greater emphasis on the existence of exceptions. Neither policies nor guidelines are optional (in the usual sense). — David Levy 07:54, 11 August 2014 (UTC) reply
  • Oppose  Removing the word "all" is ok, but removing "should" weakens the language.  Unscintillating ( talk) 01:00, 12 August 2014 (UTC) reply
    I agree that the word "all" can be removed. It makes the sentence shorter and more concise without losing meaning in the process. Spirit of Eagle ( talk) 02:16, 12 August 2014 (UTC) reply
  • Oppose - the word "should" is correct - it's weaker than "must" (an absolute requirement), which is clearly contradicted by IAR, but string enough to mean that users are expected to do it for the most part. עוד מישהו Od Mishehu 08:12, 13 August 2014 (UTC) reply
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Post-RfC discussion

Should anything like this come up again, please ping all previous respondents in these RfCs, and myself as well (and anyone else who asks), and list it at WP:Village pump (policy). This looks like trivial copy-editing (and on a template like Template:Wikipedia how-to it might be), but in the WP:PAG context it is not. Such proposed wording alterations deserve careful and community-wide consideration.  —  SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  00:08, 23 June 2016 (UTC) reply

Useless (?) "shortcutoverride" parameter

Is there any rationale for the undocumented |shortcutoverride= parameter? I cannot think of a legit use case, and would just as soon strip it out, so that the code for shortcuts here is precisely the same as that in Template:Guideline. I suspect someone added this to get around the five-shortcut limitation, but this is silly; just use a separate Template:Shortcut. And it's discouraged to display more than five at a time, anyway. Some pages have 20+ shortcuts, but we do not need to "advertise" any but the most common and useful.  —  SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  00:04, 23 June 2016 (UTC) reply

Font size

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Consensus is to have a line break and the lower text be 90% size on {{ Policy}} and related templates. More specifically, the consensus is to use Version D.

Bryan Henderson (giraffedata) ( talk) 03:07, 20 June 2017 (UTC) reply


Should {{ Policy}} and related templates contain a line-break, and if so, what what should the font size for the lower text be. TheDragonFire ( talk) 04:39, 14 May 2017 (UTC) reply

Pre-RFC Discussion

@ Atón: You've changed the font size on 13 important templates, including this one. In my view the new font size of 11.9px fails WP:ACCESSIBILITY, and looks visibly jarring. Would it be possible to solicit further feedback before continuing? TheDragonFire ( talk) 14:39, 10 May 2017 (UTC) reply

I'm sorry to hear that since my intention was to make it less jarring. I think the new font size makes the template clearer to the reader. The jarring effect could be solved by increasing the line height or the minimum margin between the text and the box instead. I'll wait for further feedback. Atón ( talk) 17:54, 10 May 2017 (UTC) reply
All the changes should be reverted and a sandbox set up to show the proposal with before-and-after boxes, followed by one discussion. The tiny type is unacceptable. The line break might be good, but I'd want to think about it. Johnuniq ( talk) 02:14, 11 May 2017 (UTC) reply
I've reverted changes to this template, and to {{ guideline}} and {{ essay}} (those being the the most high visibility). Atón's changes have been moved to {{ Policy/sandbox}}. I'll leave the other changes in place pending further discussion. Below is a comparison of original, Atón's version and Johnuniq's version.

Version A

Version B

Version C

TheDragonFire ( talk) 03:42, 11 May 2017 (UTC) (Added version numbering - Tamwin ( talk) 19:27, 16 May 2017 (UTC)) reply
The font size was too tiny, I agree. But a clear distinction between the principal statement and the explanation helps navigate the template, specially in the cases of {{ guideline}} and {{ essay}} where the explanation is longer. Just a line break doesn't create enough contrast, in my view. I've corrected the font size (from 85% to 90%) and increased the top and bottom margin. It would look like this:

Version D

Atón ( talk) 08:29, 11 May 2017 (UTC) (Added version numbering - Tamwin ( talk) 19:27, 16 May 2017 (UTC)) reply

RFC Discussion

  • The samples are nice but they don't convey the impact of the change. When I first noticed it, the guideline I was looking at made the small-text line invisible. The problem is the normal banner blindness where everyone knows to skip over messages in a box at the top—particularly lines in tiny type. A wonderful layout may look good, but if the text is unimportant it would be better to delete it. Johnuniq ( talk) 10:58, 14 May 2017 (UTC) reply
    • I like that "This page is X" pops up. It makes it very easy to spot the 'X' word, which is the most relevant. I don't think the lower text is unimportant, it's helpful for new users, but the "This page is X" statement is enough information for most users. The 85% font size was too small, I agree, but 90% looks OK to me. Atón ( talk) 12:18, 14 May 2017 (UTC) reply
PD: Deleting the explanation altogether is not a bad idea, as Johnuniq has explained. A link to Wikipedia:Policies and guidelines is enough.

Version E

Are there objections to this solution? Atón ( talk) 17:28, 16 May 2017 (UTC) (Added version numbering - Tamwin ( talk) 19:27, 16 May 2017 (UTC)) reply
I object. They look empty, and there really should be a short version on the page. I don't see why we shouldn't go with as small a modification of the current version as possible. Tamwin ( talk) 19:29, 16 May 2017 (UTC) reply
Version C, D, or A, in that order of preference. These options are the closest to the original in content and meaning, and the least visually jarring. Strong oppose versions B and E, as these look bad/ do not convey the meaning of the original. Tamwin ( talk) 19:35, 16 May 2017 (UTC) reply
  • Version D looks good. It makes clear that the second line eludicates on the 'headline' (which can be insufficient to new users on its own), but everything is nice and readable. I would object to E. -- SubSeven ( talk) 05:22, 18 May 2017 (UTC) reply
  • Version D is my personal favourite. It looks good and is clear. Oppose version A (the original), anything is better. Laurdecl talk 07:47, 18 May 2017 (UTC) reply

Version F

  • Support the change, BCD are good, but I suggest this version F. Having the critical sentence on its own line help it pop out. The key sentence should pop out with a larger font size, instead of fiddling with the text size underneath. (To clarify, I suggest POLICY and GUIDELINE should be style F. Essays and How-To should be be style B, C, or D.) Alsee ( talk) 06:56, 18 May 2017 (UTC) reply
  • Oppose F, the boldness is too much, it distracts from the actual page. Laurdecl talk 07:47, 18 May 2017 (UTC) reply
  • Version D is also my favourite. Atón ( talk) 06:28, 3 June 2017 (UTC) reply
  • Support C or D. Strong Oppose E. After being away from this discussion for a bit, and returning with fresh eyes, I'm warming up to the linebreak. I think a decision should be made for C or D (or a tweaking of either), with reference to the Web Content Accessibility Guidelines. The detail is important, and I don't feel E is appropriate. TheDragonFire ( talk) 06:35, 6 June 2017 (UTC) reply

I've upgraded the templates except for {{ Subcat guideline}}, which is protected. Atón ( talk) 09:04, 13 June 2017 (UTC) reply

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Reverse recent decisions related to line break and font size

I believe that the recent changes to this and related templates make them look outdated. The <br><small> stuff was removed from the mainspace cleanup templates around 2009; the consensus to introduce it to the projectspace templates contradicts precedent. KMF ( talk) 04:08, 23 July 2017 (UTC) reply

Support classic pre-2017 look

Oppose; keep new look

Discussion

  • The established (classic) version for this page is the current version ( 04:21, 23 July 2017). The "small" version is 06:19, 13 July 2017. I support the established version. The small stuff is too finicky and at variance from established styles. If the small text is unimportant, delete it. For this discussion, I don't think the headings are needed. Johnuniq ( talk) 06:00, 23 July 2017 (UTC) reply
  • OMG, look at what's happend to {{ nutshell}}: diff. @ Primefac: Do you really like the result? It looks shocking on my system. I was skimming WP:MINOR and the important information (what is in the nutshell) looks as if it should be ignored—I only looked because I know the nutshell is generally an excellent summary of the point. Johnuniq ( talk) 06:15, 23 July 2017 (UTC) reply
    I'm not strictly opposed to it. There was a TPER related to the above RFC, it was reasonable, and so I made the change. If it's determined that the above RFC should be overturned, I'll probably end up restoring the original version. Primefac ( talk) 11:14, 23 July 2017 (UTC) reply
    I agree with Johnuniq regarding {{ nutshell}}. The point of changing the font size in {{ policy}} and related templates was to make them less wordy by making a distinction between the main statement and the auxiliary explanation. The case of {{ nutshell}} is different. The essential text there is the summary, it shoudn't look small. I don't think the result of the RfC above applies to {{ nutshell}}. Atón ( talk) 15:35, 23 July 2017 (UTC) reply
    Fair point. Self-reverted. Primefac ( talk) 15:39, 23 July 2017 (UTC) reply
  • Oppose reversion: This looks brand new and much cleaner than the previous one. Ups and Downs ( ) 07:33, 23 July 2017 (UTC) reply
  • I have no opinion on the reversion, but if you're going to keep it please don't do it by putting inline CSS in every individual template. Have the underlying mbox template do it, like {{ ambox}} does with |issue= and |fix=. Anomie 01:38, 11 September 2017 (UTC) reply

Has this issue come up before?

An editor recently quoted "Changes made to it should reflect consensus" from this box in support of the proposition that Wikipedia:Don't revert due solely to "no consensus" does not apply to policies and guidelines. This seems to conflict with WP:PGBOLD. I'm wondering whether anyone recalls a discussion of this possible conflict between the text in this template and the policy reflected at PGBOLD. - Butwhatdoiknow ( talk) 16:20, 21 August 2022 (UTC) reply

From Wikipedia, the free encyclopedia

RFC re changing "should" to "must" in first sentence

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


There has been a substantive change to this widely used template [1] based on a discussion held on a different talk page that did not have wide participation. In order to assess if the change is widely supported by the Wikipedia community at large, I am starting a greater discussion here. The RFC question is:

  • Does the community support the change in this template from "...should normally follow..." to "...must normally follow..." -- Jayron 32 12:06, 21 May 2014 (UTC) reply

Please input your feelings and rationale below:

Support "should"

  1. The old wording "should" better captures Wikipedia's ethos of no firm rules, and of discussion and consensus taking primacy over rules and bureaucracy. -- Jayron 32 12:06, 21 May 2014 (UTC) reply
  2. "Should normally" is better than "must normally" - the latter implies a discrete set of exceptions more strongly than the former. All the best: Rich  Farmbrough16:21, 21 May 2014 (UTC).
  3. I waver on this, but we should probably stick with "should". "Must normally" seems to be a little bit of doublespeak to me. If there are exceptions, then why say "must"? The other factor is that our policies are not really written in an airtight, authoritative manner. This is often intentional. If there is a distinction between guideline and policy, it's fuzzy at best. If I repeatedly make bad CSD decisions after being informed of the problem, I could face personal sanctions. But likewise, if I repeatedly brought a bunch of clearly notable articles to AfD, I'd probably face sanctions as well, even though I'd "only" be violating WP:DISRUPT and ignoring WP:N, both guidelines. One could argue that WP:DISRUPT is miscategorized as a guideline, but even if that's so, it highlights the fact that our current documentation doesn't really reflect a good hard distinction between the two. Gigs ( talk) 20:21, 21 May 2014 (UTC) reply
  4. In my view, "should" is sufficiently strong. "Must", even when paired with "normally", conveys a level of strictness beyond that which actually exists.
    In particular, newcomers ideally should adhere to policies in most instances, but they aren't expected to read and understand all of them before editing. They're encouraged to be bold and do their best, with experienced editors correcting their errors and bringing the relevant issues to their attention. The "must normally" wording could be interpreted to mean that any deviation outside exceptional circumstances (even one stemming from unfamiliarity with a policy) is forbidden, resulting in a chilling effect. It's much better that users dive in and learn from their mistakes. — David Levy 17:42, 22 May 2014 (UTC) reply
  5. Should because WP:IAR is policy and if we write must, then we create circular logic. "You must ignore all rules" and then you must ignore WP:IAR thus you have to follow WP:IAR which then requires you to ignore WP:IAR and so on and so forth. But really because policies need to be fluid and open to interpretation as well as having the ability to be set aside if they are wrong. Policies cannot account for every exception and "should" gives us the room to wiggle.--v/r - T P 19:18, 22 May 2014 (UTC) reply
  6. Second choice after neither, as WP:IAR means "must" would be deceptive at best. —/ Mendaliv/ / Δ's/ 22:37, 22 May 2014 (UTC) reply
  7. Support The use of the word “must” implies that policy should absolutely be followed 100% of the time and that a deviation from policy, no matter how justified, is always bad. This implication goes against such established policy as ignore all rules and Wikipedia is not a bureaucracy, as well as common sense and community consensus. I much prefer the use of the word “should.” The word implies that policy should be followed as a default. However, it is less binding than the word “must” and, when paired with the word “normally”, implies that there are in fact situations when policy should not be followed to the letter. This is much more in line with Wikipedia editing standards. Spirit of Eagle ( talk) 05:46, 23 May 2014 (UTC) reply
  8. Per Jayron32, Rich Farmborough, Spirit of Eagle. Killer Chihuahua 01:16, 24 May 2014 (UTC) reply
  9. Should is clearer. The phrase "must normally" is self-contradictory. -- Ypnypn ( talk) 17:23, 27 May 2014 (UTC) reply
  10. Support per Ypnypn. "Must normally" is an oxymoron, since "must" leaves no room for exceptions. We've created a situation in which this template is functionally meaningless, and the only way to fix it (aside from reverting) is to prohibit rule-ignoring and require all policies to be followed to the letter every time. And why would we want to do that? The good of the project is much more important than following policies to the letter all the time. Much better to revert to a meaningful statement. Nyttend ( talk) 18:03, 27 May 2014 (UTC) reply
  11. Support per David Levy and Eagle. "Must" would not be consistent with one of our pillars, WP:IAR. There actually are a few cases (IAR notwithstanding) where "must" may be appropriate (e.g., obey copyright laws) but these situations can use the word "must" on a case by case basis. Rlendog ( talk) 15:29, 28 May 2014 (UTC) reply
  12. Support - I support the pillar and policy of IAR and the word change weakens this. Carrite ( talk) 17:39, 1 June 2014 (UTC) reply
  13. "Must normally" is a contradiction; "must" implies "always". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:10, 1 June 2014 (UTC) reply
  14. Support just on linguistic grounds. Must normally are juddering against each other: one is high-level imperative; the other works against that. Should is medium-high-level imperative, and idiomatically as well as logically appropriate. Tony (talk) 03:52, 9 June 2014 (UTC) reply
  15. Support should, based on WP:IAR and that Wikipedia does not have any firm rules. Thanks, Lixxx235 Got a complaint? 22:55, 10 June 2014 (UTC) reply
  16. Weak support on pragmatic grounds. I would mark it "second choice," but for the fact that I don't believe that "must normally," which would be my first choice, has any chance of prevailing. "Normally" alone is insufficient. We can muddle along with the status quo just fine. Regards, TransporterMan ( TALK) 12:56, 11 June 2014 (UTC) reply
  17. Support per WP:IAR, and per the fact that policies are not necessarily thinking through all possible conceivable edge cases. Also "must normally" is self-contradictory. No problems to fix in the current wording.-- cyclopia speak! 02:10, 14 June 2014 (UTC) reply
  18. Support should - that's the wording used elsewhere, fits to the no-hard-rules and WP:NOTBUREAUCRACY and to apply using reason and common sense. Markbassett ( talk) 06:53, 14 June 2014 (UTC) reply

Support "must"

  1. Policies carry weight that guidelines do not. Policies include WP:CIVIL, WP:BLP, WP:NPOV, and even WP:IAR. Guidelines include all the other norms (other than essays) that we follow but not as ironclad law. Chris Troutman ( talk) 19:15, 21 May 2014 (UTC) reply
  2. These policies are enforced as a 'must' and this would help greatly. I think making this clear will help reduce disputes on WP by strongly stating that these policies are considered a 'must' with few exceptions. There is always the possibility to change the policy, and there is the piped link to ignore all rules. -- LT910001 ( talk) 05:08, 22 May 2014 (UTC) reply
  3. Support. If it's not must, then it's not a policy, but just a guide. Lugnuts Dick Laurent is dead 12:05, 24 May 2014 (UTC) reply
  4. "Must normally" is not a contradiction, but leaves room for exceptions in less-than-normal cases.  Sandstein  18:27, 28 May 2014 (UTC) reply
  5. Second choice. Our policies may not be applicable to a given situation, but compliance is not actually optional. For better or worse, "should" is actually interpreted as "you don't really have to" by a significant minority of editors. IAR does not permit you to reject NPOV. WhatamIdoing ( talk) 05:58, 29 May 2014 (UTC) reply
  6. It's a policy, not a suggestion. And it contains the necessary caveat of "normally" for exceptional cases. -- Holdek ( talk) 20:54, 31 May 2014 (UTC) reply
  7. This would certainly cut back on the number of new editors baited into WP:WIKILAWYERING, and as a result, likely improve editor retention... — {{U| Technical 13}} ( etc) 19:41, 8 June 2014 (UTC) reply

Support neither

"This page documents an English Wikipedia policy, a widely accepted standard that all editors must normally follow. Changes made to it should reflect consensus."

  1. Fits better "policy is descriptive not prescriptive". If editors don't normally follow, the policy is obviously wrong. The should/must introduces an imperative tone at odds with "community consensus" and "no firm rules". Should/must language begs "or what?". Should/must language belongs with enforceable mediation solutions. -- SmokeyJoe ( talk) 06:18, 22 May 2014 (UTC) reply
  2. Well, I like this suggestion and for the reasons SmokeyJoe gives. (BTW the juxtaposition of "must" and "normally" seems very strained to me). Thincat ( talk) 16:01, 22 May 2014 (UTC) reply
  3. First choice. Policies and guidelines are descriptive. SmokeyJoe is absolutely correct. —/ Mendaliv/ / Δ's/ 22:36, 22 May 2014 (UTC) reply
  4. Second choice. Hadn't thought of this option, but like it. -- Jayron 32 23:48, 22 May 2014 (UTC) reply
  5. Distant second choice. While I agree in principle with the rationale, I'm concerned that this might read as too optional, leading to problems and arguments ad infinitim. Killer Chihuahua 01:17, 24 May 2014 (UTC) reply
  6. SmokeyJoe is correct and his proposal fits WP:NOTLAW best. Andrew ( talk) 10:26, 24 May 2014 (UTC) reply
  7. My choice. I echo "or what?". This has the tone of a good faith voluntary obedience. We are volunteer editors after all, but of course, if we misbehave badly enough someone will call us to account. However, we have no General Statutes law book, such as in state or local government, to drag out and thusly handcuff an editor to drag before a magistrate. Fylbecatulous talk 20:09, 26 May 2014 (UTC) reply
  8. Per SmokeyJoe. -- King of ♠ 05:00, 29 May 2014 (UTC) reply
  9. First choice. I'd also be satisfied with something like "that editors are expected to follow", as that describes not merely the fact that people do follow them, but that you can expect problems if you don't follow them. WhatamIdoing ( talk) 05:53, 29 May 2014 (UTC) reply
    I actually like your suggestion a lot. Count that as my first choice. -- King of ♠ 02:34, 31 May 2014 (UTC) reply
  10. Per SmokeyJoe. Policy should describe common Wikipedia practice and community norms. This is the best wording to suit that. It makes it clear that you should probably follow the rules, but the rules aren't firm and can be changed by consensus. Mz7 ( talk) 03:58, 31 May 2014 (UTC) reply
  11. This one; "must" and "should" are both implying an obligation, with "must" implying that obligation more forcefully; however, it is more an expectation that those aware of policies will follow them rather than an obligation. Bending, breaking, or ignoring a policy in itself is not grounds for a sanction - it is the circumstance, the reason, and/or the continuance that concerns the community. If this option gains consensus, then it would be appropriate to update wording at Wikipedia:Policies and guidelines. SilkTork ✔Tea time 10:43, 31 May 2014 (UTC) reply
  12. Support because it avoids the problem entirely and I think it is a more accurate description of the way that policies ought to be viewed. (would choose should if this is not accepted, but definitely do not want must) Zell Faze ( talk) 19:58, 1 June 2014 (UTC) reply
  13. I prefer the "editors are expected to follow" version, but this is fine. Neither should nor must really do much for me. There is an expectation that editors will follow policies, however. It makes sense to describe policy in terms of the community's acceptance, and it also makes sense to warn users that they will face opposition when they choose to ignore it. NinjaRobotPirate ( talk) 23:22, 4 June 2014 (UTC) reply
  14. Short, elegant and true. It is not something you are forced to do, it is something we all do. - Nabla ( talk) 11:49, 10 June 2014 (UTC) reply
  15. I like this version too. We could even drop the superfluous and possibly inaccurate "all". All the best: Rich  Farmbrough03:08, 16 June 2014 (UTC).
    Agree with the dropping of "all", as superfluous, inaccurate, tending to hyperbolic rhetoric. These tags should be simple and concise, written to help newcomers, not loaded to support majority domination. -- SmokeyJoe ( talk) 03:45, 16 June 2014 (UTC) reply

Threaded discussion

The discussion now exists in the archive Wikipedia talk:Policies and guidelines/Archive 13#Is a guideline different to a policy?. Mz7 ( talk) 20:53, 27 May 2014 (UTC) reply
  • I suggest discarding the "must normally" option at this point. -- SmokeyJoe ( talk) 00:01, 23 May 2014 (UTC) reply
  • Lugnuts wrote: "If it's not must, then it's not a policy, but just a guide." This is precisely the sort of misunderstanding that we need to avoid promoting.
    Both guidelines and policies have exceptions. By the same token, neither policies nor guidelines are optional and subject to deliberate defiance on a whim. No matter which label appears, the advice should be followed unless doing so impedes Wikipedia's improvement or maintenance.
    The actual distinction between policies and guidelines is documented at Wikipedia:Policies and guidelines. "Policies explain and describe standards that all users should normally follow, while guidelines are meant to outline best practices for following those standards in specific contexts. Policies and guidelines should always be applied using reason and common sense." — David Levy 21:52, 26 May 2014 (UTC) reply
  • I'm attracted to the idea that discussions over non-standard behaviour will turn to "Is what this editor is doing good or bad" and opposed to "Is what this editor doing supported by policy". Policy, per se, is not a good reason. Ideally, policy as written, is self-evidently a good idea. Not all policy is written to this standard. Policy, as written, should be informative with regard to practice, and terminology, enabling bystanders to judge whether an editor's behaviour is producing a good outcome. Policy should be subservient to the product, as per Wikipedia:Product, process, policy. -- SmokeyJoe ( talk) 03:12, 27 May 2014 (UTC) reply
    If a policy is written well, applying the advice contained therein will be sensible most (but not necessarily all) of the time. On its own, "because the policy says so" is a poor rationale, but it's helpful to examine why the policy has been written a certain way (i.e. what factors led to such a consensus) and determine whether these reasons apply to the matter at hand.
    In other words, the two questions that you cited aren't mutually exclusive; we should ask ourselves "Is what this editor is doing supported by policy?" and "Is what this editor is doing good or bad?". If the answers don't jibe, we can consider whether this constitutes grounds for revising the policy or for simply making an exception. The mistake is relying solely on whether something is supported by policy. — David Levy 03:44, 27 May 2014 (UTC) reply
  • Yes. -- SmokeyJoe ( talk) 03:50, 27 May 2014 (UTC) reply
  • Agreed. Yet it is often hard to know the "why". I think policy (and guideline) pages would be better server having some kind of "cite your sources" policy. At least pointing to relevant discussions (like this one) so that anyone can get a grasp of the "whys" and the "why nots", and moreover be confident that the current policy text is not just whatever the last editor decided to write down but actually the result of a discussion (and how long, how old, by how many, etc.) - Nabla ( talk) 11:55, 10 June 2014 (UTC) reply
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Suggestion to remove "should" from first sentence

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


During the above RfC a suggested wording change to drop the word "should" may not have been clear. The proposal was this: "This page documents an English Wikipedia policy, a widely accepted standard that all editors should normally follow. Changes made to it should reflect consensus" A later suggestion to also drop the word "all" was supported, but came very late. As such there was no clarity on support for that particular suggestion. So I think it's worth considering the proposed wording changes in isolation from the must/should debate. Is there support/opposition for the following wording:

This page documents an English Wikipedia policy, a widely accepted standard that editors normally follow. Changes made to it should reflect consensus

The words "all" and "should" have been removed, leaving the notice wording neutral, informative and factual, with the only obligatory wording being the final sentence, which is the active part of the notice.

This is set up as a simple support or oppose discussion for this template, though it will have implications for the wording on Wikipedia:Policies and guidelines, so this discussion is linked from Wikipedia talk:Policies and guidelines. 05:10, 8 August 2014 (UTC) SilkTork ✔Tea time 13:00, 23 June 2014 (UTC) reply


Hmmm, a little bit WP:ILIKEIT-y... Forbidden User ( talk) 13:03, 8 August 2014 (UTC) reply
  • Oppose and this should be advertised wider, you don't change policies with discussions on template talk pages without even an RfC. As to the question what happens about 'should' I would point to WP:Policies and guidelines#Enforcement. They are not totally optional. There are consequences and they are spelled out and that is community consensus. Dmcq ( talk) 08:56, 25 June 2014 (UTC) reply
That's a rather strange reason, given that nobody has any plans to promote this template to policy status. However, I'm happy to have more people join the conversation. WhatamIdoing ( talk) 00:13, 17 August 2014 (UTC) reply
  • Oppose How unclear is the present wording? "Editors normally follow" sounds like a trend describtion more than an instruction. This template is used to infrom/instruct users on the function of templates. Forbidden User ( talk) 13:03, 8 August 2014 (UTC) reply
  • Oppose. I cite the "descriptive, not prescriptive" principle frequently. It means that we put things in writing to document what we do (as opposed to doing things because they're written down), not that we must avoid conveying that anything is required. The tag's purpose is to explain that editors should comply with policies in most situations, not to make a "neutral" statement that this typically occurs (with no indication that it's non-optional). I agree with Forbidden User that the proposed wording comes across more as a trend description than it does as guidance. — David Levy 21:04, 8 August 2014 (UTC) reply
  • Oppose The use of the word "should" indicates that there is a strong expectation that policy be followed (except in cases where it is appropriate to ignore all rules). If we remove the word "should", then the description makes policy sound like something that editors just sort of happen to do. This does not do justice to the importance of policy, so the word "should" should stay. Spirit of Eagle ( talk) 04:13, 10 August 2014 (UTC) reply
    • It depends on your perspective. "You should do this–but you don't have to." "People should tell the truth–but they don't." Telling people that all the other editors are doing it, however, is actually a pretty good way to get people to comply. WhatamIdoing ( talk) 00:13, 17 August 2014 (UTC) reply
  • Oppose per Cunard and Spirit of Eagle. The stronger wording should be retained so that it doesn't mislead editors into thinking that policies are completely optional. Otherwise, there is no distinction between policies and guidelines, IMO. Kaldari ( talk) 07:30, 11 August 2014 (UTC) reply
    I'll note that Template:Guideline also contains the word "should" in this context. Its text simply places greater emphasis on the existence of exceptions. Neither policies nor guidelines are optional (in the usual sense). — David Levy 07:54, 11 August 2014 (UTC) reply
  • Oppose  Removing the word "all" is ok, but removing "should" weakens the language.  Unscintillating ( talk) 01:00, 12 August 2014 (UTC) reply
    I agree that the word "all" can be removed. It makes the sentence shorter and more concise without losing meaning in the process. Spirit of Eagle ( talk) 02:16, 12 August 2014 (UTC) reply
  • Oppose - the word "should" is correct - it's weaker than "must" (an absolute requirement), which is clearly contradicted by IAR, but string enough to mean that users are expected to do it for the most part. עוד מישהו Od Mishehu 08:12, 13 August 2014 (UTC) reply
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Post-RfC discussion

Should anything like this come up again, please ping all previous respondents in these RfCs, and myself as well (and anyone else who asks), and list it at WP:Village pump (policy). This looks like trivial copy-editing (and on a template like Template:Wikipedia how-to it might be), but in the WP:PAG context it is not. Such proposed wording alterations deserve careful and community-wide consideration.  —  SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  00:08, 23 June 2016 (UTC) reply

Useless (?) "shortcutoverride" parameter

Is there any rationale for the undocumented |shortcutoverride= parameter? I cannot think of a legit use case, and would just as soon strip it out, so that the code for shortcuts here is precisely the same as that in Template:Guideline. I suspect someone added this to get around the five-shortcut limitation, but this is silly; just use a separate Template:Shortcut. And it's discouraged to display more than five at a time, anyway. Some pages have 20+ shortcuts, but we do not need to "advertise" any but the most common and useful.  —  SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  00:04, 23 June 2016 (UTC) reply

Font size

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Consensus is to have a line break and the lower text be 90% size on {{ Policy}} and related templates. More specifically, the consensus is to use Version D.

Bryan Henderson (giraffedata) ( talk) 03:07, 20 June 2017 (UTC) reply


Should {{ Policy}} and related templates contain a line-break, and if so, what what should the font size for the lower text be. TheDragonFire ( talk) 04:39, 14 May 2017 (UTC) reply

Pre-RFC Discussion

@ Atón: You've changed the font size on 13 important templates, including this one. In my view the new font size of 11.9px fails WP:ACCESSIBILITY, and looks visibly jarring. Would it be possible to solicit further feedback before continuing? TheDragonFire ( talk) 14:39, 10 May 2017 (UTC) reply

I'm sorry to hear that since my intention was to make it less jarring. I think the new font size makes the template clearer to the reader. The jarring effect could be solved by increasing the line height or the minimum margin between the text and the box instead. I'll wait for further feedback. Atón ( talk) 17:54, 10 May 2017 (UTC) reply
All the changes should be reverted and a sandbox set up to show the proposal with before-and-after boxes, followed by one discussion. The tiny type is unacceptable. The line break might be good, but I'd want to think about it. Johnuniq ( talk) 02:14, 11 May 2017 (UTC) reply
I've reverted changes to this template, and to {{ guideline}} and {{ essay}} (those being the the most high visibility). Atón's changes have been moved to {{ Policy/sandbox}}. I'll leave the other changes in place pending further discussion. Below is a comparison of original, Atón's version and Johnuniq's version.

Version A

Version B

Version C

TheDragonFire ( talk) 03:42, 11 May 2017 (UTC) (Added version numbering - Tamwin ( talk) 19:27, 16 May 2017 (UTC)) reply
The font size was too tiny, I agree. But a clear distinction between the principal statement and the explanation helps navigate the template, specially in the cases of {{ guideline}} and {{ essay}} where the explanation is longer. Just a line break doesn't create enough contrast, in my view. I've corrected the font size (from 85% to 90%) and increased the top and bottom margin. It would look like this:

Version D

Atón ( talk) 08:29, 11 May 2017 (UTC) (Added version numbering - Tamwin ( talk) 19:27, 16 May 2017 (UTC)) reply

RFC Discussion

  • The samples are nice but they don't convey the impact of the change. When I first noticed it, the guideline I was looking at made the small-text line invisible. The problem is the normal banner blindness where everyone knows to skip over messages in a box at the top—particularly lines in tiny type. A wonderful layout may look good, but if the text is unimportant it would be better to delete it. Johnuniq ( talk) 10:58, 14 May 2017 (UTC) reply
    • I like that "This page is X" pops up. It makes it very easy to spot the 'X' word, which is the most relevant. I don't think the lower text is unimportant, it's helpful for new users, but the "This page is X" statement is enough information for most users. The 85% font size was too small, I agree, but 90% looks OK to me. Atón ( talk) 12:18, 14 May 2017 (UTC) reply
PD: Deleting the explanation altogether is not a bad idea, as Johnuniq has explained. A link to Wikipedia:Policies and guidelines is enough.

Version E

Are there objections to this solution? Atón ( talk) 17:28, 16 May 2017 (UTC) (Added version numbering - Tamwin ( talk) 19:27, 16 May 2017 (UTC)) reply
I object. They look empty, and there really should be a short version on the page. I don't see why we shouldn't go with as small a modification of the current version as possible. Tamwin ( talk) 19:29, 16 May 2017 (UTC) reply
Version C, D, or A, in that order of preference. These options are the closest to the original in content and meaning, and the least visually jarring. Strong oppose versions B and E, as these look bad/ do not convey the meaning of the original. Tamwin ( talk) 19:35, 16 May 2017 (UTC) reply
  • Version D looks good. It makes clear that the second line eludicates on the 'headline' (which can be insufficient to new users on its own), but everything is nice and readable. I would object to E. -- SubSeven ( talk) 05:22, 18 May 2017 (UTC) reply
  • Version D is my personal favourite. It looks good and is clear. Oppose version A (the original), anything is better. Laurdecl talk 07:47, 18 May 2017 (UTC) reply

Version F

  • Support the change, BCD are good, but I suggest this version F. Having the critical sentence on its own line help it pop out. The key sentence should pop out with a larger font size, instead of fiddling with the text size underneath. (To clarify, I suggest POLICY and GUIDELINE should be style F. Essays and How-To should be be style B, C, or D.) Alsee ( talk) 06:56, 18 May 2017 (UTC) reply
  • Oppose F, the boldness is too much, it distracts from the actual page. Laurdecl talk 07:47, 18 May 2017 (UTC) reply
  • Version D is also my favourite. Atón ( talk) 06:28, 3 June 2017 (UTC) reply
  • Support C or D. Strong Oppose E. After being away from this discussion for a bit, and returning with fresh eyes, I'm warming up to the linebreak. I think a decision should be made for C or D (or a tweaking of either), with reference to the Web Content Accessibility Guidelines. The detail is important, and I don't feel E is appropriate. TheDragonFire ( talk) 06:35, 6 June 2017 (UTC) reply

I've upgraded the templates except for {{ Subcat guideline}}, which is protected. Atón ( talk) 09:04, 13 June 2017 (UTC) reply

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Reverse recent decisions related to line break and font size

I believe that the recent changes to this and related templates make them look outdated. The <br><small> stuff was removed from the mainspace cleanup templates around 2009; the consensus to introduce it to the projectspace templates contradicts precedent. KMF ( talk) 04:08, 23 July 2017 (UTC) reply

Support classic pre-2017 look

Oppose; keep new look

Discussion

  • The established (classic) version for this page is the current version ( 04:21, 23 July 2017). The "small" version is 06:19, 13 July 2017. I support the established version. The small stuff is too finicky and at variance from established styles. If the small text is unimportant, delete it. For this discussion, I don't think the headings are needed. Johnuniq ( talk) 06:00, 23 July 2017 (UTC) reply
  • OMG, look at what's happend to {{ nutshell}}: diff. @ Primefac: Do you really like the result? It looks shocking on my system. I was skimming WP:MINOR and the important information (what is in the nutshell) looks as if it should be ignored—I only looked because I know the nutshell is generally an excellent summary of the point. Johnuniq ( talk) 06:15, 23 July 2017 (UTC) reply
    I'm not strictly opposed to it. There was a TPER related to the above RFC, it was reasonable, and so I made the change. If it's determined that the above RFC should be overturned, I'll probably end up restoring the original version. Primefac ( talk) 11:14, 23 July 2017 (UTC) reply
    I agree with Johnuniq regarding {{ nutshell}}. The point of changing the font size in {{ policy}} and related templates was to make them less wordy by making a distinction between the main statement and the auxiliary explanation. The case of {{ nutshell}} is different. The essential text there is the summary, it shoudn't look small. I don't think the result of the RfC above applies to {{ nutshell}}. Atón ( talk) 15:35, 23 July 2017 (UTC) reply
    Fair point. Self-reverted. Primefac ( talk) 15:39, 23 July 2017 (UTC) reply
  • Oppose reversion: This looks brand new and much cleaner than the previous one. Ups and Downs ( ) 07:33, 23 July 2017 (UTC) reply
  • I have no opinion on the reversion, but if you're going to keep it please don't do it by putting inline CSS in every individual template. Have the underlying mbox template do it, like {{ ambox}} does with |issue= and |fix=. Anomie 01:38, 11 September 2017 (UTC) reply

Has this issue come up before?

An editor recently quoted "Changes made to it should reflect consensus" from this box in support of the proposition that Wikipedia:Don't revert due solely to "no consensus" does not apply to policies and guidelines. This seems to conflict with WP:PGBOLD. I'm wondering whether anyone recalls a discussion of this possible conflict between the text in this template and the policy reflected at PGBOLD. - Butwhatdoiknow ( talk) 16:20, 21 August 2022 (UTC) reply


Videos

Youtube | Vimeo | Bing

Websites

Google | Yahoo | Bing

Encyclopedia

Google | Yahoo | Bing

Facebook