Jump to content

Wikipedia talk:Administrative action review/Archive 3

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

Discussion format

I'm curious how much agreement/disagreement we have amongst page watchers about this. Should one or more specific discussion formats be required, or recommended, and if so, what should the format be? Levivich 18:46, 14 June 2022 (UTC)

  • I think there ought to be one hard requirement, which is that whomever posts a new thread seeking review of an action needs to include a link to a diff or log entry of the action under review and identify which advanced permission that action requires (or set of related actions). This will allow us to easily determine if a review is in scope, and also to help remind participants of the purpose of the review (to review a specific action or set of related actions). Beyond that, I would let the person seeking the review set the format of the review, and then we can try out some different formats and see which work best. My guess is that different formats will be better for different kinds of reviews--there are a lot of very different advanced permissions, after all. Examples of possible formats include separate survey/discussion sections (like RFCs), one-section-per-editor (like arbcom), or no format (like ANI). I can see an argument for not allowing the last one per the RFC, which would be fine with me. We could create two or three format templates and allow filers to choose from among them. Levivich 18:46, 14 June 2022 (UTC)
  • Serious suggestion: if you want this to succeed, adapt the AE template, get rid of the extraneous rules that we're debating here on the talk page outside of a larger community discussion (such as time and scope), and tell people to use it to bring cases here. The community will naturally decide scope and time limits on their own by the closes. If you have a relatively small group of people dictating the specifics in advance, the result is what happened when this launched. There was consensus for a structured discussion format. Create a template for that, use it, and see if it works. Most likely way to get this off the ground, imo (and I have no strong ties to the AE format, just think it'd be easiest to try/adapt since its pre-built for you.) TonyBallioni (talk) 18:55, 14 June 2022 (UTC)
    I dislike, strongly, the idea of using a behavioral template as the basis for this page. This is not a behavioral forum. We don't have to use the current template but would suggest something closer to the MRV or DRV template be used. Best, Barkeep49 (talk) 18:59, 14 June 2022 (UTC)
    I don't have a particularly strong attachment to the AE template; but I don't really see the difference between DRV/MRV/XRV templates and AN. If people want a structured format, the only discussion venues I'm aware of with structured formats are SPI, AE, ARCA, and ARC if people want to use those as models. Everything else is freeflowing and the current template is no different than AN from what it looks like in the archives. I guess I'm saying the one thing I think everyone agrees there was consensus for (a structured format) was the one thing that wasn't implemented. TonyBallioni (talk) 19:10, 14 June 2022 (UTC)
    I see DRV etc. as 'structured' because they use dated discussion subpages, expect participants to offer a bolded !vote, and are always closed on a fixed schedule. And when I wrote the proposal, I specifically had something like DRV in mind. (I realise that doesn't mean that others who supported the idea thought the same way). Personally I find AE and arb formats in general to be a bit too structured and bloated, but I'm not opposed to it in principle. Maybe we should do a quick poll to see which is most preferred? – Joe (talk) 08:02, 15 June 2022 (UTC)
    I'll note that people do AE/Arb formats wrong and it requires active clerking, where as I see people get the DRV format "wrong" far less often. Best, Barkeep49 (talk) 13:22, 15 June 2022 (UTC)
    One page per day/week/month doesn't make a venue structured, it just makes it harder to watchlist. For venues with a lot of traffic like DRV it's a necessary evil, for something with the volume we anticipate here it's not necessary. Thryduulf (talk) 14:44, 15 June 2022 (UTC)
    You could say the lack of watchlist-ability is a good thing. Part of the problem with ANI is surely that as soon as something is posted there, every drama hound on the project sees it. I like that AfD and DRV are a bit harder to track, which encourages a slower and less noisy pace. But probably a lot of that is personal preference. And yeah you're right it doesn't make much sense to have dated subpages unless there's high volume. The kind of structure you and Levivich hashed out below works for me. – Joe (talk) 18:10, 15 June 2022 (UTC)
    I mean... that's what we did originally? With DRV templates instead AE, but still. Then we were criticised for not working out all the specifics in advance. – Joe (talk) 07:57, 15 June 2022 (UTC)
  • Each type of structured format has advantages and disadvantages. I'm not sure I have a strong preference, but I disagree people should be able to use any format they want. A format should be chosen before this starts, and then if it isn't working you can use trial and error/discussion/whatever to change it. I think it would be a big mistake to mix and match threaded discussion on some issues with sectioned discussion on others. --Floquenbeam (talk) 19:16, 14 June 2022 (UTC)
    I strongly agree that there should be a single structure, possibly with some minor alterations depending on what is being reviewed. Anything else is just going to lead to confusion and disorder. I don't have a strong preference about what that structure should be, but I do think there should be some hard requirements - the request should include all of the following:
    • A clear statement of what action is being appealed, ideally including a diff and/or log action.
      • If there are multiple aspects, which one(s) are relevant
    • Who performed the action (in most cases this will be obvious from the diff/log entry but there might be exceptions, and it also serves as a check to make sure wrong trees are not being barked up)
    • A clear statement of why it is being appealed - why do you think the decision was wrong? What do you think the correct decision should have been and why?
    • Either a link to prior discussion with the person who performed the action, or an explanation of why you haven't had a prior discussion
    • Any background necessary to understand the situation.
    This should, I hope, provide the right balance of not to onerous or bureaucratic but providing structure and making sure that everybody is on the same page. One of the issues with AN(I) is that misunderstandings can quickly snowball. Thryduulf (talk) 20:36, 14 June 2022 (UTC)
    I would support this kind of format with a few minor tweaks. I'd suggest four required sections for a new filing:
    1. A clear statement of what action is being appealed, whenever possible including a diff and/or log action (and if there are multiple aspects, which one(s) are relevant)
    2. Who performed the action, and confirmation that the person has been notified of the report (like we do at AE)
    3. Either a link to prior discussion with the person who performed the action, or an explanation of why you haven't had a prior discussion
    4. A clear statement of why it is being appealed - why do you think the decision was wrong? What do you think the correct decision should have been and why? - including any background necessary to understand the situation Levivich 21:39, 14 June 2022 (UTC)
    Yes, that's good phrasing. Thryduulf (talk) 00:30, 15 June 2022 (UTC)
    Good phrasing, but I think it would be improved at #4 with a requirement for the initiator/complainer to state their “desired outcome”. This must not be read as limiting the outcome to yes/no, as the discussion may find consensus for another outcome.
    There may be a difference between “what the decision should have been” and “what should be done now”. SmokeyJoe (talk) 00:45, 15 June 2022 (UTC)
    Much of the time there can't be an outcome because we'll be reviewing a block that's expired before the XFD closes, or a time-limited page protection decision that's no longer in force by the time the paperwork's been done. In such cases the point of XRV is to endorse or to say what we think should have happened instead -- it becomes a place for learning lessons and reflecting on how we could do things better next time.—S Marshall T/C 12:16, 15 June 2022 (UTC)
    Your comment made me think of Morbidity and mortality conferences, which are about improving future performance without assigning blame. - Donald Albury 14:42, 15 June 2022 (UTC)
    I think i"ve linked to that at some point as well Donald and agree that would be the best case version of this board. Best, Barkeep49 (talk) 15:49, 15 June 2022 (UTC)
    There's an unresolved quibble about the language we use in that case -- "Endorse" or, err, "Not endorse"? Technically I think the antonym of endorse might be "deplore", but I'm hoping to be able to improve on that word.—S Marshall T/C 16:43, 15 June 2022 (UTC)
    There's a lot of space between "endorse" and "deplore", which "no consensus" doesn't fill. The comments might deplore or even castigate, the close might draw attention to them and the admin concerned might pay attention too, but "deplore" is not a good sole alternative to "endorse", especially if we're looking to maintain a low heat. At the very least, let's start with the options clearly stated in the first RFC, "endorsed" and "not endorsed", for a trial period. NebY (talk) 16:28, 16 June 2022 (UTC)
    I disagree about stating the desired outcome. #RFC text was clear about endorsed or not endorsed, and that's it. No other outcomes. Nothing else to be discussed except whether a specific action is or is not endorsed. Levivich 19:07, 15 June 2022 (UTC)
    That’s really silly.
    I was unsure about whether a complainer should be required to articulate a desired outcome upfront, because they may be new to the culture. However, every good complaint comes with a desired outcome. Participants will mostly voice their proposed outcomes. Denying the complainer from stating their desired outcome doesn’t make any sense. WP:Consensus doesn’t work by constraining the discussion, consensus requires that the question can be modified.
    In all forms of dispute resolution, the complainers desired outcome adds much to others’ ability to understand the complaint. SmokeyJoe (talk) 22:44, 15 June 2022 (UTC)
    If the filer is, indeed, a complainer, the desired outcome is "not endorsed". Another possibility is that the filer is unsure but wants input from others, such as the self-review that was the first XRV thread. In that case, there is no specific desired outcome. Silly or not, there are only two possible outcomes, "endorsed" or "not endorsed", and that's global consensus: The purpose of XRV is solely to reach a consensus on whether the use of the permission was appropriate, not to remove permissions (so, for example, asking for removal of permissions at XRV would violate the RFC consensus, because Acting on that consensus is deferred to existing processes), reach a consensus on whether an action or set of actions is endorsed or not endorsed, and reach a consensus on whether the action should be endorsed or not endorsed are crystal-clear as to what the possible outcomes are. Levivich 22:55, 15 June 2022 (UTC)
    Yeah, I guess I object to “The purpose of XRV is solely to <hard limitations>”. That is such a limited perspective.
    The greater purpose of DRV and MRV is not to overturn or not, but it as an ongoing continuing education forum, for the parties dragged to it, participants, and the observers. If a review consensus is repeatedly critical, every sensible admin (or nonadmin closer) changes their ways somewhat in response.
    I think this purpose will be XRV’s greatest purpose, and it is needed because nowhere else do I know of when admin actions can be calmly and formally critiqued, except DRV and MRV with their limited scope.
    The second biggest purpose is to provide the symbolism of a forum where admins can be held accountable to the community. There is a most definite feeling within the community that admins hold themselves above mortal editors and routinely abuse mortal editors, and there is nothing a mortal editor can do. I don’t believe that, but the perception exists, and XRV is be a good outlet for allegations. And allegations of abuse need to be aired, in the right forum, and not speedy closed by the complainee’s peers.
    Saying the ONLY purpose are the two concrete outcome diminishes these greater but nebulous purposes.
    Review forums are prone to attract rambling complaints. Asking for a “desired outcome” is the standard way to focus a rambling complaint.
    If the outcome is to be “not endorsed”, it begs the question of what to do next. Should the admin action be reversed? Should the relevant process be re-initiated (similar to a relist or RENOM in XfD)? Should the admin be chided, or referred to ArbCom? Has the case revealed holes in policy documentation, and the discussion should continue on the relevant policy talk page?
    I think that your use of “outcomes” refers to “actions to be imposed immediately by the closer”? It means that desysops or blocks, or unblocks, or page unprotections or protections, are not to be immediately actioned from an XRV case? Personal learning can be an outcome. An apology may be an outcome. Vindication or closure may be an outcome. SmokeyJoe (talk) 02:38, 16 June 2022 (UTC)

{{XRV}} could be tweaked to something like this: 

{{subst:XRV
|action = <!-- The action (or set of related actions) you're asking to be reviewed; link to a diff or log entry whenever possible; if the link includes multiple actions, explain which are being reviewed -->
|performer = <!-- Name of editor who performed the action -->
|notified = <!-- Notify the performer on their user talk page of this review after posting it, and then replace this comment with a diff of the notification. -->
|page = <!-- The page title the action was performed on, delete if not applicable -->
|user = <!-- The user name of the editor the action was performed on, delete if not applicable -->
|discussion = <!-- Name of the section of performer talk page where discussion took place, or an explanation as to why no discussion took place -->
|reason = <!-- The reason why this action is being reviewed, including an explanation of why you believe the action should not be endorsed, and any background information necessary to understand the action -->
}}  ~~~~

What do people think? I note this addresses the structure of a filing, but doesn't address the structure of discussion (if any). Levivich 22:16, 15 June 2022 (UTC)

I know deletion review has a template, but personally I'm partial to preloaded wikitext. (Particularly when the template parameters have very specific purposes—I don't really like how the discussion parameter is assumed to be a section name on the talk page for the user whose action is being reviewed.) I think a wikitext template is generally easier to fill in for a broader segment of the editing community. isaacl (talk) 22:29, 15 June 2022 (UTC)
(edit conflict) I think "discussion" would be better as something like "link to the discussion with the performer about this action, or an explanation..." as the discussion might not be on the performer's talk page.
There should be some way to indicate that a set of related actions occurred on multiple pages/to multiple users (what comes to mind is "you blocked user:X and user:Z but not user:Y, I think you should have treated them all the same")
Could also quibble about "perform" in relation to decisions to actively not do something, as while that is (probably) going to be in scope it is (arguably) not possible to perform an inaction. However, this is very minor and only pedants will ever care (although Wikipedia does have at least it's fair share of us).
Other than that I think this is good. Thryduulf (talk) 22:31, 15 June 2022 (UTC)
What about just getting rid of |user= and |page=, and changing |performer= to |editor=? Then filers can just link to the action(s); where the action took place and/or to whom will be apparent from the link to the action (and, I think, are not that important anyway). I agree about the change to |discussion= to the more generic "link to the discussion...". We can have both a template and a preloaded wikitext button so people can use whichever they prefer. Levivich 22:35, 15 June 2022 (UTC)
Another reason why I prefer a wikitext-based template (in the English sense): there's greater flexibility in how the issue is specified. The current XRV template assumes there's an action on page or person being reviewed. isaacl (talk) 22:39, 15 June 2022 (UTC)
She's got IT
That's a big template, and potentially daunting for people who're less IT literate. How can we make it shorter and simpler?—S Marshall T/C 16:35, 16 June 2022 (UTC)
{{subst:XRV

|action = <!-- The action (or set of related actions) you're asking to be reviewed; link to a diff or log entry whenever possible; if the link includes multiple actions, explain which are being reviewed -->

|editor = <!-- Name of editor who performed the action -->

|notified = <!-- Notify the editor on their user talk page of this review after posting it, and then replace this comment with a diff of the notification. -->

|discussion = <!-- Link to the discussion with the editor about the action, or explain why no discussion took place -->

|reason = <!-- The reason why this action is being reviewed, including an explanation of why you believe the action should not be endorsed, and any background information necessary to understand the action -->

}}  ~~~~

How's this for simpler? Levivich[block] 18:53, 20 June 2022 (UTC)

That looks fine to me. We can always tweak things later if that format doesn't seem to be working well. Ajpolino (talk) 23:48, 20 June 2022 (UTC)
What @Ajpolino said. For absolute clarity it would be better to label the editor field with "username" rather than "name", but that's hardly a big thing to change. Thryduulf (talk) 00:24, 21 June 2022 (UTC)
I've updated the template following this suggestion. I dropped the "notified" parameter for UI reasons—it means you have to edit twice—but we could revisit that if failing to notify becomes a problem? – Joe (talk) 11:14, 24 June 2022 (UTC)
Failing to notify generally isn't a problem at AE which prompts that it is required in the template (you do have to edit twice there), but more often is at the more free-form ANI even though that says it on the page, in bright yellow edit notice and in the edit box (although this latter is new since last I regularly paid attention to ANI). This suggests to me that having something in the edit box saying you have to notify is a Good Thing. Whether being required to confirm you did makes a difference I don't know. Thryduulf (talk) 11:22, 24 June 2022 (UTC)
I've tried to make it a bit more prominent: [1] – Joe (talk) 09:41, 28 June 2022 (UTC)
Thanks, Joe. I tried to do this yesterday and failed, but had also removed the "notified" parameter, so GMTA (and so do ours...). Levivich[block] 16:34, 24 June 2022 (UTC)

Change the name?

While we're here, I'm curious whether anyone else besides me thinks this board should have its name changed from "Administrative Action Review" to "Advanced Permissions Review" (WP:APR is a shortcut to an essay that is currently only linked to 120 times, which is small enough to usurp, and I'd volunteer to do the work) (WP:XRV could still be retained as a shortcut as well).

Despite the fact that the #RFC text specified the name as "Administrative action review", the actual proposal talks about use of an advanced permission, including the admin tools, and otherwise speaks in terms of "advanced permissions", not just "administrative actions". The close of the RFC was even more explicit: Finally, we note that the process as proposed is not just about the evaluation of administrative actions, but about all advanced permissions, and thus also applies to non-administrators.

I think part of the animosity is because of the focus on admin actions, and it would be better to call it by a name that more closely describes what it actually is. So, anyone else think we should change the name to "Advanced Permissions Review (WP:APR)"? Would we need an WP:RFC and/or an WP:RFD to make this change? Is this even worth talking about right now or just shelve it? Thanks, Levivich 21:18, 15 June 2022 (UTC)

The original proposal name was "permissions review". It was changed because it's not the granting of permissions that is being reviewed, but the action/decision that is being reviewed, without passing judgement on whether or not the editor in question should retain the corresponding privilege. isaacl (talk) 21:30, 15 June 2022 (UTC)
"Advanced action review" is the obvious follow-up suggestion combining both of those (WP:AARV already redirects here). "Advanced decision review" is another possibility (WP:ADRV redirects to Wikipedia:Administrator review, a venue that's been marked as historical since 2017). Decision review, is even simpler but may give the impression of a scope broader than it has? (it also doesn't come with an available acronym, WP:DRV being in active use; the currently unused WP:DecRV is the best I can suggest). All that said, I don't think the name is particularly important and have no preference between keeping and changing. Thryduulf (talk) 22:01, 15 June 2022 (UTC)
"Advanced action review" is better than my idea, that would actually be perfect as we wouldn't have to change the redirect. (I agree "decision" would broaden the scope too far.) Levivich 22:07, 15 June 2022 (UTC)
Advanced Action Review makes perfect sense. Retswerb (talk) 08:35, 17 June 2022 (UTC)

This came out of an RFA discussion and is titled "Administrative action review" and the support conversations were definitely not tool-focused / tool-limited. We should change the details to match the title, not the title to match the tool-centric detail. Sincerely, North8000 (talk) 03:04, 16 June 2022 (UTC)

Well, while the proposal was named "administrative action review", the consensus was, according to the closing statement: "Finally, we note that the process as proposed is not just about the evaluation of administrative actions, but about all advanced permissions, and thus also applies to non-administrators." The title should match the consensus. We should not change the details to match the title, we should change the title to match the details :-) Nevertheless, I don't see a title change as something that we need to do right now. Levivich[block] 16:33, 24 June 2022 (UTC)
I agree both that the title should be changed to match the board's purpose (per the RfC close), and that it's not critical it happen now. Ajpolino (talk) 22:40, 25 June 2022 (UTC)
Support "Advanced Action Review". The current title doesn't match the stated intent of the board and will confuse editors; this is the appropriate location to address misuse of other advanced permissions and the title should make that clear. BilledMammal (talk) 14:33, 28 June 2022 (UTC)

Foundation for genuine progress and success

We need to start with the main intent and potential usefulness for this, which is in the title. Not get lost in the "tool" weeds. It's pretty clear that the respondents wanted to review things like topic bans along with blocks. And while we keep the contingency in mind that somebody might come here wanting a review of a non-admin tool use, but that really is rarely going to happen. And it shouldn't take a wiki-expert to be able to bring an item here. If it's clearly the wrong place we can redirect them, but expecting them to understand and rule out all of the other venues before they can bring it up here is too much of a hurdle. Also, there needs to be a possibility of milder action outcomes than just reversal of the action. Like findings like "yeah, the admin is advised thaty they were too rude and rough, but the block was justified". Much of the current stuff on the page needs to be deleted or changed.....it didn't come from and wide consensus and some of it either goes against the whole idea or would likely be a poison pill for the venue. Sincerely, North8000 (talk) 19:02, 27 June 2022 (UTC)

I think the weeds we need to be careful of most are tea leaves. We don't know what each of the individual participants in the RfC imagined. What we do know is what was proposed, and what the majority of people said they supported. That proposal was explicitly restricted to "use of an advanced permission" (reflected in the originally proposed title, "permissions review"). The inclusion of non-admin tools wasn't incidental or a semantic slip, it was a core part of the proposal that was specifically justified and which many supporters explicitly mentioned. Ditto for having a restricted and conservative range of outcomes. Conversely, I don't remember much discussion about non-tool, admin-adjacent things like topic bans. It's a discussion we could have now, but I'm struggling to think of examples that would be appropriate to bring here: for example, topic bans can only be placed by individual admins as part of arbitration enforcement, and there's no way we're going to usurp reviews of arbitration enforcement from ArbCom. The RfC text had wide consensus, and I think we're very close to an implementation that sticks closely to the proposal and overcomes many of the objections that subsequently emerged. What you're describing sounds like a completely different process... we'd have to start from square one, and I don't understand why we'd want to do that? – Joe (talk) 19:27, 27 June 2022 (UTC)
I had 3-4 main points in my post. It looks like my topic ban example of a non-tool admin action was a bad choice. I wasn't saying to exclude cases of non-admin tool use, just mentioning that they really aren't going to happen. Also it appeared that somewhere around 0% of the support respondents mentioned non-admin tools (maybe I missed some) and the support comments were almost exclusively about admin actions (the title of the RFC) and without much discussion about excluding those that don't involve tools. One main point throughout my post is that the current wording will intimidate off most people who would come here and provided details on that. I admittedly made a jump outside of the RFC advocating giving milder feedback than reversal of the action, but that's likely to come up anyway here in case we actually get someone who makes it through the gauntlet of the current wording so that the discussion can start.  :-) Sincerely, North8000 (talk) 20:30, 27 June 2022 (UTC)
Also it appeared that somewhere around 0% of the support respondents mentioned non-admin tools (maybe I missed some) You missed some:
#5 It improves upon the WP:PERM system, which has no consistent way to remove rights when needed PERM is for non-admins
#6 Editors should read the longer rationale on the talk page The longer rationale on the talk page, third paragraph, begins with "By opening the process up to all permissions, not just admin ones..."
#9 - I wrote support #9 and I can definitely state with authority that when I wrote "tool", I wasn't just talking about admin tools, but all of them
#14 Further, it lets non-admin permission holders...
#15 Support, as long as it is also open to accepting reviews of actions by non-admins (emphasis added)
#23 Where does one go to complain about page protection?
#28 ... to help ensure editors are using advanced perms in a manner supported by the community "editors" and "advanced perms" means non-admins
#30 I would like to see more-specific criteria for permission removal, but that doesn't have to happen right away. "permission removal" refers to non-admins
#32 This should be treated more as a way to deem whether such actions are appropriate to continue in the future rather than a place to seek sanctions or the removal of user rights. "user rights" == non-admin
#36 ...if you are claiming an editor/admin has a pattern of problematic actions...
#44 Provides a venue and process for providing feedback to help ensure editors are using advanced perms in a manner supported by the community.
Granted, there were 48 supports, and the remainder didn't mention non-admins specifically, many just focused on admin. 24 opposes, none talked about admins. How do we resolve this? The closers wrote: Finally, we note that the process as proposed is not just about the evaluation of administrative actions, but about all advanced permissions, and thus also applies to non-administrators.
Secondly, are you suggesting we revisit #Shortening the instructions on the main XRV page? Levivich[block] 23:04, 27 June 2022 (UTC)
I would argue that only 5 made a point of talking about non-admin tools, (vs. just a choice of noun) but 5 does show my "about 0%" prelim assessment to be incorrect. North8000 (talk) 10:59, 28 June 2022 (UTC)
On your "revisit" question, YES, and that's putting it mildly. Adding that it was never really "visited" in the first place.  :-) To the extent that the current nature and quantity of what's there is intimidation & a barrier for many and thus a near "poison pill" to this venue. North8000 (talk) 11:06, 28 June 2022 (UTC)
What do you think of my idea of moving the current instructions on the XRV page to a /Instructions subpage (which could then be edited as needed), and replacing them on the XRV page with shorter instructions (one desktop screen or less)? Levivich[block] 15:37, 28 June 2022 (UTC)
I think we can draft a set of shorter instructions first, and then decide how they may be presented. I was thinking of making a sandbox and writing a draft, but of course anyone should feel free to go ahead and do so. isaacl (talk) 16:02, 28 June 2022 (UTC)
I say go for it. For my part, I'm not sure exactly what the shorter instructions should say (I have only a vague idea), but I am sensitive to N8k's argument that "bad" instructions (however defined) on the XRV page could be a "poison pill" for the venue, which is why I brought this up a couple weeks ago--which wasn't the right time for it, but maybe now is. No one has said this explicitly but I can certainly understand if some folks think we should figure out the instructions before restoring inbound links. Levivich[block] 18:02, 28 June 2022 (UTC)

Just blank the current stuff it and put a copy of the passed RFC at the top with a sentence or 2 that says "this is that place" and "post your item here". Then we have a discussion on the preliminaries (including if this is an OK venue) and then the main discussions and then make a decision in the normal Wikipedian fashion. North8000 (talk) 01:29, 29 June 2022 (UTC)

How's this for a draft? I tried to trim it back to the essential summary of the RfC close + some instructions. I'm sure more could be trimmed by fresh eyes if needed. If folks are having issues (e.g. we're getting numerous out-of-scope requests) we can always add more guidance later. Ajpolino (talk) 04:55, 29 June 2022 (UTC)
I get that it's not perfect, but the current text is the product of quite a lot of discussion and collaborative editing here from last November onwards. I'd really rather improve it than throw it out and start again. – Joe (talk) 08:56, 29 June 2022 (UTC)
I've tried to shorten and tighten the wording based on Ajpolino's draft and other suggestions here. I think it's better now. The list of things XRV should not be used for is probably now the most bloated thing on the page. – Joe (talk) 10:16, 29 June 2022 (UTC)
I agree. Thanks to both of you. Levivich[block] 00:03, 30 June 2022 (UTC)

Minimum time

I'm curious how much agreement/disagreement we have amongst page watchers about this. Should threads be open for a minimum length of time, and if so, for how long, and are SNOW closes still acceptable? Levivich 18:40, 14 June 2022 (UTC)

  • Well, a SNOW close is a decision to ignore the rules, so we don't need to legislate for them. IAR is policy...—S Marshall T/C 18:47, 14 June 2022 (UTC)
  • It doesn't really make sense, especially for something that's already been reversed. We don't have courts and precedents here, and the natural reaction to something that is moot, even at DRV and MRV, is to close it without reaching a conclusion. Even real life courts don't deal with moot questions. If this is truly an "action review" board rather than a behavioural board, then there's no reason to continue. If there's a clear consensus that something was correct/incorrect or at the very least that a consensus isn't going to develop to overturn an action, there's not really a need for 7 days.
    The reason DRV and MRV last 7 days is because they are reviewing closes of discussions that lasted 7 days. You need to give all participants a time to comment. You don't really need 7 days to decide "oh, this removal of rollback wasn't justified" or on the flip-side "yep, he was abusing rollback, justified." It just becomes a pillory of the losing side once you keep it open too long. TonyBallioni (talk) 18:51, 14 June 2022 (UTC)
    The natural reaction to something that is moot, even at DRV and MRV, is to close it without reaching a conclusion. But not a speedy close. Calling something “moot” and boldly closing can be controversial. No harm comes from a moot case being left open a week or more. Speedy closes allow biased closes on narrow perspectives that disenfranchise editors who prefer to take their time. SmokeyJoe (talk) 22:45, 14 June 2022 (UTC)
    Little plea from the stalls here: calling something "moot" can also be controversial if it's not clear if someone's speaking AmEng or BrEng, or unaware of the difference. (Strangely similar to tabling a discussion; that one can really sour a meeting.) NebY (talk) 23:00, 14 June 2022 (UTC)
  • For my part I don't really have an opinion, other than that things should be open a minimum of 24 hours (I'd like to see 48 hours) to allow global participation before anything is SNOW closed (this is a general principle applicable to all discussions IMO). I can see the benefits of keeping things open longer, just as I can see the downside of doing it. I wouldn't oppose a 7-day minimum, but I'd be fine with a 24-hour minimum, too. Levivich 18:56, 14 June 2022 (UTC)
    • Only "problem" (and I use that in quotes because its a minor one) that I have with 24 hours is that you'd have people still wanting to review moot actions or minor stuff like removing rollback that's quickly solved. If you frame it as a suggested minimum, and then give examples of situations when the minimum might not happen, I'd be good with it.​ TonyBallioni (talk) 19:13, 14 June 2022 (UTC)
      Suppose I want to contribute a statement to the review of a moot action. Why do you want to use bureaucracy to lock me out? Why do you push notions like “quickly solved”? “Quickly” is not an important feature of a review process. “Timely”, yes, “quickly”, no. SmokeyJoe (talk) 22:49, 14 June 2022 (UTC)
  • AE, AN/ANI, and DRV/MRV are the most frequently mentioned semi-equivalents of AARV, and only DRV/MRV have a minimum length of time. I believe (but am not positive) that DRV will often close earlier than 7 days once a decision seems clear? Hell, for permabans of people - a much more serious discussion - the discussion "must be kept open for 72 hours except in cases where there is limited opposition and the outcome is obvious after 24 hours" (from WP:BAN). I don't object to a minimum length if it is reasonable, but 1 week is just giving any dispute unnecessary time to fester. We would be trying to give the dispute a chance to be reviewed by multiple people in various locations; we should be trying to solve problems, not trying to give every editor a chance to comment on every dispute. Personally, I think no minimum time is OK; I don't mind 24 hours; I could accept 48 hours if people honestly felt it better than 24; I would grudgingly accept 72 hours only if doing so breaks a logjam of disagreement here, and only if there were a SNOW exception similar to the WP:BAN quote above; and I would oppose any minimum time longer than 72 hours. If people are really planning to review rollbacks here (🙄) then I super-duper deal-breakingly strongly oppose any minimum time at all for those. That would be extreme overkill (it's rollback, for God's sake). I'm curious if there should be a maximum time, but (unlike fundamental issues) that is the kind of thing that could be hashed out later. --Floquenbeam (talk) 19:02, 14 June 2022 (UTC)
    DRV will often close earlier than 7 days once a decision seems clear? No. “Seems”? “Seems” is a very weak word. Try “is”. I am not sure that “often” is correct either. SmokeyJoe (talk) 22:52, 14 June 2022 (UTC)
    “1 week is just giving any dispute unnecessary time to fester”. Disagree with this. A review process centred on a complaint serves to illuminate and air an issue. This is the opposite of festering. More damage comes from requiring participants to jump in fast and hard or risk being excluded from being allowed to contribute. SmokeyJoe (talk) 22:56, 14 June 2022 (UTC)
  • One of the big problems with AN/I is the way AN/Is get closed before you get time to have your say. At AN/I decisions are made by the people who're on Wikipedia the most: it works to the benefit of the prolific Wikipedians who're here for hours a day and for whom a three-day discussion seems like a needlessly long one. Seven-day discussions would be an opportunity to fix that problem and allow the weekend-only people a chance to get heard. Honestly, who's meant to be harmed by letting a review of their choices run for seven days?—S Marshall T/C 19:16, 14 June 2022 (UTC)
    • I disagree with the focus on giving particular people a chance to get heard. The focus should be on giving the issue a chance to be reviewed by a cross-section of people. Once that has happened, any further delay doesn't contribute to actually solving the problem. And the harm in a 7 day review is that, for admin actions like blocking, once a decision is clear, keeping it open only allows bad feelings to fester. And for "admin" actions like rollback, it about an order of magnitude more time than the problem deserves. Even though participation is optional, there is still a cost, in time, work, and happiness, in dragging out a dispute. --Floquenbeam (talk) 19:22, 14 June 2022 (UTC)
      I agree minimum time limits can cause problems. Especially if there is no requirement to informally discuss things before bringing it here you will have situations where the admin concerned reads the report, says "ah yes, I made a mistake" and immediately reverses their decision - there is no benefit to anybody in keeping these reports open any longer. So I cannot support any minimum period that doesn't have allowances for exceptions. Thryduulf (talk) 19:36, 14 June 2022 (UTC)
      “requirement to informally discuss things before bringing it here”. I strongly support this as one of very few conditions for opening an XRV case. There must be at least a thread addressing the issue and evidence of at least two editors in considered disagreement. This is strongly encouraged at DRV and is almost mandatory at MRV. XRV should not be a place to first mention a disagreement, or it will be filled with trivially resolved issues. SmokeyJoe (talk) 23:02, 14 June 2022 (UTC)
      Would we want to keep it open long enough to give the administrator concerned time to respond? If so, what would be reasonable without stringing things out? Maybe likewise for the editor affected, if someone else starts the thread? NebY (talk) 20:14, 14 June 2022 (UTC)
      Boy, I love this idea. As a general rule, I've always felt that whenever someone's edit is reported to any noticeboard, the person who made the edit should have a chance to respond to the filer's statement before everyone else jumps in with an opinion. How could any uninvolved editor evaluate whether an action is proper if they don't even hear the actor's justification for the action? I'd support making that part of the structure (see next thread below): no uninvolved commentary until the person who made the action has a chance to give their explanation. I'm not sure anyone else agrees with that, though :-) One obvious concern is that a "bad actor" could stall review by refusing to comment. This could, in turn, be addressed by saying something like... no comments from uninvolved editors in the first 24 hrs until after the editor whose action is under review has a chance to comment; after 24 hrs, if the editor hasn't commented, we allow uninvolved commentary. That, however, seems like cumbersome rule creep. I'd love to see it as an unwritten cultural practice, though... everywhere, at XRV, ANI, DRV (the closer should have a chance to explain the close before others review it), MR, etc. Levivich 20:26, 14 June 2022 (UTC)
    Wow. So many ways to stop people discussing bad calls.  :(—S Marshall T/C 20:52, 14 June 2022 (UTC)
    The purpose of XRV, of course, isn't to discuss bad calls, which would be a pointless endeavor. The purpose is to determine whether a call was a good call or a bad call (endorsed or not endorsed are the two options, per the RFC text). It's difficult to imagine how editors could intelligently discuss whether a call was good or bad if they haven't yet heard from the person who made the call. In fact, there exists, to my knowledge, no investigation or dispute resolution procedure in the entire world that doesn't involve an opportunity for all parties to state their views before the decision-makers make a decision. Investigators don't conclude their investigation without first attempting to talk to the person they're investigating. Judges and arbitrators don't make decisions -- or even offer opinions on the merits -- without hearing from both sides first. There's a reason the whole world operates this way, and it's because it's a universal principle of fairness. In fact, it's one of the principles in the FairProcess meatballwiki article you linked to ("Involve individuals in the decisions that involve them. Get their input..."). In my view, anyone !voting "endorse" or "not endorse" without first reading the explanation for why the action was taken would be seriously jumping the gun. And, again, this is applicable not just to XRV but to any investigative or dispute resolution procedure. And of course a delay in allowing uninvolved editors to respond is not the same thing as stopping anyone from discussing anything. Levivich 21:34, 14 June 2022 (UTC)
    If it's at XRV then at least one person thinks it could be a bad call. I don't want people getting their balls busted for talking in the wrong order, particularly if they've got something to say and the discussion is going to get closed after an unknown interval.—S Marshall T/C 21:46, 14 June 2022 (UTC)
    @Levivich Something like the person who made the action should generally have the opportunity to respond before others comment. If, after they are made formally aware, they choose not to respond at all others can leave comments after 24 hours. If they make edits elsewhere on the project then others can comment 1 hour after those edits. However, that should not apply to reports that are clearly made in bad faith, trolling, where the reporter has clearly misunderstood something, or where the reportee has unquestionably made a mistake. Putting the two together I think the best thing would be for comments by others to be generally discouraged unless the situation is obvious and/or egregious. Thryduulf (talk) 20:58, 14 June 2022 (UTC)
    Agree, that makes sense to me. Levivich 21:36, 14 June 2022 (UTC)
    Well! I was thinking more that a thread shouldn't be closed for some minimum time that would give the admin a chance to respond, but this is all much more interesting and could lead to calmer more measured discussions. Yes, waiting would preclude rapid corrective action, but making it clear that it's the wrong venue for that could help calm the board too.. NebY (talk) 21:45, 14 June 2022 (UTC)

Summary so far (minimum time)

It's only been a day, but so far I see:

  • S Marshall and SmokeyJoe in favor of a 7-day minimum
  • Tony, Floq, and Thryd are in favor of no minimum or a short minimum like 24hrs
  • NebY in favor of at least long enough for an admin to respond
  • I'm kind of ambivalent; I think there ought to be a minimum, maybe 24-48 hrs, but would support trying any minimum
  • Everybody (I think) agrees no matter what the minimum, there should still be IAR/SNOW exceptions for obviously bad-faith, out-of-scope, etc., threads

Is this a fair summary? If not, please set me straight. If so, this is a bit of a split, at least numerically. How do we want to resolve this? Do we want to just try one of these options for now and revisit it later (my preference)? Or put it to a talk page !vote? Include it in some future RFC? Levivich 20:15, 15 June 2022 (UTC)

My preference is for no statutory (not quite the right word) minimum, with a second preference for something short. For anything longer than ~24 hours there needs to be exceptions for matters that are unquestionably resolved to the satisfaction of (almost) everybody involved, which are now moot (British English meaning) and/or where (almost) everybody has clearly moved on. Leaving these threads open will not bring anyone any benefit and will increase the risk of them being used for trolling, harassment, etc. Regardless of what the minimum time is or isn't, there should be a culture of not rushing to close. Thryduulf (talk) 22:17, 15 June 2022 (UTC)
A culture of not rushing to close is well put and half of what I would want. It what I see at DRV and MRV. Where as at ANI it feels like things are closed either very fast or very slow. So I think it should be "a culture of not rushing to close but things are reliably closed". I think putting a minimum discussion time is one way to accomplish this - since it provides a cue that it's OK to close - but certainly not the only way. Best, Barkeep49 (talk) 22:22, 15 June 2022 (UTC)
I completely agree with "a culture of not rushing to close but things are reliably closed" being what we want, but I disagree that a minimum time is a good way to achieve that. Thryduulf (talk) 23:05, 15 June 2022 (UTC)
@Barkeep49 and Thryduulf: I was initially in favour of a minimum time because it was the only way I could think of to establish "a culture of not rushing to close" (which is really important). I can see now it has some downsides, but... what are the alternatives? – Joe (talk) 09:16, 24 June 2022 (UTC)
We should have a clear statement about our cultural expectations. Perhaps something along the lines of "reviews should not normally be closed unless it is clear that discussion has either reached a clear consensus or that after extensive discussion no consensus will be reached. Closure of reviews must always be done by an experienced editor and who should almost always be uninvolved. Do not rush to close a review, it is significantly better that one be left open a little longer than required than it be closed too early. While there is no minimum time for a review, it is expected that most on-topic requests made in good faith will remain open for at least a few days. There is no maximum length of time for a review, and ongoing productive discussion should be allowed to continue. Do not close a discussion that has not reached consensus if there is a reasonable possibility that it might do so. On the other hand, it is equally important that every review has a formal closure that clearly states the outcome, and ideally summarises the key points made. Where appropriate, advice for similar situations in the future (e.g. for the person whose action was reviewed, the person requesting the review and/or others involved) is encouraged. Take care that any advice is not seen as patronising or overly prescriptive."
I'm not suggesting we adopt that verbatim, but that we use that as a starting point for discussion. The point about closures being by experienced editors is that one of the criticisms I've seen of ANI (albeit not recently) is of enthusiastic but inexperienced editors trying to demonstrate the qualities needed for adminship closing discussions before they're quite finished. It is important that people get the chance to learn how to close discussions, but I don't think this should be seen as an appropriate venue for that. Thryduulf (talk) 09:49, 24 June 2022 (UTC)
I agree with Thryduulf's first paragraph. Culture can be set in ways beyond formal rules and can have some advantages in discretion that a brighterline rule does not have. One concern I have heard about ANI is the kind of mirror of nthusiastic but inexperienced editors trying to demonstrate the qualities needed for adminship closing discussions before they're quite finished. That is that admin are too quick to close threads about other admin. It was even an ArbCom principle once and I feel like it has been discussed by ArbCom at a couple of other cases even if it didn't make it into principles. But hopefully some of the other pieces being put in place to encourage productive discussions could mitigate the reasons that admin make those decisions. Best, Barkeep49 (talk) 14:56, 24 June 2022 (UTC)
In favour of seven days discussion minimum, for any valid complaint, and that should probably be after 48 hours for involved parties to present their facts. SmokeyJoe (talk) 22:36, 15 June 2022 (UTC)
I too am largely ambivalent. If anything I have a slight preference that we start with a short (or no) minimum rather than a long one. If that leads to discussions that are too chaotic or are closed prematurely, I'll stand corrected and support adding more structure going forward. Ajpolino (talk) 00:02, 21 June 2022 (UTC)
Seven days is a long time to have your fuckups get discussed and let everyone pile on. valereee (talk) 19:26, 23 June 2022 (UTC)
You sound unfamiliar with review processes. Have you ever been involved in one, whether reviewed (personally or your output), or as the reviewer? SmokeyJoe (talk) 00:14, 24 June 2022 (UTC)
I'm not aware that any review process has a minimum time - if the outcome is clear then it is closed before it becomes a pile-on. The closest example I can think of to what this would be is RFA, and even they can be withdrawn. The goal of the discussions that resulted in AARV was to improve RFA not replicate it. Thryduulf (talk) 08:39, 24 June 2022 (UTC)
Think of real world review processes. They have minimum times for processing. They never have the option for fast reviewers to decide that no further others need be heard. Here, I suggest 48 hours for the involved parties to present the facts, before uninvolved participants get involved. Minimum time couples to curtailing the WP:AN style of a rush to close. The rush to close tendency creates a need to rush to comment.
Worse than a rush close is a case that is archived without a close. Both of these things are problems of WP:AN as an administrator review forum.
Who said the goal was to improve RfA? Some, but I don’t that that was thought through. I think the goal of AARV / XRV was to address something deeper, in the hope that that would improve RfA. Maybe the removal of the perception that admins are unreviewable short of ArbCom. I think there were signs that a review forum that was different to WP:AN was desired. Minimum time, and formal closes, would make it different, in a good way.
I doubt that nominator withdrawal should be a speedy close criterion. A boomerang close after a full review might be on the cards.
Even if something could be closed early due to there being nothing to say, should it? Is a week of no comments harmful? There’s harm in closing before allowing comment by people who don’t rush to comment. SmokeyJoe (talk) 09:48, 24 June 2022 (UTC)

Minimum time (continued)

@S Marshall and SmokeyJoe: (the two editors who've voiced a preference for a 7-day minimum) and anyone else: currently, there is no minimum time. A proposal to institute a minimum time could be made by anyone at any time. Do we want to delay restoring inbound links to this page until after we've resolved the minimum time issue, or do we "re-open" without this issue being resolved first (and basicall resolve it later)? Levivich[block] 16:19, 23 June 2022 (UTC)

  • No, I don't want to delay until after we've resolved this.—S Marshall T/C 16:32, 23 June 2022 (UTC)
  • I don't see any reason this needs to be resolved before we figure out what a reasonable length of time is by living through it a few times. 7 days is definitely too damn long for a minimum time to discuss something someone did wrong, IMO. valereee (talk) 19:28, 23 June 2022 (UTC)
  • No, minimum time agreement is not a good reason to delay. I don’t see any good reasons to delay. I hope that the initial period of rapid closing wreckers has passed. —SmokeyJoe (talk) 09:51, 24 June 2022 (UTC)
  • for clarity, since i say this below buried in other test: I think coming up with a minimum time is necessary first, but i think we've pretty much already got that ironed out. Someone just needs to interpret consensus (which, a little messily, I think probably implies coming up with a compromise between 0 and 7). Alternately, Levivich's suggestion works too, if S Marshall and SmokeyJoe are Ok with it. --Floquenbeam (talk) 18:16, 24 June 2022 (UTC)

Remaining blockers

  • This is a sensible suggestion, but given that there are other issues that definitely are blockers to restarting where we haven't reached agreement it doesn't really matter (yet) whether this one is or not. Thryduulf (talk) 23:56, 23 June 2022 (UTC)
    @Thryduulf: what do you see as the outstanding blockers at this point in time? Levivich[block] 16:25, 24 June 2022 (UTC)
    The biggest one is what is and isn't in scope. After that we have what happens when a decision is not endorsed - should it be reverted/reversed or does it need to go somewhere like AN(I)? What happens if an incident is being discussed here and at AN(I)? @Floquenbeam may also have useful thoughts on this. Thryduulf (talk) 16:40, 24 June 2022 (UTC)
    Thanks. I believe both of these points -- scope and what happens when a decision is not endorsed -- is answered by the RFC itself. I posted an analysis up above, see Special:Diff/1093031478. Would you mind telling me specifically what part of the RFC/my analysis of it leaves you with remaining questions about scope and what happens if a decision is not endorsed?
    Here's the TLDR: the scope is (1) any action or related set of actions (2) that requires advanced permissions and (3) is not reviewable elsewhere (e.g., DRV, MR). What happens if a decision is not endorsed is that anyone who can act on it, may act on it (e.g., an editor can revert an edit; an admin can remove a perm or reverse an admin action; anyone can file at ANI/AE/Arbcom), but enforcement is not handled at XRV.
    I'm not seeing what the open questions are about scope or enforcement, and would ask you to please be more specific, particularly in light of the #RFC text and the discussion above about it. Thanks, Levivich[block] 16:50, 24 June 2022 (UTC)
    I haven't been able to participate here this week because of real life, thanks @Thryduulf: for the ping. I see it's progressing, which is good. I wish I had more time to organize. I'm not sure that this thread is the right place to relist issues I, personally, think should be dealt with before going live, so anyone is free to move it to a better section. Apologies in advance for the disorganized unproofread thoughts:
    • There was a strong consensus to remove incoming links and pause the implementation of this board. I still believe there is no rush to make this live in the next week or so, given that it's been X months since it was paused (whether I ultimately replace X with the actual number will be a measure of how much time I have to comment; hopefully you know what I mean anyway). For myself, I would still want to see a well-attended discussion (I still favor an actual RFC) once there is a consensus on the major issues still to be determined, that the result matches what the community wanted. that is, a consensus to overrule the previous consensus to pause it. If I didn't get my way on some of the stuff below, but there was a clear consensus that the community was happy with the decisions made and ready for it to go live, I would not be opposed to that. If there is no clear consensus to go live, I would be opposed to going live, even if I got my way on most of the items below. TLDR summmary, if you don't read anything else: This is the main, overarching concern I have. A go/no go RFC once the stuff below is hammered out.
    • Remaining items that I call "major issues":
      • Intent #1: Clarity that is this solely to endorse/overturn actions, not to sanction anyone.  Done. I'm satisfied on this score now.
      • Intent #2: Clarity on the expectations for participation. If someone brings one of my admin actions here, am I obligated to defend it? Since it's a consensus-based discussion, i know I couldn't revert if it was overturned, but is particpation here voluntary? We've clarified that this is not a forum for sanctioning people, so it seems like that would mean by extension that it's voluntary, but I get the vibe here that an admin or rollbacker not participating here would be considered "actionable" somehow. If there's already a consensus somewhere for this, then fine.
      • Detail #1: Minimum length of time a thread can be open is something that should be decided. sort of  Doneish. I would think there's enough discussion above that someone could interpret consensus on this now; obviously a wide range of opinions, but as long as one of the extremes (no minimum; 7 day minimum) isn't chosen, I doubt this would be a sticking point. Somebody pick some compromise numbers and we're set. Minimum length of time until it's archived is a nit that we can pick later, IMHO.
      • Detail #2: Format: As I say above, I don't know what would be best, and don't care too much what is decided on, but a standard format based on AE or DRV or an improvement on both should be chosen, and people required to use it. Either Thryduulf or Levivich above seem to have reasonable ideas; if no one thinks Levivich's format is bad, let's just use that, and then we're  Doneish. Once it's up and running, then if the format isn't working, it can be changed thru discussion, but don't start out with a free for all.
      • Scope #1: An agreed scope. I do not agree that, for example, there is a clear consensus that individual rollbacks would be reviewed (and I find it hard to believe that a board that is, at heart, the result of a discussion about reform of RFA could have come to that conclusion). If there's consensus for that, so be it (the only real effect is to cause me (definitely) and other people (probably) to take the board less seriously), but I'd want to be confident that such a consensus existed. Aside from any picky technical definitions, a rollback isn't actually a use of advanced permissions the way blocking/protection/etc are; it is a normal edit that has been made incrementally easier thru software.
      • Scope #2: Somewhere on this page, maybe in this section, it says this board is for things that aren't already reviewable elsewhere (DRV, RM). But currently every action I've seen proposed as reviewable here is already reviewable elsewhere, at ANI/AN. That needs to be cleaned up. Are they no longer reviewable at AN/ANI (see implementation #1 below)? Or does the wording here just need to change?
      • Implementation #1: Double jeopardy: if someone doesn't get the result they want here, can they immediately take it to AN/ANI for a review/second whack?
      • Implementation #2: if someone brings an issue here that doesn't belong (in particular, if they do try to get an editor sanctioned), is there a mechanism for shutting it down and/or transfering it to AN/ANI?
      • Implementation #3 Are expected behavioral standards stricter, more lenient, or the same as AN/ANI? Actually, this one is something I think should be addressed before it goes live, but it isn't a dealbreaker for me if it gets ironed out later.
  • --Floquenbeam (talk) 18:10, 24 June 2022 (UTC)
    It looks like everything on this list has already been addressed except for Implementation #1-#3 (let me know if I'm misreading), so I'll take a crack at those:
    1. Double jeopardy - that concept doesn't exist here, as nobody is in "jeopardy" at XRV. By design--by the #RFC text--enforcement action is deferred to existing processes, so yes, it is quite possible that someone would go to ANI after XRV. This is not "double jeopardy", it's "single jeopardy" (you're in jeopardy at ANI, not at XRV).
    2. The RFC says XRV threads are to be closed by uninvolved administrators. That would of course include closing threads as out-of-scope. Whether an admin decides to transfer (move) an out-of-scope XRV thread to the correct forum, or just close it as out-of-scope (with or without instructions about the correct forum) would be something decided by admins on a case-by-case basis depending on the particular out-of-scope thread.
    3. There are expected behavioral standards at AN/ANI? That's news to me, and I'm probably the top editor of ANI. Our expected behavior standards are outlined in policies like WP:CIVIL and they don't change from one page to another.
    W/r/t Scope #1, the scope was set by the RFC. You don't have to believe it or agree with it :-) The close was explicit: all advanced permissions that can't be reviewed elsewhere. Yes, that means rollback. That one or two or three or ten of us don't agree with this is not cause to revisit it. The RFC close was upheld on review already. It's only a few months old, too soon to test if consensus has changed. The scope is all advanced permissions that can't be reviewed elsewhere, and we needn't discuss that further. Levivich[block] 16:21, 25 June 2022 (UTC)
    @Floquenbeam: I'm going through these again to make sure we've at least tried to address them all.
    • Intent #2 – I think everyone agrees that participation here is voluntary, so I've added that to the header.
    • Scope #1 – I've started a thread about rollback below.
    • Scope #2 – the current wording of the header is "another, more specific review process". The intended meaning is things like DRV, MRV or ARCA, and this is made explicit in the following section. As I see it, AN/I is a noticeboard, not a review process, and to the extent it has 'review' functions it is definitely less specific than XRV. Do you think that makes things clear enough?
    • Detail #1 – I think there's a consensus to defer the question of minimum time for now. I've updated the header to say only that they should be sufficient time for a consensus to emerge (or not).
    • Detail #2 – we've implemented Levivich/Thryduulf's suggested format, let's see how that goes.
    • Implementation #1–#3 – I think these are interesting questions but larger ones of wider project governance, not something we can or should try to hammer out here. AN(I) is by design a "catch-all" noticeboard so the existence of XRV changes nothing about AN(I)'s scope or operating procedures, in the same way that the existence of DRV doesn't stop someone taking a bad deletion to AN. Or for that matter challenging a DRV close at AN if they don't like the result. As Levivich says, behaviour here is governed by the same conduct policies as everywhere else. I hope all this time we've spent crafting the process to be low-stakes and non-confrontational will produce a better atmosphere at XRV than ANI, but it's not a hard code of conduct or anything.
    Does that sounds fair to you? Am I missing anything? – Joe (talk) 08:08, 3 July 2022 (UTC)
Floquenbeam intent #2

Per WP:ADMINACCT:

Administrators are expected to respond promptly and civilly to queries about their Wikipedia-related conduct and administrative actions, especially during community discussions on noticeboards or during Arbitration Committee proceedings. Administrators should justify their actions when requested.

Based on that:

  • Administrators should reply substantively to a query about their tool use somewhere.
  • Administrators should make a post on this noticeboard once they become aware of an open discussion, either replying substantively here, or else directing us to a place where they have done so.
  • Administrators are not required to keep up with every twist and turn of a protracted discussion, their obligation is one substantive post. Anything beyond that is discretionary.

Tazerdadog (talk) 20:24, 24 June 2022 (UTC)

Are we ready to do this? Is there anything left to discuss/decide before we do? Can I get a headcount of who thinks we should/shouldn't have an RFC to restore the incoming links (as opposed to a "regular" talk page discussion here that isn't tagged with {{RFC}} and advertised elsewhere)? Levivich[block] 15:16, 27 June 2022 (UTC)

Normally I would say that an RfC is not needed given the existing recent consensus. How it came into being during an RfC on RfA hurts it in this regard. Some chose not to participate in that process because they were cynical anything would happen that they cared about. Those people deserve to live with the consequences of their choice. But others are interested in user conduct but not RfA and so might have chosen to not participate thinking it wouldn't be of interest to them. Those people are harder to write off for me. Further, as a conduct board in order to be effective it must be seen as legitimate so a follow-up RfC feels more reasonable here than with say removing autopatrol from admins which also took some people by surprise. Having community demonstrated through an RfC would provide that legitimacy and I think was an important factor in Floq and Thryduulf coming to form the consensus that people have reached here. Best, Barkeep49 (talk) 19:56, 27 June 2022 (UTC)
I think we're ready to restore incoming links and give this board a second chance to operate. I don't think we need another RfC, as we're still just trying to enact the close of the RfC that sparked the creation of this page. We've already had RfC#1 to start this page, RfC#2 proposing the page be shut down (closed early as unhelpful; note part of TonyBallioni's close Those of us who think it was a bad idea are content to see if it actually takes off or if it dies), RFC#3 above proposing again that the page be marked historical (again closed early as unhelpful). Do we really need an RFC#4 to query whether the page can be advertised by incoming links? The stakes are truly not that high. The board can only discuss actions to endorse or not-endorse. If it devolves into unhelpfulness (as most new things are likely to do!) we can revisit tweaking the procedures or shutting it down. Ajpolino (talk) 04:01, 28 June 2022 (UTC)
I don't think an RfC is necessary. In the discussion that led to the links being removed, it was proposed as a "temporary" measure until "there is a consensus somewhere that it is ready to go live". But we might want to do it anyway, because (assuming it's successful), it should remove any doubt that this implementation of XRV has consensus. – Joe (talk) 09:31, 28 June 2022 (UTC)
I don't think we need an RfC to restart it, but we definitely do need a clear consensus of more than just 4-5 people - ideally comparable to the size of the consensus to remove them. Per other discussions on this page it definitely is not ready to be restarted yet. Thryduulf (talk) 10:26, 28 June 2022 (UTC)
It is functioning. The “restart” notion is moot. Can you link the consensus to remove incoming links? I don’t recall even the proposal.
it definitely is not ready to be restarted is a nonsense statement. Have you studied the beginnings of WP:DRV? What makes that opinion “definite”? SmokeyJoe (talk) 12:14, 28 June 2022 (UTC)
The consensus that led to the removal of incomming links was linked by Joe with the words "discussion that led to the links being removed". If you aren't reading and/or understanding something that couldn't be more obvious then it's no wonder you aren't understanding anything more complicated written here.
I have not studied the beginnings of DRV, but I don't understand why that is at all relevant given that this is not DRV and there are multiple sections on this talk page detailing what needs to be agreed before it can restart - it was, as Joe quotes paused "until there is consensus somewhere that it is ready to go live". It doesn't need to be perfect (that is indeed unobtainable) but it does need agreement on the absolute basics if we don't want a repeat of what happened last time. Thryduulf (talk) 13:20, 28 June 2022 (UTC)

Restore. You don't need perfection to start. We can work this out and evolve with real cases which is the Wikipedian way for such things. Also, a temporary decision to hide this forum last January when this was new was OK, but keeping it hidden 6 months later is in conflict with / would be a cancellation of the broad RFC which created it and would need another equally broad RFC to do. North8000 (talk) 12:39, 28 June 2022 (UTC)

It was hidden until there is a consensus that it is ready to go live, such consensus has not yet been achieved. This is not in conflict with the RFC which authorised (for want of a better term) the development of the venue, not it's near immediate start without agreement on all the fundamentals. Thryduulf (talk) 13:22, 28 June 2022 (UTC)
No, the RfC authorized the immediate start, NOT further discussion and development. That's why it was started. The fundamentals were agreed upon at the RfC. Please don't suggest there wasn't consensus for immediate implementation. Levivich[block] 14:27, 28 June 2022 (UTC)
The RfA RfC was explicit that proposals needed to be ready enough for implementation that a further RfC would not be necessary and proposals that did not meet this standard, in my judgement as the facilitator, were removed. So I agree with Levivich that the RfC did authorize the opening of the board. That said I've noted above why I think an RfC at this point would be helpful. Best, Barkeep49 (talk) 15:45, 28 June 2022 (UTC)
Restore. There was a consensus to start this board, and until that consensus changes it is inappropriate to make the board non-functional through other means. BilledMammal (talk) 14:30, 28 June 2022 (UTC)

I agree with resuming promotion of this venue as a place to review actions taken by holders of advanced permissions, in accordance with the consensus agreement in the 2021 RfC to implement the proposed review process. As with many other English Wikipedia processes, the community can determine by consensus how it may want to refine this forum's operating procedures, through a feedback cycle based on how cases are being handled. The greater flexibility with this approach is, in my view, preferable than having an RfC now to try to set the operating procedures. isaacl (talk) 15:57, 28 June 2022 (UTC)

I would really encourage those who are saying to restore links to think carefully about the point TonyBallioni made about proponents overplaying their hand, and that is at least part of why this didn't take off. Best, Barkeep49 (talk) 16:11, 28 June 2022 (UTC)

Can you explain that? What is the "hand" in this analogy? And how does one over or underplay it? I kinda reject the poker analogy because this is not a game, or a competition of any kind, nobody has a hand to play, no one is trying to win anything, and no one can lose anything. But maybe I'm not understanding the analogy. Levivich[block] 16:13, 28 June 2022 (UTC)
You're right it's not a game. It's simply a situation where people who think this board could be useful could move in a way that might lead to a rejection, where a different way of moving would lead to its acceptance. That is there's no difference in the structure of the board only a difference in how it is rolled out to the community. That's how I would see "overplaying the hand." Best, Barkeep49 (talk) 16:54, 28 June 2022 (UTC)
I have a different perspective on this entire dispute.
I reject the characterization that the board "didn't take off" (or that it "failed" or was "unsuccessful" or anything similar). The board took off right away. It had lots of use. It was successful. Immediately. Then it was stopped. Shut down. It wasn't any kind of natural death or failure to launch, it was just that a few people took actions (delinking, closing threads) to try and stop this board from being used. Those actions were not successful; the board has continued to be in use, despite being delinked. It never stopped. It was delinked in January, but there were reviews in February and March, and now again in June. In March and April we were all on the talk page. That everyone took a break in May doesn't mean this didn't take off.
"People who think this board could be useful" == the global community. It has consensus. I reject the idea that what we're doing here is moving towards "acceptance". This board has already been accepted by the community, by a 2:1 margin, and upheld on appeal. We're not moving towards a place where this board may be accepted or rejected. The board was already accepted, and it's too soon to revisit that decision.
We are all moving towards the same place: the inbound links will be restored. It's not about if, it's about when, and whether we do some other things first (as we've been doing: modifying the template, discussing the instructions, discussing details like time limit and the gray areas of scope, etc.).
There is no way that anyone working here can fail or overplay their hand. It's just not possible. And I think, for anyone who thinks that this is about "some people who want this board" vs. "some people who don't want this board", is thinking about it wrong. That discussion was had at the RFC; this is not that discussion. This is the discussion about how to implement, not whether. And you can't overplay your hand in a discussion about how to implement something. We're not rolling this out to the community because this has already been rolled out to the community; all we're talking about here is what we need to do before inbound links are restored. Levivich[block] 17:10, 28 June 2022 (UTC)
I used the words rejected and accepted for a reason. I would characterize what happened as a rejection of the board by a number of editors. There were enough of them, and they had enough social capital, that this group of editors was able to make this board hard to find compared to other similar boards. These actions had an impact. I also find it impossible to believe you (Levivich) think these actions had no impact else you wouldn't have done the work you have to reverse them. I do not think a board that is accepted enough to do 1 or 2 reviews a month, which is what this board has averaged, is much of a success compared to a DRV/MRV which may do 1 or 2 reviews a day. And for that greater success the number of people who accept this board matters as does the number, and social capital, of those who dislike it. Do I think, by the letter of an RfC, that this board could be relinked? Yes. Do I think it should be? No, I think it would be unwise but since according to your frame I am thinking about this wrong I will unwatch this board so as not to get in your way. Barkeep49 (talk) 17:46, 28 June 2022 (UTC)
Move review is actually used at a similar rate to this board; this month it has considered three moves, and in May and April it did two. February and March had a few more, six and eight respectively, but in January it didn't review any discussions. BilledMammal (talk) 00:12, 29 June 2022 (UTC)
I find it very annoying that proponents somehow have to be 'careful' how they 'play their hand' because there's an influential group of opponents who will jump on every poorly-played card. I understand that those who are recommending taking such care are trying to be genuinely helpful to the process, but honest to fucking god. Seriously, it requires walking on eggshells to get people to agree we've all agreed admins need to be accountable? Over on AN right now I've got an admin arguing that a completely out of touch admin who has been creating crap and refusing to discuss needs to be 'taken at their word' (which they violated ten minutes after giving it) and that we should just close the discussion and allow that admin to go on their merry misguided way. If this were an editor with 2000 edits, they'd've been indeff'd a week ago for creating crap and refusing to discuss. But it's a legacy admin, sooooo..... Fine, if we need another RfC, let's do it. But super annoying. valereee (talk) 17:58, 28 June 2022 (UTC)
To explain what I meant — I was simply saying that some of the suggestions on this talk page for how this board should function never had anything approaching community consensus and are ideas on the fringe of how most editors think of Wikipedia's self-governance (the minimum 7 day period, mandatory closing statement, review of moot actions, etc.) The other reason this board failed is because anytime anyone tries to point out any of the issues, they get sucked into unending conversations without the idea of compromise in mind, so anyone who was willing to help work out the kinks decides to abandon this page and only the people supporting it are left. That further feeds the problem of a small group attempting to impose on the community a process there was never consensus for.
In terms of restoring incoming links, I essentially agree with what Beeblebrox was hinting at above: this was attempted. It failed. There was consensus to remove the links. If you want to start it up again, you need an active consensus for it. If you want to try it without doing that, it won't be regarded as legitimate by a significant portion of the community because it was essentially abandoned for months and left unused because the format wasn't working. TonyBallioni (talk) 20:58, 28 June 2022 (UTC)
Just for the record, I specifically mentioned a mandatory close by an admin in the RfC proposal text and the 7 day minimum period was motivated the fact the main model for XRV, WP:DRV, has a 7 day minimum period (which we've now dropped). – Joe (talk) 08:28, 3 July 2022 (UTC)
I considered what I thought would be the best path forward, considering the strongly-held viewpoints of various editors (both proponents and opponents), and in terms of what Dennis Brown said: saying it's good enough to start, starting, and then improving the process. I think we can get better community feedback on next steps by having some more practical examples, and then reviewing how they've gone. I agree there is value in re-establishing community consensus with another RfC, and that it may be helpful to build support. Nonetheless, I think on balance it would be more effective to have more data first upon which further decisions can be based, whether that is to refine the procedures or retire the review process. Right now, there are a lot of experienced editors who feel that the process wasn't given a reasonable period to be evaluated. More cases will enable editors to revisit their views as appropriate.
I think the current proposed procedure is about as minimal as possible and has addressed a number of TonyBallioni's specific concerns, thus is a good starting point. Tony suggested that the only discussion format likely to get community support is an open-ended one similar to the administrators' noticeboard. Other than a defined format for the original commenter, the rest of the discussion is indeed open-ended. Regarding two of the points mentioned regarding going beyond consensus from the RfC: one of them is on a minimum duration; there is an apparent consensus to have no fixed minimum time for now. Another is on whether or not the community could review a choice not to act; there is an apparent consensus that a choice is not reviewable, whereas a decision declining a formal request is considered an administrative action and thus is reviewable, though it may be more reasonable to pursue other options, such as making a better request later. [2] [3] (Guidance on review of settled matters and accompanying closing statements does not yet have consensus agreement. By default the usual community consensus on a case-by-case basis is applicable. This will likely mean settled matters will generally not be reviewed.) There is of course disagreement on whether or not the original consensus should be considered invalidated by a failure of the process, which was covered in Wikipedia talk:Administrative action review#Formal RFC. isaacl (talk) 22:20, 28 June 2022 (UTC)

To use an usefully-oversimplified term, in Wikipedia a "consensus" is basically a supermajority. And a normal maneuver in Wikipedia debates is to try to craft it that the action/person/side that they disagree with needs a consensus (supermajority) in order for their view to be followed. This isn't mis-behavior, it is common accepted tactic, but it should be recognized. And a common tactic to further it is to suggest that pointing it out is making a severe accusation and thus itself mis-behavior......it isn't. So maybe we should say that a consensus is required in order to require a consensus.  :-) North8000 (talk) 11:54, 3 July 2022 (UTC)

Consensus is NOT a supermajority. The two concepts have huge overlap, but a consensus cannot ignore a vocal minority, as can a supermajority. —SmokeyJoe (talk) 12:21, 3 July 2022 (UTC)
I know that (and knew that 10 years ago) which is why I prefaced my use of the term. But with that caveat it was still a useful term towards succinctly making my point.North8000 (talk) 12:36, 3 July 2022 (UTC)
Here's a substitution that was shortened by use of that term: The referenced accepted and common tactic is to invoke/craft the "consensus needed" wording that "my" view automatically prevails if:
  • Nobody does the work of going through the process that could result in obtaining a consensus
  • They do go through the work and a middle ground "no consensus" result ensues
Sincerely, North8000 (talk) 12:46, 3 July 2022 (UTC)
I think I agree with you, although you are not writing plainly enough for me. I’m glad you know what consensus is, because I thought you did, for well over a decade. I think you might be saying that some people are making debate manoeuvres, aka GAMEing, to derail this review forum. I think we might agree that people who keep talking about “consensus” are not sincerely working towards consensus. SmokeyJoe (talk) 03:34, 4 July 2022 (UTC)

Should rollback be excluded from review?

(Working through Floquenbeam's list of remaining blockers)

The original RfC set the scope of XRV to the admin tools plus any user right handled at PERM. This technically includes rollback, but rollback is often seen as a trivial tool. Should rollback be specifically excluded from the list of permissions reviewable here? – Joe (talk) 07:36, 3 July 2022 (UTC)

  • I'm neutral on this. Obviously XRV was not proposed with rollback specifically in mind, we've just inherited the odd classification of rollback as a 'permission' that needs to be granted by an admin. Nobody has challenged a single rollback here so far, and I doubt they will do, so it doesn't seem like a problem that needs to be solved. On the other hand, the potential silliness of a "rollback review" has been a recurring point of criticism, so I have no problem removing that possibility if it reassures others that this is supposed to be a venue for serious review of actions that have a tangible impact on the encyclopaedia or on other editors. – Joe (talk) 07:42, 3 July 2022 (UTC)
  • Lots of such tools will never have a case brought here. But they were in the RFC so we should just leave it open to that possibility without spending a lot of time and page space planning for what will not occur. North8000 (talk) 13:08, 3 July 2022 (UTC)
  • Actually, there was one rollback review, it was on Jan 5, a number of people had a strong reaction to that, and it's what led to the temporary delinking on Jan 7 (and the close of the review thread following the delinking). Personally I don't see the harm. Yes, it's hard to think of something less important than reviewing a single use of rollback, but there are lots of things that people do on this website that I think are really unimportant. Adjusting the formatting of the templates for train lines, for example. Rewriting the instructions at MOS about passive voice. Every day thousands of people spend time on this website doing things that I think are a complete waste of time. But I don't have to participate in it, it doesn't hurt me to let other people work on something they think is important. So, I think if someone wants to bring a rollback here for review, and if others want to participate in that review, let them. Misuse of rollback have been the catalyst for plenty of AN/ANI/Arbcom cases; it's rare but it does happen. Frankly, I think the collective "freak out" about that one rollback review caused way, way more work and problems than just letting that review proceed. (Indeed, six months later, here we are...) Levivich[block] 15:03, 3 July 2022 (UTC)
    Ah, I see. Now it makes more sense why rollback keeps coming up. – Joe (talk) 09:24, 4 July 2022 (UTC)
    More substantively, I think we might end up wanting to modify the scope from the RFC's broad scope of "all", but I also think the board needs more experience under its belt before we really know how exactly the scope should be modified. I would revisit scope after there's been like 20 threads. Levivich[block] 22:54, 11 July 2022 (UTC)
  • Why? Now, if someone bothers to come to a dramaboard about one single rollback - just move along; if it is a series of them, or a bulk-rollback, sure why not? — xaosflux Talk 20:59, 3 July 2022 (UTC)
  • I'd lean to including rollback per the RfC close. If rollback reviews become a problem, we can revisit this issue in the future. Ajpolino (talk) 18:30, 8 July 2022 (UTC)
  • Yes, please remove from scope. Misuse of rollback is a behavioral issue. Unlike every other "administrative" permission, it doesn't allow anyone to do anything a non-rollbacker can't do, it just allows them to do it in one click with no explanatory edit summary. If someone misuses rollback once, it doesn't belong here. If they have a pattern of misusing it, then that belongs at ANI where they can be warned or sanctioned or have it removed. Since people have been very clearly telling me that the only thing that can happen on this page is endorsing or overturning the action(s) under review, we would be having a structured discussion that at the end of 2 or 3 or 5 or 7 days (haven't looked at previous sections yet to see where we are on that) would result in an "endorsement" of an edit, or a revert of an edit. Reviewing rollback here would (a) lead me to believe that maybe we are evaluating behavioral issues after all - which I was assured we weren't - and (b) lead me (and, maybe I'm projecting, others) to not take the board seriously. If a board does something silly and triffling, it loses the respect necessary for being used in non-silly and non-triffling issues. --Floquenbeam (talk) 20:03, 8 July 2022 (UTC)
  • No, or at least wait for rollback reviews to become seen as a problem. Recall that XRV is not a first port of call for reporting a problem, there must be some attempt to resolve that is unable to be resolved without wider input. As any admin can grant or remove rollback permission, this almost necessarily means that the issue has become a disagreement between admins over whether to remove someone’s rollback permission, and that, rollback permission granting/removal disagreement, squarely belongs at XRV. Behaviour will always be a factor with any action, and so XRV will never be blind to behaviours. It is sufficient that XRV is not a forum for ruling on behaviour in the absence of an issue of use administrative actions. —SmokeyJoe (talk) 01:59, 12 July 2022 (UTC)
  • [if] the issue has become a disagreement between admins over whether to remove someone’s rollback permission, [that] squarely belongs at XRV I strongly disagree with that. A disagreement over whether to remove someone's permission is something this board definitely should not be used for. It can explicitly only "endorse" or "not endorse" an action, and one of those outcomes (which depending on the status quo ante) would mean the permission needed to be removed or re-granted - something that is explicitly outside the remit, so it would have to go to AN for a discussion to either endorse or not endorse the consensus here. That is just a complete and utter waste of everybody's time when it should have gone to AN straight away. As for individual rollback actions, Floquenbeam has it spot on - single instances of (possibly) incorrect rollback are far too trivial to spend multiple days of structured discussion over, multiple instances are a pattern of behaviour which are something else that is explicitly outside the scope. Thryduulf (talk) 10:27, 12 July 2022 (UTC)
    It depends how the review plays out. If the crux of the question is whether use use of rollback was so bad as to warrant removal, then it is a worthwhile review. SmokeyJoe (talk) 11:18, 12 July 2022 (UTC)
    If the single action was such that removal of the permission is an option that needs to be realistically considered then the review should not be happening here because the board explicitly cannot remove a permission. Thryduulf (talk) 11:48, 12 July 2022 (UTC)
    We don’t shut down DRV because sometimes a question nominated could be resolved elsewhere.
    If the crux of the question is whether the action was improper, then this forum would not be a wrong venue. If XRV resolves that an action was wrong, that’s an outcome. The process of community consultation and group reflection is the purpose of a review forum, and this purpose will have been met. Whether it means someone’s permission should be removed, eg they say sorry won’t do it again but someone else doesn’t believe them, then sure, take that to the drama board. You may call this inefficient, but efficiency is not a primary KPI of a review process. Utter waste of time is an exaggeration. SmokeyJoe (talk) 12:19, 12 July 2022 (UTC)
    We don’t shut down DRV because sometimes a question nominated could be resolved elsewhere. We don't, but that is not relevant because (a) there is agreement about what DRV should be used for (which is what we're trying to achieve here) and (b) when something out of scope for DRV is raised at that venue we don't waste time discussing it there we close it and direct the requester to the correct venue. The purpose of this board is only for reviewing actions where the appropriate courses of action are "endorsed" or "not endorsed, with no possibility of sanction". If a sanction could be appropriate if the action is not endorsed then discussion here is a waste of time. If any individual rollback action rises to the level of significance that a structured discussion is not cracking a small nut with hydraulic press then removal of the rollback right has got to be a possible outcome and that just is not possible here. Thryduulf (talk) 12:46, 12 July 2022 (UTC)
    We have wildly different perspectives if you think XRV is to be like a hydraulic press.
    I think XRV is to be a calm place where particular questions can be discussed in an exploration of consensus on such questions. A room with tea and lounges.
    I think the underlying demand was for something DIFFERENT to AN(I), and I am befuddled by the XRV-resentment of the AN(I) crowd. It’s as if they fear losing power or something. SmokeyJoe (talk) 02:01, 13 July 2022 (UTC)
    AARV isn't (hopefully) going to be like a hydraulic press in character, but using it to discuss an individual use of rollback is going to be similarly overkill to using a hydraulic press to crack a nut, especially as informal discussion with the person who used rollback first. The only time that using a heavyweight process like a review venue for a single possibly bad rollback (not a pattern of possibly bad rollbacks) is if the use was so inappropriate that it needs to be considered whether the person is fit to have rollback access. AARV is explicitly not allowed to make those considerations, so any discussion here that concluded the rollback was not endorsed would have to then go to either AN or ANI to determine whether the rollback permission should be revoked. Given that AN(I) is equally capable of deciding that the specific rollback should be endorsed, there is literally no benefit to anybody to having a discussion here (unless you consider spending 3-7 days discussing a single rollback only to conclude that more discussion is needed elsewhere is a good use of editors time, and a good way to encourage editor retention). Thryduulf (talk) 09:50, 13 July 2022 (UTC)
    Just like this thread itself, some people may like to discuss angels on the head of a pin, or the boundary line of the proper use of the advanced permission of rollback in a particular circumstance. Better to let them discuss it, in this contained "no outcomes" special location, that to tie yourself in knots writing rules to prevent discussions that you don't think are important.
    In real cases, on a case by case basis, if there are really going to be cases, participants can say there and then that it is out of scope. This is what's done at DRV. Closing out of scope case with a consensus that it is out of scope is far healthier that making rules to prevent people raising something they think they should be able to raise.
    The question of access to the advanced permission, which you say agreeably is squarely an AN issue, can depend on whether the community thinks the practice is OK or not. This forum would be for the narrow question of whether the action was OK, and like any forum, individuals may make recommendations, but I am with you on actionable outcomes being for AN to make formal decisions. And I note there has never been a suggestion that decisions at WP:AN might be limited by an ongoing discussion at XRV.
    I see no downside of freedom to raise any issue of advance permission here. Editors are not dragged here by any threat if they don't. Who do you think is scared of this review forum operating, at any level, let alone to the point of leaving should it be active? I think more people are frustrated by the lack of process at ANI. SmokeyJoe (talk) 10:58, 13 July 2022 (UTC)
  • If it's going to be an ongoing source of pushback here, I'm fine with leaving it out, at least until the board has had time to mature. We can always open a future discussion if those leery of this board start to feel better about it over time. valereee (talk) 10:54, 12 July 2022 (UTC)
  • Comment (I weighed in above) If we are talking about changing /affirming the details of the scope, it does need to get switched to that of the title...(all) admin actions....and the title was a big part of the RFC. If we're not, it's a waste of time worrying about rollback which this board would never get used for anyway. North8000 (talk) 11:20, 12 July 2022 (UTC)
    Well the scope in the RFC close was "the process as proposed is not just about the evaluation of administrative actions, but about all advanced permissions", and it is not universally agreed whether rollback is an "advanced permission" so that doesn't help at all. Thryduulf (talk) 11:44, 12 July 2022 (UTC)
    I was just going by this RFC's wording which said that the finding included permissions handled at PERM. In which case, rollback would technically be a part of the finding with no open question. Your post points out that that handled at PERM is not technically the case and thus there that there is a question to be decided. North8000 (talk) 13:25, 12 July 2022 (UTC)
    Of course rollback is an advanced permission. There is no dispute rollback is a perm. Levivich[block] 14:48, 12 July 2022 (UTC)
  • We're spending far more time discussing whether rollback is in scope than we've spent reviewing rollbacks at XRV. If the point of excluding rollback is to avoid wasting time at XRV, we seem to be doing the opposite. Levivich[block] 14:54, 12 July 2022 (UTC)

Inclusion of XRV at WP:DRR

 You are invited to join the discussion at Wikipedia talk:Dispute resolution § Discussions for discussion and administrative action review. {{u|Sdkb}} talk 17:25, 12 September 2022 (UTC)

Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia_talk:Administrative_action_review/Archive_3&oldid=1160264871"