Community Wishlist Survey 2019 Pt. 1

The Community Wishlist Survey 2019 is the annual edition of the “tell us what you want” festival organised by the Wikimedia Foundation.

The Wikimedia Foundation don’t do everything that has been asked for, but do some of the easier stuff if enough people support it.

Admins and stewards

Admins and stewards – 7 proposals

Create an integrated anti-spam/vandalism tool

Idea by Ajraddatz, create a better tool to combat spammers by combining “the functions of the spam and title blacklists, as well as limited abusefilter functionality, to better respond to ongoing spam and vandalism at the global/cross-wiki level”.

This idea is good with a low likelihood of implementation.

The main barrier to implementation is the difficulty of getting such a complicated tool created, there is no easy way to add anything to abusefilter without writing abusefilter code so that would have to be crafted. There is no easy way to add to the spam blacklist without doing complex regex so that would have to be crafted. Then because mistakes or human error could block editing on all Wikipedia’s globally, this needs some serious testing and will presumably be restricted to stewards and global sysops.

Feature parity for tools dealing with deleted revisions

Idea by MER-C, get all the normal Mediawiki search and special pages tools to work on deleted contributions. Basically to make it possible for an admin to work on deleted contributions as if they were live.

This idea is excellent with a high likelihood of (at least partial) implementation.

The good thing about this proposal is that it collects all the things that could improve the admin deletion interface in one place. Most of the issues already have phabricator tickets. The developer can work on this in manageable chunks on already defined and known tasks. Ideally all wishlist proposals would be organized this way.

The main foreseeable difficulty is in creating the search table needed for searching deleted contributions without it becoming easily accessible to everyone via the API.

In case it isn’t clear why I am particularly excited by this, note that these changes apply to the Mediawiki core and would greatly improve my admin workflow on all wikis.

Add Admin functionality to mobile sites

Idea by Ninovolador, to add admin tool options to the mobile skin.

There is already a mobile compatible skin called “Timeless” which allows for this. Therefore, this idea is already done as Timeless is enabled on all Wikipedia sites already.

Throttled page protection

Idea by Jayron32, the idea is not well defined, but seems to be a logically unlikely type of page protection. However the gist is that spammer IP’s would not be able to spam the help desk and legitimate IP’s would be.

This will be achieved by only allowing an IP to edit the help desk once every few minutes, a spammer will then have to cycle to a new IP to spam, making it harder to do a “DDOS” type attack.

This idea is okay with a low likelihood of implementation.

Unfortunately the idea is not well explained and is difficult to decipher, it is unlikely that it will generate sufficient support to get anywhere. Although if it were, to add this kind of functionality is easy enough. A similar function already exists on RationalWiki.

Overhaul spam-blacklist

Idea by Dirk Beetstra, to replace the current highly archaic spam-blacklist with something like the abusefilter extension. Dirk describes it as a “specialised form of the AbuseFilter that only matches regexes against added external links”.

This idea is good with a high likelihood of implementation.

The idea already has a phabricator task and a detailed technical description of the proposed changes. This of course makes it more likely to happen and is a great thing to make the proposal more realistic to the developers.

Overall the idea is very good, it is also expected to solve the issue which makes it very easy to bypass the spam filter with funny unicode character hacks.

Make undeletion page ID sensitive

Idea by GeoffreyT2000, focused on a virtually incomprehensible process where the revision history of a page is split or merged into other pages. This process is currently badly organised and Geoffrey proposes a number of fully explained improvements which will deal with this.

This idea is good with a low likelihood of implementation.

Unfortunately it takes half an hour just to understand what Geoffrey is talking about, here is a short extract;

We would then have a “pagearchive” table with columns named “pa_id”, “pa_namespace”, “pa_title”, “pa_page_id”, and “pa_rev_count”, and the archive table would have a new column named “ar_pa_id”. Also, a script that migrates the “ar_namespace”, “ar_title”, and “ar_page_id” columns to the new table would then be created. Then another script would be created that would de-duplicate page IDs in the pagearchive table, and also de-duplicate those that duplicate the ID of existing pages or an existing rev_page field. Finally, one more script would be created that would populate missing pa_page_id fields that previously corresponded to missing ar_page_id fields.

The high probability of  Mer-C’s idea being implemented means that this mutually exclusive plan has very little chance of success. Maybe the concept can go back to the drawing board and come up with something that is actually compatible.

Monitoring of new external links

Idea by Amir, to only allow whitelisted external links.

This idea is good with a low likelihood of implementation.

Despite how this would drastically stop spam, I can’t see anyone being bothered. Of course if it was implemented maybe only extended confirmed users should be able to add links to the whitelist and maybe there would be new link patrol. So the idea needs some expansion.


Photo credit Betty Wills/Wikimedia

One comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.