User talk:Isaacl/Archive 3

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1 Archive 2 Archive 3

your insights

Hi. your insights today were very welcome. I was enjoying our dialogue. you clearly were trying to offer your genuine insights. I will be glad to hear any thoughts of yours any time. you are always welcome to come by my talk page if you wish, or alternately to post any comments or thoughts here, and to ping me. I appreciate all your input. thanks. --Sm8900 (talk) 00:54, 8 May 2020 (UTC)

EOTW Nomination

What started this morning as an innocent IP nomination has escalated. I'm sure that we agree as to the healing potential for the individual editor. What it says to the "maddening crowd" is not my concern. I have reached out to Editor FeydHuxtable to write up a nomination. he said he might get around to it on Tuesday Burn this when read!!! LOL―Buster7  05:16, 26 May 2020 (UTC)

7-day straw polls

Hi isaacl, hope things are going OK in your neck of the woods. Your recent comments in various discussions have had me thinking more about methods for resolving content disputes. What do you think about this procedure for content dispute resolution:

  1. Tier 1: Bold editing - like normal. Once reverted, a bold edit cannot be reinstated without consensus obtained through one of the following escalation steps.
  2. Tier 2: 48hr call for objections - If, after being reverted, an editor wants to reinstate their bold edit, they start a talk page discussion, with their proposed edit and reasons for inclusion. If no one objects after 48 hours, the bold edit can be reinstated. (It's possible the editor who originally reverted the edit, upon reading the reason for inclusion, may no longer object to the edit.) If anyone objects, move on to the next escalation step.
  3. Tier 3: Non-binding dispute resolution options - At this point, there is a "live dispute" between at least two editors, and editors may choose to engage in a dispute resolution method, though none of these are compulsory or binding.
    3A: Talk page discussion - Editors may choose to continue pursuing talk page discussion (which began with the 48hr call for objections) if they think it's productive and may lead to the resolution of the content dispute.
    3B: Third opinion - If the dispute is between only two editors, they have the option of listing the dispute at WP:3O
    3C: Dispute resolution noticeboard - If the dispute is between more than two editors, they have the option of listing the dispute at WP:DRN
  4. Tier 4: 7-day straw poll - If Tier 3 doesn't resolve the dispute, any editor may open a "straw poll" proposing the edit be made. The straw poll could be closed after 7 days by any editor, including one who has voted in the straw poll. The straw poll outcome is a straight vote, with no assessment of consensus, and a majority vote (or supermajority?) deemed sufficient to make the edit. Any editor may challenge the straw poll vote outcome by escalating to Tier 5.
  5. Tier 5: Request for Comments - Any editor may open an RFC regarding the edit. The content at issue (which presumably would have been added following a straw poll) should be tagged inline on the mainspace article, with a link pointing to the RFC thread on the talk page. The RFC would be subject to all the normal RFC rules. Typically, it would be open for 30 days, but it may be shorter or longer, and it would be closed by an uninvolved editor assessing consensus.

My thinking is that the straw poll could filter disputes as well as hone RFC questions, and the drawbacks associated with straw polls would be counterbalanced by the temporary nature of the straw poll outcome (appealable via RFC), and the fact that it gives participants to a dispute some method for coming to a binding resolution, at least temporarily, that doesn't take a month or more. A really bad straw poll outcome would be overturned quickly by a snow-closed RFC. Whereas, a straw poll outcome that is genuinely a matter of dispute would be replaced after thorough discussion by a closed RFC. Can I trouble you for your thoughts? Levivich[dubiousdiscuss] 19:51, 12 June 2020 (UTC)

If I understand correctly, the two new steps you are proposing is a 48 hour call for objections and a 7-day straw poll. The key problem in introducing more steps with the current set of people who like to discuss these things is that there isn't consensus support for more structure, much less more mandatory steps. (Which is why even though I still plan one day to put forth my proposal for "structured content dispute resolution", I know at present it has no chance of gaining widespread acceptance, and close to zero chance of even being attempted anywhere.)
Putting aside that issue, though: I think people will object to 48-hours as being too rigid, taking into consideration the frequency with which people edit. Lack of objection is already used to assume consensus, for non-controversial edits. I don't think the straw poll approach is going to gain much favour, as many editors insist on the illusion that discussions are not resolved that way. (I agree that some aren't, but many are, as a proxy for determining strength of argument when closers want to only evaluate what consensus participants have reached.) Also, what are the chances that the participants who didn't gain majority support aren't going to launch an RfC? Basically both the 48-hour period and straw poll period only seem to delay the next step which involves discussion, and I think people prefer getting to the discussion sooner than later if it seems inevitable. (As you may guess from the name of my proposal, I would like to make the discussion more effective.) isaacl (talk) 20:32, 12 June 2020 (UTC)
Thanks for your thoughts! Yes, you understood correctly, those are the two new things. Would your opinion change of either of them if the time periods were different? The call for objections is probably more in the category of "best practice" than "police change", so focusing on the straw poll, and assuming an RfC is inevitable anyway, do you think it would gain more acceptance if it were suggested as a temporary measure for quieting edit wars while an RfC is ongoing? RFC sometimes take 30, 60, 90 days, during which there can be a lot of edit wars. The straw poll could always be the same question, "should it be 'X' or 'Y' until the RFC is closed?" The benefit being that some stability can be obtained without having to rely on an uninvolved editor or admin to act. Levivich[dubiousdiscuss] 05:36, 14 June 2020 (UTC)
I don't think a fixed period for objections works very well for all cases, because the context makes a big difference. As Wikipedia:Silence and consensus says, silence is the weakest form of consensus, and withdrawing from a discussion doesn't give other editors the right to do as they will. So the nature of the edit and related past history, along with the interactions of the disputing editors, will play a role in whether or not it is reasonable to proceed without further discussion.
I'm not aware of cases where admins didn't halt edit wars during an ongoing RfC. Sometimes other edits of the same nature will be made to different articles, but typically admins would intervene in those situations, too. Knowing this, most editors don't engage in edit warring at that stage. And if they do, I don't think a straw poll would stop them.
Straw polls can help lay the groundwork for an RfC, by clarifying people's positions on different aspects of the disagreement. So it is a tool that can be used, but I don't see it as a mandatory one. isaacl (talk) 06:13, 14 June 2020 (UTC)
I had in mind recent experiences with RFCs at various articles related to George Floyd, Joe Biden, and race and intelligence. There was edit warring, and blocks, and page protection, and noticeboard threads, basically multiplying the amount of editor time sunk into the content dispute. All while arguments on the RFCs continued. And that was with lots of editors across the gamut--IPs, new accounts, EC, experienced veterans. At worst, the article ends up full protected, which everyone hates. I'm thinking if editors can point to a straw poll outcome that is the temporary consensus while an RFC runs, then it's easier for admin to just partially block an editor who edits against the straw poll consensus. I guess I do think a straw poll will stop some editors, or at least give everyone some place clear to hang their hat on.
Anyway, thanks again for your thoughts. Definitely some good points to keep in mind. I might float the straw poll idea on some article next time there's a troublesome RFC. It won't be long :-) Cheers, Levivich[dubiousdiscuss] 01:59, 15 June 2020 (UTC)
I typically don't follow breaking news articles, so am not familiar with the dynamic. But in those situations I strongly suspect there'll be a lot of editors making changes without reading the talk page (or even knowing there is such a thing) and I think full protection is going to happen in any case. isaacl (talk) 14:58, 15 June 2020 (UTC)

A barnstar for you!

The Half Barnstar
For helping me out with Fourth Opinion! MrSwagger21 (talk) 01:01, 23 June 2020 (UTC)

I always like the way you make your points, and I find myself thinking about them when I disagree too

... but you don't come across as the kind of Isaacl who craves barnstars, plus I'm lazy ... anyway, thank you and great appreciation for sharing your thoughts and wisdom, always worth reading. ---Sluzzelin talk 21:32, 27 July 2020 (UTC)

Thank you for your kind words; a personal note is always appreciated. Just curious if there was a comment in particular you had in mind? I'm often trying to present a different perspective than those already expressed, so am glad to know that even when you disagree, you can find something of interest. isaacl (talk) 22:03, 27 July 2020 (UTC)
The most recent inputs were at Wikipedia talk:Requests for adminship, but it's a general appreciation. Yes, I can sense the interest in presenting a different perspective, but somehow you manage to pull it off without being contrarian for the sake of it. ---Sluzzelin talk 22:15, 27 July 2020 (UTC)

Copyright application

I have not misundertood you over at Iri’s page ... just do not want to publicly discuss at this stage of a legal process, hence my terse answers ;) I will fill you in after The Fat Lady Sings, but with COVID-related delays, that could be a while. All the best, SandyGeorgia (Talk) 01:44, 15 August 2020 (UTC)

Sure, I understand. I was only commenting on why collective action is unlikely as long as copyright isn't getting assigned to a single entity to take action upon. Individual action of course depends on whatever effort individuals are willing to expend. Thanks for your note! isaacl (talk) 01:50, 15 August 2020 (UTC)
One would think the WMF might care enough to put up accurate and helpful info so individual editors do not have to incur extra legal fees to uncover the basics. But no ... like everything on Wikipedia, best to do it yourself ! Take care, SandyGeorgia (Talk) 01:55, 15 August 2020 (UTC)
The usual problem about the reliability of unspecific legal advice applies... isaacl (talk) 05:08, 15 August 2020 (UTC)
While looking for info on something else, I came across this circular on U.S. copyright registration for web site content. isaacl (talk) 05:27, 15 August 2020 (UTC)

Content dispute resolution toolbox

@Levivich: just an fyi that I have finally written up some ideas for techniques to mitigate difficulties in content dispute discussions. You may have already seen the link at User:Isaacl/Community/Fostering collaborative behaviour, but here's a direct link: User:Isaacl/Community/Content dispute resolution toolbox. isaacl (talk) 00:29, 17 September 2020 (UTC)

Those look like three useful tools. I wonder if they've been used at DRN lately and if not it might be a good place to try them out. Lev!vich 04:43, 17 September 2020 (UTC)
I don't follow the dispute resolution noticeboard so I don't know. Resolutions for hot issues have on occasion specified moratoriums on reopening discussion, but as far as I know formal ones are quite rare. Typically participants just decline to start discussion again. I have seen pros and cons summaries attempted on some discussions. In those discussions, a lot of times there isn't a concerted effort to keep them updated or use them as a basis for a final decision, but obviously I've only seen a tiny sliver of all the discussions out there. isaacl (talk) 22:16, 17 September 2020 (UTC)

ArbCom 2020 Elections voter message

Hello! Voting in the 2020 Arbitration Committee elections is now open until 23:59 (UTC) on Monday, 7 December 2020. All eligible users are allowed to vote. Users with alternate accounts may only vote once.

The Arbitration Committee is the panel of editors responsible for conducting the Wikipedia arbitration process. It has the authority to impose binding solutions to disputes between editors, primarily for serious conduct disputes the community has been unable to resolve. This includes the authority to impose site bans, topic bans, editing restrictions, and other measures needed to maintain our editing environment. The arbitration policy describes the Committee's roles and responsibilities in greater detail.

If you wish to participate in the 2020 election, please review the candidates and submit your choices on the voting page. If you no longer wish to receive these messages, you may add {{NoACEMM}} to your user talk page. MediaWiki message delivery (talk) 01:29, 24 November 2020 (UTC)

Happy Holidays

Spread the WikiLove; use {{subst:Season's Greetings}} to send this message
Thanks! I hope the Christmas season and new year will be kind to you and your family. isaacl (talk) 18:54, 26 December 2020 (UTC)

Scope of action

Do you have any further reading for the limit on the scope of the community's action you mentioned? –xenotalk 02:00, 1 March 2021 (UTC)

Sorry, I did not keep track of the discussion I recall. (I didn't plan on ever having to refer to it.) In my memory, the community discussed if it could ban an administrator from using administrative tools. The consensus was that it would be equivalent to removing administrative privileges entirely, and so lay within the scope of the administrators policy pertaining to removing administrative privileges and the arbitration policy. From a practical perspective, I feel the sentiment was that the community shouldn't try to backdoor a desysopping procedure, but explicitly enact one. After all, if a sanctioned admin decided the procedure was invalid, a case request would end up in front of the arbitration committee anyway to resolve.
I won't discount the possibility I'm misremembering the arguments expressed. I suspect I would have remembered if a different conclusion was reached, but again, I could be wrong. isaacl (talk) 02:27, 1 March 2021 (UTC)
You may well be right, I was just curious to read it. –xenotalk 03:07, 1 March 2021 (UTC)
I found these discussions that touched on banning an administrator from one particular administrative action. Voices were expressed on both sides; below is a highly selective list (just names that caught my eye). The latter two discussions were regarding specific events and so of course untangling the reasons for supporting/not supporting is more difficult.
  • Wikipedia:Administrators' noticeboard/Archive251 § Is the community free to restrict an admin's use of some but not all admin tools? — supporters included NewYorkBrad, Salvio Giuliano, and Risker (some by reference to links in other discussions), Dennis Brown (but see later discussion), VanIsaac, the editor currently known as Lepricavark. Against included NuclearWarfare, BeyondMyKen, Apteva. GiantSnowman and Kudpung felt if there was an issue warranting banning one action, then the validity of holding the entire toolset should be examined.
  • Wikipedia:Administrators' noticeboard/IncidentArchive821 § Jclemens restriction — several supports; these are just a few opposes based on the general principle
    • Bbb23: Except in the case of an emergency, only ArbCom can desysop someone. A community restriction on the use of an administrator's tools is an end run around the rule.
    • Cas Liber: ... I can't imagine a restriction like this being compatible with holding adminship. The arbitration committee is the place for review of tool use, which is where this should go.
    • Black Kite: Wrong venue, and far too messy and vague. Needs to go to ArbCom...
  • Wikipedia:Administrators' noticeboard/Archive276 § Ban Ritchie333 from unblocking — again several supports; some dissents based on principle:
    • Beeblebrox: The other reason is that I am opposed to the very idea of banning an admin from using one particular tool while retaining all the others. Either we trust a user to be an admin, or we do not. If you can prove a pattern of tool misuse, take it to arbcom.
    • Dennis Brown: I would note that Arb has been given the authority to issue sanction for admin abuse, not the community, and it has always been reserved for them. No admin has ever had their tools limited by Arb, at least that I'm aware of. ie: If you want to remove some of his tools, you have to remove all of them, and Arb is where you file. We tried to pass admin sanction policies before (I wrote one of them, WP:RAS) but the community has soundly rejected the idea in the past. So my take is, even if it were to pass here, it has no authority because the community has already rejecting giving itself that authority in the past, many times. So, vote your hearts out, but it isn't enforceable until it goes to Arb.

← Thanks, these are good reading (you might also be interested in Wikipedia:Arbitration/Requests/Case/RHaworth/Proposed decision#RHaworth prohibited from performing deletions, where Beeblebrox stays true to the 2015 remark above!). It shows that the issue is far from settled, and it doesn't look like it's been taken up by the community otherwise since admins became unable to unblock themselves. I'm still trying to recall admin blocks that happened even further prior to 2013; any where an administrator was blocked for "overall" reasons, not specific to a particular tool or form of use: an indefinitely blocked administrator is desysopped in all but name. Maybe it never happened? Absent that, Lourdes I think you're right in that: it's never been done per se. –xenotalk 19:16, 2 March 2021 (UTC)

All of these deal with banning from a particular action and not the entire toolset. I think if the community ever attempted to ban use of all administrative privileges, the administrators policy would get modified at the same time, and the community would have to accept or reject both together, as policy is supposed to be descriptive of practice. isaacl (talk) 19:31, 2 March 2021 (UTC)
Thanks xeno, would be good if you write this also on the desysop proposal page for other readers' benefit. Thanks, Lourdes 03:45, 3 March 2021 (UTC)
Lourdes: I still want to research "admins being blocked as admins" (from earlier than these) and see if any of those led to users being compelled to shed the tools, as that is the form I am thinking about (not a case of trying to restrict specific tools in the set). After that I can update the thread with the precedent (or lack, if I’ve misremembered this ever happening). –xenotalk 13:00, 3 March 2021 (UTC)
Lourdes and isaacl, thanks for your patience; now I remember: the last major set of cases where admins attempted to enforce purported disruptive administrative behaviour via the blocking policy occurred between 2006 and 2009 and concerned the use of unapproved scripts (admin bots) on their administrator accounts. See especially running unauthorized robots, Archive478, running an adminbot, Massive redirect deletions, Rogue admin bot for background reading. This all caused a lot of disagreement, so eventually WP:ADMINBOTs had to come out of the shadows instead of being a semi-open secret. Also brings to mind the curious case of the admin who stopped communicating one day, yet kept on reverting and blocking (sometimes inappropriately). Although they were removed by arbcom motion, the community could have also ended the non-communicative spree via blocking. (I always wondered if they would have unblocked themselves for fear of falling asleep) –xenotalk 03:13, 4 March 2021 (UTC)
For the record, I don't think No admin has ever had their tools limited by Arb is true. See here re David Gerard's use of admin tools. ProcrastinatingReader (talk) 11:26, 3 March 2021 (UTC)
Another counter-example was given below Dennis's statement; I chose not to edit that portion out of his comments as it's tangential to the issue of the community issuing a ban on a specific type of administrative action (which in turn is a step away from a ban on all admin actions, which is the original topic of this thread). isaacl (talk) 15:45, 3 March 2021 (UTC)
  • Somewhat related, an essay by Wugapodes (to be refined) presents a fairly cogent argument against the notion of a non-arbcom led CDA process (which I suppose also applies to non-arbcom led "bespoke restricting" of admins (for example, restricting article creation). –xenotalk 02:32, 31 March 2021 (UTC)
    • I think "argument against" might be too strong. Maybe it's the linguist in me, but I think redundancy in a system is a good thing: different processes have different failure modes, so the strengths of one can make up for the weaknesses of the other. A non-arbcom process is viable, but it requires innovation---I can't think of a decentralized dispute resolution system developed for use at our scale. We know something is off with our current processes but the different parts are so intertwined that localized solutions might be undermined by other parts of the system (c.f. dynamical systems theory). If we can develop a thorough understanding of why our system so often converges on negative outcomes, then we can identify the places where can most effectively nudge the system towards positive outcomes. — UwU wug's this? 07:02, 1 April 2021 (UTC)
      I've previously stated I feel conduct issues are more efficiently handled through a hierarchy, as is done in real-world organizations, including volunteer ones and other online communities. I appreciate why this is anathema to various editors, and it definitely has disadvantages. But it's hard to avoid stalemates without some form of delegation to deal with issues, rather than always trying to manage problems through large group discussions. isaacl (talk) 05:12, 3 April 2021 (UTC)

Talk page threading - colons and asterisks

Hi, I've seen some of your posts elsewhere asking about the formatting of talk page discussions. The primary guidance is at MOS:LISTGAP and its supplement MOS:INDENTGAP (although these are MOS pages, they apply in all namespaces), but a fuller explanation is at WP:COLAS. Some people are unaware of the problems that incorrect formatting can cause; others are aware but are unsure why or how to fix it; and some wilfully disregard the advice. --Redrose64 🌹 (talk) 19:12, 22 March 2021 (UTC)

Perhaps you are thinking about another editor? I've written my own essay, User:Isaacl/On wikitext list markup, on this matter, and have posted advice to others on their talk pages. isaacl (talk) 19:34, 22 March 2021 (UTC)
No, I'm thinking of this post and the preceding portions of the same thread, and another thread further up the same page, in which I was named (not by yourself). --Redrose64 🌹 (talk) 22:05, 22 March 2021 (UTC)
OK, but I didn't ask about the formatting of talk page discussions. And I've said the same things as you did, during the current arbitration case and in the thread you linked to: many editors, even long-time ones, aren't aware of the problem, and some others just ignore it. isaacl (talk) 22:15, 22 March 2021 (UTC)

It amazes me that arbitrators themselves, after voting to desysop one of the most accessibility-driven admins we had, are still violating MOS:LISTGAP in discussions. The lack of decency is astounding - but thanks for at least trying to maintain them. I don't personally use screen reader or any other form of assistive technology, but it's not just that which causes problems when lists are incoherent. -bɜ:ʳkənhɪmez (User/say hi!) 20:19, 2 April 2021 (UTC)

Unnecessary changes in list styles also can cause issues for those who are using the visual diff tool (enabled via a beta feature). For example, compare [1] with [2]. But it's pretty hard to get people to not do what they want to do, particularly when it's what they've always done or if it's a tragedy of the commons situation. isaacl (talk) 05:24, 3 April 2021 (UTC)


Hi, can you further explain this edit? I'm not offended by it, I'm just genuinely curious as to what it means. I can't comprehend how a standard indentation could be more confusing than a bulleted indentation for screen readers. What is the actual difference in practice? In my mind, I use the standard indentation to avoid confusion. ~Swarm~ {sting} 06:41, 4 April 2021 (UTC)

Sure—I just ask for your forbearance if I cover things you know already, since I'm not sure what you're familiar with. The standard guidance is at Wikipedia:Manual of Style/Accessibility § Lists and Help:Talk pages § Indentation; RexxS has written an essay, Wikipedia:Colons and asterisks that discusses the issue along with examples of the underlying HTML, and I have written my own essay, User:Isaacl/On wikitext list markup. I'll discuss this guidance in the context of your edit, [3].
To start, note there is, to my eyes, no perceptible visual difference in the appearance of your comment between your edit and my immediately subsequent edit, [4]. However, there is a change in the following comment, which has two bullets displayed in your edit. I'll discuss this further in a moment.
The key aspect to know is that *, :, and # aren't represented in the underlying HTML as an indent level. They are used to introduce the start of a list (when appended to an existing prefix) and a list item. The * represents a bulleted list item, # represents a numbered list item, and : represents what I'll call an unbulleted list item (see either of the essays I referred to for more details on what it actually is).
The comment before yours started with **, so (going from right to left) it nested a second-level bulleted list item within first-level bulleted list item. Your comment started with :::, so it created a third-level unbulleted list item nested within two other levels of unbulleted lists. This has the effect of ending two levels of bulleted lists, and starting three unbulleted lists, nested within each other. Screen readers announce the start and end of lists, so five announcements are made, compared with just one if you had used a prefix of **:. But since the comment following yours starts with **, another five announcements are made to close the three unbulleted lists and open two bulleted lists, compared with just one announcement to close one unbulleted list. Thus an extra eight announcements are made. This is also why the comment after yours had two bullets, since with your change it started two levels of bulleted lists. isaacl (talk) 15:31, 4 April 2021 (UTC)
Wow, that all makes sense but I honestly had no idea. I deeply regret to learn that I've been regularly using bad indentation practices this whole time. I never even thought about this sort of nuance to indentation. Thank you for the explanation and all the resources you've provided. I get it now, and I will certainly follow the guidelines going forward. Good on you for correcting this sort of thing. ~Swarm~ {sting} 00:54, 5 April 2021 (UTC)
Yeah, if you think of the characters as indents or tab stops, as I suspect many do, it's not obvious why it makes a difference what character is used. It's more evident when you know they define nested lists. It's not a great fit for threaded conversation, but the markup and visual output resemble the old-school visual indenting used on Usenet and text emails. Thanks for your consideration! isaacl (talk) 01:07, 5 April 2021 (UTC)

Editor of the Week

Editor of the Week
Your ongoing efforts to improve the encyclopedia have not gone unnoticed: You have been selected as Editor of the Week in recognition of your community awareness. Thank you for the great contributions! (courtesy of the Wikipedia Editor Retention Project)

User:Barkeep49 submitted the following nomination for Editor of the Week:

I nominate isaacl to be Editor of the Week for his incredibly deep thinking about the community and community processes. I don't know of an editor who has thought more about our systems, contradictions and all, than isaacl. His writing on consensus has really shaped how I view the way we work. However, he doesn't just think about how things are, he thinks about how things can be made better. I think more admins and others mediating disputes should be using his User:Isaacl/Community/Content dispute resolution toolbox. When he shows up to a discussion I know that what's written is going to come from a place of great study and be something I need to consider carefully and fully. He is a valued member of Project Editor Retention and always brings level headed, helpful and fair thoughts in conversations in which he participates. His comments are consistently helpful in dispute resolution.

You can copy the following text to your user page to display a user box proclaiming your selection as Editor of the Week:

Editor of the Week
for the week beginning April 25, 2021
A deep thinker about the WP community and community processes. His observations come from a place of great study. A valued participant in maintaining the Editor Retention Project. Brings level headed, helpful and fair thoughts into conversations in which he participates.
Recognized for
being consistently helpful in dispute resolution
Notable work(s)
User:Isaacl/Community consensus and User:Isaacl/Community/Content dispute resolution toolbox
Submit a nomination

Thanks again for your efforts! ―Buster7  14:19, 24 April 2021 (UTC)

Historically I've turned down nominations for this recognition, because as one of its organizers it felt too much like self-dealing, but clearly I need to pay more attention to the nomination queue :) Thank you very much to @Barkeep49, Buster7, and ProcrastinatingReader: for your kind words! Buster7, if anyone raises a concern in future, feel free to move it out of the official recognition list; it's enough for me to know that some people were motivated enough to nominate. isaacl (talk) 16:12, 24 April 2021 (UTC)

Congrats on your recent commendation

wow! congrats on your award as "Editor of the Week"! that seems very impressive. I'm highly interested in your thoughts on community processes and inner workings. I will try to take a look over your recent work, output ideas, on such topics. thanks! ---Sm8900 (talk) 🌍 20:11, 7 May 2021 (UTC)

For the record

Seeing all of your thoughtful comments in these RFA related discussions reminds me, I'd be very happy to support this should it ever happen. Go Phightins! 16:33, 13 May 2021 (UTC)

(Or, for that matter, to nominate) Go Phightins! 16:35, 13 May 2021 (UTC)
Thanks for the vote of confidence! Leaving aside the fact that I'm one of those people not interested in administrative chores—if I were somehow able to consistently devote contiguous hours to Wikipedia, I'd be more interested in doing some content work again, or trying to help other good-faith editors through mediation or something else—there's no chance I'd pass a request at the moment. (I believe the only criterion I'd pass is "seems unlikely to delete the main page".) I'd have to start taking an interest in articles for deletion and other admin areas to build up a track record, and that's not in the cards at the moment. I really do appreciate your kind words! isaacl (talk) 16:55, 13 May 2021 (UTC)
Fair enough. The point I was trying to get at on the WT:RFA page was that, to me, what we really need are editors with good judgment. I'm not too concerned about much else beyond a basic level of technical competence and understanding of how we work. To me, you pass all of those criteria with flying colors and, as such, would be an asset with the tools even if you hardly ever used them, though I understand that people other than me also vote at RFAs. Go Phightins! 17:41, 13 May 2021 (UTC)
Thanks! Obviously (or maybe not so obviously?) I think I am capable of filling the role, and editors who know me over multiple interactions may feel they have sufficient trust in my judgment. At Wikipedia talk:Really simple guide to requests for adminship § The big three I said I think interacting and collaborating with a lot of people while demonstrating sound judgment helps a lot. (Anna's RfA is one of those that sailed through happily because so many people had pleasant experiences with her.) But with the community being so large, most editors including me are going to be unknown to most commenters at RfA, and so the stats combined with spot checks are going to be the only way these commenters can get a feeling of whether or not they trust the candidate. It's just an inevitable consequence of using a consensus-like process in a large group. I'm glad I can count on your support, though! (I think Buster7 might also provide a moral support, so that gets me up to 2 :-) isaacl (talk) 18:39, 13 May 2021 (UTC)
Don't run for RfA unless you can be certain that you will be able to fend off the all-admins-are-evil brigade - not just during the RfA itself, but a few years down the line. Despite what Jimbo intended, adminship has become a big deal, and some of those who aren't admins have taken it upon themselves to make sure that nobody else can be an admin either. They are driving out good content creators like Kudpung and RexxS. It's so toxic that Wikipedia will implode, because soon nobody will have both the desire and ability to block the vandals. --Redrose64 🌹 (talk) 19:41, 13 May 2021 (UTC)
Never fear, I am familiar with the English Wikipedia editing environment. As stated, I have no plans to request administrative privileges, for unrelated reasons and independent of whether or not the community would grant privileges. isaacl (talk) 19:59, 13 May 2021 (UTC)

DS 2021 Review Update

Dear Isaacl,

Thank you for participating in the recent discretionary sanctions community consultation. We are truly appreciative of the range of feedback we received and the high quality discussion which occurred during the process. We have now posted a summary of the feedback we've received and also a preview of some of what we expect to happen next. We hope that the second phase, a presentation of draft recommendations, will proceed on time in June or early July. You will be notified when this phase begins, unless you choose to to opt-out of future mailings by removing your name here.
--Barkeep49 & KevinL (aka L235) 21:05, 19 May 2021 (UTC)

You've got mail

Hello, Isaacl. Please check your email; you've got mail!
It may take a few minutes from the time the email is sent for it to show up in your inbox. You can remove this notice at any time by removing the {{You've got mail}} or {{ygm}} template.Barkeep49 (talk) 00:59, 5 June 2021 (UTC)

Question regarding LISTGAP

Hi, Isaacl. I've seen you making many LISTGAP corrections around Wikipedia, and they're appreciated. I wanted to ask a question regarding LISTGAP: does the screen-reader issue apply between a line of unindented text and indented text? An example I currently have is at Wikipedia:Sockpuppet investigations/Stepgilara, between my comments at 15:27 and 16:16. Does the blank line matter there? Many thanks, Sdrqaz (talk) 21:32, 7 June 2021 (UTC)

The key thing to remember that in spite of what some of the help page documentation on discussion thread formatting says, :, *, and # aren't actually indent levels. They represent different types of list items, and simultaneously introduce the start of new nested lists when used to extend the prefix string of the previous line of text in the wikitext source. When a single character prefix is introduced, such as :, after a regular paragraph, it starts a new first-level list. Thus a blank line in the wikitext source before it doesn't matter, as there's no preceding list that will get closed.
The issue with blank lines between list items is that all of the nested lists before the blank line will get closed, and then re-opened for the list item after the blank line. There is no visual difference on screen, so the extra announcements made by screen readers serve no distinguishing purpose for users making use of that assistive technology. isaacl (talk) 22:29, 7 June 2021 (UTC)
Ah I see, Isaac. Thank you for the thorough explanation. Planning on going through my archives and replacing those pesky blank lines with {{pb}}, so you've been a great help! Sdrqaz (talk) 00:33, 8 June 2021 (UTC)


FYI, I noticed that this manual archive you did got repeated later on by the archiving bot. So there are now two identical "தனீஷ்: May 21, 2021" sections in the archive page. --- Possibly (talk) 18:01, 9 June 2021 (UTC)

Thanks for the note; I've removed one of the duplicated sections. isaacl (talk) 19:57, 9 June 2021 (UTC)

Cheating in baseball has been nominated for Did You Know

Hello, Isaacl. Cheating in baseball, an article you either created or to which you significantly contributed, has been nominated to appear on Wikipedia's Main Page as part of Did you knowDYK comment symbol. You can see the hook and the discussion here. You are welcome to participate! Thank you. EnterpriseyBot (talk!) 12:00, 17 June 2021 (UTC)

Thank you

very much for this. I'd been led to believe it was impossible to accomplish this kind of formatting without screwing up screen readers, and having spent 12 years doing it this way, I occasionally still forget. I'm really quite happy that there is a (relatively) painless way to achieve the formatting I want without screwing up screen readers. I bow to your superior wikitext/HTML/java-something/whatever-this-stuff-actually-is skills. Now I just have to figure out a way to actually remember this can be done, and find a place to save it so I'll remember the actual method to do it. Anyway, thanks much. --Floquenbeam (talk) 18:01, 22 June 2021 (UTC)

The most correct way to do it requires more HTML markup, which I know will be offputting for many. This way creates an empty list item which isn't ideal from a semantic point of view. (It also puts the last part into its own list item instead of continuing the original one, which is semantically different than continuing within the first list item. I imagine for threaded conversation, the distinction isn't significant.) However the MediaWiki software detects the empty item and gives it a style class so it won't be displayed, and Graham87 confirmed that screen readers thus ignore it. I can't claim credit for coming up with it myself; I saw someone else (Redrose64 perhaps?) use it. Glad to be able to help! isaacl (talk) 18:17, 22 June 2021 (UTC)
It wasn't me. RexxS (talk · contribs) probably, or maybe Pigsonthewing (talk · contribs). --Redrose64 🌹 (talk) 23:09, 22 June 2021 (UTC)
Wasn't RexxS; I don't think it was Pigsonthewing. isaacl (talk) 23:15, 22 June 2021 (UTC)

As described in Wikipedia:Manual of Style/Accessibility § Multiple paragraphs within list items, the {{bulleted list}} template could also be used:

* Start first list item that is an intro for a list of points: {{bulleted list
|1=point 1
|2=point 2
|3=point 3
}} Continue first list item
* Second list item

Resulting output:

  • Start first list item that is an intro for a list of points:
    • point 1
    • point 2
    • point 3
    Continue first list item
  • Second list item

This method doesn't add any extra list items so is semantically more clean, at the cost of using a template instead of wikitext list syntax. isaacl (talk) 23:35, 22 June 2021 (UTC)

DYK for Cheating in baseball

On 1 July 2021, Did you know was updated with a fact from the article Cheating in baseball, which you recently created, substantially expanded, or brought to good article status. The fact was ... that pitchers are cheating in baseball with a glue invented for strongmen to hold Atlas balls? The nomination discussion and review may be seen at Template:Did you know nominations/Cheating in baseball. You are welcome to check how many pageviews the nominated article or articles got while on the front page (here's how, Cheating in baseball), and if they received a combined total of at least 416.7 views per hour (i.e., 5,000 views in 12 hours or 10,000 in 24), the hook may be added to the statistics page. Finally, if you know of an interesting fact from another recently created article, then please feel free to suggest it on the Did you know talk page.

Cwmhiraeth (talk) 00:03, 1 July 2021 (UTC)

They cheat in baseball? For shame! --Redrose64 🌹 (talk) 18:58, 1 July 2021 (UTC)
My question is about "strongmen holding Atlas's balls"? I had no idea!!!! ―Buster7  12:18, 2 July 2021 (UTC)
I wrote the hook and tried to make it eye-catching :-) isaacl (talk) 00:45, 3 July 2021 (UTC)

My sig

Sorry for the slow reply but fixed with special:diff/1032477502 ~ RhinosF1(Chat) / (Contribs) 17:33, 7 July 2021 (UTC)

(talk page watcher) @RhinosF1: It's now 264 characters, which is above the 255-char threshold permitted by WP:SIG#LENGTH. You can shorten it without altering the appearance:
<span style="color: #33cccc;">~</span> [[User:RhinosF1|<strong style="color: #0000ff;">Rhinos</strong><em>F1</em>]][[User Talk:RhinosF1|<sub style="color: #999999;">(Chat)</sub>]] / <sup>([[Special:Contributions/RhinosF1|Contribs]])</sup>
which is 238 chars. This works because all attributes that are valid on a <span> tag are also valid on all other opening tags. --Redrose64 🌹 (talk) 08:33, 8 July 2021 (UTC)
Redrose64,  Done ~ RhinosF1(Chat) / (Contribs) 14:48, 8 July 2021 (UTC)
Thank you --Redrose64 🌹 (talk) 14:59, 8 July 2021 (UTC)

both your are edits are correct

I'll fill in the dates tonight (need to clear my mind before I go back to it) But note reference #2. Smallbones(smalltalk) 21:14, 24 July 2021 (UTC)

Sorry, I was unclear that I was referring to the quotes where there is a "July XX" placeholder. Since they are from editors other than one for footnote 2, if I understand correctly, there should be separate citations for them. isaacl (talk) 21:19, 24 July 2021 (UTC)

In case you're looking for more poetry

(Just in case you're interested, the Burna-shave fad seems to have originated in this thread.) EEng 02:58, 25 July 2021 (UTC)

RfA 2021 review update

Thanks so much for participating in Phase 1 of the RfA 2021 review. 8 out of the 21 issues discussed were found to have consensus. Thanks to our closers of Phase 1, Primefac and Wugapodes.

The following had consensus support of participating editors:

  1. Corrosive RfA atmosphere
    The atmosphere at RfA is deeply unpleasant. This makes it so fewer candidates wish to run and also means that some members of our community don't comment/vote.
  2. Level of scrutiny
    Many editors believe it would be unpleasant to have so much attention focused on them. This includes being indirectly a part of watchlists and editors going through your edit history with the chance that some event, possibly a relatively trivial event, becomes the focus of editor discussion for up to a week.
  3. Standards needed to pass keep rising
    It used to be far easier to pass RfA however the standards necessary to pass have continued to rise such that only "perfect" candidates will pass now.
  4. Too few candidates
    There are too few candidates. This not only limits the number of new admin we get but also makes it harder to identify other RfA issues because we have such a small sample size.
  5. "No need for the tools" is a poor reason as we can find work for new admins

The following issues had a rough consensus of support from editors:

  1. Lifetime tenure (high stakes atmosphere)
    Because RfA carries with it lifetime tenure, granting any given editor sysop feels incredibly important. This creates a risk adverse and high stakes atmosphere.
  2. Admin permissions and unbundling
    There is a large gap between the permissions an editor can obtain and the admin toolset. This brings increased scrutiny for RFA candidates, as editors evaluate their feasibility in lots of areas.
  3. RfA should not be the only road to adminship
    Right now, RfA is the only way we can get new admins, but it doesn't have to be.

Please consider joining the brainstorming which will last for the next 1-2 weeks. This will be followed by Phase 2, a 30 day discussion to consider solutions to the problems identified in Phase 1.

There are 2 future mailings planned. One when Phase 2 opens and one with the results of Phase 2. To opt-out of future mailings, please remove yourself here.

Best, MediaWiki message delivery (talk) 00:08, 10 October 2021 (UTC)

RfA Reform 2021 Phase 2 has begun

Following a 2 week brainstorming period and a 1 week proposal period, the 30 day discussion of changes to our Request for Adminship process has begun. Following feedback on Phase 1, in order to ensure that the largest number of people possible can see all proposals, new proposals will only be accepted for the for the first 7 days of Phase 2. The 30 day discussion is scheduled to last until November 30. Please join the discussion or even submit your own proposal.

There is 1 future mailing planned with the results of Phase 2. To opt-out of future mailings, please remove yourself here.

16:13, 31 October 2021 (UTC)

ArbCom 2021 Elections voter message

Hello! Voting in the 2021 Arbitration Committee elections is now open until 23:59 (UTC) on Monday, 6 December 2021. All eligible users are allowed to vote. Users with alternate accounts may only vote once.

The Arbitration Committee is the panel of editors responsible for conducting the Wikipedia arbitration process. It has the authority to impose binding solutions to disputes between editors, primarily for serious conduct disputes the community has been unable to resolve. This includes the authority to impose site bans, topic bans, editing restrictions, and other measures needed to maintain our editing environment. The arbitration policy describes the Committee's roles and responsibilities in greater detail.

If you wish to participate in the 2021 election, please review the candidates and submit your choices on the voting page. If you no longer wish to receive these messages, you may add {{NoACEMM}} to your user talk page. MediaWiki message delivery (talk) 00:08, 23 November 2021 (UTC)

Talk page guideline. Name is confusing

Howdy. The name of the guideline page, creates slight confusion. I thought it was the talkpage. GoodDay (talk) 05:11, 9 December 2021 (UTC)

RFA 2021 Completed

The 2021 re-examination of RFA has been completed. 23 (plus 2 variants) ideas were proposed. Over 200 editors participated in this final phase. Three changes gained consensus and two proposals were identified by the closers as having the potential to gain consensus with some further discussion and iteration. Thanks to all who helped to close the discussion, and in particular Primefac, Lee Vilenski, and Ymblanter for closing the most difficult conversations and for TonyBallioni for closing the review of one of the closes.

The following proposals gained consensus and have all been implemented:

  1. Revision of standard question 1 to Why are you interested in becoming an administrator? Special thanks to xaosflux for help with implementation.
  2. A new process, Administrative Action Review (XRV) designed to review if an editor's specific use of an advanced permission, including the admin tools, is consistent with policy in a process similar to that of deletion review and move review. Thanks to all the editors who contributed (and are continuing to contribute) to the discussion of how to implement this proposal.
  3. Removal of autopatrol from the administrator's toolkit. Special thanks to Wugapodes and Seddon for their help with implementation.

The following proposals were identified by the closers as having the potential to gain consensus with some further discussion and iteration:

  1. An option for people to run for temporary adminship (proposal, discussion, & close)
  2. An optional election process (proposal & discussion and close review & re-close)

Editors who wish to discuss these ideas or other ideas on how to try to address any of the six issues identified during phase 1 for which no proposal gained are encouraged to do so at RFA's talk page or an appropriate village pump.

A final and huge thanks all those who participated in this effort to improve our RFA process over the last 4 months.

This is the final update with no further talk page messages planned.

01:46, 30 December 2021 (UTC)

Discretionary sanctions topic area changes

In a process that began last year with WP:DS2021, the Arbitration Committee is evaluating Discretionary Sanctions (DS) in order to improve it. A larger package of reforms is slated for sometime this year. From the work done so far, it became clear a number of areas may no longer need DS or that some DS areas may be overly broad.

The topics proposed for revocation are:

  • Senkaku islands
  • Waldorf education
  • Ancient Egyptian race controversy
  • Scientology
  • Landmark worldwide

The topics proposed for a rewording of what is covered under DS are:

  • India, Pakistan, and Afghanistan
  • Armenia/Azerbaijan

Additionally any Article probation topics not already revoked are proposed for revocation.

Community feedback is invited and welcome at Wikipedia:Arbitration/Requests/Motions. --Barkeep49 (talk) 16:59, 27 January 2022 (UTC)

Discretionary sanctions topic area changes

In a process that began last year with WP:DS2021, the Arbitration Committee is evaluating Discretionary Sanctions (DS) in order to improve it. A larger package of reforms is slated for sometime this year. From the work done so far, it became clear a number of areas may no longer need DS or that some DS areas may be overly broad.

The topics proposed for revocation are:

  • Senkaku islands
  • Waldorf education
  • Ancient Egyptian race controversy
  • Scientology
  • Landmark worldwide

The topics proposed for a rewording of what is covered under DS are:

  • India, Pakistan, and Afghanistan
  • Armenia/Azerbaijan

Additionally any Article probation topics not already revoked are proposed for revocation.

Community feedback is invited and welcome at Wikipedia:Arbitration/Requests/Motions. --Barkeep49 (talk) 04:36, 28 January 2022 (UTC)


I think the community will eventually end up back at some sort of participation metric with more scrutiny at which leagues are included in the metric. It is the cleanest, and makes the most intuitive sense. I also think that there will remain an expectation that articles about athletes must have more than just database coverage. --Enos733 (talk) 16:44, 9 March 2022 (UTC)

If (big if) the interested editors for a given sport agree on the predictor principle, and they do the groundwork to show that, say, 95% of all athletes (probably based on a random sample) in league X (possibly after year Y, and maybe with Z appearances) have suitable coverage that meets the general notability guideline, I think a community consensus can be reached to agree. There may be some editors who will be adamant against participation criteria, but I think a compromise can be found. But that only covers a certain number of sports; (association) football is more club-centric with the relegation/promotion framework, plus there's a national team aspect. (It also runs into the problem of systemic bias of media coverage which some feel strongly about. However that's a much broader problem that really needs an editorial board to resolve.)
Database entries have long been considered to be routine coverage and thus not suitable for meeting the general notability guideline. The problem was that they are sufficient to show that a participation criterion has been met, so editors focus on that instead of trying to find suitable sources to show that the general notability guideline has been met. isaacl (talk) 21:31, 9 March 2022 (UTC)

A barnstar for you!

The Special Barnstar
Thanks for sharing your thoughts on Visual Editing. It's always good to consider other perspectives. Clovermoss (talk) 19:45, 11 June 2022 (UTC)

Copyediting the Criminals on Wikipedia article

Over to you. Hope I didn't cause edit conflicts. Adam Cuerden (talk)Has about 8% of all FPs 04:52, 31 July 2022 (UTC)

Several, but that's the way of simultaneous editing. I previewed each of my diffs before submitting to try to avoid removing any of your edits. I apologize in advance if I accidentally removed anything. isaacl (talk) 04:54, 31 July 2022 (UTC)

Update: Phase II of DS reform now open for comment

You were either a participant in WP:DS2021 (the Arbitration Committee's Discretionary Sanctions reform process) or requested to be notified about future developments regarding DS reform. The Committee now presents Wikipedia:Arbitration_Committee/Discretionary_sanctions/2021-22_review/Phase_II_consultation, and invites your feedback. Your patience has been appreciated. For the Arbitration Committee, MediaWiki message delivery (talk) 17:01, 3 September 2022 (UTC)

Lightbreather appeal

The Arbitration Committee is considering an unban appeal from Lightbreather (talk · contribs). You are being notified as you participated in the last unban discussion. You may give feedback here. For the Arbitration Committee, Barkeep49 (talk) 22:42, 6 September 2022 (UTC)


Hi, your comment in response to my concluding thoughts. I did not respond there because I am trying my best to steer clear of that discussion so I can focus on some of the more pressing NPP issues that are on my plate. You asked about my comment re:DS should apply to all articles, which is not what I meant when I said: Abolish – treat everything like it's under DS and we can eventually eliminate ANI. Atsme 💬 📧 7:55 pm, 10 September 2022, last Saturday (3 days ago) (UTC−4) IOW, I don't want it "officially" applied because I want all DS/AE abolished. My reference was directed to editors and suggesting that they treat everything like it's under DS, and we can eliminate DS/AE, and ANI issues. In retrospect, I should have simply stated that "editors should" treat everything like it's under DS. I suck at brevity, and whenever I attempt it, I tend to omit important details. My apologies. Atsme 💬 📧 14:12, 13 September 2022 (UTC)

Thanks for the clarification. To zoom out to the broader point, it sounds like you're saying that editors should act more collaboratively. As I've written about before, I think we need to foster collaborative behaviour by adopting processes and procedures that encourage it, and make poor behaviour a losing strategy for which no replies are needed. This would mean, though, changes to English Wikipedia's consensus-based decision-making traditions, as they allow a small number of editors to stalemate discussions. So far, there isn't enough support for this type of change. isaacl (talk) 15:28, 13 September 2022 (UTC)
Agree - and it's explained brilliantly in this article. yes Atsme 💬 📧 20:39, 13 September 2022 (UTC)

panel closings

Re: this comment: next time, I'm going to word it, "I am willing to close this if I can get another experienced closer to join me in a panel close." :D No need for me to recommend a panel close. Just "I'll do it, but I want another pair of experienced eyes." Valereee (talk) 18:40, 16 October 2022 (UTC)

Sounds good to me! ;-) isaacl (talk) 19:48, 16 October 2022 (UTC)

Discretionary sanctions review: proposed decision and community review

You are receiving this message because you are subscribed to updates on the Arbitration Committee's discretionary sanctions review process. The Proposed Decision phase of the discretionary sanctions review process has now opened. A five-day public review period for the proposed decision, before arbitrators cast votes on the proposed decision, is open through November 18. Any interested editors are invited to comment on the proposed decision talk page. MediaWiki message delivery (talk) 21:56, 13 November 2022 (UTC)

ArbCom 2022 Elections voter message

Hello! Voting in the 2022 Arbitration Committee elections is now open until 23:59 (UTC) on Monday, 12 December 2022. All eligible users are allowed to vote. Users with alternate accounts may only vote once.

The Arbitration Committee is the panel of editors responsible for conducting the Wikipedia arbitration process. It has the authority to impose binding solutions to disputes between editors, primarily for serious conduct disputes the community has been unable to resolve. This includes the authority to impose site bans, topic bans, editing restrictions, and other measures needed to maintain our editing environment. The arbitration policy describes the Committee's roles and responsibilities in greater detail.

If you wish to participate in the 2022 election, please review the candidates and submit your choices on the voting page. If you no longer wish to receive these messages, you may add {{NoACEMM}} to your user talk page. MediaWiki message delivery (talk) 00:23, 29 November 2022 (UTC)

Contentious topics procedure adopted

You are receiving this message because you are subscribed to updates on the Arbitration Committee's discretionary sanctions review process.

The Arbitration Committee has concluded the 2021-22 review of the contentious topics system (formerly known as discretionary sanctions), and its final decision is viewable at the revision process page. As part of the review process, the Arbitration Committee has resolved by motion that:

The above proposals that are supported by an absolute majority of unrecused active arbitrators are hereby enacted. The drafting arbitrators (CaptainEek, L235, and Wugapodes) are directed to take the actions necessary to bring the proposals enacted by this motion into effect, including by amending the procedures at WP:AC/P and WP:AC/DS. The authority granted to the drafting arbitrators by this motion expires one month after enactment.

The Arbitration Committee thanks all those who have participated in the 2021-22 discretionary sanctions review process and all who have helped bring it to a successful conclusion. This motion concludes the 2021-22 discretionary sanctions review process.

This motion initiates a one-month implementation period for the updates to the contentious topics system. The Arbitration Committee will announce when the initial implementation of the Committee's decision has concluded and the amendments made by the drafting arbitrators in accordance with the Committee's decision take effect. Any editors interested in the implementation process are invited to assist at the implementation talk page, and editors interested in updates may subscribe to the update list.

For the Arbitration Committee, MediaWiki message delivery (talk) 21:47, 14 December 2022 (UTC)

Discuss this at: Wikipedia talk:Arbitration Committee/Noticeboard § Contentious topics procedure adopted

Seasons Greetings you and yours. ―Buster7  15:43, 28 December 2022 (UTC)

A barnstar for you!

The Tireless Contributor Barnstar
For everything you do here. Clovermoss🍀 (talk) 01:21, 3 January 2023 (UTC)
Thanks for the message of appreciation! isaacl (talk) 02:52, 3 January 2023 (UTC)

Contentious topics procedure now in effect

You are receiving this message because you are subscribed to updates on the Arbitration Committee's contentious topics procedure revision process.

In December, the Arbitration Committee adopted the contentious topics procedure, which replaces the former discretionary sanctions system. The contentious topics procedure is now in effect following an initial implementation period.

The drafting arbitrators warmly thank all those who have worked to implement the new procedure during this implementation period and beyond. KevinL (aka L235 · t · c) 19:44, 17 January 2023 (UTC)

Discuss this at: Wikipedia talk:Arbitration Committee/Noticeboard § Contentious topics procedure now in effect

Contentious topics procedure now in effect

You are receiving this message because you are subscribed to updates on the Arbitration Committee's contentious topics procedure revision process.

In December, the Arbitration Committee adopted the contentious topics procedure, which replaces the former discretionary sanctions system. The contentious topics procedure is now in effect following an initial implementation period.

The drafting arbitrators warmly thank all those who have worked to implement the new procedure during this implementation period and beyond. KevinL (aka L235 · t · c) 19:44, 17 January 2023 (UTC)

Discuss this at: Wikipedia talk:Arbitration Committee/Noticeboard § Contentious topics procedure now in effect

Reorganizing the skin RfC

After discussion the RfC has been reorganized, sorting comments into "support", "oppose," "neutral", and "RfC discussion" subsections. You supported keeping the 2022 skin in place, so I placed your comment into the "oppose" subsection. Is that cool with you or do you want it to go elsewhere? --Kizor 23:17, 20 January 2023 (UTC)

I don't really like having support, oppose, and neutral sections for discussions that aren't supposed to be votes. Nonetheless, my statement is accurately categorized as one that answers "No" to the posed question. (On a side note, "Yes" and "No" would be more fitting section headings, I think, as they directly answer the question. I have to think twice about what "Support" means, and that's part of why my statement doesn't use "support" or "oppose". But I understand that everyone else used those terms, so that's just the way it is.) isaacl (talk) 23:26, 20 January 2023 (UTC)
I can understand that. For what it's worth, I'm hoping this'll help people learn and keep track of the facts & arguments, leading to better-informed input. And we had to take action to differentiate the main event from question #2 (as well as any & all questions to come), the confusion was getting out of hand - though I'll be the first to tell you that the need to do something doesn't in itself justify doing some specific thing. (And full disclosure? I'd be lying if I said didn't feel satisfaction during the discussion that my side, support, has had more people. Right now I just feel tired. However, I trust the RfC closers to look at the matter more maturely than me. Ain't hard.) --Kizor 00:55, 21 January 2023 (UTC)

On kindness

I see this talk page is barely above the "fewer than 30 watchers" threshold, while my User:isaacl/Community page is below the threshold, so as an experiment I'll try posting this: I've added the essay User:isaacl/On kindness to my community page, which encourages being kind over acting un-collaboratively. A good companion piece is User:isaacl/Be respectful of others, and User:isaacl/Top ten ways to avoid trolling may be instructive as well. Enjoy! isaacl (talk) 21:16, 12 February 2023 (UTC)

Red-linked no more

I thought "Did isaac finally create a userpage" but no it just turns out to be a link to your contributions. Curious what made you change after all this time? Best, Barkeep49 (talk) 19:58, 6 March 2023 (UTC)

This will probably give you a clue (the signature was not created by me). On some level I felt there was something wrong with it other than the initial uppercase letter, but now I understand it was the blue colour ;-) isaacl (talk) 22:47, 6 March 2023 (UTC)

Discussion on the wording of 3RR

Hi. Can you offer your thoughts regarding the question I asked here? Thanks. Nightscream (talk) 00:46, 7 March 2023 (UTC)


Hello, Isaacl. Please check your email; you've got mail!
It may take a few minutes from the time the email is sent for it to show up in your inbox. You can remove this notice at any time by removing the {{You've got mail}} or {{ygm}} template.

Buster7  19:36, 22 March 2023 (UTC)


Thanks for your diligence in repairing formatting to make discussions easier to follow for those you use screen readers. Just wanted to let you know that it's appreciated. ScottishFinnishRadish (talk) 00:47, 23 March 2023 (UTC)

You're welcome. I had hoped that IndentBot would take on most of this work, but it seems that its operator decided to work on a Javascript-based tool instead to adjust the list-nesting levels (I have no idea what its status is, though). It would be nice if some different wikitext syntax were introduced for branching conversations so that blank lines could be ignored and editors wouldn't have to carefully count the number of prefix characters, but it's not an easy problem to solve, and the difficulty of getting editors to learn and use the new syntax would be a challenge. isaacl (talk) 01:30, 23 March 2023 (UTC)


Hello, Isaacl. Please check your email; you've got mail!
It may take a few minutes from the time the email is sent for it to show up in your inbox. You can remove this notice at any time by removing the {{You've got mail}} or {{ygm}} template.

Soni (talk) 00:28, 18 April 2023 (UTC)

Procedural notification

Hi, I and others have proposed additional options at Wikipedia:Village_pump_(policy)#RfC_on_a_procedural_community_desysop. You may wish to review your position in that RfC. TonyBallioni (talk) 02:28, 20 April 2023 (UTC)

Other idea

Since asked about my previous comments : )
I laid out my other idea there. Though I think both ideas are important. I really think we have an admin problem (retention, new ones, rfa process, etc). And I think providing the community with a de-adminship process, as well as addressing the "block" situation, seems like the way forward. - jc37 17:31, 11 July 2023 (UTC)
Historically, the community has agreed with Barkeep49: there are scenarios where admins should be protecting or deleting a page (or revision) and blocking a user, for example, and so the three are bundled together for effectiveness.
I understand why some community members want to have a voting process to remove administrative privileges. However I don't think that's going to make the everyday commenter at requests for administrative privileges loosen their standards, many of which aren't versed in the arcana of Wikipedia procedures. Admins are seen as managing problem edits and editors, and so people want to get a good feeling of trust for them.
The problem I see is that administrative tasks are like chores: you do them for the community without much recompense than personal satisfaction. That was fine when the editing rate at Wikipedia was within the capacity of willing volunteers, but it's getting harder and harder to find people wanting to take on thankless volunteer tasks. I don't have any good ideas about how to address this. In the 2021 review of the RfA process, I suggested having fixed terms in order to get people willing to loadshare interested (much like how people in the workplace might be in a rotation for some undesirable job), and although I think it's worth trying, I'm not really convinced that would attract a significant number of new volunteers. isaacl (talk) 17:48, 11 July 2023 (UTC)
block and protect typically are responses to behavioural issues. But other than a few things at WP:CSD, delete really isn't much used as a response to behavioual issues. so there's really no reason that we could not have someone who could delete, but not block/protect.
But you are very right that those who are not well-versed in the policy and practice are perhaps less likely to see that, and may just see it as "admins stopping me from doing what I want to do".
And you are also right that it's becoming more work for fewer people, and not just a thankless task, but people now often can constantly have torches and pitchforks a-plenty a-waiting.
In my not-so-humble-opinion, this needs fixing - badly. And has for some time. - jc37 18:17, 11 July 2023 (UTC)
A deleter user group is a proposal that comes up every now and then. Without going back to check, I believe people perceive the need to block spammers who are creating poor articles/adding bad edits. Additionally, there is an overhead in evaluating editors, so some commenters prefer to invest that time in evaluating a candidate for all three permissions at once rather than just a subset.
I don't think the concern for most commenters at RfA is about admins stopping them from doing what they want to do (though it may be for some), but that they want to trust the potential admin.
I've been writing about Wikipedia's structural issues since before 2015 (a quick look at what I think is the oldest quote comes from 2011). Consensus-based decision making doesn't scale upwards, and it stalemates attempts to make significant changes. isaacl (talk) 20:58, 11 July 2023 (UTC)
"Deleter user group"? Nod, that was me, several times lol
WP:MOD, I think was the most recent.
I've been around these discussions this side of forever, and you and I have chatted before about them : )
I've done a lot of deep diving related to user-rights over the years. And been in a LOT of discussions. Even had to talk with the foundation's legal people a few times concerning "view deleted". It's been a long road...
As for "blocking spammers", that's different tasks. The editor likely gets blocked regardless. Then someone reverts. If deletion is necessary, then there's WP:CSD, or even XfD, if necessary.
So, again, there's no real reason to have the same person have the ability to block and delete. We're all just used to that situation because the sysop+ user-right group just has been a dumping ground for abilities by the devs. There's really no task-based reason that these couldn't be split.
But let's forget about the rest of the community for a moment and what we think might gain consensus. I think you likely have an informed opinion on all of this - What would you like to see? - jc37 21:41, 11 July 2023 (UTC)
I'm not sure what scope you are including in that question. If just regarding the bundling of delete, block, and protect, I don't have enough experience with the recent changes and new page patrol to have a strong opinion on a deleter group. From a perspective of vetting overhead, I lean towards those who support keeping the three bundled. isaacl (talk) 21:49, 11 July 2023 (UTC)
Scope - any changes that you might suggest, which you think might make things better. - jc37 11:17, 12 July 2023 (UTC)
You can see User:isaacl/Community for various comments on things to improve. A different way to make decisions is needed to break the stalemate on changes. Semi-binding decisions would enable editors to move forward and adapt to decisions, rather than keep trying to attract a different set of editors to establish a different consensus. This would help the community adopt processes that rewarded desired behaviour, rather than allowing editors to persevere with uncollaborative behaviour. I understand, though, that changes along these lines would significantly alter English Wikipedia's character—for better or worse, making it more hierarchical like other communities/organizations, and there are many wary of this. (On a smaller scale, User:Isaacl/Community/Content dispute resolution toolbox describes some approaches that could be used now to make discussions more effective.) isaacl (talk) 15:52, 12 July 2023 (UTC)
(de-dent) - It was interesting reading that page. I started going through the links and was finding my name popping up on the pages. It was fun to do a page search to see how I (and others) might have commented back then.
All these discussions and so little change.
I've re-read your comments above and I'm not sure what you mean by semi-binding decisions. - jc37 18:03, 12 July 2023 (UTC)
The present status quo is that any decision only lasts as long as no consensus is reached to change the decision, so there's incentive to keep raising an issue until the right set of participants is found to support a desired position, and to wear out any opponents until they lose interest. If there were, for example, an editorial board that made final rulings on content issues, then the incentive for tendentious behaviour and acting aggressively towards others would be diminished, and editors could adapt to and build on the rulings, rather than continue to seek ways to reverse them. I labelled it as semi-binding because of course there can always be a change in circumstances that can cause a ruling to be modified, but this would be due to new information or a new rationale, not just because of a change in participants. isaacl (talk) 20:54, 12 July 2023 (UTC)
Moving away from consensus-based decision making is the key that would unlock the stalemate preventing most change. Better content dispute resolution would reduce the incentive for poor behaviour, which would in turn reduce the need for interpersonal dispute resolution. isaacl (talk) 21:01, 12 July 2023 (UTC)
For another idea on dealing with Wikipedia's scale, see Iridescent's first comment in User talk:Iridescent/Archive 46 § On breaking up Wikipedia, and my followup comments under User talk:Iridescent/Archive 46 § Break: splitting. The idea is to basically turn Wikipedia into a federation of communities, each responsible for their own area and able to set specific rules that best serve its community.
There was a discussion a looooong time ago which was about what to do with "expert editors" - editors who are professionals inn a topic. Like mathematicians, scientists, theologians, etc. They were finding it tough to add things to articles when an army of teenagers would oppose for various, often nonsensical reasons.
So they were talking about options like curation, etc.
And during all of this I proposed a separate wiki called "WikiWorks". For all of those things which are created - ideas, concepts, inventions, structures, objects, art, fiction, etc.
Much later, during what was later termed the BLP disruption, there was talk (including by Mr Wales) that perhaps the answer would be to split all of the biographies (people, groups of people, and events) to a separate WikiBIO wiki. That one had some traction, but in the end, they created the BLP policy and Notability was updated as well.
In hindsight, I think maybe we should have split WikiBIO. And it also likely would have accomplished much of what you were talking about without needing so many sub-wikis.
Who knows, it could still happen someday... - jc37 01:43, 21 July 2023 (UTC)
Here's where I saved the discussion of the one - User talk:Jc37/Proposals/WikiWorks (Note - this was me bringing it up later under a different topic, as I recall.)
No chance I'd be able to begin to find all the threads of discussion on the other lol - jc37 01:49, 21 July 2023 (UTC)
I think the problems of scale would still be an issue with a community solely for biographies, so I don't think that would be enough by itself—it would still need to change to a more effective decision-making method than consensus in order to avoid the structural issues I have discussed. isaacl (talk) 03:15, 21 July 2023 (UTC)
Well, my point was/is that BLPs bring an entire overhead of rules along with them, so by splitting them, it could allow for an entire re-thinking of policy related to BIOs. And would allow for a re-assessment of current Wikipedia policy as well. - jc37 03:49, 21 July 2023 (UTC)
As far as I can tell, the community isn't ready to move away from consensus-based decision making, even if a split took place, and a split could push that decision further down the road. isaacl (talk) 04:38, 21 July 2023 (UTC)
Well, to be fair, I'm not ready to move away from consensus-based decision-making, either, so there's that : )
But there are a fair number of policies which I think exist more for BIO-related things which then bleed into other areas, possibly unnecessarily. - jc37 12:54, 21 July 2023 (UTC)
In my view, if we want less poor behaviour, which would also reduce the need for enforcement actions and thus make the administrator role less onerous for volunteers, we need to reduce the incentives for it. I don't think a split into person-related topics and non-person related topics would result in changes in procedure that would enable this without first changing how decision-making is done, as I think the stalemate would remain in place. isaacl (talk) 14:30, 21 July 2023 (UTC)

User script to copy wikitext for links to comments or headings into the clipboard

I wrote a script, User:isaacl/script/copy-comment-link-to-clipboard, that can be used to copy the link for any discussion comment or for any heading to the clipboard, to enable easy pasting into wikitext. It uses the ID used by the mw:Talk pages project/Notifications feature, so the comment will be highlighted. For headings, it also allows you to use the usual ID used by the table of contents. A caveat: I think there are still race conditions that make the script behave imperfectly. If anyone is interested, see the documentation page for more details. isaacl (talk) 21:12, 21 July 2023 (UTC)

As someone with an excessive number of user scripts, I tried this out. I don't think there were any issues caused by script conflicts, but there are 3 issues I found:
  1. The copy function does not work for me. This is because I am using a browser that doesn't support the modern method of copying. Instead, you need to append a textarea element to the document, fill it with the text to be copied, select the text, and then copy it (Nardog has a script that does this)
  2. Both a <> and <h /> appear before a heading; I assume only a <h /> should appear.
  3. More of a suggestion, but it might be helpful to also allow the page title to be copied.
I use Factotum, so won't be using this script, but I hope you found this feedback helpful! — Qwerfjkltalk 21:26, 23 July 2023 (UTC)
Specifically regarding 1 , Nardog's script does this:
let $input = $('<input>').attr({
			type: 'text',
			readonly: '',
			style: 'position:fixed;top:-100%'
		let copied;
		try {
			copied = document.execCommand('copy');
— Qwerfjkltalk 21:31, 23 July 2023 (UTC)
Thanks for testing it out! I didn't bother trying to figure out how to suppress the </> target before a heading, so it works as intended, if not necessarily optimally. Although I'm not sure I see the use case now, perhaps one day I'll want to link to a section heading and have it highlighted.
Thanks for the info on a legacy way to support copying to the clipboard and the code fragment; I'll take it under consideration. It seems Safari is the Grade A category browser that either doesn't support the Clipboard API entirely, or even with more recent versions within the Grade A category, doesn't support the writeText() method outside of gesture event handlers. I'm not sure if there's an easy graceful degradation to the legacy approach.
Since the page title can be readily selected and copied, I didn't think of adding a target for it. I appreciate the feedback! isaacl (talk) 22:00, 23 July 2023 (UTC)