Please disable 2-factor authentication on this account - 2016-08-15 - thanks
- User Since
- Oct 7 2014, 2:49 PM (366 w, 6 d)
- IRC Nick
- LDAP User
- MediaWiki User
Yeah, as mentioned above, I don't think the Structured Data team has the requisite expertise to handle this, especially given our reduced capacity - I believe even the 10 days estimate above proved to be overly optimistic. It's always sad for me to say that we can't help out when Commons, or media support in general, has an issue, but at the moment I don't believe we can do anything. Possible that someone with more experience debugging Swift, or working with it, might be able to do something.
Sep 8 2021
Moving back to Needs Design, @egardner will circle back to Matthew to discuss further.
Jul 20 2021
Approved as manager!
May 25 2021
Hereby approved by manager :) thanks, all!
Apr 19 2021
Hello! Sorry about the lag, I don't have good notification settings for Phabricator and I was on vacation last week when I was notified outside of Phabricator.
Mar 31 2021
Sorry about the delay, luckily I was here anyway approving T279014. Approved as manager!
Approved as manager!
Mar 24 2021
We received a helpful email on the subject and have brought it into our process, which is currently fairly tied up with an imminent feature release and associated work. I would anticipate this work can be completed sometime in the next month, but at the moment, I have no further specifics. The maintenance of the Media Viewer feature has been Complicated(tm) since the Multimedia team became the Structured Data team and moved on to other projects.
Feb 8 2021
Per @sbassett 's review and the requirement for manager sign-off, and as the interim manager for the Web team, I am going to approve the deployment of WVUI per the discussions I've had with @phuedx and @Jdlrobson today.
Dec 9 2020
Dec 7 2020
"maintains" is a strong word for the relationship Structured Data has with this extension. We have an SLA level at or near "only security patches/issues will be considered". Nobody on the team has very much experience with it.
Ignore the above, it was typed when I had but dreamt of having my morning coffee.
Managed to find that, at least on simple.wikipedia.org, the URL in question is "/beacon/media", which is being passed into the mw.Uri constructor unmolested. Not terribly ideal, so I suppose we should de-relativize it before passing it into mw.Uri. Might be a nice-to-have if mw.Uri handled relative URLs in the future but I think hardly a necessity.
Nov 18 2020
Nov 2 2020
Notes from a quick perusal of logstash: ~60 of these errors in the past 7 days, so not exactly a universal occurrence but not completely uncommon either. Unclear what effect this might have on the UI or if the users were able to circumvent the error somehow...in any case, I suspect this is something changing somewhere upstream and us needing to update the UW code. I feel like we've seen this bug before as well, but can't recall what exactly the issue was.
Oct 29 2020
Approving as manager.
Oct 27 2020
@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!