Change Details

==== Problem Statement In most cases, users watchlist entries (on **Special:EditWatchlist**) can grow as large as >700 articles and figuring out the latest article added to watchlist (for example) is a difficult task (taking into consideration the user can't even remember the name of this particular article that was added), so, I was experimenting on building an extension (say WatchListFilter extension maybe?) to filter watchlist based on various parameters (like `desc order of timestamp`, `asc order of timestamp`, `date added`, etc) but by default, based on their timestamps added. See also: {T100508}, {T208487} ==== Proposed Solution MediaWiki already has a way of dealing with Timestamps, see https://www.mediawiki.org/wiki/Manual:Timestamp, which is very nice so a solution to handle this problem would be altering the watchlist table to add the `wl_addedtimestamp` attribute to it so it can be used in the filtering process. The attribute will store MW timestamp that will be used by MW or other extensions that may need this feature. There would be a lot of filters that can help the users find the article added to watchlist without knowing the name of the article; * ASC order of TS * DESC order of TS * Range TS / Date search * Order by Alphabet (this can make use of other attributes in the watchlist table) * Filter by Regex * etc | **Motivation** | **Other thoughts** | | Trying to solve the finding watchlist entry problem with an extension I'm intending to work on "WatchListFilter". | Whether the feature may be made available in core could be a different topic for discussion but the basic level usage here is for an extension. Also, other topics as per how the filter will look on the Special:EditWatchlist special page based on the OOUI-fication that has happened and others can be addressed on other tickets, maybe sub-tasks of this one I guess :) ==== Alternative solutions I've not had deep investigations on an alternative way to solve this problem with other means different from this proposal. Looking at the current watchlist table, I don't yet see an alternative means although there may be a way I don't yet know but others do :). ==== Side effects * Though I see no side effect(s) here apart from more data going into the database which will increase the DB size over time, this feature is quite advantageous as other things can be built on it like the WatchListFilter extension etc. * Another advantage can be that, this feature can act as a partial "watch this and read for later" as the user won't bother to bookmark the page or remember the name of the article. All the user needs to know is the approximate time the article was added to their watchlist and the filter can be used to figure the potential article. ===== Comments An RfC was filed some weeks ago (as of today) which was quite wrong per the request, see https://phabricator.wikimedia.org/T208487, thanks to @daniel, @aaron, @Catrope, @Anomie for feedback that enlightened me to create this "real" RfC proposal. This RfC is a product of T208487.

==== Problem Statement In most cases, users watchlist entries (on **Special:EditWatchlist**) can grow as large as >700 articles and figuring out the latest article added to watchlist (for example) is a difficult task (taking into consideration the user can't even remember the name of this particular article that was added), so, I was experimenting on building an extension (say WatchListFilter extension maybe?) to filter watchlist based on various parameters (like `desc order of timestamp`, `asc order of timestamp`, `date added`, etc) but by default, based on their timestamps added. See also: {T100508}, {T208487} ==== Proposed Solution MediaWiki already has a way of dealing with Timestamps, see https://www.mediawiki.org/wiki/Manual:Timestamp, which is very nice so a solution to handle this problem would be altering the watchlist table to add the `wl_addedtimestamp` attribute to it so it can be used in the filtering process. The attribute will store MW timestamp that will be used by MW or other extensions that may need this feature. There would be a lot of filters that can help the users find the article added to watchlist without knowing the name of the article; * ASC order of TS * DESC order of TS * Range TS / Date search * Order by Alphabet (this can make use of other attributes in the watchlist table) * Filter by Regex * etc | **Motivation** | **Other thoughts** | | Trying to solve the finding watchlist entry problem with an extension I'm intending to work on "WatchListFilter". | Whether the feature may be made available in core could be a different topic for discussion but the basic level usage here is for an extension. Also, other topics as per how the filter will look on the Special:EditWatchlist special page based on the OOUI-fication that has happened and others can be addressed on other tickets, maybe sub-tasks of this one I guess :) ==== Alternative solutions I've not had deep investigations on an alternative way to solve this problem with other means different from this proposal. Looking at the current watchlist table, I don't yet see an alternative means although there may be a way I don't yet know but others do :). As proposed here: T209773#4756088, that can be another approach in introducing this feature. ==== Side effects * More data going into the database which will increase the DB size over time, this feature is quite advantageous as other things can be built on it like the WatchListFilter extension etc. * After adding this attribute to the table (approach 1) or even approach 2 (as suggested by Brian), items already added to watchlist before the introduction to this feature will have no timestamp or default timestamp (which can cause some inaccuracy in the filtration process). So this is something worth noting how to deal with. * Another side effect (adv) can be that, this feature can act as a partial "watch this and read for later" as the user won't bother to bookmark the page or remember the name of the article. All the user needs to know is the approximate time the article was added to their watchlist and the filter can be used to figure the potential article. --- ==== Use cases <TBA> --- ===== Comments An RfC was filed some weeks ago (as of today) which was quite wrong per the request, see https://phabricator.wikimedia.org/T208487, thanks to @daniel, @aaron, @Catrope, @Anomie for feedback that enlightened me to create this "real" RfC proposal. This RfC is a product of T208487.

==== Problem Statement In most cases, users watchlist entries (on **Special:EditWatchlist**) can grow as large as >700 articles and figuring out the latest article added to watchlist (for example) is a difficult task (taking into consideration the user can't even remember the name of this particular article that was added), so, I was experimenting on building an extension (say WatchListFilter extension maybe?) to filter watchlist based on various parameters (like `desc order of timestamp`, `asc order of timestamp`, `date added`, etc) but by default, based on their timestamps added. See also: {T100508}, {T208487} ==== Proposed Solution MediaWiki already has a way of dealing with Timestamps, see https://www.mediawiki.org/wiki/Manual:Timestamp, which is very nice so a solution to handle this problem would be altering the watchlist table to add the `wl_addedtimestamp` attribute to it so it can be used in the filtering process. The attribute will store MW timestamp that will be used by MW or other extensions that may need this feature. There would be a lot of filters that can help the users find the article added to watchlist without knowing the name of the article; * ASC order of TS * DESC order of TS * Range TS / Date search * Order by Alphabet (this can make use of other attributes in the watchlist table) * Filter by Regex * etc | **Motivation** | **Other thoughts** | | Trying to solve the finding watchlist entry problem with an extension I'm intending to work on "WatchListFilter". | Whether the feature may be made available in core could be a different topic for discussion but the basic level usage here is for an extension. Also, other topics as per how the filter will look on the Special:EditWatchlist special page based on the OOUI-fication that has happened and others can be addressed on other tickets, maybe sub-tasks of this one I guess :) ==== Alternative solutions I've not had deep investigations on an alternative way to solve this problem with other means different from this proposal. Looking at the current watchlist table, I don't yet see an alternative means although there may be a way I don't yet know but others do :). As proposed here: T209773#4756088, that can be another approach in introducing this feature. ==== Side effects * Though I see no side effect(s) here apart from more* More data going into the database which will increase the DB size over time, this feature is quite advantageous as other things can be built on it like the WatchListFilter extension etc. * After adding this attribute to the table (approach 1) or even approach 2 (as suggested by Brian), items already added to watchlist before the introduction to this feature will have no timestamp or default timestamp (which can cause some inaccuracy in the filtration process). this feature is quite advantageous as other So this is somethings can be built on it like the WatchListFilter extension etc worth noting how to deal with. * Another advantageside effect (adv) can be that, this feature can act as a partial "watch this and read for later" as the user won't bother to bookmark the page or remember the name of the article. All the user needs to know is the approximate time the article was added to their watchlist and the filter can be used to figure the potential article. --- ==== Use cases <TBA> --- ===== Comments An RfC was filed some weeks ago (as of today) which was quite wrong per the request, see https://phabricator.wikimedia.org/T208487, thanks to @daniel, @aaron, @Catrope, @Anomie for feedback that enlightened me to create this "real" RfC proposal. This RfC is a product of T208487.