User:Isarra/talk



Let's start at the beginning.

Talkpages suck. Now they're awesome in many ways, but because that's all they are - pages that are used for talking - they are harder to use than they really need to be. But because they are pages, and because people talk on them, they have certain features that do make them useful, and have developed certain workflows through which folks approach them. Though the things themselves need replacing, ideally these useful aspects and workflows will be largely maintained.

At some point folks decided the solution to the problem of replacing talkpages was to implement some sort of message board - a thing somewhat like a forum, with posted comments and replies each acting as their own object on the board - and thus we've gone through a few implementations: LQT, Message Wall, comments on articles. All, in various ways, kind of sucked, but Message Wall proves it is at least doable and can potentially be an improvement (whereas even that potential is often debated with LQT).

A message board-type thing
Let's just start from the beginning with the message board.

A message board consists of three things:
 * A container - the page on which it appears, or potentially any space where a bunch of threads wind up if it can be arbitrarily inserted like fora using Extension:DPLforum. Basically the container holds the threads.
 * The container contains:
 * Threads
 * Filters
 * Searchability
 * A set of actions/tools - delete, lock, add a thread/topic/whatever, mark all read


 * Threads - related groupings of comments/replies, also potentially referred to as 'discussions' if one wants to be optimistic about the nature of the project. On a talkpage a thread would be analogous to a section.
 * These might be attached to a particular page or topic, but a single thread could appear in multiple containers as relevant - for a thread about how a policy applies to an article, it could appear in both the article's talk container and the policy's (just don't ask how the thread would figure out that it is relevant to both of these).
 * Each thread would have a title for the specific discussion, say, "Proposal to revoke BWilkins' adminship" - after which would come the first poster's comment explaining why they don't want BWilkins to be an admin, and the rest of the ensuing drama would take place in subsequent reply comments indented according to which particular other person the each poster is inclined to yell at at the time.
 * A thread contains:
 * Comments
 * Titles
 * A set of actions/tools - edit, delete, lock, etc
 * Collapsibility
 * General reply functionality
 * Tagging/categorising functionality
 * General information about the thread - Time, commenters involved, number of replies, containers it shows up in


 * Comments - these make up the threads, either starting a thread, or replying to another comment. All comments in a thread are children of either other comments or the thread title. The first comment is a child of the title, as would be any outdented comments getting back to the original point or merged in comments from a duplicate thread, if such is supported. The rest reply and discuss like civilised people. Things. Objects.
 * Each comment contains:
 * Poster's username, avatar, user information, actions on user (block, directly contact, etc)
 * Message - the actual content/text of the comment
 * Time of post, other info
 * A set of actions/tools - edit, delete, move, protect, etc
 * Reply/quote functionality

Things to worry about
Now that, of course, is pretty basic. Doesn't account at all for searchability, what will be doable through the API, or how exactly the replying, tagging, etc would actually work.

Requirements

 * It works - can make now threads, reply to comments, read indented converstions...
 * It works in general - normally or without js (though not necessarily prettily), in stupid skins, from the API, etc
 * All the usual things - multi-user interaction, threading, editing, locking/protecting, archiving, whatever
 * A personal feed that gets all watched threads into some grand feed - probably just integrate this into the watchlist
 * Supports wikimarkup and VE
 * Allows watching pages or just specific threads
 * Taggable threads - for searching/filtering
 * Searchable (preferably directly - on the page/whatever so a user can search a specific page/area for a topic)
 * Some way to distinguish between read/unread comments, and to mark comments as read/unread

There has been confusion about the distinction between a personal feed and a user feed. Consider the user feed essentially their talkpage - easily accessed from their personal feed (watchlist), but a separate feed that anyone can access. All pages will have an associated feed; the personal feed includes all relevant threads off any of these, either because the page is watched or the thread is.

How shall discussions - threads, comments, tags - exist in the database?
Should comments each be their own pages within some new namespace, with parent containers and threads being simply information about those pages stored as metadata or such, or should comments be something else entirely, contained in new tables with their own implementation distinct from those of revisions and pages?

While probably easier to set up a basic working model with pages, it seems messy and ultimately unintuitive. It would confuse the search when searching all pages - a comment is not a page in the user's mind - and also create issues with how metadata like parent threads and containers and tags are handled, and subsequently also with the searchability of any of that.

Either way would probably work, but which is chosen will affect development time as well as what all can reasonably be done on the front-end.

How shall discussions be sent to the browser?
There are two ways to do this - have the browser dynamically assemble the page with javascript, or assemble the page prior to sending it.

There is absolutely no good reason to do the former. Dynamic assembly is only useful for two things - infinite scrolling and draining batteries. This is probably not somewhere where we would need infinite scrolling, but even if we do it should still at least build the initial chunk of page before sending it.

General javascript functionality, however, is a must.

Transition from talkpages
There will be a transition in any already existing wiki - talkpages will be archived, and thread containers (message boards, if you prefer) will replace them. To not do this - to only replace on some pages, or only use the thread containers on new ones, would be very confusing especially for new users and just result in a horrible sort of mess.

Of course there is the issue of how, but given most projects have their own ways of archiving things they'd probably be able to come up with the best things to do with their archives themselves. This, however, assumes all projects would have the means to implement something following their usual methods (which tend to be done manually especially on smaller projects), which is not a valid assumption.

Due to the arbitrary ways in which users start talkpage threads and reply to each other manually (for instance creating no new section for a new discussion and using strange section headers, outdents, indents, indents of random amounts, etc) there is no real way talkpage discussions could be automatically migrated (someone might want to do this because if it were doable then the old ones would benefit from the searchability of the new system, and also allow for more easily linking back to old discussions, or even resuming them, with the new system).

LQT, however, probably would be migrateable, though the difficulty may depend on the implementation of the new system. May also not.

Users who hate being constrained
Block button works even better at constraining people.

Layouts
General gists. Based in part on the layout at the top of this page, as it should wind up something like that.

Comments
Comments may or may not have avatars, may or may not have user information, may or may not use space various ways. This will affect the layout.

Mockups would be here had I not misplaced them all when I broke balsamiq. Shut up.

Replying
Replying will probably be like with lqt or bugzilla, but smarter. There will need to be a non-js fallback (like the current LQT implementation) if we don't want users rioting, but we probably want the normal replying on the page itself (like how bugzilla does it, though slightly more complicated), just uncollapsing out of the space after the post to which the reply is directed. The parent.

Threads/container
Threads are probably pretty straight-forward - have title, comments, various tools. Sort out which and where later.

Container won't have a whole lot besides threads. Might need a ToC. Remains to be seen.

Personal feed (watchlist)
This presents a whole lot of unique problems that don't show up anywhere else.
 * How do we include the title of the page the threads belong to? (What if a thread belongs to containers for multiple watched pages?)
 * Would this be the only one where read/unread messages comes into play?
 * Will read messages fall off the feed entirely, collapse, what?
 * Threads that aren't specifically watched on watched pages - special? Perhaps start out collapsed as a notification that hey, there's a discussion happening without actually splaying the entire discussion on the page?
 * How will it interact with other watchlist stuff - page edits, notices, etc? Just a separate tab? What if when the discussion happened is relevant to when the edits happened?