Fri, May 25
Thu, May 24
Duplicated on meta: at https://meta.wikimedia.org/wiki/Category:Deleteme
Wed, May 23
Looks to be an ancient problem related to T18036
Tue, May 22
I'm aware - it's no big deal.
503 errors loading various projects:
Mon, May 21
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.
Tue, May 15
Mon, May 14
Questions added to enwiki BRFA: https://en.wikipedia.org/wiki/Wikipedia:Bots/Requests_for_approval/Community_Tech_bot_5#Discussion
Sun, May 13
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.
Sat, May 12
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.
Fri, May 11
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)
Fri, May 4
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=*
Thu, May 3
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??
This problem is now appearing in Special:AbuseFilter as well. Possibly related to T132284
Apr 22 2018
Apr 18 2018
By bot tasks were mostly related to Special:LintErrors/self-closed-tag ; I'll see if anything else is easily scriptable.
Apr 13 2018
Some keywords for searches:
echo-pref-notifications-blacklist does not activate saveprefs
Apr 9 2018
It should either be fixed to work with IP's, or fix the workflow to result in a graceful denial instead of a protocol error. I'd much prefer the former.
Apr 8 2018
From a read, the problem is actually with the verbiage for posting to nonexistent user talk/talk SUBPAGES. Not necessarily just "archives" - on enwiki this is templated in https://en.wikipedia.org/wiki/Template:No_article_text and may be adjustable there.
Apr 7 2018
Apr 6 2018
Mar 28 2018
Mar 27 2018
@Nikerabbit - there may be competing arguments. Mine is
Mar 26 2018
enwiki VPT recent thread for reference: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=832585665#No_Watchlist_notice_for_RfAs
Just ran across this headache again on enwiki, some user had changed their interface to en-gb and were no longer seeing any project custom interfaced messages - suggest they be able to fall back to en when interface message does not exist and user language is an en-variant.
How about a legacy directive that could be added to or warpped around the existing models (basically recasting in to arrays), would still require touching the filters but not so much "rewriting" them.
Mar 22 2018
Does not occur on import to test2wiki:
Mar 21 2018
Can you describe what the needs for this are more?
Mar 6 2018
not sure on casing on that table, may want to also to a:
Note, some of these are not editing enwiki at all - for example:
Perhaps stop by default, but allow an override via a new api parameter - this would have to be purposefully asserted and would not currently exist.
@Niharika I've created a logging filter on enwiki, see results here:
(I just exempted SineBot due to the Blacklist already discussed)
Mar 5 2018
@MusickAnimal muting the bots is a lot of work as EACH editor has to do it, better would be to investigate any high-use bots in advance and contact the operators. They could change their user: links to something else (e.g. contributions as mentioned above, or logs or something else). I'm not sure what the "best" approach to this is. Perhaps a more complicated "exempt API edits unless some additional parameter is purposeful set" ?
Is this going to hit for BOT edits that mention usernames? For example this one: https://en.wikipedia.org/w/index.php?title=Wikipedia%3AAdministrator_intervention_against_vandalism&type=revision&diff=828934435&oldid=828934414
@Aklapper the "display issue" is that the bounds of one row are intruding on another row as in the example above. While this may change with browser preferences somewhat as in Anomie's example, stock Firefox and stock Chrome on a not-logged in page both demonstrate the disruption.
Mar 4 2018
- @Cyberpower678 Perhaps we can make an edit filter for high counts of U+0300 to U+036F in the summaries
If it is actual desired to support that many vertically shifted characters (which I think it a bad idea), the boundary between rows should be maintained to prevent characters from one entry from overlapping another.
@Aklapper see the image attached to the description
Suggest a blacklist or whitelist be used for input validation of edit summaries, or have the parser ignore these somehow on display.
See also T161783
Feb 28 2018
Suggest a centralized page for questions on outreach.wikimedia.org, agree email-only responses are a limiting factor unless you set up role accounts and use Special:Email