@dbarratt - When I try to submit the form on the web interface, I get "Error authenticating. Resetting. Please try again." Is that related to the callback issue?

@dbarratt - I've added you as a maintainer to the citations and citations-dev tool forge projects. All testing should be done in citations-dev and then once it's running smoothly, the code can be moved to the main citations tool as well. Web interface for citations-dev: https://tools.wmflabs.org/citations-dev/

A volunteer dev started working on this recently. Their pull request is at https://github.com/ms609/citation-bot/pull/1624. A good starting point would be to review the patch and see how far they got.

Oh yeah, the community really wants Citation bot to stop doing user-activated edits as Citation bot. In fact they've debated blocking the bot because of it.

@Mooeypoo - I've updated the acceptance criteria to address your concerns.

I was thinking that we not only authenticate with OAuth but also use the OAuth credentials to make the actual edit as well (similar to how IABot's user activated edits work). That way blocked users would be blocked from making the edits automatically and we would always be able to prove who made a particular Citation bot edit (and it couldn't be denied as spoofing).

Sadly, my flight was cancelled and I wasn't able to find another flight in time so I won't be making it to the Hackathon. Good luck to everyone else!

@Krenair - The actual uploading is handled by urluploader, but UploadWizard has to do a lot of communicating with Flickr's API beforehand for information. Is there some kind of proxy API it should be using for that?

Works now! Thanks!!

@Bawolff - What is now the correct way to import images to Commons from 3rd party websites on the client-side? For example, when I currently try to import images from Flickr using UploadWizard, I get the following error:

[Report Only] Refused to connect to 'https://api.flickr.com/services/rest/?&format=json&nojsoncallback=1&method=flickr.photos.licenses.getInfo' because it violates the following Content Security Policy directive: "default-src 'self' data: blob: https://upload.wikimedia.org meta.wikimedia.org *.wikimedia.org *.wikipedia.org *.wikinews.org *.wiktionary.org *.wikibooks.org *.wikiversity.org *.wikisource.org wikisource.org *.wikiquote.org *.wikidata.org *.wikivoyage.org *.mediawiki.org wikimedia.org". Note that 'connect-src' was not explicitly set, so 'default-src' is used as a fallback.

Should we add api.flickr.com to the CSP or does UploadWizard need to be refactored somehow?

Tried logging in again from an incognito tab, but still just get 401s for all the actual content. And if I try to go directly to any of the content URLs like https://superset.wikimedia.org/superset/recent_activity/154/?limit=50, it says "access denied".

Thanks Nuria! I can log in now, but when I do I get a bunch of 401 errors and nothing loads besides the header (regardless of which tab I click on). Not sure if that's just me or how it is for everyone.

@Volker_E - Thanks!

Thanks for your work on this, @Krinkle!

Any chance this can be fixed before the Hackathon (a week from now)?

@Nemo_bis - No, Maarten says he doesn't work on pull tools, only push, and for iNaturalist it seems like pull is a better fit (since we don't really want to import everything from iNat). I've started working on a gadget for this, which you can see at https://commons.wikimedia.org/wiki/User:Kaldari/inat2commons.js. The idea is that if you're on a Commons category page for a taxon, there will be an "Import from iNaturalist" button, which will let you choose freely licensed iNat images of that taxon (based on the mapping in Wikidata) to import into the category. One tricky part is that because Wikidata only supports 1-to-1 sitelinks for Commons, half the taxon categories on Commons have a Q ID, but the ones that also have a Gallery page don't have a Q ID (since it's associated with the Gallery page instead). There are a few different ways we could work around this, but it does introduce some complexity to the task.

@Nuria, @Milimetric - Crap, I didn't mean to sound hostile. I love the Analytics Engineering team! Y'all are literally the smartest people I know. Right before I wrote that comment, I had had a 1:1 meeting with Kate which consisted mainly of me explaining the pain points that Product has around data analysis. I was pointing out this ticket to her as an example of cases where product has a hard time getting basic ball-park data to help with decision making and community discussions (since it was directly related to our discussion). It wasn't meant as a criticism of the Analytics Engineering team. I'm sorry if the lack of context made it seem that way! My sincere apologies.

@Milimetric - Thanks for explaining that and thanks for your help on this. I'm glad we have a Product Analytics team now and hopefully requests like this will go smoother in the future.

FYI, I'm planning on working on a iNaturalist importing tool for Commons during the hackathon. If anyone else wants to help, let me know.

@kzimmerman - Since Analytics was unable to provide any information for us, we did the work ourselves (per T166269#3346965). I think this ticket is a great example of Analytics' difficulty with providing Product with basic ball-park data to help with decision-making and community discussions due to Analytics' self-imposed requirements for perfect data (which is almost never possible in the context of Wikipedia). We need some sort of process where we can get Analysts to give us ball-park data quickly, rather than waiting months for reports that never materialize. This is one of the main reasons why PMs are asking for dashboards.

I think this might be a child (or duplicate) of T221190 though.

@ppelberg - No, this is a separate bug from T167078 (although that was a good guess). VE specifically told me that I was blocked after trying to save my edit (rather than saying "Error: Edit not saved"), and I wasn't trying to add anything from the spam blacklist.

@ppelberg, @Ryasmeen - This needs tests.

@alexhollender - Personally, I never go directly to Special:Logs. It's almost always from a user or page specific link (with preset query parameters). It's not a terrible idea though. Putting Wikipedia:ArticlesForDeletion in the sidebar seems a bit strange, though. What would be more useful, IMO, would be having Special:MovePage in the sidebar, as otherwise it is quite difficult to move a page manually on mobile: you have to manually go to Special:MovePage, and remember the exact title of the page you wanted to move, which is often tricky if you're moving the page due to a misspelling or bad title. There should be a way to reach Special:MovePage directly from the article context (and have the title pre-filled as it is on desktop). This may not be a commonly visited special page, but it provides an essential function.

@jmatazzoni - I added some new documentation at https://www.mediawiki.org/wiki/API:Userinfo. I still need to write up an email for Leighanna and Trust and Safety.

I dug through the old code and looks like it was using jQuery UI Selectable. Just adding that here for my own reference.

Perhaps @MMiller_WMF or @RHo could answer your questions.

Thanks Ed! Looks like if the query string includes "vehidebetadialog", the dialog will be suppressed.

@Esanders - Is it technically possible for Getting Started to suppress the introductory editing dialog that VE presents?

I'm with @thiemowmde. I originally filed the URL shortener bug, created the RFC, and have been following its progress for 7 years. At no time did I or anyone else list "reserved URLs that are easy to remember" as a requirement (AFAIK), and no one's really made a good argument about why they're needed. I say launch it as is and let people start using it.

Do we really need to reserve 729,000 URLs for special use? Reserving 1-letter URLs makes sense, and maybe 2-letter, but 3-letter seems overly cautious, IMO.

@jmatazzoni - Perhaps it's related to the fact that I copied and pasted the category name into the interface rather than typing it.

Note that current versions of Vega (since 4.3.0) need ES6 support, so we would either need to transpile Vega with Babel (slightly increasing the JS footprint) or keep Vega locked at an older version. Some back of the envelope calculations:
Minified transpiled Vega core: 442 KB
Minified d3: 222KB
Total extra JS load (minimum): 664 KB
Obviously, we couldn't load that for every page as it would more than double our JS load per page, and we probably wouldn't even want to top load it on pages that needed it. It seems most realistic that we would end-load it on pages that need it and show a spinner in place of the graph until then (as suggested above).

I like it!

@chasemp - You may want to include Marcella's ticket at the same time (T215961) since it's similar (Engineering Manager needing access for triaging, etc.)

Sorry for the last minute interruption! Danny has requested that we freeze any further Flow deployments pending the outcome of the Talk page consultation process.

@Urbanecm - Considering the uncertain future of StructuredDiscussions, I really hope that more wikis aren't going to convert their Help desks to it as there's a good chance this will cause headaches in the future.

It looks like the CSS explicitly suppresses any indication that the title is a link :(

@jmatazzoni - No, it definitely happened on my first attempt to add a category.

@Samwilson - Do you want to disable these tests in the meantime? They seem to be causing trouble: https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/TemplateWizard/+/499879/

If it seems like this will cause too many expensive queries, we can live without it.

@Nickps, @Neil_P._Quinn_WMF - Can either of you confirm that this bug still exists? The scrolling code for mobile editing has been significantly refactored.

@aezell - There's a whole slew of related (but more specific) tasks in Phabricator. Not sure how these should best be organized...

Overachievers! ;)

Wow, that's super complicated. Have y'all considered just using a PNG pokey like the Echo overlay?

I understand the main issue here is my connectivity, but I'm wondering if there's some way we could work around the connectivity problems. When I'm on a shitty connection, which is pretty often, especially when I travel to other countries, I can pretty much forget about uploading anything to Commons, which is unfortunate. It looks like T205619 is probably the same issue.

@Aklapper - I don't know if this helps, but I tried running PingPlotter while I was doing the upload and monitored connectivity to text-lb.eqiad.wikimedia.org. For the first 5 minutes I'm just running the monitor, then I start trying to upload (which is where you can see the latency shoot up), then the upload gives up after a couple minutes and the chart goes back to normal: