Community Wishlist Survey 2019/Archive/Implement widespread autoarchiving
Implement widespread autoarchiving
Outside the scope of Community Tech
- Problem: Widespread variation in implementation and syntax, bot dependent, intermittently broken, and time consuming for editors to manually implement autoarchiving on talk pages
- Who would benefit:
- Editors, as:
- Decreases needless edits. If (in my experience) pages require 3 - 5 edits to get auto archiving right per page, that's approximately 25 million wasted edits that could be potentially automated for an easily automated process
- Improve readability of talk pages. Lots of article talk pages have threads on them that potentially expired a decade ago, and for lack of attention and because it's not the easiest thing to do, haven't yet been auto archived. This improves talk page readability, and keeps discussion focused on the active article at hand.
- Editors, as:
- Proposed solution:
- WMF should provide community talk page archive bots, with a view to eventually assuming community bot responsibilities
- WMF should provide an easy prompt to implement autoarching on talk pages (eg duration, number of remaining posts, and desired archive box)
- More comments:
- Phabricator tickets:
- Proposer: Tom (LT) (talk) 09:18, 31 October 2018 (UTC)
Discussion
- If this is to be done, I hope we make this kind of archival as opt-in: Korean Wikipedia largely prefers archiving by actually moving the page (even if I run the autoarchival bot), and wouldn't welcome this kind of stuff forced on them. — regards, Revi 10:21, 4 November 2018 (UTC)
Hi Tom (LT), I have good news and bad news about this proposal. :) The good news is that the Wikimedia Foundation is starting the planning process for a big global Talk pages consultation which will begin in February. The idea is that we need to step back from LiquidThreads and Flow, and start over with a totally public and transparent consultation. We want to bring together as many people as possible, and come to consensus on the problems with talk pages that we want to solve, the good things about talk pages that we want to keep, and the tradeoffs involved in finding a solution that will work for new and experienced editors. You can read a lot more about it on that project page that I linked. The planning has just started, and we're starting to talk about the structure for this consultation and how it's going to work.
The bad news for right now is that we don't want to include proposals about talk pages in the Wishlist Survey voting. No matter what happens in the Wishlist Survey voting, all of the future talk page work will be determined by the Talk pages consultation happening next year. We don't want people to vote for something, and then find out that we still have to have another process before we make any decisions.
But -- these proposals and the discussions that people are having here are important, and I've added a section on the Talk pages consultation page which lists each of the related proposals, so that they can be a part of the public record during this planning stage. We'd like to include all of you in the consultation -- and in the planning, if you're interested. There's a lot to talk about and figure out.
I'm sure this will be disappointing right now; I hope it's also heartening to know that this problem will get a lot of attention next year. Let me know what you think. -- DannyH (WMF) (talk) 06:41, 6 November 2018 (UTC)
- Thanks DannyH, no problem and look forward to the discussion. I hope that in our discussion next year, we can talk about both what might make a great future solution (eg. VE, flow, etc.) but also about things that can improve the current experience and can be implemented more easily in the meantime, lest the best become the enemy of the good. --Tom (LT) (talk) 10:31, 6 November 2018 (UTC)
- Yes, that's absolutely going to be part of the discussion. Incremental changes could turn out to be the right answer in some cases. -- DannyH (WMF) (talk) 00:32, 7 November 2018 (UTC)