@aaron, @Krinkle: Can we use the stash cache for storing the half-parsed wikitext of references (for the duration of the parser cache)? (see https://gerrit.wikimedia.org/r/#/c/277445/13)

Strip markers would remain in the half parsed text but would be explained in the API:

I've made an attempt to refactor EditPage in https://gerrit.wikimedia.org/r/#/c/338276/.
This goes a bit beyond factoring out a backend as I've also rewritten the UI part based on an MVC pattern.

Yes, I'll merge it.

In T157715#3044879, @jmatazzoni wrote:

As part of our RC Page Improvements, we are implementing:

• A filter for patrolled/unpatrolled
• Various ORES filters that will enable users to find the edits that are most in need of review.
• User-defined highlighting as an alternative to or in addition to filtering, so users can decide which edit properties they want to spotlight.

Using these tools, which will be out this spring, users can easily find edits that are likely damaging and unpatrolled. (See this video for a demonstration of the tools generally.)

This sounds promising, though I'd still like a way to integrate other sources than ORES, such as AbuseFilter and bots.

In T156083#3002405, @Pginer-WMF wrote:

There are several points in the process where knowing that your edit is pending review seems relevant. Ideally it would be great to be able to tell editors of issues on their edits as the users makes them, or as soon as they try to save.

In case of abuse filter deferral, I've made so that the user is shown a notice after saving the page:

Notifications can work well to inform of the deferral event right when it happens. This approach is consistent on how we inform about related events such as edits being reverted. For the case of anonymous users, we may want to inform that those notifications may be because of activity from a different user:

I've added a warning about that, see image below. I've put it at the bottom to avoid being too obtrusive to experienced IPs and in light yellow from the color palette to differentiate it from other notifications.

Hm yeah, but the special page would be hard to implement compared to just adding some options.

Not just moves accross namespaces are an issue, see this recent discussion.
I think we need something like Special:NewMoves and move patrol (T98617).

Inclumedia seems to be dead, and the project's initiator is globally locked. As such I am closing this task. If however, someone still finds a convincing use for it, feel free to reopen it.

Inclumedia seems to be dead, and the project's initiator is globally locked. As such I am closing this task. If however, someone still finds a convincing use for it, feel free to reopen it.

Inclumedia seems to be dead, and the project's initiator is globally locked. As such I am closing this task. If however, someone still finds a convincing use for it, feel free to reopen it.

Inclumedia seem to be dead, and the project's initiator is globally locked. As such I am closing this task. If however, someone still finds a convincing use for it, feel free to reopen it.

Mirror tools / inclumedia seem to be dead, and the project's initiator is globally locked. As such I am closing this task. If however, someone still find a convincing use for it, feel free to reopen it.

Mirror tools / inclumedia seem to be dead, and the project's initiator is globally locked. As such I am closing this task. If however, someone still find a convincing use for it, feel free to reopen it.

Mirror tools / inclumedia seem to be dead, and the project's initiator is globally locked. As such I am closing this task. If however, someone still find a convincing use for it, feel free to reopen it.

Looks like this is broken since January 31, see here.

I tried to load Special:Tags at Wikidata. After waiting almost 25 minutes, this is what I got: 504 Gateway Time-out nginx/1.11.6.

I think we absolutely need a form of patrol intermediary between NPP and RCP.
But tags can't be the solution, though they may be part of the solution.
We should check if an edit is worth being shown as needing patrol from a variety of sources, including: problem tags (as this task suggested) , but also ORES and AbuseFilter, and bots via the API.
Problem is how do we store this data? It would be nice for the patrol flag to have three states: -1 for "needs patrol", 0 for "not patrolled", +1 for "patrolled". Unfortunately, rc_patrolled is unsigned in the rc table, so we would need a schema change.
I'll make a task for selective patrol in a short while.

Low if this were only that, but I've addressed some related issues in the patch set, the code needed some refactoring.

@Aklapper Ok, thanks for the heads-up. I'm not sure yet if I'll rewrite the task description or simply make a patch myself.

A Revert object is a good idea, I think I'll implement this in a new version of https://gerrit.wikimedia.org/r/#/c/329651/.
This should be kept separate from the Revision object though, a revision shouldn't be aware of the Revert object, a Revision object is standalone and shouldn't depend on the page history (revisions can be moved around for instance). So I don't think we should have a method on Revision to indicate if it's a revert, but the goals underlying this task can be accomplished without.

I've done the edit, thanks for checking the tags.

This would be helpful for contributions, we don't have any built-in way to check non-redirect page creations by a user.
I'm not saying this would replace a log, but this would be easier to implement.

I could easily add a page creation tag as part of https://gerrit.wikimedia.org/r/#/c/194458/ (for T73236).

Isn't this resolved by the confirmed usergroup?

They both would make it unnecessary for extensions to set ConfigRegistry, but T155154 suggests a GlobalVarConfig object while this one suggests a new LocalConfig object (see https://gerrit.wikimedia.org/r/#/c/335383/5/includes/config/LocalConfig.php) that would be based only on the extension's own settings and handle merging with local settings. Eventually, this aims to deprecate GlobalVarConfig, and do the same thing for core (achieving a separation of configs and the removal of configuration globals).

I've done this in https://gerrit.wikimedia.org/r/#/c/335383/ as part of T156877.

Yes, it works. Thanks

It takes several minutes to load Special:Tags at wikidata, the way we're retrieving hitcounts is not efficient or sustainable.
It's also a concern for the dropdown (T27909) on cache misses.
My suggestion, implemented in the above patch set, is to create a table holding tag hitcounts, updated when adding/removing tags.

I've looked into this and the titleblacklist log entry will only appear at the wiki where the user created the account, not on the central loginwiki.
It certainly would be appreciable to have a centralized log of titleblacklist hits (same for spamblacklist) but it doesn't look easy to accomplish.

Regarding the feasibility of anon notifications (T58828), I had made a rough patch that didn't alter the db and was mostly OK for the purpose of deferred changes, so it can be done without hassle. But we might as well provide full support for anon notifications while we're at it; the implementation is relatively straightforward, I've updated the patch (https://gerrit.wikimedia.org/r/#/c/329374). We just need to make sure that the changes in the db schema are OK.

Assuming we can alter the db, I've modified the patch set to offer the same level of functionality than notifications for logged in users. They can be marked read / unread and filtered by titles, and cross wiki notifications are possible. The last one requires caching the IP address in a global key.