LiquidThreads 3.0/Design issues
This page is obsolete. It is being retained for archival purposes. It may document extensions or features that are obsolete and/or no longer supported. Do not rely on the information here being up-to-date. |
This is a list of pending design issues in the LiquidThreads 3.0 backend update.
It seems pointless to reimplement these features with the new backend (particularly considering the substantial change in backend design) without first considering their design.
Refactoring the comment structure
editOn existing MediaWiki talk pages, because they are stored as unstructured text, any user can refactor, edit or delete another user's comments, or split, merge, and otherwise reorganise conversations in aggregate. While not all uses of these behaviours are necessarily desirable, and it may not be necessarily desirable to allow all users to undertake all of these actions, it is clear that these actions fulfil a social function in the existing commenting system. Any replacement needs to include an analogue to the administrative functions that this functionality makes unnecessary.
In the existing LiquidThreads code base, this is achieved by allowing all users to edit other users' posts, by providing functionality for splitting and merging threaded discussions, and by not displaying posts which have no content.
In general:
- I want to be able to remove offensive, trollish or spammy posts without needing to involve an administrator.
- I want to be able to reorganise conversations as they evolve so that they can be better understood.
History and Auditing
editOn existing MediaWiki talk pages, because changes to discussion pages are versioned changes to unstructured data, they are easily audited. They appear in aggregate on user contribution pages, in recent changes, and in individual discussion page histories.
Because LiquidThreads 3.0 entails a migration to structured data away from the auditing mechanisms afforded by using MediaWiki pages to store comment text, analogues to these features need to be developed to allow auditing of comment and topic history. This problem is compounded in relation to other commenting systems by the ability to refactor comment structure, as described above.
In general:
- When I view a discussion page, I want to be able to understand the chronology of a discussion or post, so that I can understand posts in their proper context and attribution.
- I want to be able to see which other places a user has commented on, so that I can understand them better.
- I want to be able to view recent comments on a wiki or page, so that I can keep abreast of developments.