Page MenuHomePhabricator

Allow configurable default expiry time etc.
Open, Needs TriagePublicFeature

Description

German WP users seem to be quite happy with this feature. However, three suggestions came up:

  1. Provide a Special:Preferences field for a particular default span. Rather than infinit it might be wanted to ask for 1week if somebody is making almost only maintenance edits, and wants articles to vanish if nobody argued within one week. Then it could be avoided to open the fly-out and choose an option with every edit.
  2. Provide Special:Preferences switch if new switch shall not appear (may be solved by personal CSS display:none for more experienced users as first aid). Might be -1 in suggestion #1.
  3. Provide customized periods; either by editing arbitrary number of days and requesting 40 days in suggestion #1, or extend drop box by input field for number of days.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Aklapper renamed this task from FEATURE REQUEST: Configurable default expiry time etc. to Allow configurable default expiry time etc..Oct 16 2020, 1:28 PM
Aklapper changed the subtype of this task from "Task" to "Feature Request".

@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.

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

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!

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