Sebastian wrote:

I don't think it would be a good to use time since message as a cutoff criterion, because there are huge differences in how long it takes for people to reply. Some editors log in only casually, and such a setting would lose their replies.

Instead, I think it would make sense to use a criterion like "5 days after recipient_reply", where "recipient_reply" would be technically defined like this: Let Senderi be the user whose settings we're talking about. Sender left a message on [[User talk:Recipient]]. Then "recipient_reply" is the first edit by Recipient on [[User talk:Recipient]].

Changed component to "Watchlist"

• Bug 18644 has been marked as a duplicate of this bug. ***

Adding the word "expiry" to summary for better searching.

ramwikimedia wrote:

*** Bug 48879 has been marked as a duplicate of this bug. ***

I wonder if it makes sense to add a generic field to the watchlist table for metadata, allowing each watched title to have associated data.

This metadata field could have a number of purposes:

• a user script could be employed to track when pages were added to the watchlist

• users could add annotations to specific entries to remember why they watched a particular page title

• users could tag certain entries with keywords and a user script would allow filtering the watchlist entries by particular tags/keywords

The UI exposure would be minimal (or non-existent), but user scripts or extensions could use this field as they wanted. Hmmm.

(In reply to MZMcBride from comment #6)

I wonder if it makes sense to add a generic field to the watchlist table for
metadata, allowing each watched title to have associated data.

This metadata field could have a number of purposes:

• a user script could be employed to track when pages were added to the

watchlist

• users could add annotations to specific entries to remember why they

watched a particular page title

• users could tag certain entries with keywords and a user script would

allow filtering the watchlist entries by particular tags/keywords

The UI exposure would be minimal (or non-existent), but user scripts or
extensions could use this field as they wanted. Hmmm.

+1
This is a great idea.

Community-Tech is investigating this so marking as external. It's not something Growth-Team could work on in the short-to-medium term anyhow.

@ifried should this be closed as already implemented?