User talk:Valereee

Need help and don't know where to find it? Help!

non-regulars answering edit requests at articles that have plenty of regulars

Copy-paste from Talk:Killing of George Floyd

EEng wrote:

• (Idea 1) One way would be a template with parameters X and Y. When present on a talk page, it causes edit requests on that page to not appear in the patrol queue (or whatever they call it) if there have been at least X edits (non-bot edits) to the talk page within the last Y days. Something like that.
• (Idea 2) Or maybe that should be the default all the time, no template needed.
• (Idea 3) Or maybe either of the above, plus if the request remains unanswered after Z days, then it goes in the general queue of edit requests needing answering.

Unfortunately this will take some technical work, not sure how much though. How about you and I commit to remembering to raise this at VP.

I really like 2+3, but 1+3 might be an easier sell. An added benefit is that this represents lessening the burden on editors patrolling requested edits.

Is there any perceived benefit to noninvolved editors responding to edit requests? It's possible the regulars at an article could be owny enough that they just mark all requested changes as answered/not done. Right now they'd have to answer those requests within minutes to ensure no fresh set of eyes shows up. Changing it to at least Z days might be seen as a downside? —valereee (talk) 13:58, 5 August 2020 (UTC)

I think the right question is Is there any perceived benefit to noninvolved editors responding to edit requests when there are editors active on the article's talk page on a daily basis? Answer: No, and in fact it's a net negative. Semi-protected articles (and semi is, I suspect, by far the most common form of protection) are that way because there're (shall we say) lots and lots of people editing, and therefore available for handling edit requests.

So on reflection, I wonder how useful this patrolling-by-drive-by-editors actually is. Unless there's some flaw in my logic above (and I stand ready to be corrected on it), I would think that the vast majority of edit requests, if patrollers would just leave them alone, would be answered within 24 to 48 by editors active on the page. EEng 21:46, 5 August 2020 (UTC)

^{( Buttinsky)} - noninvolved is defined in a few dictionaries, but not in Oxford. I checked to see how it's trending and it flatlined. Just curious...maybe it's just me being picky but wouldn't uninvolved editors be the better choice? ^Atsme _Talk 📧 18:48, 8 August 2020 (UTC)

Atsme, totally —valereee (talk) 20:30, 8 August 2020 (UTC)

WP:UNEVOLVED. EEng 01:51, 9 August 2020 (UTC)

EEng, there are 10,000+ semiprotected articles. Orinx has 2 watchers, 1 of whom visited recent edits. —valereee (talk) 12:50, 6 August 2020 (UTC)

And interestingly...there are ~20 current requests at semiprotected edit requests. One, at Balkans, is a month old. Eight are from today. I'm sure some patrollers come in and start with the fresh requests, figuring some of them will be easy to handle. And there doesn't seem to be any instructions for people on how to handle requests, unless it would be somewhere other than Wikipedia:Edit_requests#Responding_to_requests_and_mandatory_copyright_attribution —valereee (talk) 14:03, 6 August 2020 (UTC)

(Saw the comment on the article's Talk Page, and followed the discussion here) As another possible idea (independent from the ones above), might it help to write a polite essay on the problem of drive-by patrolling editors who flip edit requests to "answered" while posting useless and/or unhelpful comments that frustrate newbies? The intended audience would be the problematic drive-by editors themselves, explaining to them why they cause more problems than they solve by their behavior (including examples). Then create a WP shortcut to that essay page (perhaps "WP:EDITREQUESTFAIL" or something more catchy), and when you see a drive-by editor make a problematic edit like that, just revert them with a polite edit summary like "Reverted good faith but unhelpful comment per WP:EDITREQUESTFAIL". Doing so would 1) remove their useless post, 2) flip the "Y" back to "N" on the answer (to attract a better answer from a more knowledgeable editor), and 3) politely direct the drive-by editor to a well written page where he or she can learn why their short-sighted and problematic edit was reverted. I suspect most of the problematic editors would learn quickly and stop doing that after a single instance; only obtuse patrollers would go right back to the Talk Page in question to combatively revert your revert of their useless post. Would instituting something like this be worthwhile, and gradually educate the community over time to stop making those kinds of unhelpful posts that mess up the edit request process? Regards, AzureCitizen (talk) 23:55, 5 August 2020 (UTC)

AzureCitizen, it's not a bad idea. The problem here was that the person patrolling, who was just trying to help, probably should have just recognized the situation for what it was: a requested edit that may or may not be a reasonable change to ask for, to an article currently being heavily edited and with hundreds of active watchers. I believe the correct decision is move on, as someone brand new to this article is unlikely to be able to answer almost any edit request better than someone already working here. —valereee (talk) 11:57, 6 August 2020 (UTC)

EEng invited me here from the article talk because I was "missing the point". Conceptually, I have no problem if we want to optimize the edit request process site wide. However, the edit request response that spurred this was fine. While the request did not cite any sources, we don't need a response that "us regulars know everything there is to know, it's been discussed ad nauseaum, and consensus ain't changing." Perhaps there is something we missing before, there is new information, or this editor has a new angle? Or maybe they're just wrong or trolling. In any event, inviting them to establish consensus is a neutral response that encourages good-faith editors and does not feed any would-be trolls.—Bagumba (talk) 05:45, 6 August 2020 (UTC)

Bagumba, I guess I don't agree that the response was fine. It felt to me like someone who decided to help out at requested edits, dropped in, made their best guess as to what might be a halfway reasonable response, and moved on to the next request. It wasn't helpful to someone making their first edit. What does 'please gain consensus before suggesting this alteration' even MEAN to someone making their first edit, much less their first edit request? That is a very high-traffic article with HUNDREDS of watchers, so there are many people available who understand the article, and answering an edit request there right now probably requires some level of familiarity or willingness to become familiar with it. This isn't some West Texas high school protected because someone keeps changing the name of the principal from Patsy to Pussy and someone's making an edit request to ask we change the stated location because they just put up a new building. —valereee (talk) 11:48, 6 August 2020 (UTC)

... made their best guess as to what might be a halfway reasonable response ... Maybe, maybe not. I as a semi-regular on that page would likely have said something as neutral and avoided outright saying the OP was wrong or assume I was necessarily up-to-date on the latest sources. You do have a point of regulars throwing the word "consensus" around, which might not be accessible to a complete newbie, but neither is pointing them that a way to an FAQ or giving them the impression that consensus cannot change because I am all wise (well ... I am, but ...) While I'm not saying edit request patrolling can't be improved, I am saying that the response in this specific case was fine, even if the (speculated) rationale behind it might not have been.—Bagumba (talk) 12:35, 6 August 2020 (UTC)

Bagumba, believe me, I've seen regulars at a page give unfriendly and unhelpful and sometimes deliberately obtuse responses to edit requests. Let's for the sake of argument leave aside the quality of this particular response; I'm not even sure it's important. My feeling is that on a page that is currently being heavily edited and is actively watched by hundreds, an edit request response from someone who is unfamiliar with the article isn't likely to be as on point as the most-helpful response that could be given by the most-well-intentioned regular, and so when a patroller lands on a talk page at such an article, it's highly likely the best move is to move on to the next edit request. Would you be more likely to agree with that? —valereee (talk) 13:03, 6 August 2020 (UTC)

If we move away from this particular response, I'm indifferent on any process changes. Cheers. —Bagumba (talk) 13:17, 6 August 2020 (UTC)

I don't understand. What does move away from this particular response mean, exactly? EEng 17:12, 6 August 2020 (UTC)

EEng, it was in response to Valereee's ... leave aside the quality of this particular response—Bagumba (talk) 00:31, 7 August 2020 (UTC)

Got it. EEng 01:15, 7 August 2020 (UTC)

an edit request response from someone who is unfamiliar with the article isn't likely to be as on point as the most-helpful response that could be given by the most-well-intentioned regular, and so when a patroller lands on a talk page at such an article, it's highly likely the best move is to move on to the next edit request – Yes, though I'd put it a bit more strongly: Even a mediocre response from a regular is likely to be at least as good as any response make by someone unfamiliar with the article. I've bolded part of your post because it's pretty much what we want, though I'd add that even better than the patroller recognizing they should move on would be for the system to never take the patroller to the page at all. EEng 17:12, 6 August 2020 (UTC)

Yes, but that would be a training issue. Having the edit request just not show up at the various lists for 24 hours would likely fix the problem without instruction creep and retraining of every new patroller. There's just really very little reason for an edit request to be funneled to a random patroller before 24 hours have gone by. Any page that has an urgent change needed is likely to have multiple editors headed there or working there already. —valereee (talk) 17:30, 6 August 2020 (UTC)

I agree with everything you just said, with the exception that I don't know what it is you're saying would be a training issue. EEng 01:19, 7 August 2020 (UTC)

EEng, sorry, by 'training issue' I just meant that trying to get patrollers to recognize when their help isn't needed means 1. adding to the instructions and 2. getting each new patroller to actually read and internalize the instructions.

If instead requested edits simply don't show up at Category:Wikipedia semi-protected edit requests and User:AnomieBOT/SPERTable and wherever else they transclude to for say 24 hours, we don't have that same issue. We don't have to train patrollers. —valereee (talk) 11:46, 7 August 2020 (UTC)

Right. That's what you said and that's what I agreed was the best thing to happen. We are in violent agreement. EEng 12:56, 7 August 2020 (UTC)

I was responding to with the exception that I don't know what it is you're saying would be a training issue. —valereee (talk) 13:15, 7 August 2020 (UTC)

I think you must be reading something I said backwards, but no matter. So... shall we summarize the possible changes to the process we're contemplating, and then where do we raise this? EEng 17:45, 8 August 2020 (UTC)

That would be not unheard of, and yes. I think we could raise it at Wikipedia talk:Edit requests or at Wikipedia:Village pump (policy). My best guess would be Village pump policy; only 39 watchers visited last edits at the talk page for edit requests.

drafting proposal

Something like:

Patrollers of requested edits at semiprotected articles sometimes are the first to visit a request at even heavily-edited talk pages. Often some familiarity with the article and recent talk page discussion would allow for more helpful response, and on pages that are currently being heavily edited, there are usually many editors available to help. We’re suggesting that edit requests on talk pages that are currently being heavily edited simply not show up at at Category:Wikipedia semi-protected edit requests and User:AnomieBOT/SPERTable for 24 hours, or that they're greyed out for the first 24 hours to indicate they aren't in urgent need of help from patrollers, to give regulars at high-traffic articles a chance to respond. This will lessen the burden on patrollers at edit requests and increase the likelihood new editors’ requests will be answered by someone familiar with ongoing discussions at that article.

That's terrible, but as a draft. —valereee (talk) 18:13, 8 August 2020 (UTC)

EEng,I've given it a copyedit. —valereee (talk) 14:27, 10 August 2020 (UTC)

Will be distracted for the next week or so but don't let me forget to get back to this. EEng 02:14, 13 August 2020 (UTC)

I still have this in my ping list. Right now I'm busy grinding someone into a grease spot. EEng 00:41, 20 August 2020 (UTC)

EEng, same —valereee (talk) 01:05, 20 August 2020 (UTC)

Oh, you're grinding someone into a grease spot as well? That's a side of you I haven't seen before. EEng 01:53, 20 August 2020 (UTC)

Not my choice; they're pretty much forcing me to. —valereee (talk) 16:04, 20 August 2020 (UTC)

EEng is this still on the radar? —valereee (talk) 21:53, 15 September 2020 (UTC)

Funny, I was just looking guiltily at it last night. The answer is yes, but I'm still just too distracted to concentrate on it. Don't worry, I never forget a commitment. EEng 00:48, 16 September 2020 (UTC) Not that I remember, anyway.

Zero worries, there's no urgency. —valereee (talk) 01:04, 16 September 2020 (UTC)

Still on my mind. EEng 05:06, 7 October 2020 (UTC)

The elephant never forgets. EEng 02:34, 25 October 2020 (UTC)

Well, I really wish I'd followed up on this before now. Every day at T:Joe Biden we've got people swooping in out of nowhere saying the same stupid thing over and over: Get consensus first, Get consensus first, Get consensus first, Get consensus first, Get consensus first, Get consensus first, like they've helped by saying that. I'm so sick of people doing mindless things that help not at all and waste others' time. EEng 04:29, 10 November 2020 (UTC)

Silver lining: we now have another really good example of why it makes sense to propose something like this. —valereee (talk) 09:56, 10 November 2020 (UTC)

Arbor-treeish break

I have another thought on how to go about this, but first I need to understand something. Where do these protected edit requests come from? What I mean is, how do IP editors stumble into the place where they're told "You can't edit this article, but if you fill in this box that will make a post to the talk page, with this little template attached"? I had imagine that it pops up when they try to edit the article, but I logged out just now and I realize that, in fact, when an IP tries to edit a protected article, there is simply no edit button for them to click. So where, exactly, do these templated posts come from?

The reason I ask is that, it seems to me, the way to fix our problem is just to make is so the edit-request template is omitted from the post. In other words, we don't need options for how the request will be handled, what we need an option to make the post just a simple post, without the request template. EEng 19:10, 10 November 2020 (UTC)

EEng, I think these must be people who are used to being able to edit, or people sophisticated enough to realize viewing source might let you edit. If you log out and click view source, you get an edit request button. —valereee (talk) 19:18, 10 November 2020 (UTC)

Ah yes, it's all coming back to me now. OK, so we need to investigate how that template pops up, and what mechanism can be inserted to modify that on an article-by-article basis, perhaps based on some magic word or template inserted on the article's talk page. EEng 20:03, 10 November 2020 (UTC)

So, I've already poured myself a glass of wine. Don't judge. But why is that better than having edit requests for articles (that have 400+ watchers who visited recent edits/have 50 edits per day) or edit requests less than 24 hours old simply not show up at the edit requests dashboard? That's probably where most of these eager beavers are coming from. —valereee (talk) 20:21, 10 November 2020 (UTC)

Not to butt in, but I saw "investigate how that template pops up". I'm thinking you may be referring to the set of templates that is MediaWiki:Protectedpagetext (shown when clicking "view source"). The one shown in the header after you click "submit an edit request" and are redirected to the talk page is Template:Edit extended-protected/editintro. The template popping up in the post itself is the preload: Template:Submit_an_edit_request/preload. Mobile editors can't see any of this, though, and when they click the pencil they just see "This page is protected to prevent vandalism", so how on earth they're submitting requests I don't know...

Regarding the "no consensus" replies, probably just a habit of using the userscript and giving the generic responses I think. I've been guilty of it too, but now that you mention it, I suppose it is a pretty unhelpful thing to reply with. Also worth noting Module:Protected edit request shows the banner. ProcrastinatingReader (talk) 01:33, 11 November 2020 (UTC)

PR, butt in any time. :) —valereee (talk) 14:28, 11 November 2020 (UTC)

EEng, found this one today: Special:Permalink/1006579385#Semi-protected edit request on 13 February 2021. The request was answered in seven minutes with canned "unclear what you're asking" response to someone's first edit. —valereee (talk) 17:21, 13 February 2021 (UTC)

Believe it or not, in my little ding-a-ling bell notification thingamajig at the top of every page, every day I skip over an open item I leave there reminding me to get back to this. Do not lose hope. EEng 18:50, 13 February 2021 (UTC)

No worries! Sorry to ping unnecessarily! —valereee (talk) 20:20, 13 February 2021 (UTC)

It's still on my to-do list. EEng 03:33, 8 March 2021 (UTC)

Thinking of this problem again after recent events. ProcrastinatingReader (talk) 11:19, 13 May 2021 (UTC)

@ProcrastinatingReader, sorry, not enough coffee yet...recent events? —valereee (talk) 12:15, 13 May 2021 (UTC)

lol nevermind, REALLY not enough coffee! haha —valereee (talk) 12:16, 13 May 2021 (UTC)

examples

25 May 2021 —valereee (talk) 21:52, 27 May 2021 (UTC)

getting up to speed

Regarding this edit: this is just a guess, so it could be wrong, but I think the editor to which you were replying may have interpreted "you" to refer to them. (You first used "they" to refer to the returning editor, which may have led to this confusion.) Either way, though, I do agree the comment feels patronizing to whomever it is addressed. isaacl (talk) 21:40, 11 July 2021 (UTC)

On second thought, re-reading the thread, I'm more doubtful of my guess. The editor may just not be pleased with the tone of your comment. isaacl (talk) 21:43, 11 July 2021 (UTC)

@Isaacl, whichever, I'm still interested in what made you feel the comment was patronizing? —valereee (talk) 01:32, 12 July 2021 (UTC)

Mentioning children at swim meets using colloquial language makes it sound like you're considering the activity to be of lesser importance to the activity of familiarizing oneself with the English Wikipedia editing environment. I appreciate you may have been trying to make a light-hearted joke. Note there is no need to ping me in replies. isaacl (talk) 01:56, 12 July 2021 (UTC)

@Isaacl, not at all! I don't know where you are in your progression through life, but the 20+ years most people spend raising children results in their time for other things during that period being severely limited. People give up their own activities to deal with much of it because it's important. I know parents who spent as much time or more on their kids' sports as the kids do. I picked competitive swimming because it's pretty time-consuming for parents and can last from the time a kid is six until they go off to college. That's how it should be -- no one should be editing instead of taking care of their real life responsibilities. But that doesn't mean that as an admin you're able to just pick up where you left off 8 years ago now that life has gotten less busy. I doubt the other editor thought I was referring to him. He just enjoys being prickly with people who aren't agreeing with him correctly. :) —valereee (talk) 11:05, 12 July 2021 (UTC)

Val, for whatever it's worth, I didn't find it patronizing in any way whatsoever, and I really strained to find even a kernel of that. PS: 9-year break, one edit per year, 2013-2017. Oh no, I think I just said the quiet part loud! El_C 14:00, 12 July 2021 (UTC)

lol...yeah. I don't know how we fix this. I do recognize the 'crats feel like they're between a rock and a hard place, and none of them want to invoke the whole "reasonable belief" clause. I'm sure they have their reasons for that, but I don't really understand. Someone needs to run for 'crat on a "reasonable belief" platform. :D —valereee (talk) 14:16, 12 July 2021 (UTC)

Oh, and thanks, re: patronizing. I was completely puzzled. I'm like "how is it patronizing to assume people have more important things to do (like raising children) that might keep them from editing for years at a time?" I was glad to have Isaacl turn it around for me: that what I said could be interpreted as "if you want to spend your time doing silly things like attending the kids' sporting events rather than focussing on the serious bizniz of editing, that's on you!" From the time I became a fluent reader I probably spent 20+ hours a week reading. A book a day or more was not unusual. But once the second kid came along, I rarely had big-enough chunks of time to do more than read the newspaper. —valereee (talk) 14:36, 12 July 2021 (UTC)

It's a consequence of the problems with consensus-like decision making, which I've written about before. As a group grows larger, it's becomes impossible for it to remain highly aligned in its goals, which is needed for consensus to work. In particular, the self-selected segment of the English Wikipedia community that likes to discuss these types of matters is very diverse, including a libertarian influence dating back to the founding of the site. Thus those who try to make decisions on behalf of the community are typically very conservative in their approach. English Wikipedia's consensus-based decision-making traditions stalemate just about every major change to Wikipedia's processes. isaacl (talk) 14:48, 12 July 2021 (UTC)

Yes, it's unusual that we actually get things done in the larger wikipedia, although it does happen. What I see most often is that while we might have consensus there's a problem that needs solved, but we seldom get to consensus on how to solve it.

Wikipedia:Requests for comment/2019 Resysop Criteria (2), where I see you participated, was actually an interesting case. Because we'd already agreed there was a problem that needed solved, we were able to get some solutions agreed on. Although we did have to reaffirm in Q14 that the first RfC (does resysop criteria need to be tightened/loosened/remain at status quo) provided some teeth for the second one. In that case I think the fact the overwhelming majority of non-admins thought it needed to be tightened was persuasive to some admins whose initial reaction was that this was a solution looking for a problem. —valereee (talk) 15:31, 12 July 2021 (UTC)

Sorry, I don't agree that your Q14 was needed. If one or more of the proposals gained sufficient support, then it would have been enacted, regardless. Proposal 1 was sufficiently nebulous to garner support. Proposal 3 only imposed a mild constraint on individual bureaucrats, and there's a significant amount of people who like the theory of "have a committee make a decision", if not necessarily the implementation. Personally, I don't think there is reflexive opposition by administrators. I think many in the community feel that privileges are granted based on trust, which includes trusting the individual to smoothly re-adapt to engaging once again with the community.

In many cases, it's hard to say if there is a consensus that a problem exists, when in reality, that group encompasses subsets which each think a different underlying root cause exists, often due to differing underlying goals. That misalignment in goals or viewpoints is why consensus fails to form on how to address concerns. isaacl (talk) 15:56, 12 July 2021 (UTC)

It may not have been. I think it helped, but YMMV.

I think there's pretty strong evidence that being an administrator vs not was key in whether you believed resysop should be tightened. The fact it was the sysops who tended to think it didn't need tightening and the non-sysops who thought it did is pretty telling, IMO. There's something there. Why would sysops be more likely to trust the individual to smoothly re-adapt than non-sysops? —valereee (talk) 16:07, 12 July 2021 (UTC)

I haven't done an analysis, so I don't know if that is true or not. The problem, though, is that since the incoming rates for administrators has dropped off dramatically, there is a correlation between being an administrator and level of experience on Wikipedia, as well as the entry date into Wikipedia. Thus it's hard to decouple these influences. Long-time contributors remember a smaller community during their formative editing years, and have a different view on editor behaviour and motivation compared with newer contributors. isaacl (talk) 16:29, 12 July 2021 (UTC)

Eh, I've been editing over fifteen years, edited mostly logged out for a decade, and didn't run RfA until 2019. —valereee (talk) 19:08, 12 July 2021 (UTC)

Sure, obviously each generation doesn't all think the same way (we have differing viewpoints, after all). To take one example, though, those who remember the Eastern European mailing list problems and WP:Esperanza first-hand likely see off-wiki discussion through a different lens than those who grew up gaming on Discord. isaacl (talk) 20:39, 12 July 2021 (UTC)

Can you elaborate? I know it's a tangent, but I've recently become interested in what's happening on Discord. I saw someone say something along the lines of "it's not that we don't get any actual work done there, we do" and my knee-jerk reaction is that work should be done in public, and Discord isn't public enough. What kind of work is done there that wouldn't be better done in Talk or Wikipedia space? I mean, I know it's a place people go to quickly get admin attention to an urgent vandalism issue, which seems fine. —valereee (talk) 11:47, 14 July 2021 (UTC)

Do you mean elaborate on why people like to use real-time communications methods like IRC or Discord? (Just a note that I don't use either of those, though I use other messaging apps.) In User:Isaacl/Consensus requires patience I wrote about challenges with online decision making in a global community. You can return to a conversation in Wikipedia after being away and see that it took a whole different direction, without your input. This clustering of responses based on time zones can make the discussion less effective. Real-time discussion doesn't solve this, because it still forces everyone to be available at the same time, but it helps on a microscale. With wiki-based discussion, you can have a lot of simultaneous comments being made in multiple branches (such as this particular conversation) and it's easy to start getting lost with who is saying what where and where to respond. Real-time conversation is linear (*), and as I wrote in my essay, people can make timely interruptions to avoid having one person dominate conversation, which helps enable broader participation. Also presence indicators alters conversational flow as well (it took me by surprise the first time I starting using messaging apps how much difference it makes): you can adjust your level of engagement and expectations for responses with each person based on their presence.

(*) The typical online forum discussion thread format is also linear and remains popular (at least in part) for that reason: it's much simpler to catch up when returning. Just find the last post you previously read and continue.

Not sure if you saw my comment regarding minimum requirements for participation on English Wikipedia, and Barkeep49's reply. I prefer maintaining the minimum requirement of being engaged on this site alone, and due to the global nature of the English Wikipedia editing community and diversity of devices used to access Wikipedia, I think consensus would probably agree with me. But I recognize that this is in part a personal bias of mine. For example, if the WMF deployed its own lightweight real-time messaging service, supported on a wide number of devices, that followed WMF polices and was fully logged, perhaps consensus on English Wikipedia would shift. isaacl (talk) 20:24, 14 July 2021 (UTC)

I appreciate that was not your intent so no explanation is required. I'm just providing insight on how your tone may have come across (unintentionally on your part) to some others. Again, there's no need to ping me in replies. isaacl (talk) 14:34, 12 July 2021 (UTC)

(ec) @Isaacl I was grateful to you for explaining! :) —valereee (talk) 14:37, 12 July 2021 (UTC)

Whoops, sorry on the ping! hahahaha ADD---->—valereee (talk) 14:38, 12 July 2021 (UTC)

Regarding approaches moving forward, though I appreciate why some editors are concerned about various situations where administrative privileges are restored, I suspect the vast majority of editors don't care that much about the details of the processes related to granting administrator rights. In terms of effect-to-effort ratio, personally I think trying to get more editors to assume administrative duties for the first time is key. isaacl (talk) 15:00, 12 July 2021 (UTC)

I think you might be surprised at how many highly-active non-admin editors think it's unfair that someone who was sysopped in August of 2009, almost immediately started editing less frequently, soon stopped editing regularly at all, has made fewer than 1000 edits in the past 11 years and fewer than 100 in the last 7, now wants to come back in and deal with their behavioral issues. I have no proof, but personally I suspect many non-admins who don't have a problem with this are the ones who are hoping to pass an RfA themselves one day. :D

The reason I care about this is because something between some and many non-admin editors feel it's unfair, and some not-zero-number have a level of resentment over it. I think we can deal with the odd out-of-touch admin who comes in and makes too many mistakes, even bad ones, but it's hard to overvalue editor morale. Non-admin editors are the backbone of this site. I strongly believe we need to respect their feelings on this. —valereee (talk) 15:54, 12 July 2021 (UTC)

In terms of numbers, I think the vast majority of editors pay no attention to the administration of the web site, and are happy just making good edits. As long as they can do so undisturbed, and don't see articles being overrun with vandalism or promotional content, they just assume it works. That's why I think the best way to keep most editors happy (with respect to administrator processes) is to refresh the administrator pool to alleviate fatigue. isaacl (talk) 16:07, 12 July 2021 (UTC)

So long as we allow admins to vote in sysop RFCs, there will never be reform. None of the other stuff is anywhere near as much of an obstacle as the reliable voting block of admins who oppose reform RFCs. (Many of whom are not very active, but in numbers they far outweigh the admins who are pro-reform, such as val.) But good luck trying to get admins to agree to sit out sysop/desysop/resysop RFCs... and if only the pro-reform admins sat out, it'd make the problem worse. Levivich 16:03, 12 July 2021 (UTC)

Non-admins vastly outnumber admins, so I don't agree that this an implacable obstacle. Plus there are prominent admins such as TonyBallioni who favour reform. isaacl (talk) 16:11, 12 July 2021 (UTC)

I suspect that the level of pro-reform feeling among admins is directly correlated to date-of-sysopping. There are likely complex reasons for that. —valereee (talk) 16:16, 12 July 2021 (UTC)

Perhaps; that would point to their entry date into English Wikipedia as being a more significant factor, versus whether or not they'd gained administrative privileges. isaacl (talk) 16:23, 12 July 2021 (UTC)

I can think of a simple reason: self-interest. Levivich 16:51, 12 July 2021 (UTC)

I tend to agree with Levivich. It's their bull being gored.

Why in the world would the average editor -- most of whom probably think admins are paid staff -- care about admin fatigue? —valereee (talk) 16:13, 12 July 2021 (UTC)

As I said, they don't: they just want everything to work behind the scenes. I feel the best way to support this in terms of the administrator processes is to ensure there is a healthy incoming flow of administrators. (There are of course a lot of other ways to improve the lives of average editors that are unrelated to administrator processes.) isaacl (talk) 16:18, 12 July 2021 (UTC)

You said it yourself: non-admins vastly outnumber admins, but they also vastly don't care about internal workings, so non-admin RFC participants don't vastly outnumber admin RFC participants. As a group, admins are vastly overrepresented in these RFCs, and non-admins are vastly underrepresented. This is how decisionmaking on Wikipedia works: it's up to whomever shows up to decide, and admins show up at a far higher rate than non-admins to these RFCs, which is why things are the way they are. It's why adminship is a lifetime gig. If admins were prohibited from !voting, we'd have had term limits and community desysop years ago.

What really grinds my gears is the admins who barely do anything, editing or admin-tool use, but still make time, sometimes even to come out of retirement, to oppose sysop reform like term limits, and they do it on the grounds such as "we'll have too many RFAs"... cough, bullshit, cough. :-D Levivich 16:51, 12 July 2021 (UTC)

Yeah, all those RfAs! One every couple weeks last year. Sheesh, what a time sink. —valereee (talk) 18:50, 12 July 2021 (UTC)

The most recent proposal for term lengths suggested holding 15 RfAs a week for a year and half to clear the backlog of current admins who would be due for a reconfirmation. If we're doing this for real and not just for show, that's a lot of effort with a corresponding opportunity cost. isaacl (talk) 23:29, 12 July 2021 (UTC)

Only if we assume everyone will run. I think in reality it would be less than 100 total. If we implemented staggered terms we could do one or two a week for a year or two, which is not too many. Levivich 03:28, 13 July 2021 (UTC)

You think less than an eighth of the administrators with over two years of tenure would run (based on the number of 876 eligible admins in the RfC)? Currently, there are 488 admins with 30 or more edits in the last two months (according to Wikipedia:List of administrators). Based on this I'd think there would be closer to 500 admins who would be willing to continue to serve. Yes, we could spread it out over a longer period than a year and a half. Over two years it's about 5 RfAs a week, and then we start over again (with maybe about ~13% attrition, based on Worm That Turned's figure of 50% attrition over ten years). Let's say a solid investigation into each takes 30 minutes, and at least three people review each administrator. That's 7.5 hours a week not doing something else to contribute. Now three people sounds a bit low to do a good review, but in practice, I think people are going to tire of doing these week after week forever, and we'd be lucky to get three. As I suggested, if we were to have term limits, I'd prefer to introduce term limits for new admins, and let attrition handle the existing ones. We could hurry that along a bit by introducing a one-time term limit date of, say, ten years from now for current admins. But I'd rather focus on the underlying issue: is it possible to get more people to sign up for thankless administrative tasks, so the long tail of earlier admin cohorts loses significance? Or, as others have suggested, should we be figuring out how to operate with fewer admins? The key issue there is that's inevitably going to mean some other hierarchy being put into place to manage content, and the community is highly resistant to this. But that might be the only path forward for long-term sustainability. isaacl (talk) 04:32, 13 July 2021 (UTC)

(Non-administrator comment) I've been following this conversation for a while now, as well as the original thread on BN, and I'm struggling to find an actual problem this solves? Is there a high number of old-timer bad admins? Term limits are generally something that do not help - they screwed up the government of my state by running people out of the job who actually have experience. If we're forcing admins to run for reconfirmation RfAs, I also think that is counterproductive - I want admins to be willing to make hard decisions, and if you're worried about playing politics, you're less likely to do that. The bar to desysop is intentionally high - you have to actively do things wrong - and I don't see the problem with that. Elli (talk | contribs) 13:14, 13 July 2021 (UTC)

@Elli, for me it's not the risk of bad old-timer admins, although I do know that can be a problem. But we can deal with that, IMO. For me it's about the perceived unfairness and the effect of that on perception on editor morale. We have to deal with that perception, and I don't think we can deal with it simply by telling people they're wrong to feel that way.

When we ran the first RfC on whether automatic resysopping should be tightened up, the divide between admins and non-admins was quite significant. 80% of non-admins !voted to tighten restrictions. (I can't recall the rest of the numbers, but I believe it was maybe 2/3 overall to tighten so obviously a much lower #of admins said tighten.) My feeling is that when the "have-nots" think the "haves" maybe have a little too much, the haves should listen lol. Instead we had many many admins saying, "solution looking for a problem" and "not broke, don't fix it." —valereee (talk) 13:56, 13 July 2021 (UTC)

I guess as a non-admin I'm in one of the 20% :D I don't want to speculate on the motives of the 80%, and while I'm sure they are acting in good faith... I'm not sure their policy would actually make things better. At least, I haven't seen convincing evidence that it would.

I suppose an interesting related question is if non-admins support RfA being easier or harder compared to admins. Wasn't there that discretionary zone RfC a while back? Would be interesting to analyze, I think. Personally, my perspective comes from wanting more admins as, as well as wanting the path to adminship to be easier and the level of elevation above the rest of the community to be minimal (after all, it shouldn't exist at all - we're all equals - but we all know that it does to some extent). I think making it more of a big deal to get the tools would only make that worse. Elli (talk | contribs) 14:00, 13 July 2021 (UTC)

Combining The bar to desysop is intentionally high - you have to actively do things wrong - and I don't see the problem with that. with wanting the path to adminship to be easier, and I hear you saying you think adminship should be easy (or easier) to obtain and difficult to lose. Doesn't that strike you as a bad idea? Admins are the only people (WMF aside) who can stop people from editing (either by blocking accounts or protecting pages), and who can stop people from reading (by deleting and revdeleting) "the encyclopedia that anyone can edit" (and read). That's huge IMO. The most powerful editors are admins, IMO. Making that easy to get and difficult to lose seems like a horrible way to set things up :-) I agree with making it easier to get, and I think that making it easier to lose will make it easier to get: people will be more likely to support RFAs if adminship wasn't a lifetime appointment. That's the #1 problem IMO that things like terms, term limits, activity requirements, community desysop etc., solves: it makes adminship easier to obtain, and thus keeps our admin core refreshing constantly (more new admins, more frequently) while also checking the potential for power abuse (by removing admins more frequently, and by having a higher % of editors be admins at some point, thus diffusing the power amongst the editor base, instead of concentrating it in ~100 "experts" who have been here for 10+ years [you know, those powerhungry fascists like val ;-)], which is what we have now). Levivich 16:27, 13 July 2021 (UTC)

@Levivich: sure but... are there admins abusing their tools? Generally when that has happened I've seen them end up at ArbCom and desysopped relatively quickly.

People can abuse rollback, but that doesn't mean we need to cycle and reconfirm rollbackers. Or page movers. Or template editors. Or anything else. We simply remove the permissions if there is actually an abuse - but not simply controversy. I worry that requiring reconfirmation RfAs or term limits would lead to removing people for the latter. Elli (talk | contribs) 16:45, 13 July 2021 (UTC)

RB, PM, TE, and the other PERMs can't stop anyone from reading or editing, so they are different from the admin toolkit (block/protect/delete). Case in point: who is it that decides whether a PERM is being abused and removes the PERM? Admins :-) Admins are in a category of their own because of the unique and powerful nature of their tools; it's part of the reason why WMF requires a community vetting process for the admin toolkit but not the other perms, and thus why we have RFAs in the first place.

As to admins abusing their tools? Yes, of course, that happens; it's not very common but it happens more than once a year. I can think of three ANI threads from the past year off the top of my head, plus at least one desysop this year, three last year, three the year before IIRC. Is that a lot? I don't know. Not a surprising volume, not a concerning volume. I think we do OK with handling tool abuse; generally Arbcom does OK with that. If anything, I think more ANI threads should have turned into Arbcom desysops but meh, not a big deal.

But I believe we should desysop not just for tool abuse but also for loss of community trust, or failure to maintain community trust. So-called "long-term, low-level" problems. I'm not going to name names but there are admins who I believe routinely make very poor decisions, or behave in very poor ways. It never rises to the level of tool abuse or clear incivility, but it's more things like: prematurely closing threads (so-called "wagon circling"), making poor uses of discretion in discretionary sanctions areas, making poor choices (albeit within policy) when it comes to blocking and unblocking users, protecting and unprotecting pages, and so on.

Now, some might respond to that with, "Levivich, you're saying you want to desysop admins who make decisions that are within policy but that you personally disagree with." Not exactly: I want to desysop admins who make decisions that are within policy but that the community disagrees with. The community shouldn't have to change policy, or make policies more and more specific, just to force an admin to exercise better or different judgment. The admin should be implementing the will of the community. And the community should have a way of saying, "this admin just isn't doing things the way we want an admin to do things, even if it's not against some written policy." Right now, we have no way of desysoping someone for making a lot of decisions we all disagree with, so long as they're not breaking a written rule. That's one problem community desysop would address.

Terms and term limits would also address this, by keeping things "fresh," which means having admins who are more in line with community consensus because the community !voted on them more recently. Right now, we have dozens of admins making decisions whose decisionmaking basically was never reviewed by anyone who currently edits. People who became admins on 10- or 25- or 50-vote RFAs 15 years ago, and who never, ever, had their "community trust" tested since. Some of those admins are making decisions that I think are outside community norms but inside policies. We have no way of removing them. Terms will at least ensure that everyone has their "community trust" evaluated every so often (like every 5 years or 10 years or whatever). Levivich 17:09, 13 July 2021 (UTC)

A minor note regarding removal of privileges: having an admin decide to remove privileges is the fastest way, but the community can reach a consensus agreement to do it as well.

Regarding group dynamics: no matter what the system, there's always trickiness in dealing with marginal cases, particularly since everyone is prone to them to some degree. So even if term limits helps in some cases, I think there will be new areas where it does not (cliques could push out admins they dislike, for example). But at a minimum, if there is a greater turnover rate in admins, then the effect of any one problem admin can be limited (with the potential cost of limiting the effect of other admins). isaacl (talk) 17:25, 13 July 2021 (UTC)

...for this reason, I favor terms more than term limits. Like: be an admin forever as long as you can pass an RFA every 5-10 years. Levivich 17:34, 13 July 2021 (UTC)

Sorry, I meant fixed-period terms for holding administrative privileges. The broader point, though, is they'll always be interpersonal problems that will manifest in some way. Systems that provide checkpoints to limit the effect of individuals will do so in both directions, which of course may be an acceptable compromise. isaacl (talk) 17:45, 13 July 2021 (UTC)

Regarding encouraging commenters to approve more new admins, term limits on new admins going forward is sufficient for this purpose. I also think that it may be helpful in terms of recruitment: editors may be more willing to sign up to help out for a fixed period of time and thus more apt to stay active throughout that time. isaacl (talk) 16:48, 13 July 2021 (UTC)

I think that making it easier to lose will make it easier to get: people will be more likely to support RFAs if adminship wasn't a lifetime appointment. Is there any evidence for this? It is difficult to tell, since RFAs aren't votes, but rather strange dynamical systems where the question is less whether people will support or oppose and more what kinds of accusations they make and what evidence they post and then how others react to that. In any case, I don't recall seeing many people saying "I'd support you for 5 years, but not for lifetime". —Kusma (talk) 16:54, 13 July 2021 (UTC)

I think the evidence for this is in the comments in past sysop-reform RFCs, wherein some folks supporting (such as myself) explicitly cite this as a reason for their support. (Although those RFCs are supported by majorities or supermajorities of non-admins, I'm not sure how many of those non-admin supporters factor this particular reason into their support, or how strongly.) Levivich 17:09, 13 July 2021 (UTC)

As I said, no evidence in RfAs. How many people have been opposed because people thought their adminship should be term limited? —Kusma (talk) 18:23, 13 July 2021 (UTC)

I do recall commenters saying their standards are high because granting of administrative privileges is permanent. I don't think introducing term limits in isolation is a magic bullet, but it might contribute to an overall effort to recruit more admin candidates to run, thus encouraging commenters to adapt to a more flexible approach to approving requests. isaacl (talk) 17:15, 13 July 2021 (UTC)

We can either have short terms (lets say one year) that are pretty unrealistic - I mean, that would be dozens of simultaneous RfAs - or longer terms (lets say five to ten) at which point if you support someone at RfA they could still do admin stuff for a long time. If anything, desysops for abuse would be less likely since, well, they're not an admin forever. People might say that they'd support adminship if it wasn't forever - and it sounds like a nice sentiment - but it makes absolutely zero sense. Elli (talk | contribs) 18:20, 13 July 2021 (UTC)

And I haven't seen a convincing case for "convincing more admins to run" - making the position you run for worse doesn't make it more appealing. It makes it less appealing. Elli (talk | contribs) 18:20, 13 July 2021 (UTC)

It's a shift in psychology. Consider some despised chore at work, such as replacing the coffee filter. You could ask for volunteers to do it for the next week, after which they will be replaced, or ask for volunteers to do it for an unspecified amount of time, and you'll look for more volunteers based on their feedback. I think more people are willing to participate (and stick it out while counting the days until it ends) in a "share the load" approach, where they sign up for a fixed period, and rotate with others. Regarding administrative chores, this does have to be accompanied with greater flexibility in granting privileges in order to get people to sign up for their turn. And as I said below, we ought to take a holistic view and look for what could make adminship more attractive, and what could be done to reduce the need for administrators. For better or worse, though, the entirely self-directed nature of Wikipedia volunteers makes long-term planning quite difficult. (Its libertarian roots makes it highly resistant to the usual approach of volunteer organizations of having paid staff work on long-term planning.)

Regarding removal of privileges due to misuse, consider the various editors of which you are aware on that would be likely to make a big deal of this today. The ones I can think of would still push forward even with a fixed-length term. isaacl (talk) 19:05, 13 July 2021 (UTC)

I don't really see adminship as a despised chore. It makes every task on Wikipedia you might want to carry out more convenient, not less. It's a tool, and should be available to all trusted to use it. Certain administrative tasks are chores, sure, but one person's chore is another person's relaxation. Overall though, your view on adminship seems to be radically different from how I see it. There's no expectation of doing anything with the bit, so I don't see why people wouldn't step up for that reason. Elli (talk | contribs) 19:34, 13 July 2021 (UTC)

If blocking editors or deleting pages is someone's idea of relaxation, they shouldn't be an admin. :-) Levivich 19:43, 13 July 2021 (UTC)

Consider the perspective of all those editors who are choosing not to request administrative privileges. The key abilities for which administrators are needed are to delete undesired content, and to block poorly-behaved editors. This is an endless treadmill of trying to keep Wikipedia in place. More admins to edit the main page or templates and (under certain conditions) move pages are nice to have, but getting people to share the workload for the chores, or developing new processes to reduce the number of admin chores is needed for long-term sustainability. isaacl (talk) 19:46, 13 July 2021 (UTC)

Admins don't need to delete pages or block editors though. They certainly don't need to do any more than they enjoy. I look at it like this - non-admins, when they need a page deleted for whatever reason (say, spam, copyvio, holding up a page move) need to ask an admin. Admins can just do it themselves. That makes adminship more convenient, not less. If someone never needs to delete pages as a non-admin, they don't need to as an admin either.

Yes, the tools generally have an administrative focus - it's in the name - but it's not a job. Compare to something like ArbCom which is - solving complex disputes is rarely an idea of fun, nor is getting yelled at by a lot of people, and I think the term system works perfectly well there. It's not like Arbs can just choose to not hear cases - Arbs are expected to actually arbitrate. Elli (talk | contribs) 19:56, 13 July 2021 (UTC)

It's fine to recruit more admins that don't want to delete content or block editors. But we need to replenish and keep the pipeline flowing for admins who do want to perform these tasks. isaacl (talk) 20:05, 13 July 2021 (UTC)

Sure, but that undermines your original premise, that people would step up if it was limited time. If you block vandals for a year, then do nothing for a year, then block vandals for a year again, on and off - no one's going to yell at you (other than some vandals, maybe :P). There is no need to restrict the ability of competent administrators, who actually enjoy the work, from doing it. Elli (talk | contribs) 20:21, 13 July 2021 (UTC)

Competent administrators can sign up for another term and keep doing the work, without any problems. I appreciate you don't feel that fixed-length rotations might attract candidates that aren't interested right now. isaacl (talk) 05:08, 14 July 2021 (UTC)

I sort of think this "admin is forever, so standards are high" is just an excuse, and many of the standards have nothing to do with any long-term things about a candidate (i.e. clue/judgment/ability to keep their cool) but are just things like "recent AfD record" or "only one GA" that could easily change over ten years. I don't think something like a five-year term will appear noticeably shorter than "forever" to most voters. —Kusma (talk) 18:21, 13 July 2021 (UTC)

Here's my admittedly-fuzzy math: 488 (the # of admins who made an edit in the last 30 days) isn't an approximation of the number of people who would run for re-RFA, it's the entirety of the realistic pool of potential candidates. How many of those ~500 active admins used the tools in the last month? I bet it's half. And how many of those want to use the tools again enough to run for RFA? I bet it's half again. And that's how I get to (in this fuzzy math hypothetical case) ~125 re-RFAs, or one or two a week for a year or two. (I recognize I'm making huge assumptions here... but so is anyone else making such a prediction.) Levivich 16:27, 13 July 2021 (UTC)

If they're active and have chosen to retain their admin rights so far, why wouldn't they stand for a reconfirmation RfA? Reconfirmation RfAs are likely going to be focused on track record; extrapolating future trustworthiness based on clues isn't needed. Thus minimal effort is required on the admin's part. In any case, I think there is a higher benefit-to-effort ratio for RfA commenters to spend those aggregate hours reviewing new candidates. isaacl (talk) 16:39, 13 July 2021 (UTC)

(Without repeating the point, I think we'd have more new candidates to review if we had terms...) But as for the numbers, this hypothetical approach is unrealistic anyway. Admin-by-age isn't evenly distributed by year; we had the RFA spike of I forget what year (~2007? 2011?), and we are very likely to have a lot of admins bubbled into a smaller group of years. Probably some data analysis would be required to gain an accurate estimate of how many admins would run for reconfirmation. But if it were up to me, I'd start with 15 year terms, and reconfirm everyone who's been an admin more than 15 years. Then, I'd drop it down and do a round of 10-year terms. Then when those were done, 5-year terms, and 5 years going forward. I'm not sure exactly where I'd draw the lines (15/10/5 years), but that's what I'd want to look at the data for, to figure out where the "bubble" is, when we'd expect a high number of reconfirmations. I think we could draw the lines in such a way to smooth out the number of concurrent re-RFAs and avoid an overwhelming spike. Levivich 17:41, 13 July 2021 (UTC)

(Regarding your parenthetical, yeah, that's the same as what I said about fixed-period terms, right?) I agree it would be more feasible to specify a desired rate of reconfirmation (one every X number of days), start with the earliest admin, and move on down the list. Personally I still don't feel the benefit-to-effort ratio is terribly high, but at least the effort can be capped and sped up or slowed down as desired. (I think this may have been discussed before, and didn't garner much support, but I'm not sure.) isaacl (talk) 18:05, 13 July 2021 (UTC)

I also wonder about public voting in these RfCs. Is it likely non-sysops could decide not to comment/!vote because of fear of retaliation? (NOTE: I am not implying actual such retaliation is likely.) I wonder if a semi-public vote like for arbcom elections should be proposed for resysop/desysop RfCs? —valereee (talk) 19:28, 12 July 2021 (UTC)

I didn't remember who participated in the 2019 RfC, much less that you proposed Q14... (I couldn't even remember which proposals I commented on.) For those making respectful remarks, I don't think they would feel constrained by the fear of possible future consequences. isaacl (talk) 20:09, 12 July 2021 (UTC)

That gets back to what I've written about before (which I know you've read): English Wikipedia's consensus-like decision making traditions have many structural problems, one of them being that it only considers the views of a self-selected set of participants.(*) Without counting up numbers, I don't know if I agree that non-admins interested in administrator processes are outnumbered by admins (which is why I don't think this an impossible obstacle to overcome), but I think it is feasible that admins are more likely to stay engaged throughout the discussion. To me the answer is not to prevent admins from having a say, but to empower a smaller subgroup to make decisions, just like with real-world organizations, possibly with a community ratification step. But the libertarian roots of Wikipedia makes this hard to achieve.

(*) I know it's hard to consider the needs of a silent majority. But perhaps with some form of polling combined with cogent reasoning, we could really target initiatives that benefit them. That's part of why I think the amount of discussion over whether or not a small handful of people a year get their administrative privileges restored is disproportionate to the impact. Figuring out how to get more people willing to take on thankless tasks of all sorts, trying to figure out what tools would assist with these tasks or making them unnecessary, and improving content dispute resolution so semi-binding decisions can be made and editors can move forward instead of relitigating issues forever, to take some examples, would have a greater effect on the long-term viability of the community. isaacl (talk) 20:26, 12 July 2021 (UTC)

I wouldn't be adverse to an elected body —not ARBCOM, ACE format— that does a one-off admin policy reform with stated parameters. Review cycles could also be set up. But I know a lot of people would be against paraliament'ing the project in such a way... El_C 21:04, 12 July 2021 (UTC)

Future Nostalgia Talk Page Access

Wondering if it's time to get access back to the Future Nostalgia talk page. I keep thinking about * Jeff Bhasker , Jason Evigan , SG Lewis , * Lindgren maybe not getting the credit they deserve were it not for this edit https://en.wikipedia.org/w/index.php?title=Future_Nostalgia&diff=1019866700&oldid=1019866379 . I believe a lot of fixation was placed on an irrelevant producer's listing in one particular section of the remix album, whose big hit was Levitating Feat DaBaby. The wording on the original rfc was "For this rfc, we are hoping to reach a consensus on whether Tainy should be listed as a producer for Future Nostalgia: The Moonlight Edition" and then "To add to what LOVI33 said, we are looking for a consensus as to if Tainy and J Balvin both deserve equal producer credits for the song "Un Dia (One Day)" (track 19 of The Moonlight Edition) or not. Please see the above section for more info. Thanks!" was the thing read by the herd. And yet I was the only vote that read the rfc. It asked if he should be listed.. He's already credited several times in the article. Doesn't make sense that I can't keep talking on an article talk page. Thank you! Sucker for All (talk) 03:30, 15 July 2021 (UTC)

Sucker for All, a normal unblock request on your talk allows other admins to see it and possibly comment or action it. I see you've posted the identical question at HighInBC's talk. Please don't do that, as it tends to waste other editors' time. If you want to make sure someone has seen something on your talk, you can WP:PING them there.

For me, nothing you've said so far in your previous unblock request, the subsequent discussion, or this post makes me think you understand what the problem was. You're still talking about 'wiki swarms' and circlejerks -- both of which could be interpreted as personal attacks, btw -- and you're still trying to argue content to admins. I have no objection to any other admin lifting the block if they think we've gotten through to you, but from what I can tell you still don't seem to understand why you were blocked. —valereee (talk) 12:15, 15 July 2021 (UTC)

DYK for Black veganism

On 15 July 2021, Did you know was updated with a fact from the article Black veganism, which you recently created, substantially expanded, or brought to good article status. The fact was ... that in the United States, Blacks are twice as likely as the general population to identify as vegan? The nomination discussion and review may be seen at Template:Did you know nominations/Black veganism. You are welcome to check how many pageviews the nominated article or articles got while on the front page (here's how, Black veganism), 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.

 — Amakuru (talk) 12:04, 15 July 2021 (UTC)

Feedback request: Wikipedia proposals request for comment

Your feedback is requested at Wikipedia:Reliable sources/Noticeboard on a "Wikipedia proposals" request for comment. Thank you for helping out!
You were randomly selected to receive this invitation from the list of Feedback Request Service subscribers. If you'd like not to receive these messages any more, you can opt out at any time by removing your name.

Message delivered to you with love by Yapperbot :) | Is this wrong? Contact my bot operator. | Sent at 06:30, 17 July 2021 (UTC)

Feedback request: Wikipedia policies and guidelines request for comment

Your feedback is requested at Wikipedia talk:Notability (media) on a "Wikipedia policies and guidelines" request for comment. Thank you for helping out!
You were randomly selected to receive this invitation from the list of Feedback Request Service subscribers. If you'd like not to receive these messages any more, you can opt out at any time by removing your name.

Message delivered to you with love by Yapperbot :) | Is this wrong? Contact my bot operator. | Sent at 16:31, 18 July 2021 (UTC)

This week's article for improvement (week 29, 2021)

The Hittite version of the Treaty of Kadesh, among the earliest extant examples of an international agreement Hello, Valereee. The article for improvement of the week is: International law Please be bold and help improve it! Previous selections: International Army Games • Organized religion Get involved with the AFI project: Nominate an article • Review nominations Posted by: MusikBot talk 00:05, 19 July 2021 (UTC) using MediaWiki message delivery (talk) on behalf of WikiProject AFI •

DYK for Women's National Basketball Players Association

On 20 July 2021, Did you know was updated with a fact from the article Women's National Basketball Players Association, which you recently created, substantially expanded, or brought to good article status. The fact was ... that the Women's National Basketball Players Association was the first trade union for professional women athletes? The nomination discussion and review may be seen at Template:Did you know nominations/Women's National Basketball Players Association. You are welcome to check how many pageviews the nominated article or articles got while on the front page (here's how, Women's National Basketball Players Association), 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.

 — Amakuru (talk) 00:02, 20 July 2021 (UTC)

Nomination of Kishwar Chowdhury for deletion

A discussion is taking place as to whether the article Kishwar Chowdhury, to which you have significantly contributed, is suitable for inclusion in Wikipedia according to Wikipedia's policies and guidelines or if it should be deleted.

The discussion will take place at Wikipedia:Articles for deletion/Kishwar Chowdhury until a consensus is reached, and anyone, including you, is welcome to contribute to the discussion. Users may edit the article during the discussion, including to improve the article to address concerns raised in the discussion. However, do not remove the article-for-deletion notice from the top of the article.

To customise your preferences for automated AfD notifications for articles to which you've significantly contributed (or to opt-out entirely), please visit the configuration page. Delivered by SDZeroBot (talk) 01:02, 20 July 2021 (UTC)

Proposed Women in Green Editathon

Hello Valereee -- With the goal of helping to progress the WikiProject Women in Green (WiG) women’s rights-themed GA nomination goal for 2021, I’m proposing that WiG hold a special editathon event in the fall (maybe October/November?). I can assist with logistics, but I need to know how much interest/support there might be from WiG participants first. Please let me know what you think in the talk page conversation! All the best, Alanna the Brave (talk) 02:33, 20 July 2021 (UTC)

Your revisions to Richard Cheese

Wow. I mean....

omg, wow.

Yappy2bhere (talk) 22:49, 20 July 2021 (UTC)

@Yappy2bhere, can't decide if you're yappy or unyappy. :D —valereee (talk) 23:33, 20 July 2021 (UTC)

Mostly I'm astonished, speechless. It's like seeing a tornado suck up debris and set down a cottage.

I'm happy with the result; changes always make someone unhappy, but I can't imagine anyone will be terribly unhappy with what you made. I'm happy I can leave the article behind in good conscience; I fell into it by accident and then couldn't get out again. I'm very happy that it's properly sourced and tagged. It would have taken me ages to approach what you achieved in hours, and I wouldn't have left behind a history with such clarity. Thank you; you're a hero. Yappy2bhere (talk) 23:55, 20 July 2021 (UTC)

Wow, that is such a nice thing for you to say, thank you, and I love the picture of a tornado sucking up debris and setting down a cottage rather than the opposite. I fell into it by accident, too, and just decided to edit boldly. I'm sure there will be people who aren't happy. :) —valereee (talk) 23:59, 20 July 2021 (UTC)

I would like to add my thanks for cleaning up that article. I am monitoring the article in an administrative capacity since I saw it at ANI. HighInBC ^{Need help? Just ask.} 01:46, 21 July 2021 (UTC)

Richard Cheese page

Thank you for making those updates to the Richard Cheese page, you did a great job. I can't make any edits, so I'm glad that there is someone conscientious doing the work!

I spotted one typo in this sentence:

In 2019, the band released Richard Cheese's Big Swingin' Organ, an album of instrumental organ versions of 9 of songs.

But, since there is a discography section later in the article, I wonder if that entire "Releases" section is even necessary?

Perhaps that entire "Releases" section could be shortened to just this:

Richard Cheese's debut album Lounge Against The Machine was released in 2000. Since 2000, the Richard Cheese & Lounge Against the Machine band has released 28 albums.

And maybe move the discography section earlier?

Thanks again :)