Change Details

This is a request for comments regarding implementing expiring watchlist entries in Mediawiki. **Background** This feature request features on both the German Technical wishlist from 2014 and the WMF Community Tech team wishlist at position #12 for 2015. A bug has existed for this feature since 2006 T8964. WMF Community Wishlist proposal and votes: https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Watchlists#Watchlist_timed_expiry **Proposal** It should be possible to watch a page and have it be removed from your watchlist after a custom timeframe. Users should initially be able to change the expiry time of a watchlist entry using the API. Users should also be able to set a number of days for how long a page should be watched or make watchlist entries never expire on the Special:EditWatchlist page. The initial implementation would not include any changes to watching a page directly from an article page (i.e. clicking the star button on the toolbar). All entries added to the watchlist by clicking the star button would still initially have an unlimited expiry date. The feature would be first offered as a beta feature. The initial proposal is to add a single new field to the watchlist table containing an expiry timestamp. All selects on the watchlist table would be updated to only select watchlist entries that have not yet expired. Users would be able to set an expiry when watching a page using action=watch specifying a parsable expiry (similar to protection expiry through the API) The initial implementation would also have a maintenance script to remove expired entries **//Backend Refactoring//** The WatchedItem class currently contains methods such as doDuplicateEntries, duplicateEntries, removeWatch, addWatch, batchAddWatch, resetNotificationTimestamp & load all of which do not belong in this class. They should be moved to a WatchedItemStore or something similar. Looking at usage of these methods if they were moved the only extension that would need updating would be Flow which uses the duplicateEntries, removeWatch & addWatch methods in production code and tests. Methods could then be added to this store such as loadWatchedItemsForUser, loadUnwatchedItems and perhaps loadUsersWatchingPage which would remove the spread of SQL that would need to be touched by this proposal. The SQL that would need to change is currently distributed through the following classes: InfoAction, ApiQueryInfo, ApiQueryUserInfo, ApiQueryWatchlist, ApiQueryWatchlistRaw, EmailNotification, SpecialEditWatchlist, SpecialRecentchanges, SpecialRecentchangeslinked, SpecialUnwatchedpages, SpecialWatchlist. **Applications / User stories** Expiring watchlist entries could be useful for the following reasons: * Watch a talk page of a user that you message for a response for a limited time * Watch a page for a specified amount of time after a page protection expires * Watch a page for a short amount of time after reverting vandalism on the page. * Watch a time boxed discussion page for the length of the timebox **Considerations** * It might make sense to refactor access to watchlist items before or potentially after trying to implement this with the goal of having a single location that makes calls to the watchlist table (currently queries are spread between multiple locations) * The expiry field of the watchlist table may need an index * As mentioned in T8964 to cover further expansion to the watchlist table a more general properties field may be preferable, although this would likely mean selecting non expired watchlist items would be harder * It might make sense to also allow adjusting the expiry date of watchlist entry in the raw watchlist editing mode (Special:EditWatchlist/raw). One possible way to do this would be expanding the raw watchlist format so that each row could also include a number of days to watch the page. Such a change should be backwards-compatible so that importing and exporting of already existing watchlist would not require any actions from the user. **Key Questions** * Should the expiry date be its own field or should a properties field be introduced? * Is a more automatic way of keeping the watchlist table clean needed or will a maintenance script do? * Will indexes be needed on the expiry column in order for this to scale? * Should the refactoring talked about actually happen and if so should it happen before or after the changes? * Should custom expiry date be considered in the import/export process using Special:EditWatchlist/raw), or should all imported and exported watchlist entries always have unlimited watching duration? **See also** * Current Phabricator task - T100508 * Oldest Phabricator task (2006) - T8964 * Gerrit patch with rough implementation - https://gerrit.wikimedia.org/r/#/c/245881/ * Gerrit patch with some rough re factoring - https://gerrit.wikimedia.org/r/#/c/267259/ **After initial implementation** * Api modules that output info about watched items such as ApiQueryInfo, ApiQueryWatchlist & ApiQueryWatchlistRaw should display watchlist entry expiry times * Some sort of automatic removal of expired items may be desired

* Affected components: MediaWiki core (Watchlists). * Engineer for initial implementation: Community Tech team (WMF). * Code steward: TBD. ### Motivation **Background** This feature request features on both the German Technical wishlist from 2014 and the WMF Community Tech team wishlist at position #12 for 2015. A bug has existed for this feature since 2006 T8964. WMF Community Wishlist proposal and votes: https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Watchlists#Watchlist_timed_expiry ##### Requirements Expiring watchlist entries would be useful for the following reasons: * Watch a talk page of a user that you message for a response for a limited time. * Watch a page for a specified amount of time after a page protection expires. * Watch a page for a short amount of time after reverting vandalism on the page. * Watch a time boxed discussion page for the length of the timebox. ------- ### Exploration //(Use this space for data gathering, status quo, proposals, other considerations etc.)// **Proposal** It should be possible to watch a page and have it be removed from your watchlist after a custom timeframe. Users should initially be able to change the expiry time of a watchlist entry using the API. Users should also be able to set a number of days for how long a page should be watched or make watchlist entries never expire on the Special:EditWatchlist page. The initial implementation would not include any changes to watching a page directly from an article page (i.e. clicking the star button on the toolbar). All entries added to the watchlist by clicking the star button would still initially have an unlimited expiry date. The feature would be first offered as a beta feature. The initial proposal is to add a single new field to the watchlist table containing an expiry timestamp. All selects on the watchlist table would be updated to only select watchlist entries that have not yet expired. Users would be able to set an expiry when watching a page using action=watch specifying a parsable expiry (similar to protection expiry through the API) The initial implementation would also have a maintenance script to remove expired entries **//Backend Refactoring//** The WatchedItem class currently contains methods such as doDuplicateEntries, duplicateEntries, removeWatch, addWatch, batchAddWatch, resetNotificationTimestamp & load all of which do not belong in this class. They should be moved to a WatchedItemStore or something similar. Looking at usage of these methods if they were moved the only extension that would need updating would be Flow which uses the duplicateEntries, removeWatch & addWatch methods in production code and tests. Methods could then be added to this store such as loadWatchedItemsForUser, loadUnwatchedItems and perhaps loadUsersWatchingPage which would remove the spread of SQL that would need to be touched by this proposal. The SQL that would need to change is currently distributed through the following classes: InfoAction, ApiQueryInfo, ApiQueryUserInfo, ApiQueryWatchlist, ApiQueryWatchlistRaw, EmailNotification, SpecialEditWatchlist, SpecialRecentchanges, SpecialRecentchangeslinked, SpecialUnwatchedpages, SpecialWatchlist. **Considerations** * It might make sense to refactor access to watchlist items before or potentially after trying to implement this with the goal of having a single location that makes calls to the watchlist table (currently queries are spread between multiple locations) * The expiry field of the watchlist table may need an index * As mentioned in T8964 to cover further expansion to the watchlist table a more general properties field may be preferable, although this would likely mean selecting non expired watchlist items would be harder * It might make sense to also allow adjusting the expiry date of watchlist entry in the raw watchlist editing mode (Special:EditWatchlist/raw). One possible way to do this would be expanding the raw watchlist format so that each row could also include a number of days to watch the page. Such a change should be backwards-compatible so that importing and exporting of already existing watchlist would not require any actions from the user. **Key Questions** * Should the expiry date be its own field or should a properties field be introduced? * Is a more automatic way of keeping the watchlist table clean needed or will a maintenance script do? * Will indexes be needed on the expiry column in order for this to scale? * Should the refactoring talked about actually happen and if so should it happen before or after the changes? * Should custom expiry date be considered in the import/export process using Special:EditWatchlist/raw), or should all imported and exported watchlist entries always have unlimited watching duration? **See also** * Current Phabricator task - T100508 * Oldest Phabricator task (2006) - T8964 * Gerrit patch with rough implementation - https://gerrit.wikimedia.org/r/#/c/245881/ * Gerrit patch with some rough re factoring - https://gerrit.wikimedia.org/r/#/c/267259/ **After initial implementation** * Api modules that output info about watched items such as ApiQueryInfo, ApiQueryWatchlist & ApiQueryWatchlistRaw should display watchlist entry expiry times * Some sort of automatic removal of expired items may be desired

This is a request for comments regarding implementing expiring watchlist entries in Mediawiki* Affected components: MediaWiki core (Watchlists). * Engineer for initial implementation: Community Tech team (WMF). * Code steward: TBD. ### Motivation **Background** This feature request features on both the German Technical wishlist from 2014 and the WMF Community Tech team wishlist at position #12 for 2015. A bug has existed for this feature since 2006 T8964. WMF Community Wishlist proposal and votes: https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Watchlists#Watchlist_timed_expiry ##### Requirements Expiring watchlist entries would be useful for the following reasons: * Watch a talk page of a user that you message for a response for a limited time. * Watch a page for a specified amount of time after a page protection expires. * Watch a page for a short amount of time after reverting vandalism on the page. * Watch a time boxed discussion page for the length of the timebox. ------- ### Exploration //(Use this space for data gathering, status quo, proposals, other considerations etc.)// **Proposal** It should be possible to watch a page and have it be removed from your watchlist after a custom timeframe. Users should initially be able to change the expiry time of a watchlist entry using the API. Users should also be able to set a number of days for how long a page should be watched or make watchlist entries never expire on the Special:EditWatchlist page. The initial implementation would not include any changes to watching a page directly from an article page (i.e. clicking the star button on the toolbar). All entries added to the watchlist by clicking the star button would still initially have an unlimited expiry date. The feature would be first offered as a beta feature. The initial proposal is to add a single new field to the watchlist table containing an expiry timestamp. All selects on the watchlist table would be updated to only select watchlist entries that have not yet expired. Users would be able to set an expiry when watching a page using action=watch specifying a parsable expiry (similar to protection expiry through the API) The initial implementation would also have a maintenance script to remove expired entries **//Backend Refactoring//** The WatchedItem class currently contains methods such as doDuplicateEntries, duplicateEntries, removeWatch, addWatch, batchAddWatch, resetNotificationTimestamp & load all of which do not belong in this class. They should be moved to a WatchedItemStore or something similar. Looking at usage of these methods if they were moved the only extension that would need updating would be Flow which uses the duplicateEntries, removeWatch & addWatch methods in production code and tests. Methods could then be added to this store such as loadWatchedItemsForUser, loadUnwatchedItems and perhaps loadUsersWatchingPage which would remove the spread of SQL that would need to be touched by this proposal. The SQL that would need to change is currently distributed through the following classes: InfoAction, ApiQueryInfo, ApiQueryUserInfo, ApiQueryWatchlist, ApiQueryWatchlistRaw, EmailNotification, SpecialEditWatchlist, SpecialRecentchanges, SpecialRecentchangeslinked, SpecialUnwatchedpages, SpecialWatchlist. **Applications / User stories** Expiring watchlist entries could be useful for the following reasons: * Watch a talk page of a user that you message for a response for a limited time * Watch a page for a specified amount of time after a page protection expires * Watch a page for a short amount of time after reverting vandalism on the page. * Watch a time boxed discussion page for the length of the timebox **Considerations** * It might make sense to refactor access to watchlist items before or potentially after trying to implement this with the goal of having a single location that makes calls to the watchlist table (currently queries are spread between multiple locations) * The expiry field of the watchlist table may need an index * As mentioned in T8964 to cover further expansion to the watchlist table a more general properties field may be preferable, although this would likely mean selecting non expired watchlist items would be harder * It might make sense to also allow adjusting the expiry date of watchlist entry in the raw watchlist editing mode (Special:EditWatchlist/raw). One possible way to do this would be expanding the raw watchlist format so that each row could also include a number of days to watch the page. Such a change should be backwards-compatible so that importing and exporting of already existing watchlist would not require any actions from the user. **Key Questions** * Should the expiry date be its own field or should a properties field be introduced? * Is a more automatic way of keeping the watchlist table clean needed or will a maintenance script do? * Will indexes be needed on the expiry column in order for this to scale? * Should the refactoring talked about actually happen and if so should it happen before or after the changes? * Should custom expiry date be considered in the import/export process using Special:EditWatchlist/raw), or should all imported and exported watchlist entries always have unlimited watching duration? **See also** * Current Phabricator task - T100508 * Oldest Phabricator task (2006) - T8964 * Gerrit patch with rough implementation - https://gerrit.wikimedia.org/r/#/c/245881/ * Gerrit patch with some rough re factoring - https://gerrit.wikimedia.org/r/#/c/267259/ **After initial implementation** * Api modules that output info about watched items such as ApiQueryInfo, ApiQueryWatchlist & ApiQueryWatchlistRaw should display watchlist entry expiry times * Some sort of automatic removal of expired items may be desired