Talk:Edit Review Improvements/New filters for edit review

Jump to: navigation, search

About this board

Leave your thoughts and ideas here about the New Filters for Edit Review filtering tools and interface. These are now standard on Recent Changes and available as a beta feature on Watchlist. What works well? What could work better?

Leave feedback in any language.

How to provide feedback

  • do you have that bug when you are not logged-in?
  • explain how to reproduce the bug (step by step)
  • tell us what is your configuration (browser version)
  • say on what page it is happening -Recent Changes, Watchlist...)

Also see the FAQ. الصورة (talkcontribs)

Hello! The new filters (or the new review of the old filters) are making the history pages more simply and beautiful, and thanks for it. But there is one problem that making it doesn't worth. I don't know why, maybe because it doesn't using more the URL to move between filters, but when I get to the URL that saved in my favorites I can't see results until I tap the button to back to the default filters... It's not fun and I hope you understood and will fix this annoying bug. Thank you.

Trizek (WMF) (talkcontribs)

Thank you for your appreciation.

I'm sorry you have this issue. Can you share a lonk you want to copy/paste, and tell me which browser you use? Thanks!

This comment was hidden by Trizek (WMF) (history)
This comment was hidden by Trizek (WMF) (history)
Reply to "URL"
PriceDL (talkcontribs)

I have attempted to make my default filter the default settings with the addition of excluding the Wikipedia namespace. The :not appears not to save and instead it includes only pages in the Wikipedia namespace.

Wargo (talkcontribs)

This bug was resolved. You need to create set again.

This comment was hidden by PriceDL (history)
Reply to "hi all..."
C933103 (talkcontribs)

I tried using this tool in Incubator and I encountered two major problem:

1. I cannot filer and see a recent change for a specific sub wiki which was posssible before

2. Even after I disabled the function in the "test" tab, I cannot get the original recent changes back.

Please fix it.

Zilant17 (talkcontribs)

@C933103 Thanks for reporting it - the issue is confirmed and will be triaged.

Etonkovidova (talkcontribs)

1. After re-checking T184214 and talking to @Mattflaschen, it seems that filters for a specific subwiki on Recent changes work as expected. Two search criteria should be entered:the type of wiki and the wiki abbreviation, e.g. 'Wikipedia' and 'mns'.

2. To opt out from Recent Changes new filters, Preferences-Recent changes 'Hide the improved version of Recent Changes' option is used. I checked it specifically for and it works.

@C933103 If you still are having some issues with RC filters, you may add your comments here or directly on the task T184214

C933103 (talkcontribs)

@Etonkovidova Is the checkbox on preferences - recent changes differentfrom the one in preferences - test function? If the checkbox for the function is already in other section of the setting then why there is still this enhanced edit review view in the beta test function page?

Etonkovidova (talkcontribs)

@C933103 Preferences-Recent changes 'Hide the improved version of Recent Changes' option controls Recent changes page. Preferences-Beta features-New filters for edit review controls Watchlist page. The description for the beta feature needs to be updated since it refers to both pages, "Review edits on Recent Changes and Watchlist ... ".

C933103 (talkcontribs)

Can someone help explains to me that what is the difference between "improved version recent changes" and "new filter for edit review"?

Trizek (WMF) (talkcontribs)

@C933103, that's quite the same thing.

  • "improved version recent changes" refers to Specal:RecentChanges with the new filters
  • "new filter for edit review" is a global project name that includes Specal:RecentChanges with the filters, but also Specal:RecentChangesLinked with the filters, Watchlist with the filters (as a Beta feature now)...
Reply to "Problem in Incubator"
Helmoony (talkcontribs)

Hi, is it possible to add a filter for edits made with AutoWikiBrowser ( ? At least in Arabic Wikipedia where we are facing many edits made by that tool (human or bot accounte) that invade recent changes watchlist. A diiscussion in ongoing about fixing a average of edits per minute BUT if you are able to fix that by allowing hiding those edits, the problem would be fixed.

Trizek (WMF) (talkcontribs)


You can locally create a tag for all edits made with AWB. You will be then able to filter tags.

Helmoony (talkcontribs)

Hi Trizek, that can fix our problem of recurent use of AWB. Is it possible to create that tag for Arabic projects (wikinews, wikisource, wikiquotes, wikiversity, wikibooks and, the most important, wikipedia). (talkcontribs)


Trizek (WMF) (talkcontribs)

There is a feature request to tag all AWB edits, but it is lacking of a person to handle it. :/

Helmoony (talkcontribs)

Thank you. The task is waiting for someone since 2015!

Trizek (WMF) (talkcontribs)

Like many. We are looking for volunteer developers (and try to do our best to ease their first steps).

Reply to "AWB filter"
טוסברהינדי (talkcontribs)

Will be great if I could maintain a few watch lists. E.g. one general, and one with only "my" articles (i.e. articles I created). Any chance you can add a filter to include only "specifically tagged" articles, so I can maintain a sub-list by tagging specific articles from my watch list?

Trizek (WMF) (talkcontribs)

I've documented your idea to keep a track of it. That idea is a good way to create multiple watchlists by bookmarking what you would have tagged yourself.

טוסברהינדי (talkcontribs)

Exactly! :)

This comment was hidden by (history)
טוסברהינדי (talkcontribs)

Not sure we need to tag a specific edit... We just need to be able to tag pages in the list (e.g. "I created", "general watch", "music", etc.)

This comment was hidden by 2405:204:3118:364D:143F:593B:299B:BAB5 (history)
Reply to "Multiple lists"
Marek2005 (talkcontribs)

Mediaiki is very good.

Suggestion: Make longer titles in related changes readable

3 (talkcontribs)


It is impossible to read the actual page name with very long page titles because it is limited by the input box size.

Steps to reproduce

  1. Go to
  2. Look at the input box


Whole title is visible or there is a visible way of seeing more content


Part of the title is hidden. The user needs to know that they can use the cursor to see more

Possible solution

  1. Make the input box as large as long as the page width (or close to that). Subpages can considerably increase the maximum page title.
  2. Make the dropdown as larger.
  3. Add a tooltip that shows the full page title when hovering over the input box
JMatazzoni (WMF) (talkcontribs)

Thanks for this suggestion. I've moved your idea to a task.

JMatazzoni (WMF) (talkcontribs)

This has been fixed on beta already. You should see it live on wikis next week.

The Polish (talkcontribs)

Is possible to hide flood edits on Special:RecentChanges? The Human (not bot) filter doesn't work and flood edits are visible. (talkcontribs)

You'll have to define "flood". If you mean the flooder user group, then theoretically it would only work if "bot" (automated edits) is unchecked. If you mean detecting floods on the fly, then that is a complicated situation, but the primary fix would be to reduce the general editing rates of all accounts to reasonable limits (high rate editing means high rate mistakes, and server load) , see:

After sane limits are added, there are two ways the rest could be addressed with filters. Server side filtering, e.g. mark all revisions in which the editor exceeds a specific rate (possibly not technically feasible). Client side filtering, after all edits are fetched it is quite easy to show or hide visible results using javascript, e.g. calculate and hide revisions from editors with more than X visible edits. (talkcontribs)

It is odd though, some bots still appear in recent changes even if "human" is selected. My guess is that these accounts are making edits without using their bot flag (see Manual:Bots#The_.22bot.22_flag).

This makes sense to an extent because admins may give themselves the bot user right, but only use it when needed, and their actions shouldn't all be hidden from recent changes. Also, an account may do an action using the bot right, and then later on within the same day have those rights removed. So only actions related to bot activities should be hidden while allowing other actions to be seen.

A reasonable solution to this issue is adding a new filter that makes it possible to hide all edits by users currently with a bot right. This will contain false positives though.

Trizek (WMF) (talkcontribs)

Massive edits made by users who don't have the bot flag will not be filters as bots, indeed. The community have to be firm about that: massive edits = bot flag. (talkcontribs)
 The community have to be firm about that: massive edits = bot flag.

That's the source of the problem. Registered users === bots (in terms of editing rate). They can essentially edit freely without limits and may causes server problems, as the linked task shows. In other words, aside from bureaucracy (and some api specific actions) no registered user really needs bot rights.

There isn't a really good way to be firm because of that. That configuration change ( should be part of edit review improvements. Simply put high edit rates === increased number of errors === high burden for editors === unreadable recent changes === higher rates of spam. Just look at recent changes in wikidata (e.g. #quickstatements tag), massive number of people editing in a bot like manner, obliviously introducing many errors and treating a database system like an article.

No human can operate above a certain rate without making many more errors (see Diminishing_returns). Developers and the so-called communities are just fooling themselves if they think otherwise. (talkcontribs)

Recent Change list should load more items after it filters out items

Reply to "Flood edits"

Suggestion: Highlight recent changes item on hover

Summary by Trizek (WMF) (talkcontribs)


As a user, I can't easily determine the beginning and end of a recent change item .

Proposed solution

Add css to highlight the specific line on mouse hover, e.g.:

.mw-changeslist-line:hover {
    background: lightgray;
Trizek (WMF) (talkcontribs)
As a user, I can't easily determine the beginning and end of a recent change item .

You mean lines are hard to read? If yes, that's a more global issue, shared with History pages, Watchlist... (talkcontribs)

They are hard to read but the primary issue here is that one often has to struggle to see where the entry ends when there are a lot of very verbose changes. The idea here is that hovering would show the whole entry, much like when one clicks a reference, and it shows the whole line rather than just scroll to the position where the reference is defined.

Fixing the "global issue" (aka Topic:Tq8rhckxxt3ol1sl) is a bigger project. It could probably be greatly improved by just reducing redundant links or putting them into a dropdown. Getting people to accept that fix is the hard part.

This change on the other hand is pretty straight forward.

Trizek (WMF) (talkcontribs)

I've reported the highlight idea, which may be indeed a nice first step to improve those hard to read pages.

For the more global improvements, there is some thoughts here and there but no formal plan.

This comment was hidden by (history)
Reply to "Suggestion: Highlight recent changes item on hover"

Perhaps exclude "Likely bad faith" and "Very likely bad faith" results from being listed as "Most likely good" edits

2001:A61:370B:2E01:B514:F2DE:9FAC:EF30 (talkcontribs)

Most of these were not good, such as:

Trizek (WMF) (talkcontribs)

The filters are predictions, so you may have false positive (check the diagram on that page).

How many changes have you reviewed to get those two edits?

JMatazzoni (WMF) (talkcontribs)

Hi, unsigned user. Thanks for asking about these filters. If you want to exclude most or all of the bad results from your "Very likely good" searches, you can achieve that I think by also selecting the "Very likely good faith" filter. This way, you'll get only those results that are both good and good faith. Like so:

If you want to refine your prediction even more, set some highlights (without checking the boxes to activate the filters) for "May have problems" and "May be bad faith." That will let you visually pick out the edits that are more doubtful. Like so:

As Trizek says, the "User Intent" and "Edit Quality" filters produce probabilistic predictions. Meaning they're not always right, but the likelihood is good. For both Very Likely good" and "Very likely good faith," the false positives should be pretty infrequent—one or two % according to tests. But we'll be very interested in hearing more about your experiences—let us know if these filters are working for you, and whether those tips help.

Reply to "Perhaps exclude "Likely bad faith" and "Very likely bad faith" results from being listed as "Most likely good" edits"