Web browser: ---
Bug ID: 60002
Summary: Separate data-handling, interface, and other
controlling methods and put generally-applicable code
into MediaWiki (tracking)
Product: MediaWiki extensions
CC: aarcos.w...@gmail.com, bawolff...@gmail.com,
Mobile Platform: ---
In the past few years we've worked really hard to bring UploadWizard to a
usable state, and now that we have a Multimedia team framework to actually do
some good work on it, and we have the impetus to start making the upload
pipeline way better, let's do it the right way: Let's make this project the
organized, well-engineered machine it should have been in the first place.
I would particularly emphasize code conventions being followed, jshint
conformance, an eye towards an MVC-like structure (nothing strict, but as a
general goal...), building toward libraries that can be used elsewhere, and a
variety of different possible interfaces.
Ideally none of the upload steps will be entangled unnecessarily with other
steps, and we will be able to untangle them when necessary and put them in
different pages or tools.
Ideally we will use the brilliant work- and complexity-reducing technology
(oojs, oojs-ui, jQuery promises, moment.js) that other projects have started
using in recent times.
It is an absolute *must* that we build tests for this system as we are building
it, if we want this to be a generally useful set of tools for other projects.
Same for documentation.
The leaders in LOC for active frontend projects deployed on the cluster are*
VisualEditor, UploadWizard, Flow, and MultimediaViewer (in no particular
order). Let's start bringing the upload pipeline projects closer to the high
standards that other projects are holding themselves to.
* According to an unscientific survey based on guesswork
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
Wikibugs-l mailing list