Help talk:Discussion

Deletion policy

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.

-- Kynikos (talk) 06:20, 12 February 2014 (UTC)

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.

I haven't tested wikipedia:Template:Hidden_archive_top, I don't really think its javascript is installed in our wiki, however such a system would indeed clean up the html talk page, but it would leave the source text too messy, which is something I wouldn't like.

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)

From my own experience, I rarely have to dig into talk page history. So I just wonder if archiving history is really worth the effort?

However, if you do think it is needed and could be done through a bot, you have my +1 here.

--Fengchao (talk) 07:18, 2 March 2014 (UTC)

Let's keep this on hold, meanwhile of course the current policy (just delete) remains enforced. -- Kynikos (talk) 13:59, 4 March 2014 (UTC)

Let's rename?

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)

Hm, thanks for pointing this out Lahwaacz! In this case let's wait until that discussion will be finished. — blackx (talk|contribs) 08:27, 25 December 2014 (UTC)

Mmm, forgot to mention Help:Style/White space as a candidate for renaming — blackx (talk|contribs) 09:39, 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)

Don't worry Help talk:Category is in my todo list :) I'll get back to all this after completing more urgent tasks. -- Kynikos (talk) 02:52, 27 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.

-- Kynikos (talk) 19:05, 13 January 2018 (UTC)

Ideal features

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 (Wiki Monkey 5 - no search yet)	No
Differentiate between discussions where my post is the latest or not	Yes	Yes	No
Assign priority levels to the saved discussions	Yes	Yes (Wiki Monkey 5 - due dates)	No
Also allow saving generic notes in the saved discussions list, e.g. as a reminder to start a discussion about something	Yes	Yes (Wiki Monkey 5)	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

Implementation

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)

MediaWiki extension

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?

-- Kynikos (talk) 19:05, 13 January 2018 (UTC)

User script

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!).

-- Kynikos (talk) 19:05, 13 January 2018 (UTC)

Periodical report

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.

-- Kynikos (talk) 19:05, 13 January 2018 (UTC)

Hybrid solution

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)

This is probably the most manageable solution: Wiki Monkey 5 comes with an optional Python server, so it's going to be much easier to integrate it with wiki-scripts, perhaps it could even be imported as a normal module :)

For the moment Wiki Monkey implements a simple "bookmark" feature that allows to save pages or sections with due dates and notes. If somebody is interested to try it, I've updated the documentation, but if tl;dr:

1. Install wiki-monkey^AUR;
2. Run wiki-monkey-gencert to generate an SSL certificate;
3. Read the output of wiki-monkey-gencert and update the ssl_cert and ssl_key values in ~/.config/wiki-monkey/server.conf as instructed;
4. Start wiki-monkey@archwiki.service (as a user service);
5. Put mw.loader.load('https://localhost:13502/WikiMonkey-ArchWiki.min.js'); in your User/common.js page;
6. Visit https://localhost:13502/WikiMonkey-ArchWiki.min.js to install in the browser the SSL certificate previously generated;
7. Refresh a wiki page and the server-aided version of Wiki Monkey should start (fingers crossed).

Optional, for who would like to try only the bookmarks functionality and disable all the rest, replace the content of ~/.config/wiki-monkey/client.json with:

{
  "#default": {
    "default_all_plugins_disabled": true,
    "Bookmarks": {"enabled": true}
  }
}

More on minimization, it's possible to prevent Wiki Monkey from launching automatically at every page load by following the "WM" menu in the top-right corner of any page, then going to the "about" tab and disabling the automatic launch at the bottom of the list: this will only leave the "WM" link in every page, and only after manually following it the application will launch.

-- Kynikos (talk) 17:29, 5 December 2018 (UTC)