Page MenuHomePhabricator

Have a way to exclude Tagged edits
Open, Needs TriagePublic


I know it has been decided not to have tags exclusion because "it is complicated" (probably because of T166618: Handle more than 500 tags per wiki?), but I'm creating that task to have clarifications about that. Also when the possibility to exclude some filters will be available, you can be sure users will ask to have it for everything. :)

Following this discussion, imagine if a wikis has 79 tags: you have to select 78 tags to display all tagged edits except ones filtered by a particular tag. This is not simple.

Another solution is to have a filter that would filter "all not tagged edits", so that people can select a little set of specific filters and add all others.

There is already a way to exclude Namespaces, which could be an inspiration. However, this system is binary: you can include namespaces OR exclude them, but it is not possible select some but exclude others.

Event Timeline

Due to the nature of tags, the exclusion mechanism becomes more complex. It may be not enough to decide whether to include or exclude all tags you selected but allow for combinations. That could be very powerful, but we need to think how to better support it.

For now we are already making it easy to add multiple tags and highlight them which is already an improvement with respect the previous state. Before starting work on this, I'd recommend learning more about how (and how much) tags are used in the new system.

New request made to have a simple way to exclude one massively used tag on Wikidata. I think the most common user case is to exclude one or two tags max.

Yes it is, good catch. I'm going to dupe this in the "wrong" direction because this task has more detail and more discussion.

As for the substance of this feature: we have an "invert" feature for namespaces already, so UI-wise it seems to me that we could apply the same concept to tags. Database-query-wise is would be pretty doable too. SELECT ... FROM recentchanges LEFT JOIN change_tag ON ct_rc_id=rc_id AND ct_tag='mobile edit' WHERE ct_id IS NULL ORDER BY rc_timestamp DESC LIMIT 50; executes quickly on enwiki, for example.

As for the substance of this feature: we have an "invert" feature for namespaces already, so UI-wise it seems to me that we could apply the same concept to tags.

We should be aware that the case of tags is a bit more complex, and a single "invert" switch provides only limited support in this case. Unlike namespaces (where a single contribution belongs to only one namespace), edits can have multiple tags. Filtering for contributions that have tag A but not B, won't be possible with a single "invert" control that affects all selected tags.

It can be argued than a basic support is better than no support at all. So we may want to support the general "invert" switch for tags which works when filtering for a single tag or when applying the same criteria to several. However, I think it would be important to know more about (a) how multiple tags are used currently (I was expecting the current OR-based combination not to be much useful), and (b) whether it is technically easy to support the exclusion of individual tags.

This feature is neccessary.

Mentionned in frwiki discussion!

it would be really useful to hide some semi-automated changes in the improved watchlist with the new filters for modifications.

Thank you.

(sorry for my bad english)

Thank you for updating the task, @Tractopelle-jaune (and your English is good!).

From the New Filters comment page, where users are suggesting an "invisible" highlight as the way to achieve this. I can't say I find this a suitable solution from a UX perspective, but there is one anon user's suggestion:

It seems the expected solution is letting perfect be the enemy of good. A hidden color is useful for many things aside from hiding tags. It could be used to further filter the visible results, rather than filtering the full entries that are retrieved from the database.

This would be a pretty cheap way of sub-filtering specific users, or indeed even filtering tags. For example, one could select all changes, then give a specific tag an invisible color. This would produce the same effect as the more complicated database filtering:

Basically, in pseudo-sql:

select * from change_tag, recentchanges
where ct_tag= "AWB"
AND (rc_id = ct_rc_id OR rc_timestamp < "12324555" )
ORDER BY rc_timestamp DESC
In fact this is partly possible by simply highlighting a tag without clicking its checkbox (to make it filter). Then all the user needs to do is change their CSS to hide the row, for color number 5 e.g.:

.mw-rcfilters-highlight-color-c5 { display:none;}
The drawback is that true filtering would actually allow the user to see more results, unlike this hacky solution.

New request to have tags excluded: "occasionally in my watchlist there will be an influx of AWB edits [...] I would like to be able to filter out edits with the AWB tag in order to see all other changes".

SBisson changed the subtype of this task from "Task" to "Feature Request".Oct 16 2018, 1:06 PM
SBisson changed the subtype of this task from "Feature Request" to "Task".Oct 16 2018, 6:41 PM

Perhaps just allow inverting the tag selection?

MMiller_WMF added a subscriber: MMiller_WMF.

@Trizek-WMF -- thank you for pointing out this new request. We have not yet started pursuing this feature, and the team has not discussed it in a while. I am moving it back to "Needs Discussion" so that we can do that.

@Trizek-WMF (and @Tractopelle-jaune) -- the team discussed this today, and we think that the solution proposed by @Catrope in T174349#3866824 could work. This would be adding an "Exclude selection" to the tag filter, like in the namespace filter:

It would be the quickest/easiest approach, but it has the downside that @Pginer-WMF mentioned in T174349#3866989, which is that edits can have multiple tags (as opposed to only having one namespace). Having an "exclude selected" filter would only allow users to select edits that have certain filters or exclude edits that have certain filters -- but not to include edits that have certain filters and lack certain other filters. Is that use case important? Or would looking at all edits except certain tags be sufficient?

@Trizek-WMF, perhaps you could ask the people who mentioned this issue on-wiki for their opinions?

@Trizek-WMF, perhaps you could ask the people who mentioned this issue on-wiki for their opinions?


Thanks everyone.

It's not totally clear to me which filters are inclusions or exclusions. If I want to see "Changes by others," that's an inclusive filter? But if I request *not* to see "Changes by you" that's exclusive? I imagine I could generate the effect of most of my inclusive filters by excluding the other options, then, no? If that's the case, I don't see this as a problem.

Spotted here: "The proposed solution is quite reasonable."

Spotted here: "The proposed solution is quite reasonable."

I second that IP's comment. The solution as explained by @Catrope seems perfectly adequate.

Thanks, all. Since it sounds like we have a reasonable solution, I'm going to put this in Upcoming Work for us to triage.

Would any work on this also solve T119072?

This task has been assigned to the same task owner for more than two years. Resetting task assignee due to inactivity, to decrease task cookie-licking and to get a slightly more realistic overview of plans. Please feel free to assign this task to yourself again if you still realistically work or plan to work on this task - it would be welcome!

For tips how to manage individual work in Phabricator (noisy notifications, lists of task, etc.), see for available options.
(For the records, two emails were sent to assignee addresses before resetting assignees. See T228575 for more info and for potential feedback. Thanks!)

Change 620512 had a related patch set uploaded (by Matěj Suchánek; owner: Matěj Suchánek):
[mediawiki/core@master] [changetags] Backend support for excluded tag filter

What is the status of this?

There is at the moment significant friction on Wikimedia Commons: as a new tool is getting some traction, some users have their watchlists filled up with tool-assisted edits, and get (understandably) increasingly annoyed about it (compounded by the fact that these are SDoC edits, which cannot be marked as minor, which could be a stop-gap workaround).

As the tool-assisted edits are tagged, the ability to filter them out would probably solve the issue for most users.

Any chance this can be looked into?

What is the status of this?

At the moment, there is no plan to work on this feature.

And we aren't only blocked by a technical issue here. I understand the need you raise as excluding a user (here a bot) from the list of recent changes. However, excluding users, or only filter edit for certain users may lead to a risk of stalking and harassement. As a consequence, working on this requires more people to be involved then just the Growth team devs.

I'll bring this topic to the next team coordination meeting.

Thanks for the answer @Trizek-WMF,

I understand the need you raise as excluding a user (here a bot) from the list of recent changes.

I think we misunderstood each other: what you describe is T209589/T167224 (which I am also interested in, but for a separate use-case).

The particular situation is the following: on Wikimedia Commons, the AC/DC gadget is a power tool to add StructuredDataOnCommons claims. The edits are made with the user account which uses the tool − not some bot/tool account. Over its lifespan, AC/DC has been used by 135 distinct users to made half a million edits (although 10% of its users are making 80% of the edits).

Some users are not interested in SDoC edits, do not wish to audit them and do not want to see them in their watchlist − and especially not when they feel flooded by these edits. By extension, they are not interested in edits made with the AC/DC tool and want to filter them out from their watchlists − regardless of who is making these edits. Filtering out edits tagged with AC/DC would be a possible solution for this problem.

I think we misunderstood each other: what you describe is T209589/T167224 (which I am also interested in, but for a separate use-case).

You are right, and I actually realized it when I turn my computer off after writing my reply. :/

I'll bring this topic of excluding tags to the next team coordination meeting. :)

The Growth team is going to expand, and we are considering to have this task as a first one for new hires.