Page MenuHomePhabricator

Allow configurable default expiry time
Open, Needs TriagePublicFeature

Description

Background

Expiring-Watchlist-Items brought the ability to temporarily watch pages and files, instead of only having the option to watch indefinitely.

Repeatedly since that feature was deployed in 2020, users have asked for the ability to set default watchlist expiries, in particular for watching in general (via watch star) and when performing rollback.

Acceptance criteria

  • Special:Preferences (under "Watchlist") should have a "Default time period" dropdown for:
    • Manually watching (Default time period to watch a page that I manually add to my watchlist)
    • Add pages and files I edit to my watchlist
    • Add pages I create and files I upload to my watchlist
    • Add pages where I have performed a rollback to my watchlist
  • The preferred expiry should be pre-selected when:
    • Using the watch star (aka manually watching)
    • Editing a page (either wikitext or VisualEditor)
    • Using the action=watch page
  • If a page is already watched, we use the existing expiry and not the preference, even if the preference is longer.
  • Actions made through the Action API should also follow the same rules when the watchlist parameter is set with either preferences (default) or watch
    • If the watchlistexpiry parameter is used, that takes precedence over the preferred expiry
  • All of the above is true only if $wgWatchlistExpiry is also true.

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
TTO added a subscriber: TTO.

I proposed this in the Community-Wishlist-Survey-2022 and it only got 25 votes (#135 in the ranking), but I'm working on it myself nonetheless.

I'm only working on point 1 of the description. I'm not sure why anyone would want to hide the expiry dropdown, which is possibly what point 2 is asking for - it's unobtrusive and can simply be ignored if not wanted (besides, after more than a year, people are likely accustomed to it by now). Point 3 should be split off into its own task.

There are some complexities involved:

  • What to do if the user has set a preference to watch edited pages for (say) 1 week by default, and they edit a page that they are already watching indefinitely? Making the edit form have a 1 week watchlist expiry by default would be very impolite behaviour in this case, as it would go against the user's prior wishes to continue watching the page indefinitely.
    • The easy way out is to only select the user's preferred watchlist expiry in the edit form if the page is not already watched. Trouble is... if the watchlist expiry is about to expire in 5 minutes, the user will probably want to continue watching the page for another week after their edit.
    • The more complex but more correct way is to preselect the user's preferred watchlist expiry in the edit form only if it would result in page being watched for a longer period of time than currently.

I proposed this in the Community-Wishlist-Survey-2022 and it only got 25 votes (#135 in the ranking), but I'm working on it myself nonetheless.

Awesome! I know you can do it :)

I'm only working on point 1 of the description. I'm not sure why anyone would want to hide the expiry dropdown, which is possibly what point 2 is asking for - it's unobtrusive and can simply be ignored if not wanted (besides, after more than a year, people are likely accustomed to it by now). Point 3 should be split off into its own task.

I agree. There is CSS users can use to hide the expiry, if they really want to.

There are some complexities involved:

  • What to do if the user has set a preference to watch edited pages for (say) 1 week by default, and they edit a page that they are already watching indefinitely? Making the edit form have a 1 week watchlist expiry by default would be very impolite behaviour in this case, as it would go against the user's prior wishes to continue watching the page indefinitely.
    • The easy way out is to only select the user's preferred watchlist expiry in the edit form if the page is not already watched. Trouble is... if the watchlist expiry is about to expire in 5 minutes, the user will probably want to continue watching the page for another week after their edit.
    • The more complex but more correct way is to preselect the user's preferred watchlist expiry in the edit form only if it would result in page being watched for a longer period of time than currently.

The first approach is always a safe assumption, I think, but this is not necessarily true for the second approach. It might be an edge case, but if someone explicitly set a watchlist expiry on a page, it may be reasonable to assume they intended to unwatch it at that exact time. For example, say it's Today's Featured Article, which they only watch for 24 hours. They have the "Add pages where I have performed a rollback to my watchlist" preference set to watch for 24 hours. If they revert an edit at the 23rd hour, they probably don't care to watch for another 24 hours on that particular page. So all in all, in my opinion is approach #1 of only applying an expiry if one doesn't already exist seems the most logical. We can always ping voters in the survey for their input too, if that helps.

At any rate, we'll be around to assist with code review and coordination with the voters as needed. Thanks for taking this on!

The first approach is always a safe assumption, I think, but this is not necessarily true for the second approach. It might be an edge case, but if someone explicitly set a watchlist expiry on a page, it may be reasonable to assume they intended to unwatch it at that exact time. For example, say it's Today's Featured Article, which they only watch for 24 hours. They have the "Add pages where I have performed a rollback to my watchlist" preference set to watch for 24 hours. If they revert an edit at the 23rd hour, they probably don't care to watch for another 24 hours on that particular page. So all in all, in my opinion is approach #1 of only applying an expiry if one doesn't already exist seems the most logical.

I suppose I am erring on the side of keeping pages on people's watchlists, rather than leaving them to fall off the watchlist. When I wrote my comment above, I was standing in the shoes of a WikiGnome who wants to monitor for follow-ups to their drive-by edits. Such a user would in most cases want a minimum period of watching after each edit (and perhaps longer, such as for certain pages that they care about enough to watch indefinitely). On the oher hand, the TFA watcher is probably not going to be too upset about getting an extra day's worth of edits to the article on their watchlist.

From a technical standpoint it's easy to go either way though, so I'm not hugely fussed.

At any rate, we'll be around to assist with code review and coordination with the voters as needed. Thanks for taking this on!

Thanks for your offer of support, @MusikAnimal! Is #wikimedia-dev still the IRC channel of choice for MediaWiki development?

User request #1 is connected to preference watch every page I am editing.

This implies:

  • There has not been any watch mark yet.
  • If any, keep existing one.
  • If I decide to select infinit or 3 months I am free to do so manually.
  • If I am mainly maintaining RC in Huggle mode I might want every suspicious thing I reverted to be watched for 24 hours whether any complaints arrive, otherwise forget about it.
  • If I am editing real content the watching period shall be kept unchanged. If I am watching Village Pump infinitely this shall not stop after 1 day as soon I am answering a question there.

Thank you for implementation work.

I suppose I am erring on the side of keeping pages on people's watchlists, rather than leaving them to fall off the watchlist. When I wrote my comment above, I was standing in the shoes of a WikiGnome who wants to monitor for follow-ups to their drive-by edits. Such a user would in most cases want a minimum period of watching after each edit (and perhaps longer, such as for certain pages that they care about enough to watch indefinitely). On the oher hand, the TFA watcher is probably not going to be too upset about getting an extra day's worth of edits to the article on their watchlist.

From a technical standpoint it's easy to go either way though, so I'm not hugely fussed.

I have no strong feelings either, I just didn't want to make any assumptions. We can always change the logic in a follow-up patch, if need be.

Is #wikimedia-dev still the IRC channel of choice for MediaWiki development?

It's a bit noisy in there as it logs all Phab activity, but yes, that channel works. There's also #mediawiki-core and #mediawiki, though the latter I think is technically a sysadmin support channel. And finally, if you want to reach out to our team there's #wikimedia-commtech.

Just in case anyone is wondering, I have a completed patch for this, but I had serious issues running the EditPage tests locally, which meant I wasn't able to write any tests. I idled in some of the above mentioned IRC channels for a few days but spotted precisely 0 active humans in any of them, which didn't really make me feel very welcome. One day I might be able to return to it.

Have you published a WIP patch in Gerrit? You could then tag this task with Patch-Needs-Improvement and maybe Code-Health-Help-Wanted which may help you to receive support.

Change 789321 had a related patch set uploaded (by TTO; author: TTO):

[mediawiki/core@master] WIP on T265716 default watchlist expiry

https://gerrit.wikimedia.org/r/789321

Just in case anyone is wondering, I have a completed patch for this, but I had serious issues running the EditPage tests locally, which meant I wasn't able to write any tests. I idled in some of the above mentioned IRC channels for a few days but spotted precisely 0 active humans in any of them, which didn't really make me feel very welcome.

In my experience I've received great support in those IRC channels, #mediawiki in particular. I would make sure to ask your question, then give time for folks to reply. Many (most?) people there use bouncers so them being idle isn't indicative of the channel being unmonitored, rather their IRC client hasn't indicated any activity so they haven't visited the channel.

At any rate, CommTech can likely lend a helping hand here. I'll try to look at the patch soon, and will let the rest of the team know about it. Thanks for volunteering your time!

I had serious issues running the EditPage tests locally, which meant I wasn't able to write any tests.

I don't know if this helps or if you already tried it, but you can run specific tests rather than the whole suite, i.e. with php tests/phpunit/phpunit.php tests/phpunit/includes/EditPageTest.php --filter 'testMethodName'

Change 789321 had a related patch set uploaded (by MusikAnimal; author: TTO):

[mediawiki/core@master] [WIP] Allow configurable default watchlist expiry

https://gerrit.wikimedia.org/r/789321

A few notes from testing:

UI does not update correctly when I click the watch star

In Vector 2022 skin or legacy Vector:

  • Set expiry default of 1 month
  • Click the watch icon

Expected: half watch star
Actual: the icon updates to the full watch star rather than half watch star. I have to refresh the page to see the correct icon

Preferences control confusing

The list is quite large now and the labels are too generic. Could we perhaps make better use of sections or use more descriptive labels? For example, the last "Default time period" dropdown - it's not obvious if it applies to the line above or below.

BEFOREAFTER (suggested)
Screen Shot 2022-12-13 at 2.54.55 PM.png (410Γ—726 px, 48 KB)
Screen Shot 2022-12-13 at 2.57.03 PM.png (639Γ—699 px, 63 KB)

Thanks for the feedback, @Jdlrobson!

Preferences control confusing

What do you think about indenting the expiry dropdowns instead? Something like this:

Screenshot from 2022-12-14 17-38-39.png (504Γ—922 px, 68 KB)

That makes it more clear which field the "Default time period" is referring to, and keeps things looking concise. The only issue I see is seemingly this can only be done by hard-coding the width of a checkbox, which varies based on skin/browser. It will still be indented for everyone, it just may not look perfect, i.e. in Monobook:

Screenshot from 2022-12-14 17-42-15.png (109Γ—835 px, 12 KB)

How does that sound? It is a pity HTMLForm and/or Special:Preferences doesn't natively support this sort of indentation.

UI does not update correctly when I click the watch star

I'm working on a fix for this.

Indentation seems better (at least for now!).

@MusikAnimal Do you know if we will still want to keep this in "Needs Attention"?

@KSiebert @MusikAnimal I'd still really appreciate a look from CommTech - it really should not take an experienced MediaWiki developer more than a couple of hours, and will help tick off another Community Wishlist item.

My apologies for this taking so long… as I recall, it was more or less finished before I started to question some things architecturally, and then I simply ran out of time. I may be able to squeeze this into the Wikimedia Wishathon next week, or at least find someone to adopt it :) Someone asked about this missing feature over at WP:VPT on enwiki a few weeks back, so I feel motivated.

Sorry, I missed this at the time, can you advice someone on the team how to do it, as you are busy.

MusikAnimal renamed this task from Allow configurable default expiry time etc. to Allow configurable default expiry time.Dec 13 2023, 6:23 PM
MusikAnimal updated the task description. (Show Details)

From the sound of it, none of us here seem to have strong feelings, so I hope it's alright to stick to essentially:

  • if user is watching the page for the first time, defer to the preference
  • if user is already watching the page, respect the existing expiry – always

While sure, most wouldn't complain about watching for too long when all they had was "indefinite" before watchlist expiry came about. However, it just feels safe to me at least for this first iteration to refrain from any sort of auto-changes. There's little harm in shipping this as-is, and we can collect feedback and change the logic accordingly (PS18 for reference).

Outstanding issues as of the time of writing:

  • Watching via watch star doesn't use preferred expiry
    • This one is pretty tricky. In JS, we can get the preferred expiry but it is returned as a value acceptable only by strtotime(), which doesn't exist in JS. So we need to somehow run the user-preferred expiry through ExpiryDef::normalizeExpiry()
  • Action API doesn't respect user preferences
  • The patch doesn't add expiry preferences for file uploads, moving pages/files, and deleting pages/files. I'm going to save that for a follow-up patch, if there's demand for it.

I'm working on the above and hope to finish it this week (for MediaWiki CodeJam Dec 2023).

Will the changes cover calls by apps like AutoWikiBrowser, like when I set it to "Use MW preferences" for determining if a page I change is watched?

Also, I realize this isn't likely the best place to request this, but could we get a 3 day (72 hour) option for watches? A week seems too long for watches after casual edits.

Will the changes cover calls by apps like AutoWikiBrowser, like when I set it to "Use MW preferences" for determining if a page I change is watched?

AWB and other clients use the Action API, so unless something other than preferences (default) or watch is passed in the API call, or it passes in an explicit value for watchlistexpiry, it will go by the user preference.

Also, I realize this isn't likely the best place to request this, but could we get a 3 day (72 hour) option for watches? A week seems too long for watches after casual edits.

Seems reasonable, but does need a separate task/discussion. Note your wiki as a community can change the options now by editing MediaWiki:Watchlist-expiry-options (enwiki example).

Update: I was able to fix the watchstar sort of, but that code still needs to be cleaned up.

The bigger issues is adding support into the API. I'd rather not just "hack" it in there, so some refactoring will need to be done first. I'm going to do that as a separate patch.

TL;DR: I won't finish this this week as I had hoped. I very much underestimated the amount of work that there was left. But at any rate, I'm still committed and will be chipping away at this task until it's done! :)