Wikipedia talk:Banning policy: Difference between revisions

The project page associated with this talk page is an official policy on Wikipedia. Policies have wide acceptance among editors and are considered a standard for all users to follow. Please review policy editing recommendations before making any substantive change to this page. Always remember to keep cool when editing, and don't panic.

Shortcut WT:BAN

Archives

Archive 1 Archive 2 Archive 3 Archive 4 Archive 5 Archive 6 Archive 7 Archive 8 Archive 9 Archive 10 Archive 11

This page has archives. Sections older than 90 days may be automatically archived by Lowercase sigmabot III when more than 4 sections are present.

The para on TBAN says the person with TBAN isn't supposed to edit articles related to a particular topic. However, the decision involving me suggests that even sandbox edits related to the topic is considered a TBAN violation. Therefore, I request to specify clearly on the said para of Project Page that sandbox editing is also covered under TBAN. Dympies (talk) 02:38, 3 January 2024 (UTC)[reply]

The section very clearly says that "a topic ban covers all pages (not only articles) broadly related to the topic". Galobtter (talk) 02:41, 3 January 2024 (UTC)[reply]

But sandbox is generally considered a practice ground and hardly any other editor visits it. Dympies (talk) 03:04, 3 January 2024 (UTC)[reply]

I could see adding a bit of language to indicate that it also applies in user space (which of course includes an editor's sandbox). From time to time, there have been issues when somebody violates a TBAN on their talk page, and perhaps it's worth clarifying this. --Tryptofish (talk) 22:01, 3 January 2024 (UTC)[reply]

@Tryptofish: the HTML is Semantic HTML. '''...''' is the wikitext version of <b>...</b>, which is not meant for empahsis (even though countless editors use it for emphasis...). Likewise for italics: from MOS:EMPH, The most accessible way to indicate emphasis is with the HTML <em>...</em> element or by enclosing the emphasized text within an {{em|...}} template. Italics markup (''...'', or <i>...</i>) is often used in practice for emphasis, but this use is not semantically correct markup, so emphasis markup is preferred. There is recent discussion on this matter at Wikipedia talk:Manual of Style/Accessibility § Strong tags. Best, HouseBlaster (talk · he/him) 21:06, 12 February 2024 (UTC)[reply]

We're talking about this: [1]. I don't know whether that discussion at a MOS talk page really represents community consensus, but it certainly does not match my day-to-day experience. --Tryptofish (talk) 21:11, 12 February 2024 (UTC)[reply]

MOS:EMPH indicates that we should use <em>...</em> for emphasis over '''...''', and MOS:BOLD says that in the rare cases bolding is used as emphasis we should use <strong>...</strong>. With all due respect, I don't believe day-to-day experience trumps accessibility concerns. HouseBlaster (talk · he/him) 21:16, 12 February 2024 (UTC)[reply]

I can't tell from the MOS discussion whether there are really accessibility concerns or not. --Tryptofish (talk) 21:18, 12 February 2024 (UTC)[reply]

I realize it is a fairly dense thread :) From SMcCandlish,

Whether screen readers right this second support this semantic markup very well is immaterial; it exists and is well-defined as serving this semantic purpose, and support will get better over time. What's never going to be helpful is using ''...'' (equals <i>...</i>), or '''...''' (equals <b>...</b>) where semantic emphasis is intended, because that is purely visual formatting with no semantic implications (e.g. italics around foreign terms or book titles, or boldface to mimic the bold keyword in a directly quoted definition that was boldfaced that way in the original source). Screen readers will ignore that non-semantic markup on purpose and are never going to change in that regard.

Screen readers and other assistive tech need to distinguish between semantic emphasis and presentation. Best, HouseBlaster (talk · he/him) 21:26, 12 February 2024 (UTC)[reply]

I just commented there, that there should be community buy-in or there will be a lot of pushback resembling the revert that I made. The first step in getting buy-in is for the community to understand the need for a change, if indeed such a need even exists. And I have to admit that I, for one, still do not understand. --Tryptofish (talk) 21:32, 12 February 2024 (UTC)[reply]

What is the scope of this campaign? Is every use of wikitext going to be replaced with "correct" html? On all pages? Johnuniq (talk) 22:13, 12 February 2024 (UTC)[reply]

If the wikitext is correct, then I have no plans to touch it. If I come across incorrect wikitext, I try to correct it (the same way one might correct a typo).

I think "campaign" is the wrong word to use: I am not going around and looking for changes to make. In this case, while reading the page for an unrelated reason, the underline of this exception <u>does not</u> allow for reporting vandalism to administrative noticeboards caught my eye: <u>...</u> is for things like seplling errors, not for emphasis. While I was making that edit, I also fixed other markup to semantically meaningful. HouseBlaster (talk · he/him) 22:24, 12 February 2024 (UTC)[reply]

I don't doubt the good intentions of this, but I have real concerns. One of the things you changed in that edit was an anchor for a section, doing away with using Template:Anchor for that purpose. I've always thought that anchors were for where something was linked to, from somewhere else. Unless I'm missing something, that has nothing to do with accessibility, nothing to do with screen readers. It's just some editors' personal opinion of what the "correct" markup should be. Has that template been brought up at WP:TfD? If there are real issues having to do with accessibility, if there are real reasons to do emphasis one way and not another, then there is a process of addressing that community-wide, but a small discussion at a MOS subpage talk page isn't that. --Tryptofish (talk) 22:44, 12 February 2024 (UTC)[reply]

The anchor template was substituted per its documentation: see Template:Anchor#Rationale for substitution in the header. That is not an accessibility issue; I sincerely apologize for implying otherwise. HouseBlaster (talk · he/him) 22:49, 12 February 2024 (UTC)[reply]

OK. [2]. But my other concerns remain. --Tryptofish (talk) 22:55, 12 February 2024 (UTC)[reply]

Rereading this, I think I should clarify that the recent discussion is not the impetus of the change. MOS:EMPH has said we should use <em>...</em> (and not use ''...'') for emphasis since 2011. I opened that thread at the MOS talk page to make sure I understood the current guidelines, not to change them. HouseBlaster (talk · he/him) 04:16, 13 February 2024 (UTC)[reply]

Thanks for that information, but frankly, I'm shocked that MOS has said this since 2011, since the number of editors who follow that guidance can probably be counted on the fingers of one hand. (I don't think it's an expectation at Featured Articles, for example.) I'm pretty sure that if this were put to a community-wide discussion, a lot of other editors would feel the same way that I do. (And I'm sorely tempted to do just that.) For that matter, it's also shocking that, for all these years, the WMF markup for the editing window has never been made congruent with what MOS says there. Perhaps MOS has become a sort-of walled garden where most editors only look when something (like this) draws their attention, but that's a discussion for another talk page, not here. It also makes me wonder how big an issue it really is for accessibility, since it seems to have attracted little notice. Please understand, I'm coming at this from a perspective of wanting to be friendly to accessibility issues, but there is so much about this that is so bizarre. --Tryptofish (talk) 21:36, 13 February 2024 (UTC)[reply]

You are obviously coming in good faith (and I am sincerely glad we can both recognize that). Though I would say "WMF has not added it to the toolbar" is hardly anything surprising (as just two examples, WP:THEYCANTHEARYOU and graphs still disabled). I would welcome an RfC at WT:MOSTEXT. Best, HouseBlaster (talk · he/him) 22:11, 13 February 2024 (UTC)[reply]

Yes, I want to confirm that I also see all of this as good faith. I don't know if I will do anything like an RfC (or maybe a more general discussion), but if I do, it will more likely be someplace like the Village Pump, definitely not at a MOS talkpage. --Tryptofish (talk) 23:40, 13 February 2024 (UTC)[reply]

Is there any chance of a direct answer to the spirit of my question. Let's say there are six million articles and uncountable other pages. How many of them are likely to use apostrophes for wikitext and fit the above "incorrect wikitext, I try to correct"? What is the status of Help:Wikitext#Format? Johnuniq (talk) 01:30, 14 February 2024 (UTC)[reply]

In articles, apostrophes are correct the vast majority of the time. <em>...</em> and <strong>...</strong> are for emphasis, not formatting. At MOS:TEXT, there are numerous reasons to use bold/italics; all of them except emphasis should use apostrophes. How many pages will be impacted? Not many in mainspace (when was the last time you saw emphasis used in mainspace? I can't recall the last time I encountered it...), none in the various talk spaces (except for possibly in banners), none in userspace. So, the direct answer: I don't know, but mostly in the project/help/template namespaces. HouseBlaster (talk · he/him) 02:02, 14 February 2024 (UTC)[reply]

I feel like this doesn't add up. I thought this was about accessibility, for people who use screen readers. But now, I'm hearing that we have to distinguish between formatting, and formatting for emphasis. Are people who use screen readers confused when, in the context of a policy page (not a mainspace page), the screen reader tells them that some text has been formatted in italics or bold, but does not tell them whether or not the intention of the formatting was to provide emphasis? --Tryptofish (talk) 18:48, 14 February 2024 (UTC)[reply]

Using semantic markup has been part of the HTML standards from the beginning, so this isn't new guidance. Generally, though, most people don't think about the labelling their words semantically when writing. Instead they consider how they want their words to look. Some semantics are clear: text editors will have a list button, as users know what that will look like. They have italic and bold buttons instead of emphasis and strong emphasis, though, as it's not apparent what visual effect that might have. For that matter, the semantic difference between the two is fuzzy as well. This fuzziness contributes to the difficulty in implementing a standard handling mechanism by screen readers. Some people have suggested that the screen reader voice could provide additional emphasis on elements marked up as having emphasis or strong emphasis. A lot of use of bold text on the web, though, is more about creating guideposts in text passages to help readers navigate to what they are looking for, and it might not be suitable for these passages to be read with emphasis. Having editors provide easy options for italic and bold is probably a better choice in the overall scheme, to avoid imparting misleading semantics by default.

A side note on what screen readers do in practice: as I understand it, some provide an option to announce when an emphasis or strong emphasis tag is present (I believe it could be a verbal announcement, some kind of sound, or an alternate voice), more intended for proofreading when editing than regular reading. They don't provide support for a emphasis voice intonation (which to work well would probably need some type of AI-based program to take into account the surrounding context).

My personal advice would be two-fold: first, we should look for other ways beyond marking phrases in bold to help readers navigate through text. Perhaps more nutshell summaries should be provided at the start of sections. (This wouldn't be appropriate in articles, but as mentioned by HouseBlaster, this type of guidepost technique isn't used in articles.) Second, given that even on Wikipedia guidance pages, emphasis semantics is not really critical to communicating the ideas being presented, I would focus on very specific situations. Perhaps on a given page, just one phrase in the overall nutshell summary ought to be marked as having emphasis. isaacl (talk) 18:59, 14 February 2024 (UTC)[reply]

To repeat: Are people who use screen readers confused when, in the context of a policy page (not a mainspace page), the screen reader tells them that some text has been formatted in italics or bold, but does not tell them whether or not the intention of the formatting was to provide emphasis? --Tryptofish (talk) 19:05, 14 February 2024 (UTC)[reply]

I'm not sure why you're repeating your question to me; I did read it after you posted it moments ago and don't have any insight into reader confusion. I will note, though, that as I understand it, screen reader users don't generally browse web pages using the proofreader mode enabled where elements get announced, as it results in too many extraneous announcements. isaacl (talk) 19:12, 14 February 2024 (UTC)[reply]

I'm not trying to be testy, sorry, but I think my question gets to the heart of what this talk section is trying to resolve: whether this policy page should be formatted one way, or the other. But I think you actually just provided some information that helps to answer the question. If the typical Wikipedia user who reads this policy page using a screen reader for accessibility is likely (at least most of the time) to do so with the screen reader set to a mode that does not distinguish between fonts that we format using multiple apostrophes, and fonts that we format with HTML markup, then this isn't a real accessibility issue. I'm inclined to think that the edit to this policy page should be reverted back to what it was before (except for that anchor).

I'm also starting to realize that this as-yet unchallenged 2011 edit to an obscure corner of MOS should also be reverted: [3]. It uses, as an illustrative example, some text that is clearly supposed to look like part of a mainspace article ("Gellner accepts that knowledge must be..."). Yet we are being told here that there are no plans to make changes of that sort throughout mainspace problems in mainspace are rare. --Tryptofish (talk) 19:34, 14 February 2024 (UTC) Revised. --Tryptofish (talk) 23:04, 14 February 2024 (UTC)[reply]

I didn't say I have no plans to touch mainspace. I said Not many in mainspace (ironically, emphasis added). Emphasis in general is not used throughout mainspace, but on those rare occasions it is used it should be with <em>...</em> or (in extraordinary circumstances) <strong>...</strong>. (In the example at the MOS page, semantic markup is correct.)

Additionally, respectfully but strongly object to the idea that if most screen readers ignore these tags that means it is not an accessibility issue. Most people don't need a screen reader, but that doesn't mean we can ignore the needs of those who do. Again, I would welcome an RfC on the subject. HouseBlaster (talk · he/him) 22:56, 14 February 2024 (UTC)[reply]

I'm not saying to ignore this particular issue, but that there are practical difficulties in dealing with it, and that there is a better benefit-cost ratio for resolving other accessibility problems. Not having certain phrases marked up as being emphasized is mostly not a significant loss in communication; it's a progressive enhancement for those who can make use of it. In articles, given the broad spectrum of reader cultural backgrounds, I think recasting the sentence to avoid emphasis would be clearer. isaacl (talk) 23:16, 14 February 2024 (UTC)[reply]

(edit conflict) If I understand correctly, this isn't a matter of some screen readers paying attention to the tags and others ignoring them. It's that readers who use them are unlikely to be using them on policy pages in proofreader mode, and so the only reason to change policy pages as you have done is to accommodate those few readers who do read the policy page in proofreader mode. And (I think) those few readers who do use proofreader mode will still know when there is italic or bold font, but they will just not be told by the software whether that font selection was made for the purpose of emphasis, or for some other purpose. When sighted readers (like me) read policy pages, we see italic and bold fonts, but nothing tells us (unless we go into the edit window and are aware of the distinctions being made in this discussion), whether the font selection was made for the purpose of emphasis, or for some other purpose. Of course, most of us easily infer what the purpose of the font was, assuming we even care. And I suspect that readers who use screen readers are just as able to infer purpose from the context. So what's the accessibility issue? What will confuse people who use screen readers? --Tryptofish (talk) 23:18, 14 February 2024 (UTC)[reply]

Based on my understanding, announcing the emphasis elements has been tried by at least one screen reader and disliked by its users, and thus it isn't a default behaviour for that implementation. I mentioned what I've seen about proofreader mode in JAWS because it is a workaround to still get these elements announced, but it's intended to let people check that they wrote their markup correctly, so they're willing to put up with additional verbosity. (I believe the specific element is announced, since that's key to knowing if the markup is correct.) isaacl (talk) 00:09, 15 February 2024 (UTC)[reply]

Thanks. I think this additional information provides even more reason to conclude that there is not a legitimate accessibility issue here the accessibility issue here is not substantive enough to justify changing the markup on this policy page, and maybe not substantive enough to justify changes elsewhere. --Tryptofish (talk) 17:58, 15 February 2024 (UTC) --Tryptofish (talk) 18:38, 15 February 2024 (UTC)[reply]

I felt it helped illuminate the relevance of the question too, so I was surprised you repeated it. I do think semantic markup of this type is ideal, but given the practical difficulties in achieving it or making use of it, I feel the benefit-cost ratio is low. I'm mostly ambivalent about the original edit that initiated this discussion; either way doesn't bother me too much (other than the underlining, which traditionally is taught as a typewriter-equivalent to italics before italic fonts became readily available to everyone, but I get that not everyone has that reaction).

Regarding the manual of style diff, as it's in alignment with the techniques described in the Web Content Accessibility Guidelines, I can't object too much to it. But as I mentioned, personally I suggest focusing on specific, targeted instances, and off-hand I can't really think of something that really benefits from this in an article. (Taking that sample fragment as an example, I think I'd rewrite it to try to convey the same connotation in a different way.) isaacl (talk) 23:11, 14 February 2024 (UTC)[reply]

I agree with you about the cost-benefit. And my comment about the MOS diff was more of a rhetorical point, than a proposal to actually revert it, especially since this isn't the page to decide that. --Tryptofish (talk) 23:22, 14 February 2024 (UTC)[reply]

I don't want to do anything too hastily, so I'll just post here that I think that any changes to policy pages are expected to have consensus if they are disputed, and I'm still waiting to see if anyone wishes to rebut the most recent arguments made in this discussion. Absent such a rebuttal, I think it will be appropriate at some point to undo the formatting changes. --Tryptofish (talk) 21:45, 16 February 2024 (UTC)[reply]

Let me try again: The HTML spec says <b>...</b> (which is the HTML produced by '''...''') is not for emphasis. That is what <em>...</em> and <strong>...</strong> are meant to do. There are plenty of sources which explain why using semantically appropriate HTML is an accessibility concern (see, e.g. [4][5][6]). I am not sure why a change for accessibility needs to be considered substantive enough to be worthwhile. If you argument is that MOS:TEXT is incorrect, that is an argument you can make at a RfC. I am reminded of File:Diagram of IGNORE.svg: if the rules are wrong, the solution is to change the rules, not ignore them. HouseBlaster (talk · he/him) 22:03, 16 February 2024 (UTC)[reply]

Maybe you could summarize how those "plenty of sources" rebut what I said above? I said: If I understand correctly, this isn't a matter of some screen readers paying attention to the tags and others ignoring them. It's that readers who use them are unlikely to be using them on policy pages in proofreader mode, and so the only reason to change policy pages as you have done is to accommodate those few readers who do read the policy page in proofreader mode. And (I think) those few readers who do use proofreader mode will still know when there is italic or bold font, but they will just not be told by the software whether that font selection was made for the purpose of emphasis, or for some other purpose. When sighted readers (like me) read policy pages, we see italic and bold fonts, but nothing tells us (unless we go into the edit window and are aware of the distinctions being made in this discussion), whether the font selection was made for the purpose of emphasis, or for some other purpose. Of course, most of us easily infer what the purpose of the font was, assuming we even care. And I suspect that readers who use screen readers are just as able to infer purpose from the context. So what's the accessibility issue? What will confuse people who use screen readers? --Tryptofish (talk) 22:19, 16 February 2024 (UTC)[reply]

PS: I've done a quick read of the three sources you linked to, but I'm not an expert on the subject. I think I'm reading that "semantic markup" is a good thing, because, for example, it's better to label a button for people to click on as a <button>. I'm not understanding how that refutes what I said. --Tryptofish (talk) 22:31, 16 February 2024 (UTC)[reply]

It is the same logic as the button example: just as it is better to label a button a button, it is better to label emphasis as emphasis. Using apostrophes will not confuse anyone, put differently, it is not "broken". An analogy would be a GA: a GA is not a "bad" article, but that doesn't mean a FA isn't a "better" article. HouseBlaster (talk · he/him) 00:38, 18 February 2024 (UTC)[reply]

Thank you for answering, and it seems to me that this is, indeed, what it boils down to. I referred below to ipse dixit assertions, and I think that's what "it's better" amounts to in this instance. I can agree that, in a sort of general, almost philosophical, way, it is kind-of "better". But I think we have gotten some progress towards consensus by you agreeing that the older formatting won't confuse anybody, and wasn't literally "broken". And it seems to me, per what I said above, that we aren't so much dealing with a matter of accessibility for persons with disabilities, as we are with something that is kind-of "better" in the way that it can announce the purpose of some formatting as being about emphasis when users of screen reader software enable a particular software mode. But it isn't really something that we need to do, to prevent readers from becoming confused, any more than we need a way to tell sighted readers why some text is formatted the way that it was. So it seems to me that it's misleading to call this an accessibility issue. It's more an issue of the most "elegant" way to markup online text.

And when we're in that context, it's fair to consider what is convenient for most Wikipedia editors, and what is most familiar to most Wikipedia editors, and the fact that WMF still gives us software where the multiple-apostrophe markup is the default. If we're not really doing this to accommodate readers with disabilities, then we can reasonably consider how best to accommodate most editors here, who routinely markup text the way we routinely do. And that's where I'm coming from. --Tryptofish (talk) 00:56, 18 February 2024 (UTC)[reply]

Where we disagree is that about whether it is an accessibility issue here. Emphasis should use emphasis markup, because semantic markup is more accessible. MOS:TEXT currently says we should use <em>...</em> (and <strong>...</strong>) when we want to emphasize things. If you wish to revert the change to this page, I think the most appropriate thing would be to propose a change to MOS:TEXT. (C.f. WP:LOCALCONSENSUS.) HouseBlaster (talk · he/him) 01:12, 18 February 2024 (UTC)[reply]

You seem to be saying that it will not confuse anyone, put differently, it is not "broken", while at the same time you are saying that it is an accessibility issue because semantic markup is more accessible. Please explain to me why non-semantic markup is less accessible, even though it will not confuse anyone. Thanks. --Tryptofish (talk) 21:30, 18 February 2024 (UTC)[reply]

Respectfully, this line of discussion is something that is better suited to a RfC than this talk page. That being said, it will not confuse anyone because <b>...</b> and <i>...</i> are presentational markup—it is no more confusing than just not emphasizing anything at all. That being said, to communicate emphasis, semantic markup should be used. To quote SMcCandlish (part of which I included in my third post in this thread): Whether screen readers right this second support this semantic markup very well is immaterial; it [semantic markup] exists and is well-defined as serving this semantic purpose, and support will get better over time. HouseBlaster (talk · he/him) 21:55, 18 February 2024 (UTC)[reply]

Either it's an accessibility issue or it isn't. Clearly, you are advocating treating it as such an issue, not because anyone will be confused, but purely on an ipse dixit basis, because semantic markup should be used or because another editor said that it's immaterial whether or not it affects readers. You keep acting like the burden is on me to open an RfC at MOS, but I could just as well demand that you get consensus to change Help:Wikitext#Format, as another editor pointed to earlier in this discussion. --Tryptofish (talk) 22:15, 18 February 2024 (UTC)[reply]

MOS:TEXT is a guideline, Help:Wikitext is not. Most of the time presentational markup is what should be used, which is why Help:Wikitext recommends what it does. With all due respect, I have explained how semantic markup is beneficial: it makes it easier for machines to process information, which is the cornerstone of accessibility software. HouseBlaster (talk · he/him) 22:26, 18 February 2024 (UTC)[reply]

You keep saying stuff like "with all due respect". I'm not trying to upset you, really, but I'm just insisting on logical thinking, not ipse dixit commandments, and I'm taking your replies to me as they come. I really don't want to have an edit war on a policy page. --Tryptofish (talk) 22:33, 18 February 2024 (UTC)[reply]

Whether to use formatting or not[edit]

Here is my feedback on each change:

• When the word "page" is used in a ban, it means any page on Wikipedia, including for example user, talk, discussion, file, category or template pages. Bold weight feels unnecessarily loud. I suggest re-writing it to "When a ban refers to a page, this includes any Wikipedia page, across all namespaces."
• Reverting obvious vandalism (such as page content being replaced by obscenities) or obvious violations of the policy about biographies of living persons. Strong emphasis feels like an unnecessary intensifier. I suggest removing bold weight.
• If someone is banned from the Wikipedia namespace, administrative boards, or is under a similar restriction, this exception does not allow for reporting vandalism to administrative noticeboards. Underlining is not recommended by Wikipedia:Manual of Style/Text formatting § How not to apply emphasis, and again emphasis feels like an unnecessary intensifier. I suggest removing the underline.
• Editors who are blocked from editing by the Arbitration Committee can appeal ... The styling is presentational, with the bold text indicating a type of inline heading. The italic setting for "by the Arbitration Committee" isn't really necessary, but could be considered to be additional presentational markup to help separate the text from the rest of the heading. I suggest leaving this as italic markup.
• The measure of a ban is that even if the editor were to make good or good-faith edits, permitting them to edit in those areas is perceived to pose enough risk of disruption, issues, or harm, to the page or to the project, that they may not edit at all, even if the edits seem good. This one is not presentational. Personally I would remove the italic markup as I wouldn't give it additional emphasis, but I can see the argument for using emphasis markup.
• This does not mean that edits must be reverted just because they were made by a banned editor... Emphasis feels like an unnecessary intensifier. I suggest removing the italic markup.
• Editors in turn are not permitted to post or edit material at the direction of a banned or blocked editor... Italic markup seems unnecessary. I suggest removing it.
• Editors who are banned from specific pages or topics must immediately cease editing these pages or topics. If they do not, then a block will be used to enforce the ban. "Then" is extraneous and could be removed. However it might be better to recast with something like "Failing to do so can result in being blocked to enforce the ban."
• Such a block will necessarily prevent their editing of the entire site, but they are not banned from the site and remain members of the community. Italic markup seems unnecessary. With the advent of partial blocks, I suggest recasting to "A full block will prevent banned editors from editing the entire site beyond their user talk page, but they are not banned from the site and remain members of the community."
• It is unacceptable to take advantage of banned editors,... Though personally I wouldn't give this additional emphasis, I can see an argument for it and thus using strong markup.

isaacl (talk) 03:51, 17 February 2024 (UTC)[reply]

Thanks for pointing out that one of the changes was actually of something that was presentational, rather than for emphasis. It seems to me that, while switching many of these to plain text might be a good way to resolve the dispute, there are really two separate questions. The question that has been at hand throughout the discussion is whether or not to use the multiple-apostrophe markup when non-plain text is intended. The second question, whether we need non-plain text at all, is really a separate question, and I suppose that in each instance an editor had a reason for the formatting when it was originally added. (I know you realize that already, and that's why you presented the list in talk.) I'm hoping to get a clear resolution to the original question, beyond just ipse dixit assertions, and I'm still waiting. --Tryptofish (talk) 22:40, 17 February 2024 (UTC)[reply]

The general question is broader than this page, and stirs up a lot of passionate debate amongst some, so to try to reach a compromise on what should be done with this page in the meantime, I examined each case to see when emphasis might be warranted, and only found two. Editors often think "this seems important; it should be set with some kind of emphasis", but as you alluded to, just because that's how it currently is doesn't mean that's actually the most effective way. Within plain prose, bold weight has a shouting connotation to many, which can be unpleasant to read. I think italics are often used by editors to mimic a speaking stress, but that can be overused, and can be difficult for non-native English speakers to interpret. isaacl (talk) 23:03, 17 February 2024 (UTC)[reply]

For clarity, I did not change the bolding of Editors who are blocked from editing by the Arbitration Committee (in other words, I did not change anything that was presentational to use emphasis markup). I purposefully left it as '''...''' because it is presentational. HouseBlaster (talk · he/him) 01:15, 18 February 2024 (UTC)[reply]

In this edit, you changed the markup for the italic setting to emphasis, and my comments were about that portion of the text. isaacl (talk) 01:19, 18 February 2024 (UTC)[reply]

Ah. I see that as emphasis (i.e. this avenue of appeal is only open to editors blocked by ArbCom). HouseBlaster (talk · he/him) 01:24, 18 February 2024 (UTC)[reply]

The bold phrases are essentially inline headings describing categories of users. There's no parallelism between the two headings that would warrant emphasizing part of one. Emphasis can come across as speaking louder and it's somewhat strained to be louder at the end of the heading. Thus I do not feel that emphasis is appropriate. isaacl (talk) 01:40, 18 February 2024 (UTC)[reply]

There's another change, not listed above. It's in a footnote in the WP:BANEX section. The relevant part of the text is this exception does not allow for reporting vandalism to, where "does not" is underlined. The markup for underlining there seems to me to be particularly wonky, and I don't think there's a compelling reason for underlining instead of italics or bold. Maybe we could change that to either italics or bold? --Tryptofish (talk) 23:18, 18 February 2024 (UTC)[reply]

Yes, I discussed this change. I suggested just removing the underline. isaacl (talk) 23:22, 18 February 2024 (UTC)[reply]

Woops. I see it now. In this case, I think some sort of emphasis serves a good purpose. But the "new" formatting for underline is awful looking, when viewed in the edit window. If we could just change it to some sort of emphasis, that won't change the meaning of the policy page, and with that, the remaining changes that are contested are not overly confusing to editors looking in the edit window. --Tryptofish (talk) 23:34, 18 February 2024 (UTC)[reply]

Personally, when I hear the different forms of emphasis in my mind and compare them to a normal reading of the sentence, I feel the regular reading is the most natural and fully conveys the intent of the sentence. Typographic changes are best used in a sparing manner. I appreciate, of course, that you and others may have a different view. We both agree that underlining is not a best practice for this sentence. isaacl (talk) 23:43, 18 February 2024 (UTC)[reply]

I changed it: [7]. With that, the overall cumulative changes to the policy page are this: [8]. As that stands, while I personally am not particularly happy about it, I also don't think it's that big a deal. There's nothing that will seriously (and, yeah, I wrote ''seriously'') confuse editors who edit the page and are accustomed to the multiple-apostrophe markup. --Tryptofish (talk) 23:46, 18 February 2024 (UTC)[reply]

I don't really like changing it to bold. To me, bold is being loud, and thus I wince when reading that sentence. Emphasis markup would be less jarring. isaacl (talk) 23:50, 18 February 2024 (UTC)[reply]

At this point, I wince when I read this discussion. If everyone is a little bit unhappy, maybe that's good enough. --Tryptofish (talk) 23:53, 18 February 2024 (UTC)[reply]

I passed that point long ago, which is why I tried to find some compromise for this page. :) If someone wants to address the broader issue somewhere else, more power to them. isaacl (talk) 23:56, 18 February 2024 (UTC)[reply]

If we aren't all unhappy, it ain't a compromise :) HouseBlaster (talk · he/him) 00:03, 19 February 2024 (UTC)[reply]

I have no interest in starting a broader discussion elsewhere. Again, [9] is the cumulative total of what has changed. If anyone wants to come along and revert most of it back, I won't object, but I'm personally not going to do it. The one broader comment I want to make here is that editors who want to make these kinds of changes on policy pages would be well advised to bring it up in talk before jumping in and doing it, no matter how certain you are that it is The Right Thing To Do^TM. --Tryptofish (talk) 00:08, 19 February 2024 (UTC)[reply]

Can indeffed users ask other users to copy paste an XFD !vote? Can indeffed users ask other users to fix a typo? If not, can we reword WP:PROXYING in a way that this can't be wikilawyered? Thanks.

Context: User talk:Sennalen#MfD nomination of Wikipedia:Prefer truth, User talk:Sennalen#Typo –Novem Linguae (talk) 15:42, 27 February 2024 (UTC)[reply]

The other would have to have a "independent reasons for making such edits" which doesn't seem possible in this context. There are valid independent reasons for making changes to content, there are none for adding an ineligible editor's comment to a XFD. Horse Eye's Back (talk) 15:55, 27 February 2024 (UTC)[reply]

It's not clear to me what revision, specifically, would be needed. I think the proxying section is pretty clear about this. Reviewing what happened with the XFD, there seems to be a consensus that posting the requested comment was not permitted. As for fixing a typo, there is room for another editor taking over responsibility for a noncontroversial fix, but when a banned editor keeps making such requests, that should generally be stopped. --Tryptofish (talk) 20:38, 27 February 2024 (UTC)[reply]

WP:PROXYING currently only aims explicitly at editors executing requests by blocked or banned users, but not at the blocked or banned users making such requests. It follows common sense that when a banned editor keeps making such requests, that should generally be stopped, but can't we codify this in some way (without WP:CREEP) to avoid wikilawyering? Either here or at WP:TPA. –Austronesier (talk) 11:00, 9 March 2024 (UTC)[reply]

Does the three time ban happen if the sockpuppeteer abused accounts for 3 years? I have seen it on revisions after a sockpuppeteer was tagged as banned 3 years after being tagged. TheGreatestLuvofAll (talk) 18:21, 24 March 2024 (UTC)[reply]

An example is here, here and here. TheGreatestLuvofAll (talk) 18:38, 24 March 2024 (UTC)[reply]

WP:BANNOTICE states Banned editors' user and user talk pages should be updated with a notice of the ban, linking to any applicable discussion or decision-making pages.

Does WP:BANNOTICE apply to topic bans? Seems to by a strict reading of this page, but I've never seen this enforced. Just want to double check. –Novem Linguae (talk) 19:23, 7 May 2024 (UTC)[reply]

• We use the same term "banned" for both, but they are very different things. One of the traditional problems with topic bans is that there isn't a template that tells other users that they are not supposed to be participating, and enforcement depends on people simply remembering. The flip side would be, do we want to force a Scarlet Letter on someone's user page saying they can't edit in XYZ topic? Current practice (which dictates policy) is no, and we only tag individuals that are site banned. The implementation of partial blocks solved a few of these cases, btw, but not most topic/interaction banned situations. Dennis Brown - 2¢ 23:28, 7 May 2024 (UTC)[reply]