Hello,
On T334344 <https://phabricator.wikimedia.org/T334344> was requested to add
the 'sboverride
<https://www.mediawiki.org/wiki/Extension:SpamBlacklist#Notes>' right to
the bot usergroup on ruwiki. This flag has never been added before to a
group afaik.
I thought that having local consensus, and since the change involves a
trusted group, the change would be fine, but, after a brief discussion on
IRC with MarcoAurelio and Martin Urbanec, I realized that this could lead
to problems, also since a GRfC
<https://meta.wikimedia.org/wiki/Requests_for_comment/Allow_sysops_to_overri…>
on giving this flag to sysops has not passed, and that there is no valid
reason why to be able to overcome the blacklist.
What do you think? This should be included into the limits to the
configuration changes
<https://meta.wikimedia.org/wiki/Limits_to_configuration_changes> or, if
local projects require it, this right could still be added? Many thanks for
your attention.
Have a nice day :)
F./Superpes
Dear Sysadmins,
Farsi Wikipedia (fawiki) changes its logo every year at Nowruz
<https://en.wikipedia.org/wiki/Nowruz> (Iranian New Year, 21 March) for two
weeks by editing MediaWiki:Common.css, circumventing a formal request in
the "Wikimedia-Site-Requests" Phabricator project which will be definitely
declined because it violates the neutrality principle and is discouraged by
the Wikimedia Foundation, as demonstrated here
<https://meta.wikimedia.org/wiki/Logo#Temporary_logo_variants>.
How should we deal with this?
Regards,
4nn1l2
Hi sitereq-l,
I'm looking for context regarding our upload-by-url allowlist in the
hopes of reducing workload for the site request process. Does anyone know
* Why do we even have an allowlist for upload-by-url? I presume this is
to make it harder to upload a large amount of non-free files, but I'm
curious if there are any other reasons that I'm not aware of.
* If there aren't other reasons for having the allowlist, are there any
reasons other than "someone needs to work on it" that would not let us
to move the allowlist to a system message that Commons administrators
can edit?
Thanks!
-- Taavi
Hello,
I'd like to let you know this list will be migrated to a mailman3 list. I
think that's a good decision for those reasons:
- Mailman3 is way better than Mailman2; it supports searching in
messages, archive is much more usable, etc;
- Mailman3 is more accessible for the technical community, anyone can
join a Mailman3 list, while a Google Group (being intended for internal
usage) requires an invitation.
Messages previously sent to this list will be transferred to the Mailman
archive; everyone currently subscribed to this list will also be subscribed
to the new one.
I will let you know once the migration is done. You can also watch
https://phabricator.wikimedia.org/T290908.
Best,
Martin Urbanec
Hello,
I'd like to inquire if the prohibition [1] to enable
wgKartographerWikivoyageMode on more wikis is still valid as of today.
An eswiki user organised a vote [2] to change the wiki config to the
following values:
* $wgKartographerWikivoyageMode = true;
* $wgKartographerStaticMapframe = false;
* $wgKartographerEnableMapFrame = false;
To avoid spending time in something that might not be possible, may I ask
if any of their proposals can be done?
If $wgKartographerWikivoyageMode is still banned for further further wikis;
what effects would have setting the later two configs to `false`?
Thanks for your help/advice on this matter.
Best regards,
Marco.
[1]: <https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/283339>
[2]:
<https://es.wikipedia.org/wiki/Wikipedia:Votaciones/2021/Solicitud_de_desact…>
Hello,
There's a request at <https://phab.wiki/255938> to rename several
namespace names for core's MessagesVec.php. See patch at
<https://gerrit.wikimedia.org/r/613110>.
Would it be okay to let those translations go with the usual MediaWiki
Train process, and run the required scripts afterwards
(namespaceDupes.php) or a specific backport window for the change be
preferred?
We've used both approaches in the past (cfr. <https://w.wiki/XE4> for
specific windows) but there are no docs as to what is the preferred
method.
In favour of letting the train take care of things is that the process
is mostly unnatended and we can take care of running the scripts
afterwards. Contras is that I'm not sure vecwiki would be error-free
if we don't run namespaceDupes.php afterwards.
In favour of using a specific backport window is that we make sure
everything gets done, but the contras are that I need to get a
specific window from RelEng, get a deployer that is willing to do that
specific window, two merges (master and wmf/*) and sit while the full
scap and l10nupdate scripts run.
What do you think?
Thanks for your help.
Best regards, M.
Hey,
we have several arbcom wikis, which all follow scheme of
arbcom-xx.wikipedia.org, where xx is the language code. Daimona recently
requested a new wiki for sysops, using the same scheme <
https://phabricator.wikimedia.org/T256545>.
However, @Amir Ladsgroup <ladsgroup(a)gmail.com> points out this makes little
sense, and sysop-itwiki.wikimedia.org would make more sense.
My opinion is we should stick with our current standard, given it works for
any hypothetical arbcom/sysop/whatever for any wiki, we'll just prepend the
wiki domain name with a prefix describing the wiki functionality.
Opinions?
Martin
Hello,
On <https://phab.wiki/253096> there's a request to remove the Insider
and Listings extensions from it.wikivoyage.
While it appears to be doable (it doesn't look like we'll need to
backup old data or that those extensions do DB changes, I might be
wrong), the task mentions that at least the Insider extension is not
working anymore, anywhere.
If that's the case, shall we go ahead and have Insider removed from
Production everywhere?
Best regards, M.
I’m quite happy go with a SWAT deployment and I agree that it’s probably a
lot safer.
My only concern with that is that between the 2 tasks it would be 5/6
patches in the SWAT window.
It would also be my first mediawiki core + extensions SWAT so are the
patches safe to +2 during / just before SWAT or Should I get that done
before?
Thanks,
Samuel
On Mon, 18 May 2020 at 16:25, Tyler Cipriani <tcipriani(a)wikimedia.org>
wrote:
> Hi Samuel
>
> On 20-05-18 09:57:54, RhinosF1 - wrote:
> >On https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/596424/, it was
> >raised correctly that namespaceDupes.php would need to be ran.
> >
> >https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/596424/ and
> >https://gerrit.wikimedia.org/r/#/q/bug:%20T251287 can mostly run with the
> >train (expect the mediawiki config patch) but all require namespaceDupes
> to
> >be ran and on https://gerrit.wikimedia.org/r/#/q/bug:%20T251287 could do
> >with being deployed as close together as possible to avoid
> >inconsistently translated namespaces.
> >
> >Would as mentioned SWAT be better for all 5 patches or should we let what
> >can ride with the train and deploy the one config patch shortly after and
> >run for both wikis in that window? or could we ask the train runners to do
> >that?
>
> What you're describing sounds like it would be a good candidate for SWAT
> deployment. My reasoning is that (1) it is atypical to run maintenance
> scripts as part of the train and (2) there are no guarantees that a
> train won't rollback.
>
> That is, backporting to a version that is stable ensures that we don't
> end up having rolled forward to all wikis, run the maintenance script,
> and then having to rollback due to an unrelated problem. Additionally,
> the log triage that follows a train window may mean that we can't
> guarantee a timely deploy of the configuration change following train.
>
> To me, this feels safer/faster/easier as a SWAT deployment; even though
> this might make for a particularly long SWAT window.
>
> Thanks!
> -- Tyler
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
--
Thanks,
Samuel