Hi, is it possible to increase the value of $wgMaximumMovedPages for eo.wikisource to 500, please?
Description
Description
Related Objects
Related Objects
Event Timeline
Comment Actions
Hi, please follow https://meta.wikimedia.org/wiki/Requesting_wiki_configuration_changes when requesting such site configuration changes. Thanks!
@Tpt: This seems to be only about one Wikisource; removing tag.
Comment Actions
@Aklapper Do I need to get a community consensus? Or is it about the tags? I’m not sure about what you’re expecting from me.
Comment Actions
hi, for site admins, renaming a book is a very boring technical task : doing it by packs of 100 pages is very tedious... - just imagine having to rename https://fr.wikisource.org/wiki/Livre:Revue_des_Deux_Mondes_-_1855_-_tome_12.djvu by packs of 100 pages...
it would most certainly be simpler if 500 was the default config for wikisources...
It's already been done on frwikisource (long ago - don't know when),
Comment Actions
Hello,
I'm calling in Performance-Team. I see this is already set to 500 at a couple of projects, but I prefer leaning on the side of caution and ensure this is indeed not problematic (especially before changing it everywhere)
Generally speaking, yes, any and all community requested changes need to demonstrate they're community-requested (rather than by an individual active in the community), which is done by presenting a consensus :). However, you might also want to wait -- maybe we'll decide to just change it everywhere.
Comment Actions
Untagging for now as I'm not able to get to this soon. As I understand it, this is currently a request from a single user. If performance was the only concern and if we determine that this limit is fine to raise to 500 on any wiki no matter what, then this request suffices and we could raise it more generally on all wikis.
However, I imagine the community may have gotten used to a certain level of control over how large a set of pages can be moved by users by default. If so, then community consensus may be desired as well. @Quiddity Do you have a sense of what community expectations around this may be?
As for the performance, please move this back to our inbox or ping us if this becomes urgent. I do note that we have other limitations on query complexity already, so it may very well be that these would timeout if attempted, or start timing out in the future when these more general limitations are brought down. In that case, MovePage might require something akin to DeletePage in terms of splitting up the work and doing it asynchronously via the job queue.
Comment Actions
Note: The Frwikisource change was done in 2010 (per T26458) and Enwikibooks in 2008 (T17932). I would guess that if there were any user-end problems with that, they would have become clear by now?
I believe that a change to increase the limit for all Wikisources would not require a community consensus, as (IIUC) the limit [for admins] only exists due to past performance issues (?).
I.e. If it is technically fine to increase, and nothing changes from the user-end except that admins can do a task more easily, then this would just deserve an announcement in Tech News, once completed.
However, if there are any remaining performance concerns - e.g. if an increase might occasionally lead to problems, perhaps if multiple users tried to move many different batches of 500 pages on the same wiki simultaneously (which could conceivably happen during a "backlog drive") - then that might require more communication, to explain the benefits/drawbacks of the options available, and request feedback&consensus. That would probably need to be centralized either on Phab or at https://meta.wikimedia.org/wiki/Wikimedia_Forum -- I.e. At minimum, to get it documented and make all admins aware, that there could be problems in [x] scenario, and how to detect and resolve them if they do occur.
Re: job queue, and related discussions, I did find this old task T20585: Moving many (>100) subpages requires loads of memory; leads to PHP Fatal error, and the details there might be relevant here. (I.e. Catrope mentions concerns with a job queue solution, but that was in 2009...) (IANAD disclaimer!)
Comment Actions
I believe this task is waiting for someone in the Performance team to evaluate the possible technical methods for increasing the limit -- I.e. Determining if there are any/many solutions that won't cause problems if multiple people/wikis then decide to utilize the feature at the same moment. ("Does it scale?").
Once that is determined (technical restrictions on possibilities), it will be clearer if, and what kind of, followup community-questions are needed.