@PerfektesChaos Thank you for filing this task! We are also very happy to read that German WP is generally pleased with the feature.

One question: For point #2, I'm not sure if I understand. Do you mean a preference to hide the new pop-up & display the old one, as we have discussed in T249259#6562737?

Overall, these are great suggestions, and they echo what we have heard from other people (i.e., an interest in more customization available via Preferences). While there are hacky solutions for some of these requests (such as, for point #3, choosing a custom number of watch days in the API Sandbox), none are actual user preferences. We probably do not have the resources or capacity to do this work now, but there may be opportunities for our team, another team, or volunteer developers to do such work in the future. In the meantime, we'll keep monitoring the feedback as we begin enabling the feature on more wikis. We'll also keep this ticket open, in case there is capacity for someone or a team to do such work in the future.

Thank you, and I look forward to your response regarding point #2!

On #2: Yes, somebody complained they were confused by the new widget and won’t use it ever. But they want to clean up the writing desk and do not want to change habits.

• It is not worth to introduce a preference on its own, but might be triggered by negative number of days.
• 0 does usually mean infinit or maximum or default.

For future developers I leave a Use Case:

• I am maintaining pages, but I am mostly not deeper involved.
• If nobody complains I want to get rid of that stuff.
• If somebody else is changing my operations I would like to watch this.
• After some days that page shall vanish from my watchlist.
• If I publish an edit and
  • the page has not been on my watchlist it shall be watched for my preferenced expiry period without touching the selection box,
  • otherwise the watchlist state should remain unchanged and/or the selection box should offer the individual state for this page.
  • I might want to select an individual option from the box at any time.
  • In Special:Preferences I want to set default behaviour to 11 days which defaults to infinit.

Thank you for this explanation, @PerfektesChaos!

Just want to complete #1: it would be nice to complete the following settings in “Watched pages” section with “for +duration drop-down”.

• Add pages and files I edit to my watchlist for [indefinite|1 week|1 month…]
• Add pages and files I move to my watchlist for [indefinite|1 week|1 month…]
• Add pages I create and files I upload to my watchlist for [indefinite|1 week|1 month…]

Meanwhile I discovered that apparently there is no memory?

• If I select a particular duration and ask for diff or preview during edit, it falls back to eternity. Seems to require to set interval on final Publish only.

A URL parameter would be nice, like &watchperiod= on action=edit.

If I select a particular duration and ask for diff or preview during edit, it falls back to eternity. Seems to require to set interval on final only.

That sounds like a bug! When previewing or viewing changes, the dropdown should remember whatever new value you've set it to. Is that not what you're seeing?

I return to initial state, usually eternity.

Apparently depending on browser.

• Firefox works as expected.
• IE10 has no memory.

I do use old browsers frequently to observe how things are working for people with not most recent equipment.

The wpWatchlistExpiry is bound to <select> but no <option> is present, since unspecific OOUI is used. When marshalling form input into HTTP POST, older systems may rely on traditional elements. Maybe a strategic OOUI problem, but a replacement by vue is envisoned anyway.

Personally I do not use this feature, since I have other (own) tools for dropping watched pages after a while. I just happened to observe this issue when I played to learn about new methodology.

Thanks for reporting this issue, @PerfektesChaos! When I tested on Brave/Chrome and Firefox, I wasn't able to reproduce the issue. However, as you report, it may be appearing on certain browsers, especially older browsers. I have created a separate ticket (T270197), so this issue can be tracked. Since it doesn't seem to happen on updated browsers, it's probably lower priority for us to fix now, but it's good for us to know & perhaps our team or a volunteer developer can fix it in the future. Thanks!

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