Requests for comment/UploadWizard: scale to sister projects

This request for comment is about UploadWizard software which the Multimedia Team (WMF) is about to embrace and take over starting within next weeks and processing it during 2014, per the text on the software page.

Proposed change
What I would like to propose is to restructure the UploadWizard software to make the following functionality available to contributors:
 * Edit text of each wizard screen on-wiki.
 * Edit the flow of the wizard (which buttons exist on a screen, where they take) on-wiki.

Context
This request is based on the following observations:
 * English and Russian Wikipedia's article creation wizards appear to be entirely markup-based, with no JS. Contributors have the flexibilities mentioned above, but lack some nice flexible things JS would let them do, such as choosing a next wizard screen depending on multiple previous choices, or entering partial data to be carried forward from page to page.
 * A product which has the flexibilities mentioned above would have the potential to be deployed across all sister projects.
 * Such a product would also have the potential to work a bit gadget-like, to address use-cases I call “interactive templates”, to aid in daily editing routine and make it more intuitive.
 * A JS-based product of this kind is under development on English Wikinews.
 * Multimedia Team mention they would start working “in the coming weeks”, making feedback pertinent earlier better than later.
 * Editing on-wiki is more collaborative than querying editing files (like ones in an Extension) would be.
 * Markup should also be less-prone to security risks.

Amount of complexity involved
I'm not sure you fully appreciate the complexity involved in a project like this.

UploadWizard itself has thousands and thousands of lines of JavaScript code that deals with step navigation, different upload methods, error checking, interfaces for different choices along the upload path, and various API calls to save all of that information on the wiki. Putting all of that in a gadget *might* be possible, but putting most of it into wikitext is not.

And even if it's possible to shunt the backend UW code into core, and put all of the frontend code into a gadget, we would lose a lot of the benefits we get from having UploadWizard be an extension: It gets proper code review, it can be configured (and the configuration also gets code review), it can be distributed to third party sites, and so on.

I would be adamantly against pushing UploadWizard more on-wiki.

However, I would be very much in favour of sticking more client-side hooks into UploadWizard. You can already edit most of the text of the wizard through MediaWiki namespace message pages, so allowing gadgets to play with the workflow and the interface is IMO the only remaining task. Let's focus our attention on accomplishing a more extensible interface instead of totally rewriting it in a new language, and screwing with the established structure of the tool. --MarkTraceur (talk) 21:18, 10 February 2014 (UTC)
 * Yeah I would say that it is important to slowly rework the wizard where possible in more subcomponents that can be reused and hooked into, instead of a monolithic and intertwined blob. That is much more important then making everything editable. TheDJ (talk) 10:27, 11 February 2014 (UTC)

which wizard are we talking about?
the page title and intro talk about "upload wizard". however, the "context" paragraph seem to be about the "article creation wizards". these are two wildly different discussions that, at least at first glance, seem to be hopelessly conflated. it's not at all clear from the discussion which wizard is being discussed here. please clarify. thanks, peace - קיפודנחש (talk) 23:21, 10 February 2014 (UTC)
 * קיפודנחש, that's right. The title says: "scale upload wizard to sister projects", meaning "scale upload wizard for all wizard needs of sister projects". Gryllida 02:38, 11 February 2014 (UTC)