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