In T265716#7726831, @TTO wrote:

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!

In T265716#7729403, @MusikAnimal wrote:

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.

In T265716#7731523, @TTO wrote:

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.

Good idea! I'll do that. Thanks.

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

In T265716#7898610, @TTO wrote:

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.

BEFORE	AFTER (suggested)

Thanks for the feedback, @Jdlrobson!

Preferences control confusing

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

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:

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.

nb. this missing feature was again brought up on wiktionary recently :-)

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.

In T265716#9404693, @Stevietheman wrote:

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! :)