See https://meta.wikimedia.org/wiki/Steward_requests/Permissions instead.

A number of platforms like Google Docs and Notion supports real-time collaboration. But MediaWiki's revision storage stores all revisions in single flat table and keep them permanently with no meaningful way for pruning. So storing a new revision when someone added something is not a scalable approach (T415237: etherpad table size is 233GB / plan to delete all etherpads in April 2026 mentions current Wikimedia Etherpad has 490 million entries, which is twice the number of revisions of French Wikipedia). If someone implemented a CollabPad, we should make sure not to store every single modification - which can be addition of one single word or even letter - forever; though we can provide such a fine-grained history for a limited time. This may need to design a new type of revision storage schema, since currently MediaWiki does not allow one revision having multiple authors, and backend storage system (current ExternalStorage is append-only and can not be purged).

Should we require user to login to Wikimedia wikis before modifying etherpad? This will reduce the risk for abusing etherpad for uses unrelated to Wikimedia (including spam).

In T416696#11592202, @PharaohCrab wrote:

I oppose getting rid of wikihiero for now because while most fonts support the hieroglyphs Unicode block not all do and wikihiero is able to be formatted in ways Unicode can't.

Some user may want their user name be displayed starting with a lowercase letter, and we may honor that. This is different from modifying the username displayed in special pages arbitrarily.

Eventually, the old page will be deleted.

For users without advanced rights, 2FA would be optional and it would be simplier if older 2FA setup is simply removed and user can setup new 2FA again. This will also benefit sysops or stewards if they eventually get 2FA reset permission (T180896): user can simply contact sysops/stewards they personally know via off-wiki means and they can remove 2FA without involving emails. Using emails to send additional recovery codes has their own risks.

This does not need to add a whitelist. Instead you need to set a proper referer when fetching tiles.

This needs to be added to https://phabricator.wikimedia.org/diffusion/ECLD/browse/master/LocalNames/LocalNamesFr.php

For users without TAIV access, they will then only see a permission error message, which will confuse new users. Currently they can at least see legacy IP contributions from that IP, and in many wikis there are useful links leading to some external tools about that IP.

In T409140#11566054, @Wargo wrote:

There is no decision to stop using and undeploy.

The development of global modules can still happen in a (and even any) local wiki (in addition to GitLab and LuaRocks), we just allow pushing them to a common repo so that they can be used in another wiki.

On-wiki. A developer works on module pages, perhaps under a sandbox hierarchy on a production wiki. When they are satisfied, they want to export the current state of the sandbox as a merge request.

@Amire80: This task currently has a very board scope (allowing modules in any Wikimedia wikis be invoked in another arbitrary Wikimedia wikis similar to T6547: Cross-Wikimedia inclusion (interwiki templates transclusion, etc.) unsupported. This is a valid feature request, and the task can be kept as-is for this goal. However, T411834: Scribunto external dependencies - roadmap and requirements proposed a more limited way for external invocation (user can write libraries to be deployed in a (proposed) central repo and such libraries be used in Wikimedia wikis. This is enough to implement cross-wiki modules without arbitrary cross-wiki invocation support.

Note you may want to check "bot" right instead of "bot" group - some (but not all) wikis have other related groups for bots such as "botadmin" or "flood".

Should we just change the interface messages? So extension will still be named AbuseFilter and all interface will show "edit filter".

You may want a new Phabricator project.

In T387736#11536857, @Urbanecm_WMF wrote:

Do we need a production testing wiki? Wouldn't eg. officewiki suffice for most needs?

In any cases, abuse filters with zero hit will be safer to unsuppress.

Also we should allow unsuppressing individual abuse log, when an OS confirmes no PII is involved. This will neither affect the suppression status of filter nor will leak PII inside the filter.

A different approach to disallowing unsuppression would be to create a warning reminding oversighters that removing suppression also removes auto-suppression of all filter logs.

I believe warning is enough since suppression (of revisions) is reversable. As long as older abuse log are not unsuppressed automatically.

one could technically add a group which revokes all privileges associated with editor/autoreview

If we have a namespace for abuse filter, we can potentially also use it to store definitions of shared variables (T120740: Shared variables for AbuseFilter). In additional we may have "inactive filter" this is only called from another filter, otherwise called routines (T186960: Add subroutines to AbuseFilter).

Note: T249380: RfC: Per namespace view restrictions is not enough to address the abuse filter use case since now abuse filter can have different restriction flags (private, protected, suppressed, and soon checkuser).

Note: T249380: RfC: Per namespace view restrictions is not enough to address the abuse filter use case since now abuse filter can have different restriction flags (private, protected, suppressed, and soon checkuser).

Or some placeholder can be displayed for entries the user isn't allowed to see.

Another example is https://en.wikipedia.org/w/index.php?title=Special%3AAbuseLog&wpSearchUser=Popcountrysucks+Backup+4.0C - this page says 50 entries but only show 44.

See: https://www.mediawiki.org/wiki/Help:CirrusSearch#Deepcategory

In T410485#11527993, @Tgr wrote:

Alternatively, per T411441#11423029, maybe the ContactPage extension could incorporate this functionality.

Alternatively the old serviceops project can just be renamed so user will not be confused.

In T34815#11523778, @K6ka wrote:

I think this has been resolved now that T367329 has been implemented. All users can now use Special:GlobalVanishRequest to request vanishing, which when approved, renames the user to a randomly generated username and locks the account. It's as close as we can get to account deletion.

In T414301#11515070, @Pppery wrote:

We should also consider getting rid of this code at some point - it's been so many years since Graph was disabled ...

The text table is close to empty nowadays

Though this will eventually be a concern for 3rd users importing Wikipedia database dump. As it is mostly empty (and no core column refers old_id as number instead of as string), it should be easy to do a schema change in WMF production.

we did convert the most relevant fields to BIGINT

So what to do in immediate future is to convert any columns referencing such IDs.

This is because of T386978#10720296.

In T411794#11492830, @Ifrahkhanyaree_WMDE wrote:

Closing after MisterSynergy's comment, no further work needed here for now

One important point: after Mathoid is disabled in Wikimedia wikis, we need to retire the RestBase Mathoid endpoint (https://wikimedia.org/api/rest_); and we also need to retire the Mathoid MathML endpoint (https://mathoid-beta.wmflabs.org). Retiring these two endpoints will have an impact on 3rd party users using older MediaWiki versions, so we need to announce in advance.

In T273164#11498490, @bd808 wrote:

In T273164#11456523, @Bugreporter wrote:

• The page does not include 2FA requirements of any sort. We may want to codify it somewhere, and have some process to deal with legacy permission holders without 2FA.

Since there is currently no 2FA system in existence for Developer accounts generally and/or Gerrit specifically this seems like a non-issue?

See also: https://meta.wikimedia.org/wiki/Community_Wishlist/W451

To reduce security risk (of account compromise) we should also consider remove from acl*security_volunteer.

Note Code Stewardship Review is currently not a functional process.

This is not the correct way to request a Phabricator project in this case (as long as the tool is deployed at toolforge). Instead:

• Create a tool via https://toolsadmin.wikimedia.org/tools/create (if you need a new one)
• Create Phabricator project via https://toolsadmin.wikimedia.org/tools/id/<tool-id>

Please provide a link to local discussion.

$wgFixDoubleRedirects = true;

Before T17622: Create a user right to allow using redirect fixer (replacing $wgFixDoubleRedirects) is resolved, it is a concern that it can be abused by page-move vandals.

Unlike OS, CU feature is provided by an extension (though Checkusers in Wikimedia wikis also have abusefilter-privatedetails which is an AbuseFilter feature). In AbuseFilter extension we can not reuse rights defined in CheckUser extension. We need to define new ones (unlike OS level abusefilter).

In T365049#10399861, @matej_suchanek wrote:

It is worth mentioning revision (change) tags also stay forever. So purging logs wouldn't help if the filter also applies tags to matching edits.

This can already be done via https://github.com/WICG/scroll-to-text-fragment in newer browsers.

re-enabled a workboard which has only one column anyway

Workboard is a much simplier way to list open tasks and filter/sort tasks of a project (without a default limit of 100). I always find workboard useful.

I believe UserMerge is still commonly used in many third party individual (i.e. not farm) wikis.

In T91801#11473215, @Tgr wrote:

At a minimum, having the authorization form say "you have authorized this app in the past at <date>" would be nice.