User:Oiyarbepsy/Wikitalk: The Next Generation

Mediawiki is currently developing Flow, a new program that might replaces all talk pages on Wikipedia and other Mediawiki projects. The are quite a few serious problems with using wiki markup for discussion, and this page is brainstorming ways that wikitalk could be improved to address the same problems that Flow aims to improve.

Key Elements edit

Wikitalk:TNG would need the following elements:

  • Permanent links - Links to a particular section must be permanent, even when archiving. We shouldn't need to rely on bots for such a basic function, and most archive bots don't fix the links anyway.
  • Better archiving - Archived topics need to be on the same page as the active topics, unless a talk page is very large. The topics could be collapsed or changed to links, but should remain in their original location on the page when this happens. Option 2 would maintain archiving as current, but with permalinking.
  • New topics on top - For consistency with the rest of the internet. This is also required to achieve the same page archiving. Option 2 wouldn't require this, but it is still recommended.
  • A visual editor for talk pages - This visual editor would have significantly different functions than the article version. It would include basic options like reply, new post, new topic, and possibly more complex ones, such as "nominate this page for deletion"
  • Auto-sign - Four tildes needs to be a thing of the past. It is too easily forgotten and too easily forged and abused.

Two options are presented below. Option 1 places each discussion topic on a separate page. Option 2 keeps discussions on talk pages as now.

Option 1 - separate discussion pages edit

  • Separate topic from talk A topic is a distinct thing from a talk page. A talk page should be nothing more than a container for the topics. All discussion would be in the Topic namespace created for Flow, while the talk pages would consist of a series of transclusions.
  • Permalinks Below each topic heading would be text giving the permanent link: "Permanent links: In Wikipedia Topic:Test, external https://en.wikipedia.org/wiki/Topic:Test" The Wikipedia one would be a link that leads to the separate topic page. All editors linking to a discussion should link to this Topic page. Bots could correct section links on talk pages to Topic links. Links would be the topic name given by the original poster followed by a number in parentheses, based on how many times that topic name has been used by previous editors. Topic pages could be renamed (moved), but the Mediawiki software would append the number in parentheses in the rename process, and leave a Topic redirect as with other page moves.
  • Topic headings All Topic pages would have just below the title the text: "This topic appears on Talk:Test" - all pages that transclude it will be listed. If the Topic is not transcluded, the text would read "This topic is not active on any page."
  • New topics Talk pages would have a new topic button. Pressing the button will ask the user for the name of the topic. Then the software would create the Topic page, add a transclusion to the talk page, and prompt for the initial post using a visual editor type interface. Entering wikicode would be an option. The elements of posting would then apply.
  • Posting Each topic would have a new post button next to the header. Pressing the post button, would scroll to where the post will appear at the bottom of the topic. Then, the text below it will be visually pushed down and a box will appear where the user can enter their post. After hitting the place post button, the software would add a signature and reply button at the end of each paragraph. There would be a manual signature option, with the warning to only do this if you know what you're doing.
  • Replies Each post would end with a reply button. The location of this button would be marked in the wikicode by the template placed when it was posted. Like any other post, the text below will be pushed down, and ask for the comment. When the comment is complete, the software will count the colons and indent the comment properly.
  • Archiving Talk pages would be archived by changing the transclusions to an archived topic template. This template could either produce a simple link, or could create a collapse box, or other options. If a talk page gets long, a group of fifty or so could be placed in a {{collapse}} box. For very active pages, a separate archive page would still be required. Since all links should be to the Topic pages, which don't change when archived, links won't be broken.
  • Tangents Next to the reply button appearing on each post, there would also be a "new topic based on this post" button. This button would create a new topic, quote the post, and prompt for a response. The user would also give the choice between moving the post or copying it - that is, they could remove the post from its original location. This would allow tangents to be placed in a different topic, helping to keep discussions on-topic.
  • Topics on multiple pages Next to the Topic heading would be buttons for "add to another talk page" and "remove from this talk page". This would allow transclusions to be added to another page, allowing the same topic to be discussed simultaneously on two talk pages. The remove option would allow to remove the Topic if placed at the wrong page. Removing would leave behind a small note indicating that the topic has been removed. The remove option would not be available if the Topic is only on a single talk page, as this would orphan the Topic.
  • Talk page headers Talk page headers would be on a separate page so talk pages could be nothing but transclusions. More explanation below under The Nature of Talk Pages.
  • Wikicode Topic pages would still be editable with wikicode if desired. Talk pages, being nothing but transclusions, would not need to be edited by most editors.

The nature of talk pages edit

Under this proposal, Topic pages would be very similar to talk page we have now, except that they would only cover a single topic. Talk pages, on the other hand, would be nothing but transclusions. The wikicode of a talk page would look something like this (this example for WP:VPP):

{{Talk header for this page}} <!-- This template automatically points to a page outside the talk namespace that holds the talk page header. Location to be determined -->
{{Topic:Wykop.pl (1)}}
{{Topic:Policy on removing expert tags (1)}}
{{Topic:Remedy six of the infoboxes arbitration case (2)}} <!-- We're pretending that there was a previous topic with the same name for this example -->
{{Topic:Nominations for the 2014 English Wikipedia Arbitration Committee elections are open (1)}} <!-- This one topic would be on many talk pages -->
{{Topic:Obstructive article names (1)}}
{{Topic:Request for Comment (153)}} <!-- This topic title has probably been used hundreds of times -->
{{Topic:RFC/U (4)}}
{{Topic:A chronic problem in reaching consensus (1)}}
{{Topic:WP:BRD as essay (1)}}
==Recently archived==
{{archived|Topic:African-American Categories (1)}} <!-- This template could create a simple link, or it could collapse it, or other possibilities -->
{{archived|Topic:Proposal to elevate Wikipedia:Consistency in article titles to guideline status. (1)}}
<!-- A whole bunch of recently archived ones not shown -->
==Archives==
{{archivebox}} <!-- or some other archive template. This could also be shown in the talk page header. -->

Because the talk page contents are purely technical, we could limit who could edit the talk namespace. The talk namespace could only be edited by the new post button or by a new usergroup, talk page editors. All administrators and template editors would have this right, as well as others that demonstrate they know wikicode well enough to make edits. Bots would also receive this right when needed to archive or other functions. Any page in any talk namespace would be so restricted, and any page within the talk namespace would have the new post button, unless {{talkarchive}} or a similar template is on the page. Topic pages would have no such restriction. Talk headers, being outside the talk namespace, would also have no such restrictions.

Advantages edit

  • Links to Topics are permanent unless explicitly deleted. There is no chance of accidentally breaking links
  • Discussions could appear on multiple pages at once. A post on one would appear on all.
  • Solves the user talk problem. Posting on another user's talk page would transclude the Topic to both user's pages, so it wouldn't matter where the reply was placed.
  • Allows a topic to be easily deleted while preserving the talk page. Also allows the reverse, deleting a talk page while retaining the topics. While there is no obvious use for the latter, having the technical ability to do so might be useful some day.

Disadvantages edit

  • Searching a talk page is significantly more complex. The software would need to track not only which topics are on a talk page, but every topic that ever was on a talk page.
  • Watchlisting is more complex. Fully watchlisting a talk page means watching the page and all of its topics, while partially watchlisting it would only tell you about new posts. This is both good and bad, as it also allows user to watch one discussion without the whole page. The watchlist entries would also somehow need to specify what talk page the Topic is on.
  • This would be a major change to how talk pages work. People would screw up, and fixing goofs would take some time. It might be necessary to restrict talk pages as noted above to avoid users accidentally making big messes out of talk pages.

Option 2 - discussion remains on talk pages edit

  • Talk pages remain the same Talk pages would mostly remain the same as now. Changing to a new topics at top is a good idea, but not required for this.
  • Permalinks Below each topic heading would be the permanent link: "Permanent links: In Wikipedia Permalink:Test, external https://en.wikipedia.org/wiki/Permalink:Test". Permalinks would automatically redirect to where they are linked.
  • New topics Talk pages would have a new topic button. Pressing the button will ask the user for the name of the topic. Then the software would create the heading and permalink, and prompt for the initial post using a visual editor type interface. Entering wikicode would be an option. The elements of posting would then apply.
  • Posting Each topic would have a new post button next to the header. Pressing the post button, would scroll to where the post will appear at the bottom on the page. Then, the text below it will be visually pushed down and a box will appear where the user can enter their post. After hitting the place post button, the software would add a signature and reply button at the end of each paragraph.
  • Replies Each post would end with a reply button. The location of this button would be marked in the wikicode by the template placed when it was posted. Like any other post, the text below will be pushed down, and ask for the comment. When the comment is complete, the software will count the colons and indent the comment properly.
  • Archiving Talk page archiving would function as it does now. However, archive bots would be required to place the text on the archive page before removing it from the main page. The permalink would be moved with the old discussion, and the permalink would automatically link to the new location.
  • Tangents Next to the reply button appearing on each post, there would also be a "new topic based on this post" button. This button would create a new topic, quote the post, and prompt for a response. The user would also give the choice between moving the post or copying it - that is, they could remove the post from its original location. This would allow tangents to be placed in a different topic, helping to keep discussions on-topic.
  • Wikicode Talk pages would still be editable with wikicode if desired. Bots would patrol talk pages and add permalinks to headings when editors fail to do so.

Permalink namespace edit

A new namespace would be created for permalinks. This namespace could be called Permalink or Topic or some other name. Permalinks would be the name of the heading followed by a number in parenthesis for disambiguation, as topics in option 1 would be named. The Permalink would generally operate like Categories, except:

  • If only one page links to a permalink, it would redirect there. If multiple pages link there, it would list them like categories.
  • Whether a redirect or clicked link, the user would be jumped to where the permalink is located, instead of the top of the page.

To ensure permanence, the software would block any edit that would orphan a permalink. This could be overridden only by administrators, since the only reason to do this is when deleting a discussion entirely. However, in most cases, a simple note that the discussion was removed should be used instead, rather than removing the permalink.

Advantages edit

  • The general function of talk pages would remain the same, so archiving, watchlisting and searching would mostly be unchanged.

Disadvantages edit

  • The user talk problem, of which page to post to, would remain unfixed.
  • Topics would remain stuck to a single page, and there would be no ability to have a discussion on multiple talk pages.
  • The permalinks wouldn't necessarily be permanent. There is always the risk that permalinks could be lost or moved to the wrong place by accident.

See also edit