On Sat, Sep 6, 2014 at 8:03 AM, Todd Allen toddmallen@gmail.com wrote:
Erik, One huge thing is that article talk pages are not only for discussions, but also for metadata (article assessments, history, Wikiproject data, as examples from the English Wikipedia). The top of the talk page also, on many pages, serves notices and FAQs to new visitors to the talk page.
Yes, this is supported in Flow through wiki-editable headers. These are community-editable like a wiki page. LQT simply used the existing talk page for this purpose and hooked into its history and permissioning, while Flow manages them separately, and its history features are still very rudimentary for that reason.
For reviews like that, it may be necessary to have wikitext act as wikitext, another very significant concern. ("Your use of Template:Example is what's causing the text formatting to break in that section, because it does like this: (insert example). You should actually use {{example|arg1|arg2}}.")
There's nothing in Flow's design that makes this impossible. There are some inconsistencies to work through due to the use of Parsoid's HTML for comment storage, and some extensions that may just be fundamentally incompatible with a comment-based approach in their current form (e.g. page-level translation, etc).
We need the ability to rapidly archive "forum" style posts or stuff that's become unproductive, and we need -any- editor able to do that, not just admins.
Flow has a few features relevant to this right now, all still experimental:
- You can hide a topic from view (collapses it, others can undo) - You can summarize or "close" a topic (others can reopen, both actions update the summary, close also collapses) - You can edit a topic's title - You can hide an individual comment (collapses it, others can undo)
In the current permission system (which is easy to change) the only thing that is lightly restricted is editing other people's comments.
The underlying reasoning here is to try to support patterns that exist in our community, while discouraging problematic changes. Comments that solely consist of personal attacks can still be collapsed by anyone, editing is discouraged except in special circumstances (and hence restricted to admins); users don't have to monitor their own comments for inappropriate edits.
Whether that's correct or not, I personally don't have a strong opinion on. In LQT, we left comments openly editable, and I never observed a problem with it; I think the arguments on both sides of this issue are a bit out of proportion.
Back in 2004 I tried a little experiment by creating https://en.wikipedia.org/wiki/User:Eloquence/Comment_policy and adding it to my signature, to see if a subtle indicator would have more people actually do anything interesting with my comments. It never did. A year before I also tried to introduce a policy called "Remove personal attacks" on en.wp: https://en.wikipedia.org/w/index.php?title=Wikipedia:Remove_personal_attacks...
This was hotly debated, and when/where to edit other people's comments is actually still somewhat ambiguous in policies across wikis. English Wikipedia acknowledges: "There is no official policy regarding when or whether most personal attacks should be removed, although it has been a topic of substantial debate. "
Just yesterday, as I was talking with Fram on Danny's talk page about his .. slight escalation, another user popped in striking out Fram's comments, then another user reverted that, ... so, there's a fair bit of potential for conflict in this, which we do see a little bit of every day.
German Wikipedia more explicitly encourages anyone to remove attacks except people who are the subject of them, but cautions that users who are subject of personal attacks should be careful, because it can exacerbate a conflict. It then proceeds to explain that administrators are encouraged to completely delete personal attacks using revision deletion. https://de.wikipedia.org/wiki/Wikipedia:Keine_pers%C3%B6nlichen_Angriffe
I think the strongest argument to keep comments openly editable, at least initially, is that it's most consistent with policies as currently written (most policies I've seen generally discourage editing other people's comments, but have a few exceptions like the one above). If, after much debate, communities want to adopt different policies, then Flow's permissioning could be changed to reflect them. Keeping the "Hide" type functionality in place for now would be a good way to play with alternatives without immediately limiting options.
We need the ability to have real archives; again, infinite scroll with or without search is nowhere near a replacement for that.
100% agreed. But with actual metadata for comments that's structured and searchable, you can build much better search features -- search by author, by date range, or even categorize/tag individual threads. Archives in a well-built discussion system can be much more useful than the current system of copying text around.
We need the ability to easily wikilink to specific sections.
Again, none of that is limited by the architecture. Right now you can - - wikilink to a Flow board ([[Talk:Flow]]) - wikilink to a topic on a board ([[Topic:Some id|Some title]]) - URL-link to a specific version of that topic
The history features are pretty rudimentary right now, as noted above; that's mostly because the project (as noted in the original message) decided to get rid of LQT's tie-in into the page architecture of MediaWiki. That's an expensive decision, because by treating comments as pages, you get a lot of stuff for free -- but it's motivated by a desire to build UIs and an overall storage and retrieval architecture that really make sense for a discussion system, rather than a document mode system. So give them time to build out the scaffolding.
With Flow, the issue is flawed design. Supplanting current talk page functionality will not work. We need the flexibility of subpages and freely editable documents.
These are just assertions, however. I liked your earlier comments because they are testable against the architecture (even if the current implementation, early as it is, will fail many of these tests). What real world needs cannot be met by a comment-centric architecture for .. commenting? How important are they?
Erik