| Dvorapa | |
| Jul 26 2017, 9:58 AM |
| F34913195: globalwatchlist2.png | |
| Jan 10 2022, 3:01 PM |
| F34913186: globalwatchlist.png | |
| Jan 10 2022, 2:54 PM |
| F34913185: workingwatchlist.png | |
| Jan 10 2022, 2:54 PM |
Current steps to see the diff of all changes since last visit of some watched page
Proposed steps to see the diff of all changes since last visit of some watched page
This is really similar to T74937: Option to list only unviewed/unvisited changes on watchlist.
And gets at the problem for T10681: Do not group changes by day in enhanced recent changes.
@Izno I would merge into the older one, the descriptions are word to word the same as I see it. But overall thank you for your merge, I didn't know this was reported before.
The Growth team discussed this in our triage meeting today. First step would be for someone to create a mockup of what we want to build. After that, we could write the code to implement it, or it could be a good task for patch-welcome. Marking as Q4 for the Growth team for now although we can't guarantee we'll get to it.
Due to the Growth-Team focusing on newcomer homepage work, we will need to delay this feature idea
This is already implemented here: https://en.wikipedia.org/wiki/User:Prototyperspective/gadgets/aWorkingWatchlist.js
Basically, all that's needed is the will / the decision to add this code to the gadgets that one can enable from the preferences.
This has been asked since at least 2015 and also got substantial support at Wishlist Surveys. That's over 6 years now. I'd really like to know why in all this time WMF did not do a thing as basic and important as a working Watchlist. Why? (I'd really like to reconstruct why.)
I do think there's a lack of developers, especially a lack of facilitating help from volunteer-developers but I just don't understand why it hasn't been solved to at least the degree described above. Personally, I can't use the Watchlist, a core element of MediaWiki/Wikipedia, without this script (which I had to update to get it to work).
My head hurts when I think about all the precious time editors have wasted manually going through their Watchlist, clicking on the "hist" link to see all changes, select the two revisions for the unseen-changes view, and wait for it to load (or similar procedures). Wikipedia could be so much better if they didn't waste all this time unproductively on their Watchlist and used it for editing (or checking more changes).
Back on topic: the solution above would only be a suboptimal temporary solution. I think this task is about and the better solution would be to add this to the default MediaWiki code.
An optimal solution, to answer the request for "someone to create a mockup of what we want to build", would be to also display number of changes in the Watchlist item if the number is larger than 1. Hovering over it could display the edit summaries of all unseen changes separated by newlines. Especially because some pages have lots of changes the "since last seen" could also only load once clicked or hovered over. This is how it works with the current gadget linked above. It loads when hovering over "since last seen" (so if you click to fast it will fail).
Furthermore, for the current solution (the linked script) one may need to tweak some timeouts and server parameters, that's only a matter of configuring variables (like timeouts, number of items to load, and variables on the backend). Currently, there's a timeout of 7000 in the script and it may fail to load all items of the Watchlist (I don't know what your server parameters are).
Lastly, the better solution (MediaWiki development) could also display all the edit summaries on the diff page after one clicked on the "since last seen" button (however it's called then). To save even more time, reduce clutter (make it easy to see changes) and increase efficiency further it could be made configurable to filter out all edits made by specified bots (in particular "Citation bot").
AIUI from looking at https://en.wikipedia.org/wiki/Wikipedia:Gadget, you need to propose it in order for it to be listed in preferences: New gadgets should be proposed at the technical Village Pump
This has been asked since at least 2015 and also got substantial support at Wishlist Surveys. That's over 6 years now. I'd really like to know why in all this time WMF did not do a thing as basic and important as a working Watchlist. Why? (I'd really like to reconstruct why.)
I do think there's a lack of developers, especially a lack of facilitating help from volunteer-developers but I just don't understand why it hasn't been solved to at least the degree described above. Personally, I can't use the Watchlist, a core element of MediaWiki/Wikipedia, without this script (which I had to update to get it to work).
My head hurts when I think about all the precious time editors have wasted manually going through their Watchlist, clicking on the "hist" link to see all changes, select the two revisions for the unseen-changes view, and wait for it to load (or similar procedures). Wikipedia could be so much better if they didn't waste all this time unproductively on their Watchlist and used it for editing (or checking more changes).
Back on topic: the solution above would only be a suboptimal temporary solution. I think this task is about and the better solution would be to add this to the default MediaWiki code.
An optimal solution, to answer the request for "someone to create a mockup of what we want to build", would be to also display number of changes in the Watchlist item if the number is larger than 1. Hovering over it could display the edit summaries of all unseen changes separated by newlines. Especially because some pages have lots of changes the "since last seen" could also only load once clicked or hovered over. This is how it works with the current gadget linked above. It loads when hovering over "since last seen" (so if you click to fast it will fail).Furthermore, for the current solution (the linked script) one may need to tweak some timeouts and server parameters, that's only a matter of configuring variables (like timeouts, number of items to load, and variables on the backend). Currently, there's a timeout of 7000 in the script and it may fail to load all items of the Watchlist (I don't know what your server parameters are).
Lastly, the better solution (MediaWiki development) could also display all the edit summaries on the diff page after one clicked on the "since last seen" button (however it's called then). To save even more time, reduce clutter (make it easy to see changes) and increase efficiency further it could be made configurable to filter out all edits made by specified bots (in particular "Citation bot").
I hear your frustration. https://www.mediawiki.org/wiki/Bug_management/Development_prioritization is a good overview of "why isn't feature X implemented or bug Y fixed". As I understand it, there isn't a WMF team that has improvements of this type to Special:Watchlist in its purview.
FWIW if you enable the "Group changes by page in recent changes and watchlist" user preference, you do get "cur" links in the watchlist, but only for articles which were changed multiple times a day.
Or try also GlobalWatchlist which doesn't use grouping by days but does provide such a link.
Community Wishlist Survey 2022 is coming soon...
Thanks for the infos. Will propose it there (albeit having even more options could be a problem and this should be in the options of the Watchlist page if it's not enabled by default). Probably has been proposed earlier too.
I hear your frustration. https://www.mediawiki.org/wiki/Bug_management/Development_prioritization is a good overview of "why isn't feature X implemented or bug Y fixed". As I understand it, there isn't a WMF team that has improvements of this type to Special:Watchlist in its purview.
I could understand why it isn't implemented if they facilitated more volunteer developers to help out with the development (such as via a banner calling for volunteer developers above coding-related articles) and had a larger expenditure on software development. I just think it would be easy/fast to implement (at least the basic version via a gadget because the script is already there) and would save tremendous amount of editors' time they could use for other things and hence is generally important (meaning that if it isn't implemented for >6 years despite all of that, something doesn't seem to be functioning well).
I tried that earlier and I don't get such "since last visit" links there or "cur" links. Maybe one needs to also change some other options to make that work but I think I went through all possibly related options earlier too.
Great, GlobalWatchlist is amazing. Looks like this has been implemented in February this year. There are some issues which make it barely usable like displaying all these links the same way and the sea of blue instead of the article title in bold and info on how much content was overall removed or added (or an expandable list of edit summaries, etc.). Yes, I'm aware of the next Community Wishlist – I just hoped WMF would do more to actually get the prior ones implemented and forward the results pages to those that are interested in helping develop MediaWiki so that these survey are more useful. Thanks for the info!
Edit to clarify: I don't think the GlobalWatchlist is currently useful in practice as a watchlist with these diffs because of the aforementioned issues with it. However, it could be easy/quick to improve it so that it is.
Edit to clarify further: here are the two screenshots of the two approaches, I hope this makes it clearer how, even if it was the default Watchlist, it's still having problems that make it hard to use:
| GlobalWatchlist | Added button |
 |  |
 | < this screenshot makes it clearer (the panel being visible in the middle of the page was a bug of the screenshot-taker, it wasn't actually visible there. It shows the configured settings so it may be useful.) |
@Izno please don't close so quickly or more thoroughly compare: these are not the same – the other issue is about seeing all unseen diffs in one view like with the Watchlist showing edits directly in the Watchlist via the "Expand watchlist to show all changes, not just the most recent" option. In contrast, this issue here is about the normal Watchlist that shows one item per page but has an extra button to directly see a diff of all unseen changes for that page (one item in the Watchlist per watched article, not dozens of items per watched page),
The descriptions clearly discuss the same problem: I would like to know what the diff is since the last time I viewed a page. Whether that ends up being fixed with method A or B is not the point of a task, which should discuss the problem first/foremost and not necessarily specific solutions to the problem. That's why they should be merged even if I agreed that the two descriptions differ sufficiently not to be the same description of functionality intended. Which I don't. The distinction you see in your reading is not one I see in mine.
@Izno No, it's not the same problem or the same code issue. It's not about the last unseen diff here like you just described. It's about a convenient button in the Watchlist to see a diff of all unseen changes. I don't know how people can use the Watchlist without it, I think the Watchlist is broken. Those two issues are not about the two same thing. If there is something that they have in common create a new subtask or create a new issue where these two are subtasks but the issues themselves are very different.
Edit: both issues may depend on a shared thing but the other issue would not create a since last seen diff link and it would not put such a link into the Watchlist (merging to there means these parts are lost) – one could create a separate issue about the code that both issues may depend upon if there is one (like 'getting the latest unseen diff for an article'). If two issues depend on the same thing – and implementing that wouldn't mean either is solved – it shouldn't mean that the one that was created first is just trimmed away and decided against.
No, it's not the same problem
Yes, it is precisely the same problem. But since you don't seem interested in moving forward on the point, I'll just move on.