On Tue, Feb 25, 2014 at 01:35:33AM +1100, Gryllida wrote:
Like with all other development, I find a need in more
documentation of the plans and of the currently active things.
We do our best to keep track of things in the monthly reports [0], and
we track individual teams on pages like the Multimedia page [1]. The full
plan is available, too [2], and the engineering one is also around [3].
For example, VisualEditor has nothing to help me
comprehend its code-base than the source code itself; it had only been a jamesf's line
at a meeting which made me aware of the fact that the cologne blue and modern skins are
now only supported by community.
You mean *code documentation*? We have that, both for VE [4] and MMV [5].
If you mean documentation of decisions by the Foundation, there are always
announcements, usually they're made to the community they will affect.
If you think there was a dropped ball on the skins decision, then talk
about it with James or with the design community, but the Multimedia list
is not the place.
Now there are some really cool beta features that only
work with the vector skin. To only resource to help me is the source code. There is no UML
diagram, no docs explaining which part of code does what.
We don't really do UML diagrams, true. As I said, MMV has documentation,
and so *should* Popups. I can't speak for Jon's code, but they should
have docs too, but *again*, this is not the list where we should be talking
about this, because this is Multimedia, and MMV is the only BetaFeatures
thing we are running.
...there is a lot of pages which would make use of a
do-it-without-page-reload approach, such as log-in page, edit page, history page.
None of those examples fall in the Multimedia team's purview.
...there also is a need of all sister projects in
wizard tools and widgets. Currently adding an article to Wiktionary is a royal pain and I
could not figure out how to add an idiom with translation, without pulling hair and
spending time to find another existing Wiktionary entry which is (1) a verb, (2) an idiom,
and (3) has a translation. There also are gadgets for the so-called "interactive
template" use-case [1] where each developer reinvents wheel a lot and the gadgets
share no code but they should.
Again, while we have a wizard tool under our purview, leading the charge
towards a grand architectural change and major engineering project with
a relatively new (to this community) four-person team does not seem like
a good use of our time. We're building processes that work for us within
MMV, and we'll apply those processes to UploadWizard when we get to it.
Also, notably your RFC [6] on the subject of wizard tools has taken up
very little traction especially among the developer community, and I expect
it will stay that way - again, major architectural changes are hard to
motivate all at once, we're way better off talking about incremental
steps like adding hooks and cleaning up code structure so people can add
to the codebase in its current form, either by hooking in via mw.hook
or by writing patches for Gerrit.
...everything the WMF works on should have long-term
impact after WMF stops working on the darn thing. The impact should be cross project.
I've had a great time using MMV in all of the projects I'm part of.
Wikipedia, Wikibooks, even private wikis. I don't know why this point
was included in your list of questions of why we're working on MMV, but
I see this requirement as absolutely met.
... With this in mind I would personally encourage
heavy collaboration of all teams to build a framework which lets people script the
MediaWiki software including media viewer screen, log-in screens, article creation screens
/ wizard, an interactive thingie for working with templates [1] (taking an {{unblock}}
request for example without having to memorize the template syntax).
Just one massive framework for *all* of that? Actually, it already
exists [7]. What we should be asking for is more use of it by core and
extensions, but we're already working on that, too [8].
This may need help from VisualEditor and Parsoid
people; from Flow people who had spread the 'custom workflows' rumour; and YOUR
help to understand that moving an interactive thingie logic from an extension onto a wiki
benefits everyone, even if it makes codereview-worthy bits harder to spot (recall some
people saying that none of UploadWizard's logic can sit on-wiki because of that [2])
Yeah, me. Our code is editable, it's not like you're being told you can't
participate, you're just being told your work is going to be subject to
review. Actually, we'll happily let you work without review via the hooks
system, we just reserve the right to review where you're putting new hook
calls, and how their input and output are being treated.
We welcome patches [9]. We welcome gadgets [10]. Moving code out of the
existing CR system onto the wiki won't be that much gain for the amount
of work it will cost, because you can *already* work on our code.
Unless you have some epic technical reason for moving UW code onto wikis,
I don't see it happening.
...but seriously, what do people think about developer chatter on this
list? :)
[0]
https://www.mediawiki.org/wiki/Wikimedia_engineering_report/latest
[1]
https://www.mediawiki.org/wiki/Multimedia
[2]
http://wikimediafoundation.org/wiki/File:2013-2014_WMF_Plan_As_Published.pdf
[3]
https://www.mediawiki.org/wiki/Wikimedia_Engineering/2013-14_Goals
[4]
https://doc.wikimedia.org/VisualEditor/master/
[5]
https://doc.wikimedia.org/MultimediaViewer/master/
[6]
https://www.mediawiki.org/wiki/Requests_for_comment/UploadWizard:_scale_to_…
[7]
https://doc.wikimedia.org/mediawiki-core/master/js/#!/api/mw.hook
[8]
https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/168
[9]
https://gerrit.wikimedia.org
[10]
https://www.mediawiki.org/wiki/Extension:Gadgets
--
Mark Holmquist
Software Engineer, Multimedia
Wikimedia Foundation
mtraceur(a)member.fsf.org
https://wikimediafoundation.org/wiki/User:MHolmquist