Page MenuHomePhabricator

Enable of extended confirmed protection at ja.wikipedia
Closed, ResolvedPublic

Description

Please enable "extended confirmed protection" at jawiki.

Local consensus:
ja:Wikipedia:井戸端/subj/拡張半保護の導入(再提案)/決選投票

Settings:

  • Enable extended confirmed protection.
  • Create "extendedconfirmed" group.
    • AutopromoteOnce: 120days from first edit, and 500 edits.
  • Add "extendedconfirmed" right to sysop, interface-admin, bot, and entendedconfirmed.
  • Grant/remove extendedconfirmed flag by sysop.

Event Timeline

120 days is too restrictive. That's a long time.

120 days is quite restrictive. That's a long time.

Somehow totally remembered it was the same in enwiki (90 there). Halting progress on my side until this is confirmed to be OK.

In T249820#6043188, @Majavah wrote:

Somehow totally remembered it was the same in enwiki (90 there).

It's not 90 days on enwiki. I am not sure how you got that figure as it's not even close.

It's not 90 days on enwiki. I am not sure how you got that figure as it's not even close.

And this shows why I should not rely on my memory instead of checking things. My apologies. (it's 30)

The file shows that 'extended confirmed' is enabled on four wikis and all of them use 30 days. So the sensible thing is either to use that or even less, as this setting can have significant impact on editing.

@Marine-Blue: Could you explain which underlying problems you're facing (and/or quantify them if possible)?
There might be better or less restrictive solutions, but hard to tell without knowing why this is wanted...

Rxy signed these changes with MFA.Apr 9 2020, 9:37 PM
Rxy claimed this task.
Rxy moved this task from Blocked on others to Pending BACON deployment on the User-Majavah board.
Rxy added subscribers: taavi, Rxy.

I guarantee this are corrective consensus per our Japanese Wikipedia Community decision without an any procedure defect . Ours (Sysadmins) MUST be respects their decisions. UNLESS C-level or board level decline decision.

As background, we tried to blocking abuse for suck as LTA:ISECHIKA (Banned By WMF; sometimes copycats the latter), LTA:HAT (sometimes copycats the ISECHIKA), LTA:203, LTA:TAROSU using AbuseFilter, my bot, and manually blocking, etc... However, they are continues posting copyvio stuff, privacy vio stuff, etc, etc. ORES are not workful for our lang for now. for avoid full level protection, we decided introducing extended confirmed protection.

I'll send the patch for this and deploy as my responsibility.

  1. Pre-proposal was opened for 2017
  2. Threshold poll was opened in 2017
  3. Preparing the last decision vote in 2020
  4. Last decision vote are open from March 30, 2020 to April 6, 2020 UTC
  5. Above are notified at sitenotice (includes anons)
  6. Japanese Wikipedia Community are decided introducing as described in the task.

Change 587874 had a related patch set uploaded (by Rxy; owner: Rxy):
[operations/mediawiki-config@master] Add extendedconfirmed group and protection level at jawiki

https://gerrit.wikimedia.org/r/587874

Rxy triaged this task as Medium priority.Apr 9 2020, 10:04 PM
Rxy removed a project: User-Majavah.
Rxy moved this task from Backlog to Deploy on the User-Rxy board.

@Rxy I'm not familiar with jawiki, but should eliminator also have extendedconfirmed rights?

@Rxy I'm not familiar with jawiki, but should eliminator also have extendedconfirmed rights?

I guess so, but the specification aren't said include extendedconfirmed in eliminator group (English request and Japanese request both).

Change 587874 merged by jenkins-bot:
[operations/mediawiki-config@master] Add extendedconfirmed group and protection level at jawiki

https://gerrit.wikimedia.org/r/587874

Mentioned in SAL (#wikimedia-operations) [2020-04-09T23:17:37Z] <catrope@deploy1001> Synchronized wmf-config/InitialiseSettings.php: Add extendedconfirmed group and protection level on jawiki (T249820) (duration: 00m 59s)

Ours (Sysadmins) MUST be respects their decisions. UNLESS C-level or board level decline decision.

@Rxy: No, that is not how it works. Please read https://meta.wikimedia.org/wiki/Limits_to_configuration_changes . "C-Level or Board" are completely out of scope.

Ours (Sysadmins) MUST be respects their decisions. UNLESS C-level or board level decline decision.

@Rxy: No, that is not how it works. Please read https://meta.wikimedia.org/wiki/Limits_to_configuration_changes . "C-Level or Board" are completely out of scope.

Yeah, I know that page. Then, this request are matches which items in the page? I guess this request are not causes problem to wiki performance, and that page items are based on past WMF board resolutions or WMF Legal dept stuff in mainly except of performance stuff. When decline large community decision, may causes fantastic dramas, such as dewiki's MediaViewer incidents (That caused by C-level decision).

When override consensus by large community without defect, we requires very strong reason or input.