Talk:Community Wishlist/W311

Actual problem

An underlying issue here is that no archiving is done by MediaWiki or any extension, only by volunteer-run bots, which vary in behavior (e.g. some bots fix broken section links or create indices, others do not). Building something that takes over their work, thereby allowing for consistent talk page experience throughout Wikimedia wikis, would be the real solution. Nardog (talk) 20:42, 21 October 2024 (UTC)

With that description and no further elaboration I don't see how it's relevant or the actual problem since a) I don't know of any bot that doesn't fully archive Talk page threads and b) MediaWiki or an extension of it may archive Talk page posts in exactly the same way as the bots currently used for that. Prototyperspective (talk) 20:54, 21 October 2024 (UTC)

I'm pointing out the behavior of bots is not within WMF's remit. So if they were to do anything to address your wish, it would be to build something that replaces the bots, because otherwise they'd have to meddle with the code of each volunteer-run bot, which would be not only laborious and tedious but also something they shouldn't be doing. Nardog (talk) 21:00, 21 October 2024 (UTC)

Okay then it's simple: the Wishlist isn't only about WMF.

In addition, the bots don't even need to be changed, there could be a separate bot or tool for this. Prototyperspective (talk) 21:05, 21 October 2024 (UTC)

No, I'm saying they totally can (and should IMO) address it, just not the way you think (but better). Nardog (talk) 21:20, 21 October 2024 (UTC)

Well if MediaWiki or an extension does it that would fit the proposal which is unspecific in regard to that and it may be best if it was done that way. I think it can also be implemented without MediaWiki or extension change albeit that may be ideal. Prototyperspective (talk) 21:37, 21 October 2024 (UTC)

I believe many issues across Wikimedia projects arise from the fact that we use the same type of page for everything. While this has helped us avoid certain problems, it has also introduced significant challenges. Pages like redirects, disambiguations, archives, and user pages are fundamentally the same in the backend, differentiated only by context. As Nardog mentioned, archiving typically just means copying text from one page to another, usually by a bot, without any inherent distinction between these pages.
Your proposal is a positive step toward creating some differentiation in this system, and I support it. However, I hope this can be part of a larger effort to build a more robust archiving infrastructure. Ideally, archiving should be natively managed by MediaWiki, rather than relying on user-controlled bots. Archive pages could exist in a distinct namespace, have built-in protection, and feature an intuitive system for linking between archives and un-archiving threads when necessary (e.g., with notes like "brought back from archive..."). We could even introduce different levels of archiving, each with its own specific characteristics, including the concept you're proposing. This could integrate with existing DiscussionTools functionalities, as shown in your mockup.
The same principle could apply to redirect pages and others, but that's beyond the scope of this discussion. — Klein Muçi (talk) 23:40, 21 October 2024 (UTC)

I agree with that it should be supported natively by MediaWiki or an MW extension. However, I consider it getting actually implemented more important than having an optimal solution for it and it seems like it would be less likely to get implemented if part of MW itself.

Archive pages could exist in a distinct namespace I see no usefulness or need for this. It would make threads there even less findable so I don't support this part but agree with the rest.

As for redirects there are templates like {{Category redirect}} and maybe a script / bot could change redirect pages. They can and are already dealt with differently, e.g. show differently in What links here. Prototyperspective (talk) 12:53, 22 October 2024 (UTC)

Prototyperspective, why do you think that archives existing in a different namespace would make it harder to discover threads? I'm genuinely curious. In my eyes, that would help towards that aspect, not against it. Having a dedicated namespace for something usually means an improved infrastructure built specifically for it and thus better handling of said content. Think about how the Module and Mediawiki namespaces function (and look) differently from other namespaces, accommodating their specific needs. I believe if you want to handle things natively, you want to make changes to the core and isolate it from the other parts. That allows you to work more freely and "isolating" things in their own namespaces makes it easier to work with them. Then you could keep improving on that namespace, adding or removing features (like what we discussed) as you wish, without worrying too much how those changes might also interfere with other elements. I think namespaces are a bit underutilized in general. Having more of those for specific practices that have well-crystalized throughout the years could help speed up progress, globally standardize workflows and make things less reliant on local workarounds (such as using templates for specifying redirects, as you mention). Localized solutions are great for large wikis, as they offer flexibility, but they impose extra work on smaller ones, which then need to import those solutions and create automation tools for their operation due to limited active contributors. — Klein Muçi (talk) 10:30, 25 October 2024 (UTC)

Because a) it may not be enabled to be searched by default on Wikipedia and b) people may only check the Talk namespace when searching.

Having a dedicated namespace for something usually means an improved infrastructure built specifically for it No, why would that be the case? Mediawiki namespaces do you mean separate websites / subdomains like the MediaWiki wiki or namespaces like article & talk namespaces? "isolating" things in their own namespaces makes it easier to work with them It isolates content further so even fewer people see (or use) prior discussions. adding or removing features (like what we discussed) as you wish what is discussed here is changes at the talk namespace. (except for adding a button to unarchive to all threads in the archives). Prototyperspective (talk) 11:08, 25 October 2024 (UTC)

Prototyperspective, I meant the Module and Mediawiki namespaces, not websites/subdomains. No, why would that be the case? Because it is theoretically easier code-wise to push changes that target a specific namespace. To put it in a very simple language, it's easier to say "make all text red in archive-namespace' than to say "make all text red in talk-namespace but only if the word 'archived' is in it" and then understand that that also targets pages which randomly mention the word "archived" so you have to push new changes and specify it even further hoping you won't get other false positives or unintended effects. Separating archives into their own namespace would avoid these complications. Developers could implement changes to archives without worrying about accidentally affecting other parts of the site. On the user side, the experience would stay the same because we could design it to look and work just like the current system, so it wouldn’t necessarily make old discussions harder to find or use. — Klein Muçi (talk) 22:01, 28 October 2024 (UTC)

Ok, thanks for explaining. However, I still don't see a need for that since I don't think anything about archive pages would need to be different from other Talk pages except that they should not be editable and have a button to unarchive next to each section header (the only way to edit it) and think both of these things are probably not really helped by having it in a separate namespace which could also make things more complicated and/or cause the issues I mentioned instead of just checking if the page is a subpage of a talkpage that is titled "Archive_{number}". Maybe it would be better if it was in a separate namespace but that could be investigated/discussed later. Prototyperspective (talk) 14:17, 29 October 2024 (UTC)

I agree that it is a challenge that Wikimedia projects use the same page type for everything. AdamSobieski (talk) 03:48, 6 December 2024 (UTC)

This is fundamentally a cultural shift in how we respond to talk page messages rather than a technical shift, creating the requirement that every discussion be formally marked resolved. I'm not sure that culture shift is a good idea - sometimes letting something die silently is the correct way of handling, i.e, someone not dropping the stick. * Pppery * _{it has begun} 04:10, 22 October 2024 (UTC)

Exactly – thanks for making this point and I think so too. However:

1. this could be implemented in a way that allows things to still die silently
2. just having a thread header on the Talk page isn't much of an issue even if that thread is a nonissue
3. the benefits of this and the need for it are larger than the potential drawbacks
   (e.g. at worst case if somebody wants to have the archived thread remain included in the unsolved threads list then just have it there as it doesn't cause much of a problem except one short header more to read for those who read these which would still be few)

Also I think people 'not dropping the stick' is a bad example – I think people should drop things once there have been actual good arguments and the points made have been considered, not at any point before which is consistent with the reasons & discussion not mere votes principle that is I think a key thing that makes WP as great as it is. Watchers of a page may not like something because they tend to view xyz positively but the point raised is valid so it shouldn't be dropped just because a few fans think the stick should be dropped without having considered and responded to the points raised. A better example would be things that are simply not required by any policy or standard which a user thinks should be changed in the article and in the case of the article wouldn't improve it where there are no good reasons why it should be changed that way. Both cases could be marked as nonissue or not be marked as issue – the thing that is relevant to all of this is how the marking/unmarking is handled.

A cultural shift may be involved. It's debatable whether or how much of a shift because I think that there's no info about archived threads on the Talk page and the full-archiving methodology was never something the community deliberately decided on or culturally favors, it's that way because it was easier for bots to implement. In any case, technical changes/features would be involved here and I think are the main part of this proposal instead of any cultural change. It's indeed a change to a long default practice so some probably don't like it at first due to it being different to what they're used to. Because of that and also in general it's important to highlight and explain the advantages (or needs) for this, that Talk page threads are rarely read and that there's many in archives that point out valid major open issues which don't get discovered or read when they're only in the archive. There's also options like having the box be collapsed by default on the Talk page. Prototyperspective (talk) 11:24, 22 October 2024 (UTC)

I just dropped by to add a courtesy link for 'not dropping the stick', I assume it relates to this essay. While I am here, I would like to say that I support this wish in combination with the related wish about displaying a count of open issues and the ability to run reports on the number of open issues to facilitate actioning them.

I am not sure modifying every archive bot is feasible and the better solution eluded to by Nardog would be interesting. I imagine that would involve dedicated forum software. There was Flow but that failed, if anyone could explain to me why that would be great. Perhaps there should be an umbrella wish 'Better discussion system' because I am certain this particular wish is the tip of the iceberg when it comes to wanted features.

As for cultural shift, personally I have been burnt by archived open threads on extremely busy pages and extremely quiet ones. I am happy to reduce the burning for others by patrolling open threads and solving them where I can. Commander Keane (talk) 02:01, 23 October 2024 (UTC)

Thanks for your contributions. I am not sure modifying every archive bot is feasible Well that's also not what this proposal is about. Maybe it could be implemented by one of these bots but this proposal is not specific to such an implementation: it could also be implemented via MediaWiki, a MediaWiki extension, a separate bot, a separate script such as a default enabled gadget, or something else. (highlighting this to clear this misconception also for other readers of the wish).

I only would add that this wouldn't be solved if some volunteer develops a gadget that nearly nobody knows of or uses that can do this – it's about having these open issues on the talk page in a short way for all Wikipedia readers, including signed out ones and users on mobile.

There is the Discussion tools where you can click Reply below posts and I find it very useful. Maybe this could become part of that but I don't see how it would be directly linked to that on the technical level. When it comes to a better discussion system, I think the Reply tool should be made to be more widely adopted and these issues get addressed. Those issues also include adding a 'mark as solved' button so more people use this to mark threads as solved. Prototyperspective (talk) 12:30, 23 October 2024 (UTC)

As long as we do not use LQT or Flow, something needs to be done to fix our archive system.--GZWDer (talk) 03:36, 3 January 2026 (UTC)

Could you elaborate? What do you think needs to be done and how does this relate to this wish (where I see you haven't supported it)? Prototyperspective (talk) 21:23, 3 January 2026 (UTC)

Increase review / decline / implementation of requested article updates

Just a note that this wish also relates and may partly enable or be combined with increasing + speeding up the review of requested specified article changes such as reviewing Add-a-Fact proposals and a subset of talk page requests that propose specified changes like these – this could speed up things a lot and keep things more up-to-date which could be integrated as a task type (or a set thereof) into the Suggested tasks based on contributions history (user interests) tasks dashboard. Such proposals would be marked as issues or a special type of issues in the context of this proposal here. Prototyperspective (talk) 13:32, 30 October 2024 (UTC)

Alternative: wider adoption of unarchiving or recreating threads on unsolved issues

Rarely does one see Wikimedians unarchiving threads. However, often threads are archived merely because there has not been a reply in x days even when the issue is valid and important. Another approach to things like showing a collapsed box with titles of archived unsolved threads on the talk page could be more users unarchiving such threads from archives or to recreate more or less the same post with a link to the archived thread.

For example, there are many such archived threads at c:Commons:Bots/Work requests and c:Commons:Village pump/Technical.

I don't think this would be a good alternative to implementing what's proposed here or something more or less similar to it. Prototyperspective (talk) 17:22, 3 November 2025 (UTC)

Archive sounds rather final. Better would be next page >.

If the most recent talk page exceeds x kb move the most stale discussion to talk page 245.

When 245 exceeds x kb create talk page 246.

If page 245 continues to grow, move its most active discussion to the most recent sub page, say 249.

~2026-78106-6 (talk) 23:06, 4 February 2026 (UTC)

For many pages, it's intended for the discussion to be some kind of deactivated/deprecated. It just happens very rarely for these to be unarchived. One can't reply on archive pages currently and nobody currently watches these so nobody would read the replies either. Also I don't think that many more people would go to the next page. It's different I think if there was a box with the unsolved thread titles one can glance over within the page. Prototyperspective (talk) 23:19, 4 February 2026 (UTC)