How about just converting those threads back to Wikitext, instead? That script already exists, I've seen it used on Mediawiki. Will it mess up the pages that have already been converted using that script?

Bottom line, it makes no sense to replace software that was considered barely suitable when it was first developed with "new" software that can't even do what that old, long-neglected software could do...and in several cases, there is no intention to ever add the features already available using Wikitext.

As expectations increase for project users to post their comments/concerns/ideas/observations on Mediawiki, the use of Flow will become a barrier for participation.

Risker/Anne

On 16 March 2015 at 20:51, Nick Wilson (Quiddity) nwilson@wikimedia.org wrote:

LiquidThreads (LQT) has not been well-supported in a long time. Flow is in active development, and more real-world use-cases will help focus attention on the higher-priority features that are needed. To that end, LQT pages at mediawiki.org will start being converted to Flow in the next couple of weeks.

There are about 1,600 existing LQT pages on Mediawiki, and the three most active pages are VisualEditor/Feedback, Project:Support_desk, and Help_talk:CirrusSearch.[1] The Collaboration team has been running test conversions of those three pages, and fixing issues that have come up. Those fixes are almost complete, and the team will be ready to start converting LQT threads to Flow topics soon. (If you’re interested in the progress, check out phab:T90788[2] and linked tasks.) The latest set is visible at a labs test server.[3] See an example topic comparison here: Flow vs LQT.[4])

The VisualEditor/Feedback page will be converted first (per James' request), around the middle of next week. We’ll pause to assess any high-priority changes required. After that, we will start converting more pages. This process may take a couple of weeks to fully run.

The last page to be converted will be Project:Support_desk, as that is the largest and most active LQT Board.

LQT Threads that are currently on your watchlist, will still be watchlisted as Flow Topics. New Topics created at Flow Boards on your watchlist will appear in your Echo notifications, and you can choose whether or not to watchlist them.

The LQT namespaces will continue to exist. Links to posts/topics will redirect appropriately, and the LQT history will remain available at the original location, as well as being mirrored in the Flow history.

There’s a queue of new features in Flow that will be shipped over the next month or so:

• Table of Contents is done
• Category support for Flow Header and Topics is done
• VE with editing toolbar coming last week of March (phab:T90763) [5]
• Editing other people’s comments coming last week of March (phab:T91086)
• Ability to change the width & side rail in progress, probably out in

April (phab:T88114])

• Search is in progress (no ETA yet) (phab:T76823)
• The ability to choose which Flow notifications end up in Echo,

watchlist, or both, and other more powerful options, will be coming up next (no ETA yet)

That being said -- there are some LiquidThreads features that don’t exist in Flow yet. We’d like to hear which features you use on the current LQT boards, and that you’re concerned about losing in the Flow conversion. At the same time, we’d like further suggestions on how we could improve upon that (or other) features from LQT.

Please give us feedback at https://www.mediawiki.org/wiki/Topic:Sdoatsbslsafx6lw to keep it centralized, and test freely at the sandbox.[6]

Much thanks, on behalf of the Collaboration Team, Quiddity (WMF)

[1] https://www.mediawiki.org/wiki/VisualEditor/Feedback and https://www.mediawiki.org/wiki/Help_talk:CirrusSearch and https://www.mediawiki.org/wiki/Project:Support_desk [2] https://phabricator.wikimedia.org/T90788 [3] http://flow-tests.wmflabs.org/wiki/Testwiki:Support_desk and http://flow-tests.wmflabs.org/wiki/VisualEditor/Feedback [4] http://flow-tests.wmflabs.org/wiki/Topic:Qmkwqmp0wfcazy9c and

https://www.mediawiki.org/wiki/Thread:Project:Support_desk/Error_creating_th... [5] https://phabricator.wikimedia.org/T90763 , https://phabricator.wikimedia.org/T91086 , https://phabricator.wikimedia.org/T88114 , https://phabricator.wikimedia.org/T76823 [6] https://www.mediawiki.org/wiki/Talk:Sandbox

-- Nick Wilson (Quiddity) Community Liaison Wikimedia Foundation

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On Mon, Mar 16, 2015 at 6:02 PM, Risker risker.wp@gmail.com wrote:

How about just converting those threads back to Wikitext, instead? That script already exists, I've seen it used on Mediawiki. Will it mess up the pages that have already been converted using that script?

Bottom line, it makes no sense to replace software that was considered barely suitable when it was first developed with "new" software that can't even do what that old, long-neglected software could do...and in several cases, there is no intention to ever add the features already available using Wikitext.

As expectations increase for project users to post their comments/concerns/ideas/observations on Mediawiki, the use of Flow will become a barrier for participation.

As someone who used LQT a lot, I'd say I'd much rather flow replace the pages I maintained using LQT. Maybe you dislike flow, but it's *way* more useful than wikitext for discussion. I never want to go back to the days where I needed to discuss things with wikitext ever again. Wikitext discussion pages are just the absolute worst.

- Ryan

On Mon, Mar 16, 2015 at 6:02 PM, Risker risker.wp@gmail.com wrote:

How about just converting those threads back to Wikitext, instead? That script already exists, I've seen it used on Mediawiki. Will it mess up the pages that have already been converted using that script?

Bottom line, it makes no sense to replace software that was considered barely suitable when it was first developed with "new" software that can't even do what that old, long-neglected software could do...and in several cases, there is no intention to ever add the features already available using Wikitext.

As expectations increase for project users to post their comments/concerns/ideas/observations on Mediawiki, the use of Flow will become a barrier for participation.

Risker/Anne

Converting LQT to Wikitext would lose the major benefits of: * per-Topic watchlisting, * per-Topic category support, * Sortable views (with Filterable views on the roadmap [1]), as well as the immensely easier process for new-editors to be able to participate in discussions, and be notified about replies.[2]

[1] See Pau's design notes at https://docs.google.com/presentation/d/1DQabV3mjE9ReV9zs1qAi8u_A5560QEVX4aK9... and Hhhippo's ideas/notes at https://en.wikipedia.org/wiki/User:Hhhippo/Flow/TOC_and_filters [2] The feedback from the ongoing trial at the Frwiki newcomers' helpdesk, is that the Flow version has better engagement, with more editors returning to give further information, or ask a followup question, or just to say thanks. https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Forum_des_nouveaux/Flow https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Forum_des_nouveaux

Flow has been improving over the months. I hope you'll give it a try at the sandbox, check out the list of upcoming features (in 1st message), and let the team know what feature(s) you're most concerned about. The more specific the feedback, the more it will help influence the order new features are developed in.

Thanks, as always :) Quiddity (WMF)

Nick Wilson (Quiddity) schreef op 2015/03/16 om 19:03:

On Mon, Mar 16, 2015 at 6:02 PM, Risker risker.wp@gmail.com wrote:

...

How about just converting those threads back to Wikitext, instead? That script already exists, I've seen it used on Mediawiki. Will it mess up the pages that have already been converted using that script?

Bottom line, it makes no sense to replace software that was considered barely suitable when it was first developed with "new" software that can't even do what that old, long-neglected software could do...and in several cases, there is no intention to ever add the features already available using Wikitext.

As expectations increase for project users to post their comments/concerns/ideas/observations on Mediawiki, the use of Flow will become a barrier for participation.

Risker/Anne

Converting LQT to Wikitext would lose the major benefits of:

• per-Topic watchlisting,
• per-Topic category support,
• Sortable views (with Filterable views on the roadmap [1]),

as well as the immensely easier process for new-editors to be able to participate in discussions, and be notified about replies.[2]

But it would provide the advantage of using the standardized discussion technique used in virtually all Wikimedia installations. There doesn't seem to be any particular user demand to adopt Flow, so there's no reason to believe it will gain any more traction than LQT ever did.

KWW

On Mon, Mar 16, 2015 at 11:21 PM, Kevin Wayne Williams kwwilliams@kwwilliams.com wrote:

There doesn't seem to be any particular user demand to adopt Flow, so there's no reason to believe it will gain any more traction than LQT ever did.

There was significant community interest and momentum behind LQT including various votes to enable it [1], and there is significant interest in Flow now [2]. The main thing that prevented LQT from wider adoption was not lack of community interest, it was our decision to put the project on hold due to both major architectural concerns and resource constraints at the time. We've committed to providing an upgrade path, and this is our follow-through to that commitment.

Our main objective in Flow development is to solve for progressively more challenging collaboration/conversation use cases well, and to demonstrate positive impact at increasing scale, with the goal of providing a better experience for new and experienced editors alike. We recognize that we still have a long way to go, but we can already demonstrate that the system does one thing well, which is to make the process of using talk pages much more understandable for new users:

https://www.mediawiki.org/wiki/Flow/Moderated_Testing,_November,_2014:_talk_...

We're also seeing, as Nick pointed out, that users in a mentorship use case are more likely to follow-up with their mentors. This is a pretty big deal -- quantitative research shows that this type of mentorship improves engagement and retention of new users. [3]

So mentorship is an obvious early stage use case, even if the rest of a community functions through traditional talk pages. "Village pump" type pages that are fairly distinct from article talk pages are another obvious use case where a more forum-like system can relatively quickly outperform the talk page based approach that is rife with edit conflicts and other annoyances. We are trialing the first such use case in Catalan with lots of community participation.

As for inconsistency and fragmentation of mediawiki.org, if anything, the conversion of LQT pages on mediawiki.org will create greater consistency as we're already using Flow on Beta Features talk pages ( https://www.mediawiki.org/wiki/Talk:Content_translation is a nice example of a feedback page with lots of continuous and substantive comments from experienced users).

Flow may not serve major use cases on English Wikipedia today, or tomorrow; that's okay. Smaller projects are often happy to adopt technologies that may not meet the expectations of a large, mature community like en.wp yet, because they may be more concerned with the experience of new users than with the risks or inconveniences associated with features in earlier stages of development. (I am not dismissing either risks or inconveniences in saying so, as the requirements do of course differ at different scale.)

We, in turn, remain committed to building tools that serve users well, continuously improving, and continuously demonstrating value through data and qualitative validation. [4] This is but a small step, but it's an important one.

Erik

[1] https://phabricator.wikimedia.org/search/query/radjv9rJZNLU/#R [2] https://www.mediawiki.org/wiki/Flow/Rollout [3] http://arxiv.org/pdf/1409.1496v1.pdf [4] What we learn is summarized in our quarterly reviews, most recently: https://upload.wikimedia.org/wikipedia/commons/5/5f/Collaboration_Q3_2014-15...

Hi Nick, I'm glad the Foundation is finally valuing a usable discussion system.

Unfortunately, there are some serious issues with Flow which will prevent my use of it in production if not addressed in full:

* Administrators *must* be able to to see a deleted Flow board without undeleting it (T90972 https://phabricator.wikimedia.org/T90972) * Ordinary users *must* be able to move topics between boards (T88140 https://phabricator.wikimedia.org/T88140) * Ordinary users *must* be able to edit AND move AND indent AND dedent other users' comments (T78253 https://phabricator.wikimedia.org/T78253) * An arbitrary indentation level *must* be allowed, with optional facilitations for adding an {{outdent}}-like marker * Every basic functionality (including but not limited to the "preview" button) *must* work without relying on JavaScript (T60019 https://phabricator.wikimedia.org/T60019)

I see that the implementation of many features was delayed at the initial stage of development, but they can't be ignored when trying to deploy such a software in production. Thank you.

Il 17/03/2015 01:51, Nick Wilson (Quiddity) ha scritto:

LiquidThreads (LQT) has not been well-supported in a long time. Flow is in active development, and more real-world use-cases will help focus attention on the higher-priority features that are needed. To that end, LQT pages at mediawiki.org will start being converted to Flow in the next couple of weeks.

There are about 1,600 existing LQT pages on Mediawiki, and the three most active pages are VisualEditor/Feedback, Project:Support_desk, and Help_talk:CirrusSearch.[1] The Collaboration team has been running test conversions of those three pages, and fixing issues that have come up. Those fixes are almost complete, and the team will be ready to start converting LQT threads to Flow topics soon. (If you’re interested in the progress, check out phab:T90788[2] and linked tasks.) The latest set is visible at a labs test server.[3] See an example topic comparison here: Flow vs LQT.[4])

The VisualEditor/Feedback page will be converted first (per James' request), around the middle of next week. We’ll pause to assess any high-priority changes required. After that, we will start converting more pages. This process may take a couple of weeks to fully run.

The last page to be converted will be Project:Support_desk, as that is the largest and most active LQT Board.

LQT Threads that are currently on your watchlist, will still be watchlisted as Flow Topics. New Topics created at Flow Boards on your watchlist will appear in your Echo notifications, and you can choose whether or not to watchlist them.

The LQT namespaces will continue to exist. Links to posts/topics will redirect appropriately, and the LQT history will remain available at the original location, as well as being mirrored in the Flow history.

There’s a queue of new features in Flow that will be shipped over the next month or so:

• Table of Contents is done
• Category support for Flow Header and Topics is done
• VE with editing toolbar coming last week of March (phab:T90763) [5]
• Editing other people’s comments coming last week of March (phab:T91086)
• Ability to change the width & side rail in progress, probably out in

April (phab:T88114])

• Search is in progress (no ETA yet) (phab:T76823)
• The ability to choose which Flow notifications end up in Echo,

watchlist, or both, and other more powerful options, will be coming up next (no ETA yet)

That being said -- there are some LiquidThreads features that don’t exist in Flow yet. We’d like to hear which features you use on the current LQT boards, and that you’re concerned about losing in the Flow conversion. At the same time, we’d like further suggestions on how we could improve upon that (or other) features from LQT.

Please give us feedback at https://www.mediawiki.org/wiki/Topic:Sdoatsbslsafx6lw to keep it centralized, and test freely at the sandbox.[6]

Much thanks, on behalf of the Collaboration Team, Quiddity (WMF)

[1] https://www.mediawiki.org/wiki/VisualEditor/Feedback and https://www.mediawiki.org/wiki/Help_talk:CirrusSearch and https://www.mediawiki.org/wiki/Project:Support_desk [2] https://phabricator.wikimedia.org/T90788 [3] http://flow-tests.wmflabs.org/wiki/Testwiki:Support_desk and http://flow-tests.wmflabs.org/wiki/VisualEditor/Feedback [4] http://flow-tests.wmflabs.org/wiki/Topic:Qmkwqmp0wfcazy9c and https://www.mediawiki.org/wiki/Thread:Project:Support_desk/Error_creating_th... [5] https://phabricator.wikimedia.org/T90763 , https://phabricator.wikimedia.org/T91086 , https://phabricator.wikimedia.org/T88114 , https://phabricator.wikimedia.org/T76823 [6] https://www.mediawiki.org/wiki/Talk:Sandbox

For my perspective (sorry if this is covered somewhere I've missed), who made the decision to do this conversion? One of my reasons for interest is that at en.wn we have LQT and *do not want* Flow. (A fairly good summary of the sense of the en.wn community is (1) we would rather LQT than Flow for our comments pages, (2) our comments pages, which are meant to hold up well when edited by people who are utterly clueless about wiki markup, are better off with LQT than as ordinary wiki pages, and (3) we mostly detest LQT and want straight wiki markup for all pages that are part of our project's primary function.)

On Mon, Mar 16, 2015 at 8:51 PM, Nick Wilson (Quiddity) < nwilson@wikimedia.org> wrote:

LiquidThreads (LQT) has not been well-supported in a long time. Flow is in active development, and more real-world use-cases will help focus attention on the higher-priority features that are needed. To that end, LQT pages at mediawiki.org will start being converted to Flow in the next couple of weeks.

There are about 1,600 existing LQT pages on Mediawiki, and the three most active pages are VisualEditor/Feedback, Project:Support_desk, and Help_talk:CirrusSearch.[1] The Collaboration team has been running test conversions of those three pages, and fixing issues that have come up. Those fixes are almost complete, and the team will be ready to start converting LQT threads to Flow topics soon. (If you’re interested in the progress, check out phab:T90788[2] and linked tasks.) The latest set is visible at a labs test server.[3] See an example topic comparison here: Flow vs LQT.[4])

The VisualEditor/Feedback page will be converted first (per James' request), around the middle of next week. We’ll pause to assess any high-priority changes required. After that, we will start converting more pages. This process may take a couple of weeks to fully run.

The last page to be converted will be Project:Support_desk, as that is the largest and most active LQT Board.

LQT Threads that are currently on your watchlist, will still be watchlisted as Flow Topics. New Topics created at Flow Boards on your watchlist will appear in your Echo notifications, and you can choose whether or not to watchlist them.

The LQT namespaces will continue to exist. Links to posts/topics will redirect appropriately, and the LQT history will remain available at the original location, as well as being mirrored in the Flow history.

There’s a queue of new features in Flow that will be shipped over the next month or so:

• Table of Contents is done
• Category support for Flow Header and Topics is done
• VE with editing toolbar coming last week of March (phab:T90763) [5]
• Editing other people’s comments coming last week of March (phab:T91086)
• Ability to change the width & side rail in progress, probably out in

April (phab:T88114])

• Search is in progress (no ETA yet) (phab:T76823)
• The ability to choose which Flow notifications end up in Echo,

watchlist, or both, and other more powerful options, will be coming up next (no ETA yet)

That being said -- there are some LiquidThreads features that don’t exist in Flow yet. We’d like to hear which features you use on the current LQT boards, and that you’re concerned about losing in the Flow conversion. At the same time, we’d like further suggestions on how we could improve upon that (or other) features from LQT.

Please give us feedback at https://www.mediawiki.org/wiki/Topic:Sdoatsbslsafx6lw to keep it centralized, and test freely at the sandbox.[6]

Much thanks, on behalf of the Collaboration Team, Quiddity (WMF)

[1] https://www.mediawiki.org/wiki/VisualEditor/Feedback and https://www.mediawiki.org/wiki/Help_talk:CirrusSearch and https://www.mediawiki.org/wiki/Project:Support_desk [2] https://phabricator.wikimedia.org/T90788 [3] http://flow-tests.wmflabs.org/wiki/Testwiki:Support_desk and http://flow-tests.wmflabs.org/wiki/VisualEditor/Feedback [4] http://flow-tests.wmflabs.org/wiki/Topic:Qmkwqmp0wfcazy9c and

https://www.mediawiki.org/wiki/Thread:Project:Support_desk/Error_creating_th... [5] https://phabricator.wikimedia.org/T90763 , https://phabricator.wikimedia.org/T91086 , https://phabricator.wikimedia.org/T88114 , https://phabricator.wikimedia.org/T76823 [6] https://www.mediawiki.org/wiki/Talk:Sandbox

-- Nick Wilson (Quiddity) Community Liaison Wikimedia Foundation

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Il 17/03/2015 14:05, Max Semenik ha scritto:

On Tue, Mar 17, 2015 at 3:05 AM, Ricordisamoa ricordisamoa@openmailbox.org wrote:

...

• An arbitrary indentation level *must* be allowed, with optional facilitations for adding an {{outdent}}-like marker

Why? Manual indentation just leads to you having to decode these levels sometimes. Soulless machines are better at indenting consistently than us meatbags. Also, my personal opinion is that indenting is just silly and needs to die, not accumulate more cruft.

Software cannot understand which post a message replies to. In case a sensible way of reducing clutter in the interface without limiting indenting options can be found, I'll favor it.

...

• Every basic functionality (including but not limited to the "preview" button) *must* work without relying on JavaScript (T60019 https://phabricator.wikimedia.org/T60019)

Surprise! It's 2015, and web doesn't quite work without JS. Some basics still need to work without it, but very basics.

I have always been proud of contributing to projects that value accessibility more than fancy animations. Flow is a regression in regard to this.

On Mon, Mar 16, 2015 at 8:51 PM, Nick Wilson (Quiddity) < nwilson@wikimedia.org> wrote:

We’d like to hear which features you use on the current LQT boards, and that you’re concerned about losing in the Flow conversion.

Working watchlist functionality, see https://phabricator.wikimedia.org/T76862 and https://phabricator.wikimedia.org/T68876. Yes, LQT's inventing of their own pseudo-watchlist rather sucks, but at least it functions correctly.

Please give us feedback at

https://www.mediawiki.org/wiki/Topic:Sdoatsbslsafx6lw to keep it centralized, and test freely at the sandbox.[6]

No thanks, I prefer this mailing list thread. Feel free to copy this there if you want, but please reply here too

On Tue, Mar 17, 2015 at 9:37 AM, Ricordisamoa ricordisamoa@openmailbox.org wrote:

Software cannot understand which post a message replies to.

It can, and more easily than with raw wikitext, as long as the correct "reply" button is used, i.e. if people actually click reply instead of using the already-there box for creating a new "top-level" post in the topic.

Il 17/03/2015 14:45, Brad Jorsch (Anomie) ha scritto:

On Tue, Mar 17, 2015 at 9:37 AM, Ricordisamoa ricordisamoa@openmailbox.org wrote:

Software cannot understand which post a message replies to. It can, and more easily than with raw wikitext, as long as the correct "reply" button is used, i.e. if people actually click reply instead of using the already-there box for creating a new "top-level" post in the topic.

Of course. I was referring to an hypothetical single "reply" button.

Erik Moeller schreef op 2015/03/17 om 1:39:

On Mon, Mar 16, 2015 at 11:21 PM, Kevin Wayne Williams kwwilliams@kwwilliams.com wrote:

...

There doesn't seem to be any particular user demand to adopt Flow, so there's no reason to believe it will gain any more traction than LQT ever did.

There was significant community interest and momentum behind LQT including various votes to enable it [1], and there is significant interest in Flow now [2]. The main thing that prevented LQT from wider adoption was not lack of community interest, it was our decision to put the project on hold due to both major architectural concerns and resource constraints at the time. We've committed to providing an upgrade path, and this is our follow-through to that commitment.

[snip]

As for inconsistency and fragmentation of mediawiki.org, if anything, the conversion of LQT pages on mediawiki.org will create greater consistency as we're already using Flow on Beta Features talk pages ( https://www.mediawiki.org/wiki/Talk:Content_translation is a nice example of a feedback page with lots of continuous and substantive comments from experienced users).

I'm not arguing that nuking LQT isn't a good idea: that most certainly is. What I object to is this apparent intent to create two tiers of users: one tier that knows how to use the software and another tier that gets accustomed to a partially functional "easy" layer that provides no experience or training in how to maintain the actual project content, with no apparent bridge between the two. Between VE and LQT, newbies get provided with no experience in handling the easy cases of editing until they hit something that the simple tools can't handle, at which time they are suddenly faced with a wall of text that they have no experience in dissecting, parsing, and understanding and are expected to make a change in one of the hard parts. Much better to get them gradually accustomed to wikitext by performing small tasks than to just toss them in the deep end after their crutches break. Yes, there are at least five mixed metaphors in that last sentence, buy you get the drift.

KWW

On 17 March 2015 at 10:49, Brad Jorsch (Anomie) bjorsch@wikimedia.org wrote:

On Tue, Mar 17, 2015 at 10:35 AM, Risker risker.wp@gmail.com wrote:

...

On 17 March 2015 at 09:45, Brad Jorsch (Anomie) bjorsch@wikimedia.org wrote:

...

On Tue, Mar 17, 2015 at 9:37 AM, Ricordisamoa < ricordisamoa@openmailbox.org> wrote:

Software cannot understand which post a message replies to.

...

It can, and more easily than with raw wikitext, as long as the correct "reply" button is used, i.e. if people actually click reply instead of using the already-there box for creating a new "top-level" post in the topic.

The software can tell, but visually it is nearly impossible to determine which message is being responded to when everything has essentially the same indent level.

Granted, but that's because the output format is poor rather than the software being unable to tell.

Thank you, Brad. Is the output format not determined by the parameters in the software?

It just strikes me as weird that the software that we keep being told will improve communication and collaboration is deliberately designed in such a way that it is difficult for the human users (as opposed to the software) to be able to immediately discern who is responding to whom.

Risker/Anne

On 15-03-17 10:56 AM, Risker wrote:

It just strikes me as weird that the software that we keep being told will improve communication and collaboration is deliberately designed in such a way that it is difficult for the human users (as opposed to the software) to be able to immediately discern who is responding to whom.

[...] that it is difficuly for [a very small subset of] human users [used to a different, baroque system] to be able to [...]

I see, day in and day out, literally thouands upon thousands of fora on Internet where millions of people from grandmothers sharing their latest knitting tricks to software developers manage to communicate effectively and figure out who is talking despite the lack of indentation pushing everything in small boxes to the right margin, and without the ability (or need!) to work around the flaws of that system with horrid hacks like manual outdents.

Indentation is a crappy workaround for when your communication system does not support a sane threading model - it isn't a threading model or a substitute for one.

-- Marc

On 17/03/15 15:32, Brad Jorsch (Anomie) wrote:

On Tue, Mar 17, 2015 at 11:17 AM, Marc A. Pelletier marc@uberbox.org wrote:

...

Indentation is a crappy workaround for when your communication system does not support a sane threading model - it isn't a threading model or a substitute for one.

Err, what's the threading model in Flow's UI? Or Facebook, phpbb, and so on, or whatever other site you were referring to that knitting grandmothers use? Can you really call not having any (user-visible) threading model a threading model?

From what I've seen of those types of discussions, people have to either explicitly refer back to whatever they're replying to (e.g. Twitter tries to, and doesn't very well from what I've seen), quote whatever they're replying to (e.g. phpbb, email (especially how Gmail renders it)), and/or just deal with having to dig through an undifferentiated pile of replies to find the ones that might be replying to the post they're interested in (phpbb, Facebook).

On a lot of sites they can also get away with a lack of threading because the discussions themselves are relatively inactive, where you don't have multiple people jumping in and replying to different points. Such inactivity isn't the case on many wikis, where discussion is more key to their functionality, and certainly shouldn't be an assumption here.

- I

Thanks for all of the questions and suggestions. Flow is still in active development, and there's a lot of feature work being done right now. Some of the features that have been mentioned in this thread are actually just about to be released, and some are coming up over the next month or so.

Here's how it breaks down:

Coming out very soon:

-- The ability to edit other people's posts will be out on Mediawiki by the end of next week. We’ve made a few interface changes to support that. Posts that have been edited by someone that isn’t the original poster now say “Edited by Username 3 minutes ago”, so that it’s easy for everyone to see what’s happened. When someone edits an existing post, we fixed the diff pages so that you can browse between previous and next changes. [1]

-- Sane threading model, with more levels for replies and tangents -- also coming out next week. Talking about this feature gets super lengthy and complicated, so I’ll write another post right after this one that will give all the details for people who are interested. [2]

-- Admins viewing deleted boards without undeleting it -- coming out in three weeks. [3]

Working on these next:

-- Moving topics between boards -- We’ve got designs and estimates for this, and I’m expecting that to come out in April. [4]

-- More powerful watchlist/notification functionality -- This is a very important feature that will be getting a lot of team attention over the next month. We need to re-read the mountain of requests that have accumulated, and reach out again to you for fresh feedback. Improvements will aim to be continuous and incremental.

Future plans, not scheduled yet:

-- Full wikitext toolbar -- We’re going to release v1 of a VisualEditor toolbar in the next couple of weeks. This version will just have three functions: Bold/Italics, Links and Mentions. (Mentions will have autocomplete with user names that have already participated in the thread.) We’ll definitely be doing more work on toolbars coming up, but we want to see how this first one works before we make any solid plans.

-- Make the links to threads look nicer -- Yeah, this is annoying. It’s not in our top five list of annoyances at the moment, but we’ll keep checking off annoying items. Nicer links will get its turn. [5]

-- No-JS and accessibility -- We’ve done some work on this, and there will be more coming up. [6]

So there's a lot of work still to be done, but we're adding a lot of features. I hope this helps explain where we are in the process.

We’re going to have an Office Hours Google Hangout on Monday at 19:00 UTC, so we can answer questions and talk about the project. If people are interested, we can schedule more of these.

Thanks again for all the specific feature requests and concerns. We’ll be requesting larger and wider quantities of feedback in the near future, as some of the upcoming features are planned and built.

Danny

Phabricator tickets mentioned above: [1] Flow post editing for autoconfirmed users: https://phabricator.wikimedia.org/T90670 [2] Prototype for new indentation model: https://phabricator.wikimedia.org/T88501 [3] Admins viewing deleted boards: https://phabricator.wikimedia.org/T90972 [4] Moving topics between boards: https://phabricator.wikimedia.org/T88140 [5] Less ugly topic page links: https://phabricator.wikimedia.org/T59154 [6] No-JS tracking: https://phabricator.wikimedia.org/T60019

On Tue, Mar 17, 2015 at 12:51 PM, Derk-Jan Hartman < d.j.hartman+wmf_ml@gmail.com> wrote:

...

On 17 mrt. 2015, at 19:45, Isarra Yos zhorishna@gmail.com wrote:

On 17/03/15 15:32, Brad Jorsch (Anomie) wrote:

...

On Tue, Mar 17, 2015 at 11:17 AM, Marc A. Pelletier marc@uberbox.org wrote:

...

Indentation is a crappy workaround for when your communication system does not support a sane threading model - it isn't a threading model or a substitute for one.

Err, what's the threading model in Flow's UI? Or Facebook, phpbb, and so on, or whatever other site you were referring to that knitting

grandmothers

...

...

use? Can you really call not having any (user-visible) threading model a threading model?

From what I've seen of those types of discussions, people have to either explicitly refer back to whatever they're replying to (e.g. Twitter

tries

...

...

to, and doesn't very well from what I've seen), quote whatever they're replying to (e.g. phpbb, email (especially how Gmail renders it)),

and/or

...

...

just deal with having to dig through an undifferentiated pile of

replies to

...

...

find the ones that might be replying to the post they're interested in (phpbb, Facebook).

On a lot of sites they can also get away with a lack of threading

because the discussions themselves are relatively inactive, where you don't have multiple people jumping in and replying to different points. Such inactivity isn't the case on many wikis, where discussion is more key to their functionality, and certainly shouldn't be an assumption here.

...

I still think that a threading and collapsing model as in http://tweakers.net/nieuws/101962/google-maakt-leeftijdsrating-verplicht-voo... < http://tweakers.net/nieuws/101962/google-maakt-leeftijdsrating-verplicht-voo... makes a lot more sense.

It’s limited in width, readable, collapsible, has threading with indenting, has a maximum amount of indenting, and is a tech website that is also very intensive, and all over the place.

DJ

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

(sorry for reposting, the first version had attachments and wasn't appearing in the archive)

As a PS to that long post, here's another long post. I mentioned above that I'd get into more detail about indents and tangents.

Wikitext talk pages use indentation for two different reasons -- to create visual separation between people's posts, and to create spin-off tangents that follow a different path than the main flow of conversation in a thread. They're both important functions, but they don't need the same mechanism, and I'd argue that trying to do both with indentations makes wikitext talk pages harder to participate in and understand.

Big, complicated Village pump conversations need lots of room for tangents and subthreads. A simple back-and-forth conversation between two people doesn't need that. But we've spent years counting colons and fixing other people's indentations, to the point where it feels like a conversation can only be worthwhile if it's diagonal.

The indentation model that we've been using on Flow is kind of an unhappy compromise between the two different functions, and I don't think anybody likes it much. It retains the idea that a reply should be indented just because, but then it only goes to two levels of indentation. Once a thread reaches the second indentation level, you can't create an out-of-synch tangent even if you want to.

So we've figured out a new reply/indentation model that separates those two functions. We've been testing it out on the flow-tests server [1], and we're going to release it to Mediawiki soon.

Here's how it works:

If you're replying to the most recent post, then your reply just lines up under the previous message. A two-person back and forth conversation just looks flat, and the visual separation is noted with the user name and timestamp.

If you're specifically replying to a previous post, then your reply creates an indented tangent. If everybody responding on that tangent replies to the last message in that subthread, then it'll stay at the same indentation level. But if someone replies to an older message within the subthread, then that creates a third indentation level. I think we've got it set to a maximum of 8 possible indentation levels, and we just stop it there because there's a point where you can't fit a lot of text in each line.

The big idea of the new system is that the indentation should actually mean something. You should be able to tell the difference between a simple conversation and a complicated conversation at a glance, and using indented tangents helps you to spot the places in a conversation where there's a disagreement or a deeper level of detail.

We've been running tests comparing the old and new indentation models with several groups, and I think it's promising. You can check out the two models here:

-- New model: http://flow-tests.wmflabs.org/wiki/Talk:Something -- Old model (with 8 levels of indentation): http://ee-flow.wmflabs.org/wiki/Talk:SomethingElse

So that is the Grand Unified Theory of Flow Indentation, in theory and practice. I would be happy to hear what you think about it. There is a very good chance that this model will continue the Flow tradition of pleasing exactly nobody, and if that's the case, then we can keep talking about it and making more changes. But there's also a chance that this is brilliant and solves everything, so I want to give it a shot and see what happens.

On Tue, Mar 17, 2015 at 3:29 PM, Danny Horn dhorn@wikimedia.org wrote:

Thanks for all of the questions and suggestions. Flow is still in active development, and there's a lot of feature work being done right now. Some of the features that have been mentioned in this thread are actually just about to be released, and some are coming up over the next month or so.

Here's how it breaks down:

Coming out very soon:

-- The ability to edit other people's posts will be out on Mediawiki by the end of next week. We’ve made a few interface changes to support that. Posts that have been edited by someone that isn’t the original poster now say “Edited by Username 3 minutes ago”, so that it’s easy for everyone to see what’s happened. When someone edits an existing post, we fixed the diff pages so that you can browse between previous and next changes. [1]

-- Sane threading model, with more levels for replies and tangents -- also coming out next week. Talking about this feature gets super lengthy and complicated, so I’ll write another post right after this one that will give all the details for people who are interested. [2]

-- Admins viewing deleted boards without undeleting it -- coming out in three weeks. [3]

Working on these next:

-- Moving topics between boards -- We’ve got designs and estimates for this, and I’m expecting that to come out in April. [4]

-- More powerful watchlist/notification functionality -- This is a very important feature that will be getting a lot of team attention over the next month. We need to re-read the mountain of requests that have accumulated, and reach out again to you for fresh feedback. Improvements will aim to be continuous and incremental.

Future plans, not scheduled yet:

-- Full wikitext toolbar -- We’re going to release v1 of a VisualEditor toolbar in the next couple of weeks. This version will just have three functions: Bold/Italics, Links and Mentions. (Mentions will have autocomplete with user names that have already participated in the thread.) We’ll definitely be doing more work on toolbars coming up, but we want to see how this first one works before we make any solid plans.

-- Make the links to threads look nicer -- Yeah, this is annoying. It’s not in our top five list of annoyances at the moment, but we’ll keep checking off annoying items. Nicer links will get its turn. [5]

-- No-JS and accessibility -- We’ve done some work on this, and there will be more coming up. [6]

So there's a lot of work still to be done, but we're adding a lot of features. I hope this helps explain where we are in the process.

We’re going to have an Office Hours Google Hangout on Monday at 19:00 UTC, so we can answer questions and talk about the project. If people are interested, we can schedule more of these.

Thanks again for all the specific feature requests and concerns. We’ll be requesting larger and wider quantities of feedback in the near future, as some of the upcoming features are planned and built.

Danny

Phabricator tickets mentioned above: [1] Flow post editing for autoconfirmed users: https://phabricator.wikimedia.org/T90670 [2] Prototype for new indentation model: https://phabricator.wikimedia.org/T88501 [3] Admins viewing deleted boards: https://phabricator.wikimedia.org/T90972 [4] Moving topics between boards: https://phabricator.wikimedia.org/T88140 [5] Less ugly topic page links: https://phabricator.wikimedia.org/T59154 [6] No-JS tracking: https://phabricator.wikimedia.org/T60019

On Tue, Mar 17, 2015 at 12:51 PM, Derk-Jan Hartman < d.j.hartman+wmf_ml@gmail.com> wrote:

...

...

On 17 mrt. 2015, at 19:45, Isarra Yos zhorishna@gmail.com wrote:

On 17/03/15 15:32, Brad Jorsch (Anomie) wrote:

...

On Tue, Mar 17, 2015 at 11:17 AM, Marc A. Pelletier marc@uberbox.org wrote:

...

Indentation is a crappy workaround for when your communication system does not support a sane threading model - it isn't a threading model

or

...

...

...

a substitute for one.

Err, what's the threading model in Flow's UI? Or Facebook, phpbb, and

so

...

...

on, or whatever other site you were referring to that knitting

grandmothers

...

...

use? Can you really call not having any (user-visible) threading model

a

...

...

threading model?

From what I've seen of those types of discussions, people have to

either

...

...

explicitly refer back to whatever they're replying to (e.g. Twitter

tries

...

...

to, and doesn't very well from what I've seen), quote whatever they're replying to (e.g. phpbb, email (especially how Gmail renders it)),

and/or

...

...

just deal with having to dig through an undifferentiated pile of

replies to

...

...

find the ones that might be replying to the post they're interested in (phpbb, Facebook).

On a lot of sites they can also get away with a lack of threading

because the discussions themselves are relatively inactive, where you don't have multiple people jumping in and replying to different points. Such inactivity isn't the case on many wikis, where discussion is more key to their functionality, and certainly shouldn't be an assumption here.

...

I still think that a threading and collapsing model as in http://tweakers.net/nieuws/101962/google-maakt-leeftijdsrating-verplicht-voo... < http://tweakers.net/nieuws/101962/google-maakt-leeftijdsrating-verplicht-voo... makes a lot more sense.

It’s limited in width, readable, collapsible, has threading with indenting, has a maximum amount of indenting, and is a tech website that is also very intensive, and all over the place.

DJ

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Il 17/03/2015 23:29, Danny Horn ha scritto:

Thanks for all of the questions and suggestions. Flow is still in active development, and there's a lot of feature work being done right now. Some of the features that have been mentioned in this thread are actually just about to be released, and some are coming up over the next month or so.

Here's how it breaks down:

Coming out very soon:

-- The ability to edit other people's posts will be out on Mediawiki by the end of next week. We’ve made a few interface changes to support that. Posts that have been edited by someone that isn’t the original poster now say “Edited by Username 3 minutes ago”, so that it’s easy for everyone to see what’s happened. When someone edits an existing post, we fixed the diff pages so that you can browse between previous and next changes. [1]

By "Mediawiki", do you mean www.mediawiki.org? I would like to stress the importance of such ability for *all* wikis. On Wikimedia, unlike most other sites, nothing is 'owned' by someone, and protection is only a precautionary measure. Flow is supposed to work with this model.

-- Sane threading model, with more levels for replies and tangents -- also coming out next week. Talking about this feature gets super lengthy and complicated, so I’ll write another post right after this one that will give all the details for people who are interested. [2]

-- Admins viewing deleted boards without undeleting it -- coming out in three weeks. [3]

Working on these next:

-- Moving topics between boards -- We’ve got designs and estimates for this, and I’m expecting that to come out in April. [4]

-- More powerful watchlist/notification functionality -- This is a very important feature that will be getting a lot of team attention over the next month. We need to re-read the mountain of requests that have accumulated, and reach out again to you for fresh feedback. Improvements will aim to be continuous and incremental.

Future plans, not scheduled yet:

-- Full wikitext toolbar -- We’re going to release v1 of a VisualEditor toolbar in the next couple of weeks. This version will just have three functions: Bold/Italics, Links and Mentions. (Mentions will have autocomplete with user names that have already participated in the thread.) We’ll definitely be doing more work on toolbars coming up, but we want to see how this first one works before we make any solid plans.

-- Make the links to threads look nicer -- Yeah, this is annoying. It’s not in our top five list of annoyances at the moment, but we’ll keep checking off annoying items. Nicer links will get its turn. [5]

-- No-JS and accessibility -- We’ve done some work on this, and there will be more coming up. [6]

So there's a lot of work still to be done, but we're adding a lot of features. I hope this helps explain where we are in the process.

We’re going to have an Office Hours Google Hangout on Monday at 19:00 UTC, so we can answer questions and talk about the project. If people are interested, we can schedule more of these.

Thanks again for all the specific feature requests and concerns. We’ll be requesting larger and wider quantities of feedback in the near future, as some of the upcoming features are planned and built.

Danny

Phabricator tickets mentioned above: [1] Flow post editing for autoconfirmed users: https://phabricator.wikimedia.org/T90670 [2] Prototype for new indentation model: https://phabricator.wikimedia.org/T88501 [3] Admins viewing deleted boards: https://phabricator.wikimedia.org/T90972 [4] Moving topics between boards: https://phabricator.wikimedia.org/T88140 [5] Less ugly topic page links: https://phabricator.wikimedia.org/T59154 [6] No-JS tracking: https://phabricator.wikimedia.org/T60019

Thanks for the detailed and timely reply.

Yes, the plan is for editing posts to go everywhere. We want to go a little bit extra slow with deploying that feature just to make sure that the pieces we've put in place actually work properly. So it's rolling out to Mediawiki.org next week, and then English and Russian WP the week after. (The people at Russian WP that we've been talking to said that they weren't even interested in test pages until we had editing posts, because Russian is hardcore.)

Having the ability to edit other people's posts can be very useful, but there's also a strong cultural tradition that says that we basically don't do it, except under certain circumstances. People using Flow won't necessarily come to it with that same tradition, so we want to see that the feature set encourages the useful editing, and doesn't encourage people to mess with the wording or intent of someone else's post. Once we've seen it in action for a little while, it'll go live to all the other languages.

And I'm glad to hear that this thread has come close to almost inspiring optimism. That's what I'm here for.

On Tue, Mar 17, 2015 at 8:00 PM, MZMcBride z@mzmcbride.com wrote:

Ricordisamoa wrote:

...

Il 17/03/2015 23:29, Danny Horn ha scritto:

...

-- The ability to edit other people's posts will be out on Mediawiki by the end of next week. We’ve made a few interface changes to support that. Posts that have been edited by someone that isn’t the original poster now say “Edited by Username 3 minutes ago”, so that it’s easy for everyone to see what’s happened. When someone edits an existing post, we fixed the diff pages so that you can browse between previous and next changes. [1]

By "Mediawiki", do you mean www.mediawiki.org? I would like to stress the importance of such ability for *all* wikis. On Wikimedia, unlike most other sites, nothing is 'owned' by someone, and protection is only a precautionary measure. Flow is supposed to work with this model.

Agreed. The ability of anyone to revert bad edits also acts a major anti-abuse feature. As has been pointed out many times, there's a very real spam concern if only the author and admins can edit posts.

...

...

-- Make the links to threads look nicer -- Yeah, this is annoying. It’s not in our top five list of annoyances at the moment, but we’ll keep checking off annoying items. Nicer links will get its turn. [5] [5] Less ugly topic page links: https://phabricator.wikimedia.org/T59154

Erik B. says on that task that the deployment of ContentHandler should help. This is excellent news.

...

Thanks for the detailed and timely reply.

My thanks as well! This e-mail really helped alleviate some of my concerns with Flow's development. I have too much experience with Flow's predecessor LiquidThreads to say that I'm optimistic, but I'm definitely less concerned now about Flow's future than I was when I started the day.

MZMcBride

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Il 18/03/2015 05:08, Danny Horn ha scritto:

Yes, the plan is for editing posts to go everywhere. We want to go a little bit extra slow with deploying that feature just to make sure that the pieces we've put in place actually work properly. So it's rolling out to Mediawiki.org next week, and then English and Russian WP the week after. (The people at Russian WP that we've been talking to said that they weren't even interested in test pages until we had editing posts, because Russian is hardcore.)

Having the ability to edit other people's posts can be very useful, but there's also a strong cultural tradition that says that we basically don't do it, except under certain circumstances. People using Flow won't necessarily come to it with that same tradition, so we want to see that the feature set encourages the useful editing, and doesn't encourage people to mess with the wording or intent of someone else's post. Once we've seen it in action for a little while, it'll go live to all the other languages.

Of course it should be used carefully and for minor changes only. I agree with T91086 https://phabricator.wikimedia.org/T91086.

And I'm glad to hear that this thread has come close to almost inspiring optimism. That's what I'm here for.

On Tue, Mar 17, 2015 at 8:00 PM, MZMcBride z@mzmcbride.com wrote:

...

Ricordisamoa wrote:

...

Il 17/03/2015 23:29, Danny Horn ha scritto:

...

-- The ability to edit other people's posts will be out on Mediawiki by the end of next week. We’ve made a few interface changes to support that. Posts that have been edited by someone that isn’t the original poster now say “Edited by Username 3 minutes ago”, so that it’s easy for everyone to see what’s happened. When someone edits an existing post, we fixed the diff pages so that you can browse between previous and next changes. [1]

By "Mediawiki", do you mean www.mediawiki.org? I would like to stress the importance of such ability for *all* wikis. On Wikimedia, unlike most other sites, nothing is 'owned' by someone, and protection is only a precautionary measure. Flow is supposed to work with this model.

Agreed. The ability of anyone to revert bad edits also acts a major anti-abuse feature. As has been pointed out many times, there's a very real spam concern if only the author and admins can edit posts.

...

...

-- Make the links to threads look nicer -- Yeah, this is annoying. It’s not in our top five list of annoyances at the moment, but we’ll keep checking off annoying items. Nicer links will get its turn. [5] [5] Less ugly topic page links: https://phabricator.wikimedia.org/T59154

Erik B. says on that task that the deployment of ContentHandler should help. This is excellent news.

...

Thanks for the detailed and timely reply.

My thanks as well! This e-mail really helped alleviate some of my concerns with Flow's development. I have too much experience with Flow's predecessor LiquidThreads to say that I'm optimistic, but I'm definitely less concerned now about Flow's future than I was when I started the day.

MZMcBride

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On Tue, Mar 17, 2015 at 8:27 PM, Danny Horn dhorn@wikimedia.org wrote:

So we've figured out a new reply/indentation model that separates those two functions. We've been testing it out on the flow-tests server [1], and we're going to release it to Mediawiki soon.

I ran some tests at http://flow-tests.wmflabs.org/wiki/Topic:Sdrqdcffddyz0jeo. Here are my observations:

- Posts B, C, and I all reply to A, but the ordering is C, I, B. I'd expect replies to the same parent to be ordered chronologically (and I'd personally expect earliest first). - Posts B and C both reply to A, but are confusingly at different indentation levels. I'd expect replies to the same parent to be indented the same. - Posts I and E are at the same indentation level, despite I being a direct reply to A while E is at the end of the chain A→C→D→E. Similar confusion exists elsewhere. I'd expect two posts at the first indentation level under the same parent to both be replies to that parent. - Things are even weirder with post J: Even though D and its reply E are at the same indentation level, J is suddenly indented more because of an unrelated post I. - Things go completely wrong once we hit the maximum depth, it's impossible to have (or only to be seen as having?) "tangents" at all. The reply box doesn't even show up under the post where I actually clicked "Reply".

All in all, I personally find the resulting structure to be very confusing as to what's actually replying to what since the same reply-structure might be displayed in different ways (depending on the order the replies were entered) and different reply-structures can give rise to the same display-structure.

Also, some nice-to-have features:

* provide View Source (showing the wikitext) of someone's post https://phabricator.wikimedia.org/T62465 * post-edit diffs need a Thank link https://phabricator.wikimedia.org/T85846 * Have WhatLinksHere show full information for Flow content https://phabricator.wikimedia.org/T92571

Il 17/03/2015 11:05, Ricordisamoa ha scritto:

Hi Nick, I'm glad the Foundation is finally valuing a usable discussion system.

Unfortunately, there are some serious issues with Flow which will prevent my use of it in production if not addressed in full:

• Administrators *must* be able to to see a deleted Flow board without undeleting it (T90972 https://phabricator.wikimedia.org/T90972)
• Ordinary users *must* be able to move topics between boards (T88140

https://phabricator.wikimedia.org/T88140)

• Ordinary users *must* be able to edit AND move AND indent AND dedent other users' comments (T78253

https://phabricator.wikimedia.org/T78253)

• An arbitrary indentation level *must* be allowed, with optional facilitations for adding an {{outdent}}-like marker
• Every basic functionality (including but not limited to the "preview" button) *must* work without relying on JavaScript (T60019

https://phabricator.wikimedia.org/T60019)

I see that the implementation of many features was delayed at the initial stage of development, but they can't be ignored when trying to deploy such a software in production. Thank you.

Il 17/03/2015 01:51, Nick Wilson (Quiddity) ha scritto:

...

LiquidThreads (LQT) has not been well-supported in a long time. Flow is in active development, and more real-world use-cases will help focus attention on the higher-priority features that are needed. To that end, LQT pages at mediawiki.org will start being converted to Flow in the next couple of weeks.

There are about 1,600 existing LQT pages on Mediawiki, and the three most active pages are VisualEditor/Feedback, Project:Support_desk, and Help_talk:CirrusSearch.[1] The Collaboration team has been running test conversions of those three pages, and fixing issues that have come up. Those fixes are almost complete, and the team will be ready to start converting LQT threads to Flow topics soon. (If you’re interested in the progress, check out phab:T90788[2] and linked tasks.) The latest set is visible at a labs test server.[3] See an example topic comparison here: Flow vs LQT.[4])

The VisualEditor/Feedback page will be converted first (per James' request), around the middle of next week. We’ll pause to assess any high-priority changes required. After that, we will start converting more pages. This process may take a couple of weeks to fully run.

The last page to be converted will be Project:Support_desk, as that is the largest and most active LQT Board.

LQT Threads that are currently on your watchlist, will still be watchlisted as Flow Topics. New Topics created at Flow Boards on your watchlist will appear in your Echo notifications, and you can choose whether or not to watchlist them.

The LQT namespaces will continue to exist. Links to posts/topics will redirect appropriately, and the LQT history will remain available at the original location, as well as being mirrored in the Flow history.

There’s a queue of new features in Flow that will be shipped over the next month or so:

• Table of Contents is done
• Category support for Flow Header and Topics is done
• VE with editing toolbar coming last week of March (phab:T90763) [5]
• Editing other people’s comments coming last week of March

(phab:T91086)

• Ability to change the width & side rail in progress, probably out in

April (phab:T88114])

• Search is in progress (no ETA yet) (phab:T76823)
• The ability to choose which Flow notifications end up in Echo,

watchlist, or both, and other more powerful options, will be coming up next (no ETA yet)

That being said -- there are some LiquidThreads features that don’t exist in Flow yet. We’d like to hear which features you use on the current LQT boards, and that you’re concerned about losing in the Flow conversion. At the same time, we’d like further suggestions on how we could improve upon that (or other) features from LQT.

Please give us feedback at https://www.mediawiki.org/wiki/Topic:Sdoatsbslsafx6lw to keep it centralized, and test freely at the sandbox.[6]

Much thanks, on behalf of the Collaboration Team, Quiddity (WMF)

[1] https://www.mediawiki.org/wiki/VisualEditor/Feedback and https://www.mediawiki.org/wiki/Help_talk:CirrusSearch and https://www.mediawiki.org/wiki/Project:Support_desk [2] https://phabricator.wikimedia.org/T90788 [3] http://flow-tests.wmflabs.org/wiki/Testwiki:Support_desk and http://flow-tests.wmflabs.org/wiki/VisualEditor/Feedback [4] http://flow-tests.wmflabs.org/wiki/Topic:Qmkwqmp0wfcazy9c and https://www.mediawiki.org/wiki/Thread:Project:Support_desk/Error_creating_th...

[5] https://phabricator.wikimedia.org/T90763 , https://phabricator.wikimedia.org/T91086 , https://phabricator.wikimedia.org/T88114 , https://phabricator.wikimedia.org/T76823 [6] https://www.mediawiki.org/wiki/Talk:Sandbox

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Brad: unfortunately, it's really hard to tell very much from a conversation with messages like "3: Post C: reply to Post A". You could do that with the old model, the new model or the perfect magic Nobel-Prize-winning discussion threading still to be discovered, and it would probably look like nonsense in all three.

We've tried in our testing to pretend that we're having real conversations, so we could see whether there's any logical way to get to eight levels of nested threading. It's not easy to organize make-believe conversations, but if you want to start a thread, I'd be happy to fire up a few sockpuppets and pretend to talk about something with you.

On Wed, Mar 18, 2015 at 7:35 AM, Brad Jorsch (Anomie) <bjorsch@wikimedia.org

wrote:

On Wed, Mar 18, 2015 at 10:12 AM, Brad Jorsch (Anomie) < bjorsch@wikimedia.org> wrote:

...

On Tue, Mar 17, 2015 at 8:27 PM, Danny Horn dhorn@wikimedia.org wrote:

...

So we've figured out a new reply/indentation model that separates those two functions. We've been testing it out on the flow-tests server [1], and we're going to release it to Mediawiki soon.

I ran some tests at http://flow-tests.wmflabs.org/wiki/Topic:Sdrqdcffddyz0jeo. Here are my observations:

• Posts B, C, and I all reply to A, but the ordering is C, I, B. I'd

expect replies to the same parent to be ordered chronologically (and

I'd

...

personally expect earliest first).

• Posts B and C both reply to A, but are confusingly at different

indentation levels. I'd expect replies to the same parent to be

indented

...

the same.

• Posts I and E are at the same indentation level, despite I being a

direct reply to A while E is at the end of the chain A→C→D→E. Similar confusion exists elsewhere. I'd expect two posts at the first

indentation

...

level under the same parent to both be replies to that parent.

• Things are even weirder with post J: Even though D and its reply E

are at the same indentation level, J is suddenly indented more

because of

...

an unrelated post I.

• Things go completely wrong once we hit the maximum depth, it's

impossible to have (or only to be seen as having?) "tangents" at all.

The

...

reply box doesn't even show up under the post where I actually clicked "Reply".

All in all, I personally find the resulting structure to be very

confusing

...

as to what's actually replying to what since the same reply-structure

might

...

be displayed in different ways (depending on the order the replies were entered) and different reply-structures can give rise to the same display-structure.

(sorry for the self-reply)

Some of these might be solved by simply abandoning the idea that "first reply = main thread, all others = tangent" in favor of displaying flat if this post and its parent both have no "sibling" post.

That /would/ mean, though, that a single reply could result in a major change to display-structure. For example, a reply-chain A→B→C→D→E→F→G would be displayed flat, and then when someone posts B2 as a reply to A we'd have A, then indented under it B and B2, then indented under B we'd have C→D→E→F→G (which might still be displayed flat).

And there'd still be the case that a chain of replies and a single post with multiple direct replies (none of which were replied to) could be displayed the same in some cases, but that seems less likely to be confusing to a reader. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On 2015-03-18 11:31 PM, Isarra Yos wrote:

On 19/03/15 01:42, Danny Horn wrote:

...

Brad: unfortunately, it's really hard to tell very much from a conversation with messages like "3: Post C: reply to Post A". You could do that with the old model, the new model or the perfect magic Nobel-Prize-winning discussion threading still to be discovered, and it would probably look like nonsense in all three.

We've tried in our testing to pretend that we're having real conversations, so we could see whether there's any logical way to get to eight levels of nested threading. It's not easy to organize make-believe conversations, but if you want to start a thread, I'd be happy to fire up a few sockpuppets and pretend to talk about something with you.

I'm a little confused. Didn't LQT already solve this problem? Why not just nest/thread things the same way it does, or how well-formatted wikitext conversations in general do? That seemed to work fine; the issues with LQT lay elsewhere, and the issue with wikitext really just seems to be it all needs to be done manually and users often don't get it right as a result, hence a good chunk of why we're trying to replace it in the first place.

-I

Yes, Wikitext conversations did have a threading pattern.

From what I can see looking at a long discussion on a random FA talkpage

archive it goes like this: Users indent after each message. Then when it gets too deep someone starts their message with 0 indentation. Conversations with larger messages end up reset quicker.

Unfortunately this model cannot be applied to LQT or Flow.

LQT just keeps indenting even when you would break because the indent is too deep.

Flow tries to fix this by only indenting when replying in a spot where you can't just append.

Frankly the WikiText indentation practice doesn't make sense in LQT or Flow. As I understand we always change the indentation in WikiText in part because it's hard to see where one user's message becomes another with just a signature to break the paragraphs into messages.

That doesn't make sense in LQT or Flow where messages are structured and have an interface to differentiate them.

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]

On 2015-03-19 12:42 AM, Isarra Yos wrote:

On 19/03/15 07:00, Daniel Friesen wrote:

...

On 2015-03-18 11:31 PM, Isarra Yos wrote: Yes, Wikitext conversations did have a threading pattern.

From what I can see looking at a long discussion on a random FA talkpage archive it goes like this: Users indent after each message. Then when it gets too deep someone starts their message with 0 indentation. Conversations with larger messages end up reset quicker.

Unfortunately this model cannot be applied to LQT or Flow.

Um... LQT has exactly that model. Yes, you can keep going, but you can keep going in wikitext, too, even off the side of the page (which is exactly what uncyclopedians do sometimes precisely because they want to go off the side of the page because they think it's funny, because let's face it, it is funny), but normally you just start a new conversation/thread/topic/whatever you want to call it if it goes too far.

Can you point me to a LQT discussion that people have used that way?

In all the LQT discussions I remember being in people just replied to the comment they were replying to. No one seemed to go and reply to a post higher up just to break indentation.

And if things go to far you can't nautrally fork a LQT/Flow discussion the way you do in a WikiText page. If you did that the people you're talking to wouldn't be notified.

but normally you just start a new conversation/thread/topic/whatever you want to call it if it goes too far.

Actually this part sounds like the best solution to the 8-levels deep issue. Any discussion that deep should probably be forked.

Perhaps the Flow interface needs high level support for something like that. Something like how Discourse lets you fork a message into a new topic and displays an interface bit that links to the new topic.

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]

On Wed, Mar 18, 2015 at 9:42 PM, Danny Horn dhorn@wikimedia.org wrote:

Brad: unfortunately, it's really hard to tell very much from a conversation with messages like "3: Post C: reply to Post A". You could do that with the old model, the new model or the perfect magic Nobel-Prize-winning discussion threading still to be discovered, and it would probably look like nonsense in all three.

I shouldn't have used both numbers and post-names, but once I realized that it was already a bit late and it won't let me edit those posts. Someone with appropriate permissions is free to go back and edit them all to remove the number prefix and let the alphabetical order of the post-names suffice to indicate the chronological order of the postings, if that would make it less confusing for you.

The point is the structure you're displaying doesn't make any sense, not that the content of my messages isn't anything that might make sense on its own. My "content" is explicitly simplified to illustrate the failings in the displayed structure. Structure should *facilitate* understanding, but in your demo I'd find that understanding the underlying structure of the conversation would be *despite* the broken display-structure.

Nor is the point that people can screw up wikitext talk pages in ways that are even more confusing. That's a given, but Flow is supposed to do better. Right now it's worse than a well-formatted wikitext talk page (which has the advantage that human users can *fix* the structure when a newbie breaks it).

Comparing http://flow-tests.wmflabs.org/wiki/Wikitext version of Topic:Sdrqdcffddyz0jeo to http://flow-tests.wmflabs.org/wiki/Wikitext_version_of_Topic:Sdrqdcffddyz0je..., I find it much easier in the latter to see what is a reply to what.

We've tried in our testing to pretend that we're having real conversations, so we could see whether there's any logical way to get to eight levels of nested threading. It's not easy to organize make-believe conversations, but if you want to start a thread, I'd be happy to fire up a few sockpuppets and pretend to talk about something with you.

No thanks. Pretend "real" conversations are ok for a first assessment at usability, but by nature they're likely to be vapid and unlikely to have the inter-post complexity of actual conversations on-wiki where people are concentrating on actually communicating rather than on forcing a conversation for the sake of testing.

On 19 Mar 2015 7:55 am, "Brad Jorsch (Anomie)" bjorsch@wikimedia.org wrote:

On Wed, Mar 18, 2015 at 9:42 PM, Danny Horn dhorn@wikimedia.org wrote:

...

Brad: unfortunately, it's really hard to tell very much from a

conversation

...

with messages like "3: Post C: reply to Post A". You could do that with

the

...

old model, the new model or the perfect magic Nobel-Prize-winning discussion threading still to be discovered, and it would probably look like nonsense in all three.

I shouldn't have used both numbers and post-names, but once I realized

that

it was already a bit late and it won't let me edit those posts. Someone with appropriate permissions is free to go back and edit them all to

remove

the number prefix and let the alphabetical order of the post-names suffice to indicate the chronological order of the postings, if that would make it less confusing for you.

The point is the structure you're displaying doesn't make any sense, not that the content of my messages isn't anything that might make sense on

its

own. My "content" is explicitly simplified to illustrate the failings in the displayed structure. Structure should *facilitate* understanding, but in your demo I'd find that understanding the underlying structure of the conversation would be *despite* the broken display-structure.

Nor is the point that people can screw up wikitext talk pages in ways that are even more confusing. That's a given, but Flow is supposed to do

better.

Right now it's worse than a well-formatted wikitext talk page (which has the advantage that human users can *fix* the structure when a newbie

breaks

it).

Comparing http://flow-tests.wmflabs.org/wiki/Wikitext version of Topic:Sdrqdcffddyz0jeo to

http://flow-tests.wmflabs.org/wiki/Wikitext_version_of_Topic:Sdrqdcffddyz0je... ,

I find it much easier in the latter to see what is a reply to what.

...

We've tried in our testing to pretend that we're having real

conversations,

...

so we could see whether there's any logical way to get to eight levels

of

...

nested threading. It's not easy to organize make-believe conversations, but if you want to start a thread, I'd be happy to fire up a few sockpuppets and pretend to talk about something with you.

No thanks. Pretend "real" conversations are ok for a first assessment at usability, but by nature they're likely to be vapid and unlikely to have the inter-post complexity of actual conversations on-wiki where people are concentrating on actually communicating rather than on forcing a conversation for the sake of testing.

Let's all be happy then that we are replacing an unloved broken talk extension with Flow on a wiki where we have real conversations then ...? :) actually dogfooding will make it much easier for us to communicate errors with the Flow team and help improve the software.

I truly hope that soon we can get to a point where we can enable flow on all pages on mediawiki.org and this seems like the obvious first step.

_______________________________enable __________

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On Thu, Mar 19, 2015 at 11:08 AM, Jon Robson jdlrobson@gmail.com wrote:

Let's all be happy then that we are replacing an unloved broken talk extension with Flow on a wiki where we have real conversations then ...? :) actually dogfooding will make it much easier for us to communicate errors with the Flow team and help improve the software.

On the other hand, forcing people to dogfood a product with known issues is a sure way to piss people off and make them hate your product even after the issues are fixed. Without getting too specific, we know that from experience.

I'm glad of the initial approach taken here, with the team reaching out to wikitech-l to ask about known issues before trying a deployment. I'll be even happier if I learn they have a plan for dealing with Murphy's law that isn't "beg for patience while we rush to fix it".

I think my post might have gotten lost. But what is normal on wiki when we hit a reasonable indentation level is to use a template like {{od}} that has a return and an arrow showing that the conversation is continued unindented

What do you mean it doesn't scale?

On Thursday, March 19, 2015, Gerard Meijssen gerard.meijssen@gmail.com wrote:

Hoi, REALLY .. never ever heard about that template ... and it does not scale Thanks, GerardM

On 19 March 2015 at 16:39, John <phoenixoverride@gmail.com javascript:;> wrote:

...

I think my post might have gotten lost. But what is normal on wiki when

we

...

hit a reasonable indentation level is to use a template like {{od}} that has a return and an arrow showing that the conversation is continued unindented _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org javascript:; https://lists.wikimedia.org/mailman/listinfo/wikitech-l

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org javascript:; https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Ok stop being condescending and dismissive. I was proposing that type of functionality be added to flow as an option for dealing with reply level excessnes. It is a simple graphic to de-indent a discussion without much disruption and it improves readability

On Thursday, March 19, 2015, Gerard Meijssen gerard.meijssen@gmail.com wrote:

Hoi, It does not scale in two ways:

• you do not get everybody to know about such trivia; there are more

relevant things to learn

• it may work on one wiki but how about the next ?

Remember this is Wikimedia-l not en.wikipedia-l

Thanks,

  GerardM

On 19 March 2015 at 17:05, John <phoenixoverride@gmail.com javascript:;> wrote:

...

What do you mean it doesn't scale?

On Thursday, March 19, 2015, Gerard Meijssen <gerard.meijssen@gmail.com

javascript:;>

...

wrote:

...

Hoi, REALLY .. never ever heard about that template ... and it does not

scale

...

...

Thanks, GerardM

On 19 March 2015 at 16:39, John <phoenixoverride@gmail.com

javascript:;

...

javascript:;>

...

wrote:

...

I think my post might have gotten lost. But what is normal on wiki

when

...

...

we

...

hit a reasonable indentation level is to use a template like {{od}}

that

...

...

has a return and an arrow showing that the conversation is continued unindented _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org javascript:; javascript:; https://lists.wikimedia.org/mailman/listinfo/wikitech-l

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org javascript:; javascript:; https://lists.wikimedia.org/mailman/listinfo/wikitech-l

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org javascript:; https://lists.wikimedia.org/mailman/listinfo/wikitech-l

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org javascript:; https://lists.wikimedia.org/mailman/listinfo/wikitech-l

If it's not clear ask for clarification. I am posting from my mobile, so I don't have pretty screenshots handy. I am by no means suggesting that flow should use a template. Instead when it detects a reply above a specific indent level it uses the same functionality that od fulfilles

On Thu, Mar 19, 2015 at 8:18 AM, Risker risker.wp@gmail.com wrote:

On 19 March 2015 at 11:08, Jon Robson jdlrobson@gmail.com wrote:

...

On 19 Mar 2015 7:55 am, "Brad Jorsch (Anomie)" bjorsch@wikimedia.org wrote:

...

On Wed, Mar 18, 2015 at 9:42 PM, Danny Horn dhorn@wikimedia.org

wrote:

...

...

...

Brad: unfortunately, it's really hard to tell very much from a

conversation

...

...

with messages like "3: Post C: reply to Post A". You could do that

with

...

the

...

...

old model, the new model or the perfect magic Nobel-Prize-winning discussion threading still to be discovered, and it would probably

look

...

...

...

like nonsense in all three.

I shouldn't have used both numbers and post-names, but once I realized

that

...

it was already a bit late and it won't let me edit those posts. Someone with appropriate permissions is free to go back and edit them all to

remove

...

the number prefix and let the alphabetical order of the post-names

suffice

...

to indicate the chronological order of the postings, if that would make

it

...

less confusing for you.

The point is the structure you're displaying doesn't make any sense,

not

...

...

that the content of my messages isn't anything that might make sense on

its

...

own. My "content" is explicitly simplified to illustrate the failings

in

...

...

the displayed structure. Structure should *facilitate* understanding,

but

...

...

in your demo I'd find that understanding the underlying structure of

the

...

...

conversation would be *despite* the broken display-structure.

Nor is the point that people can screw up wikitext talk pages in ways

that

...

are even more confusing. That's a given, but Flow is supposed to do

better.

...

Right now it's worse than a well-formatted wikitext talk page (which

has

...

...

the advantage that human users can *fix* the structure when a newbie

breaks

...

it).

Comparing http://flow-tests.wmflabs.org/wiki/Wikitext version of Topic:Sdrqdcffddyz0jeo to

http://flow-tests.wmflabs.org/wiki/Wikitext_version_of_Topic:Sdrqdcffddyz0je...

...

,

...

I find it much easier in the latter to see what is a reply to what.

...

We've tried in our testing to pretend that we're having real

conversations,

...

...

so we could see whether there's any logical way to get to eight

levels

...

of

...

...

nested threading. It's not easy to organize make-believe

conversations,

...

...

...

but if you want to start a thread, I'd be happy to fire up a few sockpuppets and pretend to talk about something with you.

No thanks. Pretend "real" conversations are ok for a first assessment

at

...

...

usability, but by nature they're likely to be vapid and unlikely to

have

...

...

the inter-post complexity of actual conversations on-wiki where people

are

...

concentrating on actually communicating rather than on forcing a conversation for the sake of testing.

Let's all be happy then that we are replacing an unloved broken talk extension with Flow on a wiki where we have real conversations then ...?

:)

...

actually dogfooding will make it much easier for us to communicate errors with the Flow team and help improve the software.

I truly hope that soon we can get to a point where we can enable flow on all pages on mediawiki.org and this seems like the obvious first step.

The dogfooding has been happening for a while on WMF's own office-wiki. We haven't heard any results about that. Is the system being used more than the wikitext system? (i.e., are there more "talk page" comments now than there were before?) Have users expressed satisfaction/dissatisfaction with the system? Have they been surveyed? Do they break down into groups (e.g., engineering loves it, grants hates it, etc...)? I hear some stories (including stories that suggest some groups of staff have pretty much abandoned talk pages on office-wiki and are now reverting to emails instead) but without any documentary evidence or analysis it's unreasonable to think that it is either a net positive OR a net negative.

Really? This is news to me and if true, I really ponder why paid staff members would not be actively trying to feed back to their team mates on why it is not working for them.

In general this thread is really veering off topic in various directions. It would be great if people could start new conversations and phabricator discussions around particular bugs so that they don't get lost in the void of the ramblings of wikitech.

Risker/Anne _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On 19 March 2015 at 13:28, Ryan Lane rlane32@gmail.com wrote:

On Thu, Mar 19, 2015 at 8:18 AM, Risker risker.wp@gmail.com wrote:

...

The dogfooding has been happening for a while on WMF's own office-wiki.

We

...

haven't heard any results about that. Is the system being used more than the wikitext system? (i.e., are there more "talk page" comments now than there were before?) Have users expressed satisfaction/dissatisfaction

with

...

the system? Have they been surveyed? Do they break down into groups (e.g., engineering loves it, grants hates it, etc...)? I hear some

stories

...

(including stories that suggest some groups of staff have pretty much abandoned talk pages on office-wiki and are now reverting to emails instead) but without any documentary evidence or analysis it's

unreasonable

...

to think that it is either a net positive OR a net negative.

From what I remember officewiki is pretty unused by most of the staff, so I'd doubt you'd get much usable feedback there.

As someone who's used mediawiki for 10+ years I can say that *anything* is better than wikitext for discussion. I have a certain bias towards LQT and such, but that's because I actually want to use discussion pages for discussion and wikitext is basically the worst user experience in the world in this regard. You have a bias towards wikitext because it's been the only option and Wikimedia wikis have weirdly embraced the functionality and freedom it provides. Having that freedom hampered is surely painful to powerusers, but the new user experience isn't even comparable it's so much better.

I think you're mistaking me for someone else. I too have used wikitext for 10+ years - even though today I do the majority of my mainspace edits using Visual Editor. I get the idea of a better way of having discussions, and I also am happy that VE is well on its way. But quite honestly, what I'm seeing with Flow is...well, it reminds me of nothing more than the kinds of discussion systems that seemed old-fashioned and clunky even before I started editing Wikipedia. It wasn't envisioned as a discussion system, it was envisioned as a "workflow" system, and it shows. I routinely cannot tell who is responding to whom in Flow threads today on seldom-used and seldom-edited pages (I've never seen it used at all in any fast-moving discussions) and I'm hardly stupid - I've been participating in online discussion forums since the 1990s too.

I am not married to the idea of using Wikitext, but I don't see the benefit in making an irreversible change in discussion software to a forum that is intended to be a core, Wikimedia/Mediawiki-wide site (comparable to Meta and Commons and Wikidata) by applying software that isn't ready for prime time.

Risker/Anne

On Thu, Mar 19, 2015 at 3:19 PM, Risker risker.wp@gmail.com wrote:

I am not married to the idea of using Wikitext, but I don't see the benefit in making an irreversible change in discussion software to a forum that is intended to be a core, Wikimedia/Mediawiki-wide site (comparable to Meta and Commons and Wikidata) by applying software that isn't ready for prime time.

As long as the structure of the conversation is stored by the new system (and I think both LQT and Flow do that - using a graph of what is a reply to what?) the presentation we have for this structure can be improved over time, or we can even have multiple ways for viewing a given conversation (e.g. with infinite indentation, completelly plain, limited indentation, flow's-new style, whatever). This is like the four "View by" options at https://lists.wikimedia.org/pipermail/wikitech-l/

I don't like the current "limited indentation" view implemented in Flow, but I like even less the lack of (semantic) structure of wikitext conversations. The ":"s are converted to <dl>s and <dt>s by MediaWiki, and this breaks every time someone adds an extra new line between comments (to tell apart one comment from the next) or when someone whants to discuss a table or a template.

Best regards, Helder

On Friday, March 20, 2015, Tilman Bayer <tbayer@wikimedia.org javascript:_e(%7B%7D,'cvml','tbayer@wikimedia.org');> wrote:

Just to throw this in here as one data point: "39% of talk page threads contain wrong indentations https://meta.wikimedia.org/wiki/Research:Newsletter/2014/November#39.25_of_talk_page_threads_contain_wrong_indentations "

PS: The result from that paper was actually even worse than that (somewhat sloppy) headline suggests: the researchers "found that 29 of 74 total turns, or 39%±14pp of an average thread, had indentation that misidentified the turn to which they were a reply."

On 20 March 2015 at 06:13, Tilman Bayer tbayer@wikimedia.org wrote:

On Friday, March 20, 2015, Tilman Bayer <tbayer@wikimedia.org javascript:_e(%7B%7D,'cvml','tbayer@wikimedia.org');> wrote:

...

Just to throw this in here as one data point: "39% of talk page threads contain wrong indentations <

https://meta.wikimedia.org/wiki/Research:Newsletter/2014/November#39.25_of_t...

...

"

PS: The result from that paper was actually even worse than that (somewhat sloppy) headline suggests: the researchers "found that 29 of 74 total turns, or 39%±14pp of an average thread, had indentation that misidentified the turn to which they were a reply."

I'm not sure you really read the underlying study, Tilman; the sample size is so absurdly small that there is no way it is statistically signifant. (550 discussions on 83 article talk pages, in case anyone was wondering; the equivalent of about 10 minutes' worth of discussions on enwiki, except that they are looking at talk pages that may have conversations dating back 10+ years.) And the purpose of the study was to see if this particular manner of analysing a discussion ("lexical pairs") was useful in identifying who said what to whom; it's a discussion of the analysis process, not the actual discussions.

Nonetheless, if you were trying to illustrate that there are communication benefits in having an easily read flow of discussion, I don't think anyone is disagreeing with you about that, and simplification of the indentation system/process would be desirable no matter what underlying software is used for discussion. What is being said in this thread is that Flow does not do this now, and in fact is currently designed to prevent this from happening.

Risker/Anne

Risker schreef op 2015/03/20 om 5:46:

Nonetheless, if you were trying to illustrate that there are communication benefits in having an easily read flow of discussion, I don't think anyone is disagreeing with you about that, and simplification of the indentation system/process would be desirable no matter what underlying software is used for discussion. What is being said in this thread is that Flow does not do this now, and in fact is currently designed to prevent this from happening.

Precisely. It takes the biggest problem we currently have and aggravates it. KWW