User talk:MarkTraceur/More general frontend uploading tools

Thanks!

Hi Mark. Thanks for preparing this draft, much appreciated! I like the way you are thinking about refactoring the Upload Wizard to make it more usable by other tools. I think this is a good direction to aim for, though I lack the technical expertise to comment on the specific implementation details. I defer to other engineering team members to discuss those technical aspect.

From a product management and resource allocation standpoint, we committed to spend a few sprints each quarter to work on the Upload Wizard, so our goal would be to focus on incremental refactoring goals, starting in the places where there is the greatest need. So we may want to break up this plan into discrete chunks that can be staggered over time. That’s because we have other projects in the pipeline that will also need our attention.

Thanks again for doing this, and I look forward to comments from others. Fabrice Florin (WMF) (talk) 18:19, 20 December 2013 (UTC)

Context of UW

Hi, this is NeilK, the original author of UploadWizard. Sumana looped me in via email. I don't have any plans to help refactor this, but I'd help anyone who wanted to understand how the code worked. I believe when you use words like "convoluted", you probably meant to say "a model of crystalline clarity", but that's okay. ;)

UW is the way it is, not because it was the best way to solve the problem. Without going into too much detail the code is something like 40% actual functionality, 30% backwards compatibility with ancient browsers no longer relevant in 2014, and 30% internal Wikimedia political feuds. I can go into more detail if anyone cares.

That said, some of your use cases are supported by UW already, unless things have changed. It is designed to be "embeddable" in other pages, and with fairly simple configuration you can drop the more outré widgets, like custom licenses, and limit it to a single file. If I recall correctly such configuration is done at the MediaWiki configuration file, which isn't as convenient for obvious reasons. But I think we can work around that, or change it so it obtains configuration from some JSON on the page or something. So I can help you get many of your use cases by tomorrow, I think.

Still, I would support making a clean break with the past, to create a very simple file uploader. UW handles far too many use cases; everything from the single author own-work file, to uploading 20 different files simultaneously, all with different licenses. The simple case should be a single button.

You might run into political difficulty over that, however, since wiki maintainers (particularly Commons volunteers) get fed up with the flood of poorly-licensed images that result from that sort of interface. I have some ideas to mitigate that, but they would be out of scope for an interface change. And I have been out of the loop for two years; perhaps there are new practices in place to deal with this? I notice that Commons doesn't seem to be as afraid of UploadWizard as they once were, it's back in the sidebar, without a lot of preliminary "ZOMG, UPLOADING IMAGES? WHAT ARE YOU, MAD?!"

NeilK (talk) 18:37, 4 April 2014 (UTC)

We are so crazy these days on Commons that we even put the UW right on the Main Page. :-)

Do you realise? Offering people to upload stuff RIGHT ON THE MAIN PAGE???!!! ;-) Jean-Fred (talk) 12:56, 7 April 2014 (UTC)

Hi, NeilK! Thanks for dropping by.

While I think a lot of the code for UW could be easily split up (and indeed, a GSoC student has already done some of it), I think there's a lot more to do before the interface can be used in every page, not just on a make-the-code-work level (because I think the spaghetti code situation is way worse now), but also on a make-the-interface-more-consistent level. Rob Moen is currently doing wonderful work on that very task.

But there's more to it than just making the code work and making the interface make sense - I want this to be a hackable project. When I started it was very difficult to understand, and things haven't changed much since then. Having UW follow our code conventions, use proper jQuery syntax (though this may be irrelevant with the new UI code), pass jshint, and look more like an MVC framework would make things much easier, not only for new contributors, but also for unit testing.

This project needs a lot of love, and has for some time now, and it's not just a matter of getting it to work. We've done that for three years now, and after all of that, I want to make it work well. --MarkTraceur (talk) 15:00, 7 April 2014 (UTC)

Hi again Mark. I just spoke with Erik about maybe doing a contract for some bugfixes in UW. It's not quite clear to me what his priorities are versus yours versus Gilles. I agree with all your priorities. This project has a history of many executive-mandated features, without having any freedom to really fix how things work.

I reviewed the code and noted that you went on a jshint jihad (no problem, I was undisciplined at times). A lot of the code does seem kind of dismal to me now - it was one of my first jQuery projects, and most of it was done in a huge three month rush, and then it dragged on for a whole year afterwards. And so much of it is pointless by 2014 standards. I wonder if a line count of plumbing to functionality would be enlightening. Since it was started in the dark ages of 2010, so there's a mishmash of storing data in the DOM, using callbacks, and using Events, and somewhat dubious concepts like my "ready events" (which would be better fulfilled by Promises). These days I write everything with Promises (I prefer Bluebird) although I think you are using jQuery deferreds? That is at least a step in the right direction. As for an MVC framework what is approved at Wikimedia? It's unclear to me whether Wikimedia is ready for a bold leap into 2012 with say Backbone; I'm hearing about homegrown frameworks like OOjs_UI instead. NeilK (talk) 07:43, 24 May 2014 (UTC)

Status, and related RfC

I've heard that User:Robmoen has started implementing this RfC. Where can people follow that work? And should bug 60002 be assigned to him?

I've also posted to the talk page of a related RfC, Requests for comment/UploadWizard: scale to sister projects, to let folks know that this one exists too. Sharihareswara (WMF) (talk) 20:34, 21 April 2014 (UTC)

I moved this out of the RFC namespace because I don't think it's actually an RFC. I think we're Just Going To Do It.

bug 60002 is a tracking bug, so it shouldn't be assigned to Robmoen. If he wants to open blocking bugs to describe his current work, he can, but that's meant to be a tracker, not a specific bug.

Let me know if there's anything else you'd like me to clean up on the page. --MarkTraceur (talk) 21:28, 21 April 2014 (UTC)

Core versus extensions

I'd like to see a little more info on what you plan on putting into core, and what goes into an extension. I've already told Mark this, but IMO a lot of UW's uploading functionality should be in core, and other stuff like campaigns should be moved into their own extension. Legoktm (talk) 07:32, 22 April 2014 (UTC)