Please disable 2-factor authentication on this account - 2016-08-15 - thanks
- User Since
- Oct 7 2014, 2:49 PM (316 w, 3 d)
- IRC Nick
- LDAP User
- MediaWiki User
Approving as manager.
Tue, Oct 27
@matthiasmullie looks like all patches are merged now, can this be moved from Code Review? Or does the abandoned patch need to be replaced still?
Aug 18 2020
@Ottomata you can probably axe all of them, we have yet to decide which might be useful and/or a reason for having them, but it'll be some time before we have the capacity to address it. Thanks :)
Aug 4 2020
Prioritizing as low for a couple of reasons:
Aug 3 2020
The maintenance of Formerly-Multimedia™ components is an ongoing issue for the Structured Data team and, realistically, everyone - see T240281 - but we're starting to work through and prioritize some of those components as we have the capacity. Sadly, most of our expertise on the SD team is not in the multimedia components which makes it difficult for us to prioritize and diagnose, much less actually fix, these bugs.
Jul 27 2020
Update: Couldn't reproduce on beta, at least not with an image - chunked uploads may be treated differently somehow, certainly worth investigating still
Jul 26 2020
@Aklapper I think the line at issue in that file is https://phabricator.wikimedia.org/diffusion/EUWI/browse/master/resources/ui/steps/uw.ui.Thanks.js$146
Jul 21 2020
Gotta love someone who submits a task and a solution within 13 minutes! Thanks @kaldari
Jul 13 2020
I'm certain we discussed this but weren't sure if we wanted to get into it. In any case, not a high priority at the moment (especially given the aforementioned bot may be serving the need sufficiently) - but something we could explore at some point.
Likely a pretty small fix, so possibly something to hop on for a new contributor (though I'm loath to suggest tagging it as such, given the very limited amount of support for UploadWizard code review and whatnot right now)
Drive-by prioritization :)
Jul 8 2020
Hi! Looks like while I was looking in other directions, this garnered a fair bit of attention. I'm sorry to say we may have had some wires crossed in explaining the motivation and reality of these changes, so let me try and clarify a few things quickly:
Jul 6 2020
Also: I have tested on beta and in production with obviously-duplicate files, and have not been able to reproduce, so we may need additional details about future reports.
Huh. So I'm slowly working my way backwards in time through the untriaged bugs, and this (being the third similar issue reported that I've seen so far) seems like it may just be a general bug across our upload error/warning handlers, or possibly in the message system. The code looks good on first glance, and I haven't found any big "DEPRECATION/BREAKING CHANGE" emails about jqueryMsg or mw.Message#parse yet, so I assume these things are still fine, and there's just a problem with the way we're using them in UploadWizard.
Marking as medium to note that this is probably something someone should investigate, but n.b. that work on UploadWizard is not generally a priority for anyone - and after a brief poke around Special:NewFiles, I couldn't find any instances of this happening right now, so I suspect it may be a fairly specific problem which may require additional information (what browser(s) are being used? what versions? what kinds of information did they *try* to input?)
Have updated the task to reflect that, per the merged task, this has happened with uploads that are not upload-by-URL.
n.b. the task I just merged this into says "for Flickr uploads", I will update the description to mention this also happens for normal file uploads as well.
Jun 29 2020
Marking this as low priority mostly to make it clear we've looked at it and that the Structured Data team (tasked with limited maintenance of the extension) won't be doing much to help out here.
Jun 22 2020
Aha - the screenshot attached made this confusing. Yeah, this strikes me as a regression, then. Bumping to medium with the warning that there may still not be a rush to handle the issue given the de-prioritization of UploadWizard tasks lately.
This strikes me as low priority for the team tasked with UW maintenance (as something that would be nice, but not necessary), but would also be a nice first task for someone to jump into provided there aren't complicated implications. If anyone can investigate further and determine that for certain (i.e. check the templates exist, and will exist for the foreseeable future, and that there isn't complex logic involved) please do tag as easy.
Low priority as a feature request in a lower priority project.
Seems like a relatively simple feature request, though one we can't focus on immediately. Maybe something we could mark as easy, though I'm not making that determination at the moment.
Seems reasonably broken for RTL languages, so marking as medium priority, especially since this may meet the criteria for an easy tag. That said, UploadWizard isn't a focus for anyone right now, so it's unlikely this will get much attention soon.
As a feature request in a project that is relatively low priority for us right now, marking as low.
Marking as low priority mostly due to the small amount of time available to work on UW, but also because this seems to be a poorly-defined issue that may take a significant amount of time to properly diagnose. If we get more information about the file that failed, any errors/warnings in the console, etc. maybe we can revisit this. Though also if this is an isolated incident, it hardly seems "(un)usable" at least in the majority of cases, so without further reports, the priority may stay where it is.
As suggested by AlexisJazz, maybe this isn't a bug in UploadWizard and should therefore be marked as Resolved or Declined and tossed back to an interface editor on Commons to fix in the wikitext?
I don't believe any of the fields in the Structured Data step are required, hence there are no warnings or errors. We could detect if people have visited each file in the sequence, perhaps, and warn them if they try to publish before having done so? Or maybe change the publish button to cycle to the next file? Anyway, given these aren't required fields, and we know there are people who don't want to fill out this data in UploadWizard, I have trouble seeing a pressing need for a fix, hence low priority.
Marking as medium as it may affect more than one person if this isn't just a Heisenbug; would love more details from @Cheva whenever we can get them. Unlikely this will get much attention soon, but if you're seeing this as well, please speak up!
Marking as low priority given the current policy on UploadWizard work - though I wonder if this could be marked as easy given it is likely a relatively simple change to the matching logic?
Thanks for the patch! Given our pseudo-SLA this likely won't get immediate attention, so marking as low priority.
Marking as low priority given a need for more clarity around the request and the maintenance status of the extension right now.
Jun 11 2020
FYI to anyone taking up this task: The failures seem to be related to a change some time ago that runs tests in the qqx language instead of en. The fix should be as simple as going to each failing test and changing the expected value to use the new output (as, it appears, nothing is *really* broken).
Apr 14 2020
@Lea_Lacroix_WMDE work is ongoing to ensure that the frontend-only version of the extension will work as expected (read: minimal regressions). Our rough timeline seems to be 3-4 weeks, depending on staff capacity. Once that work is done (and Graphoid is de-deployed) we may continue by triaging and focusing on some of these bugs.
Apr 10 2020
Updated description and title to reflect my understanding of the current proposed solution. Acceptance criteria in the works for the new proposal.
Mar 18 2020
Mar 10 2020
Ramsey nerd-sniped me with this, so I dug briefly and found a Windows-specific bug which seemed on point. Initially when talking with him I thought it might be a random space character trailing a line in our output HTML, but I then found that at src/View/MediaInfoEntityStatementsView.php:371, we explicitly add the line separator character, which seems out of place here. From the Unicode docs:
Feb 5 2020
Approved as manager!
Dec 13 2019
Based on some (very) brief git archaeology, @Esanders made commit eb978f9fd3450b11e76bce6c2612b831f7e52960 which removed the clearIndicator method, which suggests he may be best able to remove the only remaining call to it when he gets a chance (and replace it with something analogous, if necessary).
Dec 12 2019
Nov 25 2019
In no particular order:
Nov 13 2019
Oct 16 2019
@crusnov that would be great! Thanks.
Oct 15 2019
Aug 31 2019
Aug 14 2019
Aug 13 2019
@colewhite my main concerns would be access to:
Aug 6 2019
As manager, noting my approval - please grant the request!
Jul 25 2019
Jul 24 2019
Matthias and I just spoke briefly about this and found another file that had this issue - it seems it's a temporary problem, possibly related to caching, that would be hard to demonstrate by one link in a Phabricator task. He's on it, though.
Jul 23 2019
@Addshore et al., not to make your lives more difficult here, but assuming caption lookup is not desired (because I can't imagine it would be), would an index of some sort be needed in order to support something like mw.wikibase.getEntity( 'File:Blah.png' ) - i.e. using the filename instead of the M-ID?
Jul 10 2019
Jul 9 2019
I believe we want to disable Lexeme statements on Commons for now - so some help for our team on how to disable them and how to turn it off (if wgLexemeEnableRepo = false isn't sufficient) would be appreciated.
Jul 8 2019
@Ladsgroup I believe SDC won't require lexeme entity rendering, so perhaps you could point us in the right direction to turn off the dependency injection you mentioned on Commons, if such a thing is possible.
Jun 25 2019
@Krinkle as far as I can tell, the message does exist in other languages, but not ja - does the RL code not do proper language fallback for some reason? Or is this purely a cache issue? As far as I can tell, the JS code and extension.json look pretty much the same as every other use of messages in the extension, and in other extensions I've worked on. Just trying to get an idea of what we need to do differently, if anything, in the WBMI code.
Jun 20 2019
@ArielGlenn https://grafana.wikimedia.org/d/000000175/wikidata-datamodel-statements?refresh=30m&panelId=4&fullscreen&orgId=1 <-- average statements per item on Wikidata
May 23 2019
May 21 2019
@Michael - is this something WMDE is looking into or something we need to sort out?
May 9 2019
Support, as Cormac's manager - we currently have one deployer and will be doing a lot of deployments in the next six months or so.
Apr 23 2019
@WMDE-leszek - I spoke with @jcrespo and some others about potential issues with the SDC deployments, and we basically decided that it would be best to move the Wikibase tables to a separate cluster out of an abundance of caution. They wanted a WMDE perspective as to whether making that move would be possible and what effects might be seen based on the various refactoring going on, in particular with the wb_terms table. Given you've been our point of contact on Wikibase work recently, I hoped you could chime in or bother the correct person to give feedback on this matter.
Apr 16 2019
@egardner I'm fascinated by that screenshot, not only because it's inconsistently broken (the best kind of broken, obviously), but also because it looks like you have an empty caption that it allowed you to submit. Perhaps more is broken here than we realize!
In production: I submitted nine captions for https://commons.wikimedia.org/wiki/File:Sollentuna_kyrka_-_KMB_-_16000200131314.jpg - five went through initially, then re-submitting the form saved a sixth, but the other three were uneditable and the publish button was once again disabled.
Apr 5 2019
I'm not entirely certain I follow the example code above (I looked for it in the patched file but it must be elsewhere), but I'm inclined to agree that it's better to fail on "impossible" behavior, then dig more to figure out why it's not impossible.
Apr 2 2019
Apr 1 2019
Additionally, we should probably replicate the first two scenarios in the File namespace, possibly after uploading our test file so we don't need to edit anyone else's files.
Mar 28 2019
Boy, we should really clean up that project's membership.