User Details
- User Since
- Jun 11 2020, 1:21 PM (219 w, 6 d)
- Availability
- Available
- LDAP User
- ProcrastinatingReader
- MediaWiki User
- ProcrastinatingReader [ Global Accounts ]
Apr 18 2024
Aug 5 2022
Apr 17 2022
Mar 7 2022
@TheDJ do you know what this task is blocked on? (afaics your patch contains all the code needed to make this happen?)
Feb 23 2022
Specifically in the case of T302047, I would prefer that active contributors on primarily single Wikipedias not be deploying those patches. For example, and without getting into the details of the mitigation here, I think English Wikipedia has certain philosophical beliefs that are not shared throughout the Wikimedia projects, and while sometimes restrictions will have to be implemented to ensure for service/reliability reasons, they should be proportionate and the minimum necessary to deal with the threat. At times the IRC discussion involved suggestion of options that were either too extreme, too soon, or not the minimum necessary to mitigate the emergency issue. I think having detached deployers (IIRC one of which said they were mostly a backend person and not focused on the onwiki-side) who looked at the proposals and offered the feeling of space for anyone to raise objections before deployment, operating quickly but cautiously, was the best approach in that situation.
Aug 31 2021
Aug 29 2021
Jul 25 2021
Jun 24 2021
Jun 6 2021
If the technical implementation in the patch works then I think it should be merged. It's up to local communities (and external projects) to grant this right or not. There's not a particularly good reason for why it shouldn't be technically possible for them to decide though.
Jun 4 2021
Why is this still stalled, even though a patch exists?
May 26 2021
May 12 2021
The issue starts because, when stewards do that, local 'crats would say that stewards are overstepping their boundary, and that is why it'd the removal is also being removed from 'crats.
Well, I said this at enwiki BN, so will repeat here:
It would've been better to post a consultation on meta and advertise it via mass messaging to the local communities and let it run for a few weeks. That way you get the ability to 'discuss' and evade the criticism of possible fiat by the WMF. The world would not end if crats get to flag IAs for another few weeks. At least from a PR standpoint (no pun intended) it'd have been a good idea to discuss it first...
May 11 2021
The use case is https://en.wikipedia.org/wiki/Wikipedia:Bots/Requests_for_approval/ProcBot_8. No API endpoints exist for editing abusefilters. So I decided to mimic the HTTP requests, but that approach can turn up a few caveats and is slightly less maintainable. I cooked up a web scraping approach using Selenium as well and that might work better. But to run it'll need a browser with headless and modern JS support (both Chrome and Firefox work, so I mentioned those two; either will work).
Apr 6 2021
Mar 20 2021
Okay, I'm mildly misunderstanding how the FlaggedRevs one works. Looks like it's part of /frontend/FlaggedRevsXML.php line #364 (function logDetailsToggle()).
@matmarex ping again on the above. Alternatively, could we provide the log entry as a param to the template rather than forcefully including it via code, so a local project could collapse/trim it if they want (such as on the Pending Changes messages, see https://en.wikipedia.org/w/index.php?title=Inner_Mongolia&action=edit for example.
Some indicators have more value than others. The protected indicators are semi-valuable (but less-so on mobile, I suppose - either you can edit it or you can't, and that's indicated by the lock on the pencil icon). The move indicators are totally useless. The featured content indicators are useful, imo. Generally, there's a higher degree of quality to GAs/FAs (yes yes, I know, the disclaimers and all, but it's generally true as a rule). Good articles are pretty much a basic peer review, and quite different to featured articles which go a lot deeper. For example, on enwiki GAs require the coverage in the article to be broad, and FAs comprehensive. How many readers actually know this I don't know, but once you know this I think it helps to know that when reading the article.
Mar 12 2021
Mar 1 2021
So... what's going on with this task (and FlaggedRevs in general)?
Feb 18 2021
Also see T275118
Also see: T263943 (preceding task)
Jan 22 2021
Dec 22 2020
Dec 20 2020
Note @ToBeFree's link is regarding the iOS app (not Android as in this ticket). But this is a problematic issue both ways - communicating with editors is very difficult without notifications.
Oct 24 2020
@matmarex @ppelberg the patch I released was somewhat tangential to what I intended this issue to be (it's an improvement, but not a 'fix' in my eyes). I'd still like to focus on hiding these details (at least the semi-protection ones) in that message entirely, if it's something I can swing by whoever needs to sign off on this. It's really irritating for me to see that regular long log dump on every other page, most of which I just can't see a use for. On pages without an actual notice, it pops up anyway (when in its absence nothing would pop-up) and slightly throws one off. Just doesn't feel like it belongs.
Oct 17 2020
@matmarex got around to the ordering, at least, in above patch. Could you see if it's all good, when you have time?
Oct 11 2020
May be of interest for enwiki: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)#Move_good/featured_article_topicons_next_to_article_name
Oct 6 2020
Saw this posted today and it makes me think, it could just be at the end of the text without alignment without much trouble?
Sep 30 2020
Although if you're not interested in this, I'll probably submit a patch myself.
Sep 27 2020
@JTannerWMF would editing be okay with / approve a volunteer patch for this? Either an option to disable this (from all editors), or disabling them entirely, one or the other?
Sep 26 2020
@TheDJ curious why the patch was abandoned? Seems like it'd technically work?
That said, I think that adding in remaining space on the right side of the title (or adding a newline) is the best solution and it can be managed in the same way.
There are cases when bot reverts should be notified. The most obvious one to me is ClueBot, https://en.wikipedia.org/wiki/Special:Contributions/ClueBot_NG. Edits are marked as minor, not sure if they're marked with bot too. Second, sometimes bots edit articles and the contributors don't want that bot edit. Many bots will edit again if the bot is reverted (they're not that smart), so notifying editors that a bot manually reverted them would seem a good idea. Such bots (at least on the English Wikipedia) will be flagged as bots, and typically mark their edits with bot: true as well, so using the fact of whether or not the particular edit by a flagged bot was also marked as a bot edit won't work.
Sep 24 2020
@matmarex imo it's pretty useless, but maybe removing it from all editors may prove a bit more work (in terms of process)?
Sep 21 2020
@matmarex whoops, I didn't mean mobile. I'm getting my tasks mixed up (as I've something similar to the opposite for mobile). Sorry, will update to clear it up.
Sep 18 2020
Sep 13 2020
Aug 29 2020
@Tacsipacsi to be completely frank, and just my opinion, but wikis don't exactly have the best idea of "what's important" from a UI perspective. Move protection indicators, for example, are utterly useless. Even 99% of editors don't wish to move the page, never mind readers. They're in place to stop the odd users moving articles, yet an icon is shown to everyone. On a smaller scale, especially for mobile, this applies for page protection too -- most people just read not write on mobile, and showing colourful locks is not particularly helpful, especially on a mobile view where they'd stand out a lot more. When you start looking at talk notices and editnotices the point becomes more obvious imo. One 'unintended' advantage of the software limitations of the mobile style is that it saves the mobile UI from becoming a cluttered mess. Quality assessment indicators are neat, and give a useful indication for readers also, though.
@TheDJ regarding "were repeatedly pointed at how useless many of these banners were", do you have links to a few past discussions by any chance?
Aug 27 2020
I do think that stuff like pp-protected should be hidden on mobiles. We only want to show indicators like good-article / featured-article. The rest is kinda bloat.
Aug 3 2020
on wiki edit notices can be extremely verbose
Jul 31 2020
@Huji Yeah, I can submit the patches (one to add it into AF before the call, then another to revert the wmf-config patch). It'll probably be a week till I can get around to it, though. If you can get around to them sooner, it's fine with me for you to submit the patches :)
Jul 22 2020
Sure, but there's a bit of a difference in having to write your DB credentials (something the software could never possibly auto determine), and having to add in a config variable for the software to work as we intended it to.
Jul 21 2020
Shouldn't those hypotheticals also be hardcoded in? My reasoning is that the point of configuration is for users to change how the software behaves. This is making adding a configuration variable a requirement for functionality to work as intended. There's no developer intention, or valid purpose, for this data to be purged from CU logs. So we're kinda just adding an extra hoop, and most non-Wikipedia users who run into this probably shouldn't have to jump into some obscure part of the doc to realise that they have to add a compulsory param. We can keep the config param too, I suppose, for future additions, I just think this particular param should also be hardcoded in.
Jul 17 2020
I believe this added param still needs to be documented at https://www.mediawiki.org/wiki/Extension:CheckUser. I wonder if a note should be added to https://www.mediawiki.org/wiki/Extension:AbuseFilter as well, since it appears to be the sole (?) culprit requiring this.
Jul 6 2020
Jul 4 2020
@Huji do you still plan to schedule the deploy for the 6th?
Jul 3 2020
@Majavah thanks for the heads up. I was under the impression that it had to be +1'd first (aware the +2 is during deploy), but if that isn't required I'll go again and schedule.
Jul 2 2020
Jul 1 2020
Having taken a quick look at this, seems to be due to the $item->canView() checks failing (eg at SpecialRevisionDelete::showForm, line 420). That function is in RevDelRevisionItem, line 81:
@Jdforrester-WMF @Aklapper if the functionality is indeed undesirable I'm not sure if it matters whether Apple fix this on their end (which, ultimately, I'd think any 'fix' would require removal of the feature, since it's hard to determine whether 900-1200 is a phone number or a year) or if MediaWiki does just for its software using the meta tag. (I believe this tag is only recognised by Safari for these purposes, but I could be wrong). Of course, links can still be formatted as tel if they're explicitly formatted as such, and via the use of a template it'd be neater than the a tag everywhere.