If I may suggest, I’d recommend putting this task on hold (or subtask it) and creating a broader, multi-phase one:

• Phase 1: Update MediaWiki help pages about configuration. For instance, this page doesn't really mention which MediaWiki: pages are configurable, such as:
  • MediaWiki:Growthexperiments-help-panel-suggestededits-tips-vector-visualeditor-references-main-value
  • MediaWiki:Growthexperiments-help-panel-suggestededits-tips-vector-visualeditor-references-main-calm
  • MediaWiki:Growthexperiments-help-panel-suggestededits-tips-vector-visualeditor-references-main-rules1
  • MediaWiki:Growthexperiments-help-panel-suggestededits-tips-vector-visualeditor-references-main-step1
  • MediaWiki:Growthexperiments-help-panel-suggestededits-tips-vector-visualeditor-references-main-step2
  • MediaWiki:Growthexperiments-help-panel-suggestededits-tips-vector-visualeditor-references-main-step3
  • MediaWiki:Growthexperiments-help-panel-suggestededits-tips-minerva-visualeditor-references-main-publish
• Phase 2: Encourage local communities to update their own configuration pages (the ones listed above, as well as MediaWiki:GrowthExperimentsConfig.json), especially to ensure that the help texts are consistent with their local editing guidelines and policies.
• Phase 3: Gather feedback from communities. Ask communities what kind of newcomer tips they would like to provide but currently cannot due to configuration limitations.
• Phase 4: Later GrowthExperiments updates: Repeat phase 1-3 + Monitor configurations. Track the differences between system messages (MediaWiki:), Translatewiki translations, and the extension itself, so that future global changes can be driven by communities ; ensuring local configurations continue to apply consistently even when global settings or translations evolve.

Bonus: could we consider renaming those MediaWiki: pages? The current naming pattern (main-value, main-rules1, main-step1, etc.) feels a bit confusing, as the logic behind it doesn't seem very intuitive for most people. Also, minera or vector-visualeditor don't seem very useful or meaningful either. Let's keep it simple.

Possible fix(?): explicitly define image parameters in WikiRegexes.cs, since they are keywords delimited by pipes |. Typo shouldn't be applied to those parameters
(including aliases, unless the language changes from [en] to the target wiki language).

In T401466#11070916, @kostajh wrote:

It's because we have limits on how many edits we query (controlled by GrowthExperiments GEUserImpactMaxEdits), which is currently 1,000 edits, and that user has a lot of edits.

it does not exist on frwiki

I just realized something: this behavior might be due to the 'checkuser-temporary-account-no-preference' permission I inherit from my frwiki CU status. However, if that’s the case, the box should be displayed and checked — and in any case, it shouldn't prevent linking to meta:Special:GlobalPreferences#mw-prefsection-personal-checkuser-tempaccount in the Guide Tour.

If this task overlaps with T298977, sorry about that, feel free to close as duplicate.

In T397676#10941701, @LD wrote:

@Stang I'm not sure I fully understood the on-wiki talk [...]

If I understood that is the conclusion showing the consensus for the task.

@Stang I'm not sure I fully understood the on-wiki talk, but is there a specific reason for moving the task from Backlog to Blocked on community consensus? If it's genuinely blocked pending consensus, should it still be reviewed and eventually merged?

Thanks @Dreamy_Jazz, newline looks good to me.

Thanks for guidance. I then suggest discussing the grant for the other groups with CheckUser access, like ArbComs. I mean publishing on CU Policy talk that groups with CU access could monitor the uses of TA views, if they ask for it.

Thanks @Dreamy_Jazz
I'd suggest to make changes to form 139 as well (permissions->group).

If there are no objections from TSP, I will proceed with the changes and deployment.

On the technical side, it's not even clear what data is available to the OAuth extension. CU gets its IP/UA/CH data from the incoming HTTP headers. For an OAuth request, those fields will probably reflect the OAuth client software rather than the end user. Possibly what we want to do is encourage client developers to pass along the original end user data in XFF headers or some similar mechanism?

Closing the task, as the policy has been reviewed by the team / @MMoss_WMF (diff).

In T393420#10794573, @Pppery wrote:

Being a crat but not a sysop makes absolutely zero sense.

I can't guarantee that this is exhaustive: at least Ket (bgwiki), Hippietrail (enwikt), Bdamokos (huwiki), and Bencemac (huwiki) are bureaucrats and not sysops.

Thanks. I didn't include huwiki (I might have failed the conversion of sitematrix), which explains why I didn't see it. I might consider trying once again to review all projects, unless someone has a better way than scraping the API.

That aside, the following sentence does not authorize sysops to terminate access.

@Ladsgroup: Thanks for keeping an eye on it. It might be helpful for communities to receive some feedback on what’s happening. Should I create a subtask?

Hashar's perspective might be relevant (feel free to unsubscribe) as I found the 'running tests' approach similar to Jenkins.

@Spartan.arbinger: While I'm not an admin on GitLab (nor an active GitLab user, to be fair), it looks like your developer account is 'spartanarbinger' - without the dot. That's why I edited the task.

@Ladsgroup: if you could examine theses one, just in case it has to be unclosed.

This still seems unresolved, unless it's related to something else.

[97675ccf-d5d6-495e-92e7-858d0f311311]

In T388521#10631809, @kostajh wrote:

In T388521#10626763, @hgzh wrote:

In T388521#10626214, @tstarling wrote:

@hgzh what are you doing which caused you to notice this? I assume you are not routinely typing mw.config.get("wgRelevantUserName") into your browser console.

I wrote a script that adds a link to block the /64 range for IPv6 addresses if Special:Block is opened for an IPv6 user. To get the block target I use wgRelevantUserName, but the link didn't show up anymore recently.

@hgzh could you share your script, please? Seems like this would be a useful thing to have in the core functionality for Special:Block, as a toggle-able option at least.

cf. github pull 280: it needs a review [patching version].

What about checkuser-temporary-account? Redefine as temporary-account-view?
view- could be prefix or suffix on its own, but then many rights have to be redefined.

For reference, step 2 is amended as:

• Make it assignable by bureaucrats. (wmf-config/core-Permissions.php)

Reason: default config creates the event-organizer user group and makes it assignable by sysop. See T376822.

Once reviewed and ready to merge, feel free to modify the deployment (there's no rush).

It seems to be being discussed this week (@sgrabarczuk).

From what I understand, if user_unnamed_ip variable (T364833) is added to frwiki, then abusefilter-access-protected-vars should be granted to local maintainers.
In the meantime, adding checkuser-temporary-account-no-preference to abusefilter group hasn't been discussed yet on frwiki (until now they discussed to grant it to rollbacker group).
It can be stalled until further clarifications, even if enwiki already has a similar config.

commit#1080244: we also need to clarify whether the default configuration, where the 'sysop' group has both abusefilter-access-protected-vars and abusefilter-protected-vars-log rights, should be transferred to those maintaining AbuseFilter locally or other groups in mediawiki-config.
Given that AbuseFilter is managed by the 'abusefilter' group on frwiki, should we: