On Sat, Sep 6, 2014 at 8:03 AM, Todd Allen <toddmallen(a)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_attack…
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
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation
