Sun, Aug 5
As there is already special checks in place for userjs/usercss could this also allow for deletion - as the mediawiki namespace normally has its own protection it won't allow arbitrary creation (unlike userspace).
@Tgr agree it could be desirable - please correct me if I'm wrong but after this change this scenario is created:
Followup #2: Will global renamer's that are not local interface admins still be able to move user .js/.css subpages? If not, how will these fail?
Following up on discussion from enwiki: Will local sysops's still be able to delete css/js pages if they are not also able to edit them?
Fri, Jul 27
With this being removed from sysop, is it actually also being ADDED to techadmin - or will it be orphaned?
Fri, Jul 20
This sounds like a very expensive way to run filters, how would it scale? Can someone show a mockup filter for when there are an example 10 different pairs of these restrictions? Or would you implement a separate filter for each group? This also doesn't seem to address discussion type pages - perhaps more filters for that?
Wed, Jul 18
@Tgr if communities need to opt-in to enable this of their bureaucrats the project level RfCs may take some time (a month is not unusual for a project like enwiki) - as the final specification for what access is being removed from sysop, and which access is being included by default in local-interfaceadmin ?
Jul 9 2018
@Ajraddatz my hopes would be that it would be like botpasswords, where basically you could log on with multiple passwords if you opt in to it, and when you opt in to it you can choose what access is available under your opt. You could lock certain passwords to certain IP's, make some edit-only, etc. Put everything entirely in control of the editor.
Jul 8 2018
See also T176033
Jul 3 2018
Jul 2 2018
Possibly related to T173977 ?
Jul 1 2018
Jun 29 2018
Couldn't replicate this on enwiki under any skin with Firefox or Chrome
Jun 28 2018
Perhaps this could be broken out to a separate function/screen? I'm usually able to determine the string hits using testers like the one at https://regex101.com/
Jun 25 2018
Please note, translation TO enwiki are currently restricted by way of an edit filter to those that are extendedconfirmed. Just an FYI (see https://en.wikipedia.org/wiki/WP:CXT)
This is now live.
Is live now, and updated expectations at meta:Template:portal talk header
Jun 21 2018
Confirm, same symptom
Jun 17 2018
Updated meta page, pending replication
Jun 8 2018
Is the default value for the "opting" something that can be specified at the project level?
Jun 4 2018
! In T195625#4254813, @Legoktm wrote:
and I worked out how to add a user preference to fully opt out of responsiveness, and just get the classic desktop styles: https://gerrit.wikimedia.org/r/#/c/437150/. Will that take care of most peoples concerns right now?
Jun 3 2018
Jun 2 2018
@stjn it is just where the volunteers are, a quick current statistics breakdown of the largest projects (wikipedia's with 1,000,000+ articles) show active volunteers of:
@stjn unlike some "third parties" that supposedly wanted this change (each of who can evaluate changes and decide if they want to actually promote them to their production environments) - the WMF managed implementations accept all current code changes to their (our) production environments - so of course there is a special relationship with the volunteers who carry out the foundation's mission; just as there is a special relationship between volunteer software developers and the WMF.
@Legoktm thanks for the reply - are you referring to this posting asking for feedback about a change "for mobile" that was actually put in to production for desktop? Event the latest post on :w:en:WP:VPT was titled "for mobile users".
@ashley if I'm reading the logs correctly, this got implemented based on your approval (+2'd) <anyone please correct me if this is wrong>. Can you explain your reasoning for how this satisfied the normal requirements including the need to "socialize high impact changes within the development community"?
Community consensus should be reevaluated prior to deploying this to production projects as the default.
"If you want to opt-out, you can use your mobile browser's "Request desktop site" option" ?! This is happening ON A DESKTOP computer.
May 30 2018
Wonder how many people will mark "no" because the slowest loading thing on the page is the survey - enough that it causes very visible page jumping.
May 25 2018
May 24 2018
Duplicated on meta: at https://meta.wikimedia.org/wiki/Category:Deleteme
May 23 2018
Looks to be an ancient problem related to T18036
May 22 2018
I'm aware - it's no big deal.
503 errors loading various projects:
May 21 2018
Note, as enwiki Bot approver, if the date needs to be adjusted that is fine, and going +/-10% edits is also fine. The tagging request is new so if it is a problem, it can be skipped, and note the tag is likely not created on any other project so far. There are a few phab tasks open regarding using tags for certain types of edit identification (such as T13181) - but most of these are stalled out. Would be interested to know what the operator team thinks of using tags for this type of task once in production.
May 15 2018
May 14 2018
Questions added to enwiki BRFA: https://en.wikipedia.org/wiki/Wikipedia:Bots/Requests_for_approval/Community_Tech_bot_5#Discussion
May 13 2018
This has no different global impact then accountcreator, confirmation is a community-local level action and does not have global impact. On enwiki the autoconfirm threshold is currently 4days+10edits, the thresholds vary on other projects. The +confirmed flag on one project does not carry over to any other project.
May 12 2018
Reopen - that other task does not accomplish the same ability. Notably, we have editors that need to create accounts in excess of the rate limit for events, etc - however they should not be exempt from all rate limiting (e.g. page moving). https://en.wikipedia.org/wiki/Wikipedia:Event_coordinator is an example of the use case.
May 11 2018
I think this should just be a collection of any actions that someone is blocked from, could be "move" but might as well be any blockable action (upload, thank, sendemail (migrate from existing system), etc)
May 4 2018
In looking how it is out there on various projects, targeting this as an "(abusefilter-view-private) or (abusefilter-modify)" gate should be done, as the ..view-private is not always explicitly assigned.
Thanks, I've let others know on the noticeboards that if they run in to this to try to regenerate their bot password. Hopefully the work in "BotPasswords: Indicate when a password needs reset" can help make this better visible.
May be better to extend to abusefilter-private instead of abusefilter-view, would like a clearer explanation of what may be able to be accessed from here that needed it to be restricted in the first place.
Hi Anomie, I was able to do this on my own:
@Anomie I personally observed this on accounts that had not had their main passwords changed since the botpassword was established, and the bot password was stored and previously working. AFAIK botpasswords should never "expire" correct?
Some users are reporting success now - please monitor
Note: after regeneration of bot password, that account can now logon, second account that was not regenerated is unable to logon still
Regenerated botpassword, verified that web logon was working for account - no change
Graph of authentication - showing it is still occuring: https://grafana.wikimedia.org/dashboard/db/authentication-metrics?orgId=1&from=1525275869702&to=now&theme=dark&panelId=13&fullscreen&var-entrypoint=*
May 3 2018
T193769 may be a good example
FYI: Unusual number of reports coming in on enwiki throughout the day as well.
Apr 25 2018
Here is a full screen example of the new layout, at 1050x1680 resolution - the menu selector consumes the majority of the screen now.
The abuse filter vertical space appears to be the same problem in monobook and vector, so it is just informational here.
@Aklapper, yes requires scrolling to even see the widget controls at many resolutions or if any project specific help as been customized in the summary area.
Apr 24 2018
Please see T181770 - did this get pushed out without verifying layout in all the skins??