[Wikitech-l] Breaking changes without deprecation in the Shellbox patch

[Tim Starling]

The following changes will be made without deprecation in gerrit
626548 :

  * FirejailCommand was removed. CodeSearch reveals no usages.
  * Command::execute() now returns a Shellbox\Command\UnboxedResult
instead of a MediaWiki\Shell\Result. I added a class alias, but
type hints don't necessarily cause PHP to load the alias when it
parses the file, so any such type hints should be manually
updated. CodeSearch finds no affected code.

Context:

This is part of T260330 
"PHP microservice for containerized shell execution" a.k.a. Shellbox.
The patch moves the traditional shell execution code from MediaWiki to
the Shellbox library, and mildly refactors it. Rigorous backwards
compatibility was a goal of this change. We took the opportunity to
make a few minor interface changes, but we don't think anyone will be
affected.

-- Tim Starling
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Is preprocessDump.php still useful?

[Krinkle]

Drafted removal at:
https://gerrit.wikimedia.org/r/c/mediawiki/core/+/659133

-- Timo


On Thu, Jan 21, 2021 at 1:39 AM Krinkle  wrote:

> This script was created in 2011 and takes an offline XML dump file,
> containing page content wikitext, and feeds its entries through the
> Preprocessor without actually importing any content into the wiki.
>
> The documented purpose of the script is to "get statistics" or "fill the
> cache". I was unable to find any stats being emitted. I did find that the
> method called indeed fills "preprocess-hash" cache keys, which have a TTL
> of 24 hours (e.g. Memcached).
>
> I could not think of a use case for this and am wondering if anyone
> remembers its original purpose and/or knows of a current need for it.
>
> -- Timo
>
> [1] First commit: http://mediawiki.org/wiki/Special:Code/MediaWiki/80466
> [2] Commit history:
> https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+log/1.35.0/maintenance/preprocessDump.php
>
> PS: This came up because there's a minor refactor proposed to the script,
> and I was wondering how to test it and whether we it makes sense to
> continue maintenance and support for it.
> https://gerrit.wikimedia.org/r/641323
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The future of UploadWizard

[Strainu]

În joi, 4 feb. 2021 la 21:31, Ostrzyciel Nożyczek
 a scris:
> 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.

Just a quick note to say that out of the 11 items you list above, 8
would also improve the Wikimedia experience :)

Strainu

>
> ...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)
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Technical Decision Making Process Update and Change

[Andre Klapper]

On Thu, 2021-02-04 at 08:54 +1000, K. Peachey wrote:
> Are the Gerrit permission requests that techcom used to handle going
> to the new forum or another team?

To be defined. :) The Technical Engagement team is currently
investigating; see https://phabricator.wikimedia.org/T273164

Cheers,
andre

-- 
Andre Klapper (he/him) | Bugwrangler / Developer Advocate
https://blogs.gnome.org/aklapper/


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The future of UploadWizard

[Ostrzyciel Nożyczek]

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)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The future of UploadWizard

[Jon Katz]

Hey Folks,
I just wanted to flag that we heard the question and had circle up to get
you an informed answer as the answer spans several teams.  The most literal
answer to Ostrzyciel's email is:  "no, there are no plans or resources
allocated to doing anything other than fix breaking upload wizard bugs on
Commons".  The longer answer is that we know we have to improve the upload
wizard and it's a matter of resourcing and prioritization.  The caveat is
that it is unlikely that the WMF will work on an upload wizard that is
specific to the needs of 3rd party wikis, anytime soon.  For the Commons
use case, I think it's much more likely.

Many of us in product have been pushing for a team dedicated to multimedia
improvements for several years, but as I hope you can understand, other
priorities have taken precedence. You are free to disagree that project X
is more important than UW, as these are decisions for which there is plenty
of educated opinion, but no right answer.  Even on this year's community
wishlist
,
upload Wizard improvements did not fit in the top 5 most-voted improvements
for multimedia. Again, we want to work on this, it's just that other work
has been prioritized above it and, believe it or not, at our size, we are
stretched pretty thinly.

I don't have the answer to the stewardship question, K Peachey.  I'm
copying Jean-Rene who chairs that group in case he has any insights.

Thanks,

Jon Katz
Director of Product

On Thu, Feb 4, 2021 at 7:09 AM Strainu  wrote:

> În joi, 4 feb. 2021 la 16:54, Bartosz Dziewoński  a
> scris:
> >
> > On 2021-02-03 23:33, Strainu wrote:
> > > One thing that puzzles me in that ticket is this phrase from Mark
> > > Traceur: "It might be better to look at something (slightly) more
> > > modern, like the upload dialog in core". Does anyone know what that
> > > dialog is? AFAIK the uploader in core (Special:Upload) hasn't changed
> in
> > > decades, except maybe for the look of the buttons. Its usability is
> > > rubbish compared to UW. Wikis used to (no, actually they still do)
> > > customize it using the uselang param,which messes with the user's
> > > settings. I can't really understand how that would be better...
> >
> > The upload dialog is this: https://www.mediawiki.org/wiki/Upload_dialog
> >
> > It's accessible from both the visual and wikitext editors (unless you
> > disabled the toolbar), though their dialogs to insert image thumbnails.
>
> Thanks to all who enlightened me. :)
>
> We're basically talking cross-wiki uploader here in the Wikimedia
> world (although I'm sure it can be used for other things). I agree
> with Ostrzyciel's assessment that it lets anyone upload anything -
> that's what prompted the request to disable cross-wiki uploads in the
> first place. The UW, in collaboration with campaigns, remains the most
> powerful web uploader the Wikimedia community currently has.
>
> Strainu
> >
> > --
> > Bartosz Dziewoński
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The future of UploadWizard

[Strainu]

În joi, 4 feb. 2021 la 16:54, Bartosz Dziewoński  a scris:
>
> On 2021-02-03 23:33, Strainu wrote:
> > One thing that puzzles me in that ticket is this phrase from Mark
> > Traceur: "It might be better to look at something (slightly) more
> > modern, like the upload dialog in core". Does anyone know what that
> > dialog is? AFAIK the uploader in core (Special:Upload) hasn't changed in
> > decades, except maybe for the look of the buttons. Its usability is
> > rubbish compared to UW. Wikis used to (no, actually they still do)
> > customize it using the uselang param,which messes with the user's
> > settings. I can't really understand how that would be better...
>
> The upload dialog is this: https://www.mediawiki.org/wiki/Upload_dialog
>
> It's accessible from both the visual and wikitext editors (unless you
> disabled the toolbar), though their dialogs to insert image thumbnails.

Thanks to all who enlightened me. :)

We're basically talking cross-wiki uploader here in the Wikimedia
world (although I'm sure it can be used for other things). I agree
with Ostrzyciel's assessment that it lets anyone upload anything -
that's what prompted the request to disable cross-wiki uploads in the
first place. The UW, in collaboration with campaigns, remains the most
powerful web uploader the Wikimedia community currently has.

Strainu
>
> --
> Bartosz Dziewoński
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The future of UploadWizard

[Bartosz Dziewoński]

On 2021-02-03 23:33, Strainu wrote:
One thing that puzzles me in that ticket is this phrase from Mark 
Traceur: "It might be better to look at something (slightly) more 
modern, like the upload dialog in core". Does anyone know what that 
dialog is? AFAIK the uploader in core (Special:Upload) hasn't changed in 
decades, except maybe for the look of the buttons. Its usability is 
rubbish compared to UW. Wikis used to (no, actually they still do) 
customize it using the uselang param,which messes with the user's 
settings. I can't really understand how that would be better...


The upload dialog is this: https://www.mediawiki.org/wiki/Upload_dialog

It's accessible from both the visual and wikitext editors (unless you 
disabled the toolbar), though their dialogs to insert image thumbnails.


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The future of UploadWizard

[Ostrzyciel Nożyczek]

While we're at, I would like to mention that these upload dialogs really
don't help with enforcing any kind of image description standard. They
allow users to just drag and drop files, which is intuitive and nice, but
also does not ask them to specify the source of the media. In my practice,
this leads to users just ignoring the wiki's rules and throwing in whatever
media they find. We actually hacked both WikiEditor and VisualEditor to
disable these upload dialogs and redirect people straight to UploadWizard,
so that any kind of standard could be enforced.

To be honest, I'm rather surprised that nobody on e.g. enwikipedia has
picked up on this issue. They have a complex wizard in place
, full of
explanations of what is free and non-free media, where to upload it and
under what circumstances it can be used. These simple upload dialogs in the
editor lack this back-and-forth dialog with the user, explaining rules and
asking for information, step by step. Also, that enwikipedia non-free
wizard looks very much like a simplified version of UW, which just shows
how much needed is a robust solution to uploading media with precise
descriptions.


czw., 4 lut 2021 o 03:55 Sam Wilson  napisał(a):

> On 4/2/21 6:33 am, Strainu wrote:
> > One thing that puzzles me in that ticket is this phrase from Mark
> > Traceur: "It might be better to look at something (slightly) more
> > modern, like the upload dialog in core". Does anyone know what that
> > dialog is? AFAIK the uploader in core (Special:Upload) hasn't changed
> > in decades, except maybe for the look of the buttons. Its usability is
> > rubbish compared to UW. Wikis used to (no, actually they still do)
> > customize it using the uselang param,which messes with the user's
> > settings. I can't really understand how that would be better...
>
> I guess it means this:
> https://doc.wikimedia.org/mediawiki-core/master/js/#!/api/mw.Upload.Dialog
>
> Which I think is only used in the WikiEditor extension. Maybe the dialog
> is in core because there was a plan to move WikiEditor into core?
>
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>


-- 
Ostrzyciel (he/him)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l