From the above consensus, these are the following proposed settings:
Sep 4 2019
May 29 2019
May 15 2019
May 9 2019
Apr 28 2019
I think range is determined, it is only used at highly vandalized pages, high volume pages, and also FA / GA etc.
Apr 26 2019
Admins should not add or remove extra group per discussion.
Here, I forgot it. lol
Aug 10 2018
Jul 21 2018
@RazeSoldier , should be problem within the Operations tem?
Jul 19 2018
Should be deployment problem?
Jul 16 2018
Removed the project of Chinese-Sites as it seem to affect more than one language version - for the cyrillic users - ja we get the same problem
I just want to ask:
Jul 9 2018
I didn't see the possibility for the interface editors not having the ability to edit userjs.
Though I am skill skeptical of this idea - isn't there other ways to resolve this problem?
Not broken. Thanks for claiming this task @Urbanecm
Jul 7 2018
Jul 6 2018
The best way to mitigate these security issue related to css and js would actually be adding a deployment (and/or review) period for these two things : Any changes in between two deployment periods (currently used to deploy newer versions of MediaWiki to different WMF-owned wikis) would be marked as a specific issue.
This is in the description at T71445: Implement a sane code-review process for MediaWiki JS/CSS pages on Wikimedia sites.
If this is the case, then there wouldn't be interface editors at some wikis.
The idea of an interface editor or engineer group that is meant to be more accessible than sysop is indeed backwards with regard to security.
I really would hope that the new group would be granted globally rather than locally though.
There is already global-interface-editor, but understandably, that right is very hard to get because of the potential damage someone could cause. With that said, though, I don't fully understand what you're trying to say. This task is about removing the right from people who don't use it anyway. If the individual communities remove it from people who don't use it, and let people who use it retain the rights, no one should notice any difference, while the security situation is much better. What you're saying seems to be that every new techadmin should instead be a global interface editor, but that would make the situation much worse with regard to security. It also would simply not work policy-wise. Only a small percentage of all techadmins across all WMF wikis would ever be trusted with global-interface-editor. You can view the complete list of members to get an idea of how restricted that is.
@1233thehongkonger to me, that seems counter-intuitive. Allowing people to edit interface messages generally requires a lower level of trust than allowing them to block people and delete pages. On the other hand, allowing people to edit JS that is run in the browser of every visitor should require a higher level of trust than regular adminship, since it effectively allows them to hijack every account on the wiki.
Jul 5 2018
as a bug reporter and sometimes a person who pushes community consensus to phabricator, I don't see the reason for not giving current users having the interface editor permission or single permission equivalent to obtain the right automatically - that say that interface editor should automatically transit to techadmin, where administrators shouldn't do so.
Jul 2 2018
Throttle it, add new tools, and I think all is set - Do not forget all those attacks. I think it is just the start only.
Jul 1 2018
Just for a note, why not add a button at Phabricator to enable reverting to an earlier state?
Jun 28 2018
@1233thehongkonger: For future tasks, please add a more complete description to this report and always include a clear list of specific steps to reproduce the situation, describing actual results and expected results after performing the steps to reproduce.
You can edit the task description by clicking Edit Task.
Ideally, exact and clear steps to reproduce should allow any other person to follow these steps (without having to interpret those steps) and see the same results.
Please also remove unneeded project tags from tasks. Thanks!
Jun 27 2018
Well, consensus showed that we do not want to do so. At the same time, @Urbanecm , I had proposed that but our result is: We should give only the required necessary rights.
Jun 26 2018
Jun 19 2018
Any idea of when it will be deployed? Malaysian editors are urging this now.
Jun 11 2018
@RazeSoldier The fallback language should be : zh-sg over zh-hans and zh-cn
@Liuxinyu970226 Check meta-wiki.
There exists related files
May 24 2018
The content is slightly different in each language variant because of naming methods in different countries. For example, in Hong Kong, we get a set of British names which are not used in other regions, and we would use noteTA to do the conversion.
The main point is about local content: it can now be correctly convert to a more localized version, which is done by noteTA.
I didn't see the difference. The bug is resolved, and most importantly, the localization is already in place but it is just blacklisted.
This does affect the content as we use NoteTA to alter local content, which is the major reason of enabling the variant
They want this as the Malays would want to get their own Chinese Language Variant, which was completely logical. There is community consensus apart from Liuxinyu970226, who opposed it. This could be seen at the discussion page, in which all but him ( @Liuxinyu970226 ) opposed. Thus I would say there is a community consensus for this problem.
May 23 2018
I request a re-evaluation of this task. This task is of high priority at local logic.
May 17 2018
(Just another thing, the Chinese Wikipedia has confirmed to enable the extension once development is finished due to recent changes at local policy)
May 6 2018
Note two more things: zh-sg option should change its name to : 新加坡简体 , and zh-my option with the name 大马简体
May 4 2018
Well, it seems that not only accounts that are based in enwp being brute-forced, but also in zhwp.
Apr 8 2018
Apr 6 2018
Mar 19 2018
One more example at zhwp: https://zh.wikipedia.org/wiki/User_talk:白布飘扬, there is still a redlink which shouldn't occur.
Dec 1 2017
The release did not fix the title problem. Please refer to the following link: https://zh.wikipedia.org/w/index.php?title=Wikipedia:%E9%A6%96%E9%A1%B5&variant=zh-hant&useskin=timeless
Please confirm it with others of Traditional Chinese Editors.
Nov 28 2017
As stated by Aklapper, that is the problem.
Nov 27 2017
Nov 24 2017
Nov 23 2017
Nov 22 2017
Dec 23 2016
@Dereckson The problem that the page had is that it affects the tool to find some particular user.
Sep 28 2016
DNS Address not found. Not the problem of Any browser.