Thank you Jon for taking the time and effort to give a comprehensive
answer. :) Honestly, this is what I expected and I won't question the
priorities set by WMF. I'm just looking into how the UploadWizard project
could be continued in the future, and with what parties involved.
Would it make sense to create a community-maintained fork of UW that would
ditch Commons-specific features such as structured captions? IMO there's
enough third-party interest for this to be viable and a fork would have two
major advantages. First, there would be no need for WMF to be involved, so
the extension could be developed at its own pace, independent of
Wikimedia's strategy and work allocation. Secondly, Commons has a very
large number of specific requirements that make adapting the tool to be
usable by both it and third parties a rather difficult task. An example of
this are image-based tutorials that are very hard to maintain, especially
for small communities. Features related to Structured Data are great, but
completely useless for third parties. I also wouldn't be surprised if
Wikibase integration becomes stronger in the future and some other parts of
the wizard could become redundant for Commons. In such a case, with a
community-dedicated fork, WMF could have greater freedom when it comes to
cutting features it doesn't need anymore. That last part is pure
theorizing, though. :)
IMO, in this case, the potential benefits coming from making a fork
outweigh the disadvantages. I see two different sets of requirements and
the division between them is likely to only increase in the future.
If we were to make a fork, I have an entire backlog of features / fixes
waiting to be implemented. Some of these stuck in review, some were already
started, and others have been patched haphazardly locally in the past, so
it's not starting from absolutely nothing. The things that I have on mind
are:
- Rework config handling to make it more consistent (now only campaign
configs are parsed, the main config is not) and robust (unit testing
included!).
- Simplify the task of including more licenses in UW (message loading
based on config), add more built-in icons to make that even simpler for
site admins.
- Change the tutorial from an image to wikitext, which should be much
easier to edit.
- Restructure documentation to be third-party centric, maybe make a
brief configuration guide (configuring UW now requires one to carefully
study a not-so-friendly PHP file).
- Add a few quick hacks to make the UI responsive, at least to some
degree (that is very much possible with just CSS). The solution can be
polished later.
- Remove Wikibase-related code and other Wikimedia-specific stuff that
will just make testing harder.
- Improve configurability for all fields in the wizard, ensure sensible
default settings.
- Add an option to use single-language fields. Multi-language fields are
unnecessary on most wikis.
- Look into how different stages of UW could be streamlined / improved
to make the upload process faster, especially on wikis requiring less
detailed information.
- Make all kinds of file description syntax configurable.
- (Maybe) prepare and package a few ready-to-use configuration sets,
together with the templates necessary to make it work. That would really
simplify the process of bringing UW to a wiki.
...and more! This may be a bit ambitious, but I think it's doable with just
a few people interested in the project and some spare time. I am certainly
on board. :P
--
Ostrzyciel (he/him)