Currently our policy for closed discussions is to delete them after a while. The advantage is that it's very easy to do, but on the other hand it makes it much harder to retrieve old important discussions that for example justified some decisions in the past. In fact, I can remember (briefly) discussing this very policy a long time ago somewhere, but I'm not even attempting to look for it, as it would probably take me half an hour...
Wikipedia uses another policy: they archive old discussions in Archive subpages, so that they'll always appear e.g. in search results. I'd like to discuss (more than propose) here whether such policy would better suit our wiki as well.
We may even create an "Archive" namespace and use its talk pages as archives, so as to allow better filtering the searches.
Finally, I think that I could automate the process of moving a closed discussion to an Archive page with Wiki Monkey, if we found that the added manual work is the only disadvantage.
- The biggest problem of the archive-by-moving method is that it is necessary to update all links to the archived discussion. Therefore the archiving process would be practically limited to using a bot.
- Personally, I find the archive scheme used on Wikipedia rather disorganized - IMO the "Archive" namespace would be better than subpages of the talkpage. They also have some archiving templates to ease browsing of large archives (I found one with ~120 pages), not sure if we need this. But wikipedia:Template:Hidden_archive_top certainly looks interesting, maybe we can just archive-by-hiding and leave the discussion in the original place (possibly moving to the top)? This way we would not have to update the links...
- If we agree on some archiving method, shall we archive all discussions or only the relevant (missing definition) and delete the others?
- -- Lahwaacz (talk) 10:51, 12 February 2014 (UTC)
- Well, I wouldn't require updating the links to archived discussions: if, after following a link to a talk page, the section is not found, a user should be aware of the fact that the discussion may have been archived, so (s)he should look in the appropriate Archive page, just like now (s)he's forced to look in the history. In fact, we're not currently requiring updating links to deleted discussions either.
- Only archiving "relevant" discussions would be ideal, the problem is indeed defining "relevant" so well and briefly that it doesn't take 10 minutes to a user to understand whether to delete or archive a discussion (most likely ending up choosing the third option "give up").
- -- Kynikos (talk) 09:19, 13 February 2014 (UTC)
As I already mentioned in Help_talk:Category#Does this page need to be improved?, we could move this page to Help:Discussions, i.e. use a plural form. It sounds better (in Russian too :) and will be more consistent with other ArchWiki pages (it seems there're much more pages where nouns in titles is in plural than in singular form). Same proposal for Help:Template. — blackx (talk|contribs) 06:15, 25 December 2014 (UTC)
- This is related to Help_talk:Style#Titles:_singular_or_plural.3F, which I think should be resolved first, there are no guidelines on this subject yet, even for regular pages. -- Lahwaacz (talk) 08:21, 25 December 2014 (UTC)
- I've proposed an idea for Help talk:Style#Titles: singular or plural?: if agreed upon, I'm in favor of renaming this page and Help:Template; I'm against renaming Help:Style/White space because I perceive "white space" as uncountable (the "space" in general, not the class of the single space characters). -- Kynikos (talk) 02:42, 26 December 2014 (UTC)
- Okay, also please don't forget to pay attention on Help:Category.
- About Help:Style/White space: I agree, "whitespaces" or "white spaces" is not correct. We could consider "whitespace characters" as a new title, but with a "Help:Style/" it becomes really long :D — blackx (talk|contribs) 07:02, 26 December 2014 (UTC)
How to manage discussions
I don't know if I'm the only one who feels like this, but I find it very hard to keep track of the discussions that I'm interested in, the ones that I want to answer, those where I answered and am waiting for a reply etc...
I'm mostly brainstorming here: if you're interested, please help discussing and adding the #Ideal features and functionality that a system to manage discussions should have, regardless of whether they can actually be implemented and how.
|Feature description||#MediaWiki extension||#User script||#Periodical report|
|Display all recent discussions like a forum, with threads, number of posts, participating users...||Yes||Perhaps doable, but it would be better to only provide an interface for a report periodically generated by a dedicated script||Yes|
|Show most recently updated discussions, and also the least recently updated (old and stale)||Yes||Only provide an interface for a report periodically generated by a dedicated script||Yes|
|Subscribe to a specific discussion and get notifications||Yes||Periodically parse all saved discussions to check if a comment has been added since the last search||Technically doable, but the user who runs the script would be the source of all notifications for everybody|
|View/sort/search/filter all personal discussions/posts||Yes||Expensive||No|
|View/sort/search/filter saved personal discussions/posts||Yes||Yes||No|
|Differentiate between discussions where my post is the latest or not||Yes||Yes||No|
|Assign priority levels to the saved discussions||Yes||Yes||No|
|Also allow saving generic notes in the saved discussions list, e.g. as a reminder to start a discussion about something||Yes||Yes||No|
|Integrate a personal task manager, allowing to link to discussions related to tasks||Yes||Yes||No|
|Easily create polls and cast votes||Yes||Yes||No|
|Easily close and archive discussion||Possibly optimise the archiving procedure to ease searching||Possibly optimise the archiving procedure to ease searching||No|
|Allow searching and viewing archived discussions||Expensive unless we optimise our archiving procedure||Expensive unless we optimise our archiving procedure||No|
I think there can be two (possibly mixable) approaches: a MediaWiki extension or a user script (this one possibly complemented by the generation of periodical reports). -- Kynikos (talk) 19:15, 13 January 2018 (UTC)
A MW extension would have the advantage that the manager doesn't have to be installed by each user, and each user's data is saved in dedicated tables of the database, so there's no cluttering of the recent changes. The mw:Structured Discussions extension may help us, but it's still in beta. I don't see viable alternatives, and personally I know enough (or maybe not enough) of PHP to be sure that I'm not going to write a MediaWiki extension from scratch ;P but perhaps there are some brave PHP fans looking for a cool project to work on?
A user script would have to save the user data in a page in the User namespace, so there should be a system to minimise the number of actual edits (perhaps queue them in the browser storage and either dump them periodically in the designated User page, or let the user do it manually).
I'm not aware of any user scripts that help managing wiki discussions, but I'd be willing to write one from scratch (good chance to learn some new cool JS library!).
A user-script solution could be complemented by the periodical (e.g. daily) generation of reports with info common to all users. This could be done with another user script, or a bot such as wiki-scripts.
Instead of developing and maintaining a full MW extension, it would be interesting to find (or make) an extension that creates (a) generic table(s) in the database and offers an API to access it, but it's only used to save and retrieve data, and all the processing work is actually done by a user script and a report-generating bot. -- Kynikos (talk) 10:01, 14 January 2018 (UTC)
- I don't know if sharing all personal and saved discussions publicly would be fine. You could probably devise a way to save per-user data and do some permission checking in the API, but that would not be generic. Also, SQL needs indexes optimized for the queries done on the database to work efficiently, so you would need to nicely wrap a lot of the SQL standard in the API. This is hard enough even in the conventional languages, let alone the web API. -- Lahwaacz (talk) 19:32, 19 January 2018 (UTC)
Hybrid solution 2
If writing PHP code, modifying the MW parser or deploying the extension would be a problem, we could use the wiki-scripts' local database and (future) parser cache to implement the backend and either a localhost webpage or a userscript with support for cross-site requests (from wiki.archlinux.org to localhost) to implement the frontend. It seems that qutebrowser might soon get a full(ish) support for GreaseMonkey userscripts ;-) Lahwaacz (talk) 19:43, 19 January 2018 (UTC)