Talk:Flow Portal/Archive2

Previous page history was archived for backup purposes at Talk:Flow Portal/Archive2/LQT Archive 1 on 2015-06-03.

Hallo,

I have a few questions about some user interface messages in Flow. As you probably know, we are very very interested in getting all the messages documented well as early as possible. The current documentation for some messages is not completely helpful now. Here they are:

1. What exactly is the definition of "Moderated user"? I found some documentation about moderation on the wiki, bot not so much about "moderated user".

2. The current documentation says "Used as text for the link which points to the "Edit header" page." The problem is that it's not quite clear what is this page about. Is it the header of an edit? Is it a page (a whole page?) where the header of something is edited?

3. Is there any difference between "Title" and "Header"? If they are not different, then the terminology must be made consistent. If they are different, then the difference must be documented.

3.1 What about "Topic" and "Topic title"?

4. Is there any difference between "Comment" and "Post"? If there's a difference, can you please define both? It may affect the translations quite significantly. If there synonymous, please consider dropping one of them.

5. Some messages that use PLURAL may or may not need an additional clause for 0. For example, it may be needed in the message flow-rev-message-reply-bundle: "$1 {{PLURAL:$1|comment|comments}} were added. I considered sending a patch with something like {{PLURAL:$1|$1 comment|$1 comments|0=No comments}}, but then thought that it may be irrelevant in this context. Please go over all the instances of PLURAL use and add it if necessary.

5.1 What would make this message even easier to understand is, again, better qqq documentation. Currently it says "When multiple replies have been posted, they're bundled. This is the message to describe that multiple replies were posted." This is good, but it should also say where does this string appear: Near a post? In an email? What must happen so it would appear? The same applies to all messages.

6. Some messages include parameters that will be replaced by usernames. It's not clear whether this must be a username or whether it can be an anonymous user, and if it is an anonymous user, how will this be handled. This must be made clear in the qqq documentation of every such message.

7. The message flow-rev-message-edit-title currently reads "[[User:$1|$1]] {{GENDER:$1|edited}} the topic title to [$2 $3].". I suspect that instead of "edited" it should say "changed", but please check this.

8. The message flow-post-history is very hard to understand. Why the quotation marks? What's the post? What's the comment?

9. Some messages with imperative verbs include the current user name for GENDER support, and this is very good, but some don't. For example, flow-topic-comments, flow-talk-link, flow-moderation-intro-* and others.

10. In general, can you please prepare a glossary of terms for this extension? All of the above and then some can go there - moderated, header, title, board, comment, post, delete, suppress, censor etc. If "moderate" can have different meanings with different words, for example "moderated user", "moderated post" etc., then all the meanings must appear. You can simply write it as a page in mediawiki.org and make it translatable. The Wikidata project did such a thing and it was supremely helpful, even though it changed frequently throughout the process. This helps not just the translators - it should help the developers understand and plan their own work better.

Re: 3, 4, 10, see Flow Portal/Nomenclature. It's a start.

Also mentioned at mailarchive:wikimedia-l/2014-September/074206.html.

And what about maths? Are we going to be able to discuss how to format a particular mathematical equation and give examples of its use? The problems here is that VE maths editor project bug 43058 has only just started. A bigger problem is that there is a WONTFIX on the rollout of the mathjax renderer bug 36496, without that anysort of interactive mathematical editing is imposible.

+1

There is a functional <math> VisualEditor plug-in that lets you edit the LaTeX directly already in master (it's currently marked as "experimental" and so isn't available on the wiki unless the wiki is set to use that setting). Longer-term this will indeed be a graphical editor, almost certainly using MathJax, yes.

You can play with the code on this test page; we're evaluating what more it needs (beyond an icon!) before it's stable enough to switch on in production. Expect things soon. :-)

Nice, but the input box needs to be much bigger. We sometimes have very large multi-line equations say

$\operatorname{atan2}(y, x) = \begin{cases} \arctan(\frac{y}{x}) & \mbox{if } x > 0\\ \arctan(\frac{y}{x}) + \pi & \mbox{if } x < 0 \mbox{ and } y \ge 0\\ \arctan(\frac{y}{x}) - \pi & \mbox{if } x < 0 \mbox{ and } y < 0\\ \frac{\pi}{2} & \mbox{if } x = 0 \mbox{ and } y > 0\\ -\frac{\pi}{2} & \mbox{if } x = 0 \mbox{ and } y < 0\\ \text{undefined} & \mbox{if } x = 0 \mbox{ and } y = 0 \end{cases}$

I also get wierd interface errors if I have my preference set to math_png and try to edit the large equations.

Is this related to Jiabao Wu work or something different?

Yes, this is Jiabao Wu's work. I agree that there are some improvements for this before it's really ready, but I think it's close.

I understand that it is proposed, if not decided, that the Flow database will contain HTML5+RDFa only, and in that case it would not be able to store mathematics markup. The workaround proposed for that would be to put mathematics markup into some kind of scratchpad.

This seems less than optimal. There is an obvious necessity for transferring mathematics between articles and boards for discussion and back. We shall almost certainly need source-level editing of the raw markup in both article space and discussion space.

Please can we have some kind of confirmation that this is going to be possible and preferably no less convenient than the current system.

I don't think that anyone has said that HTML5+RDF storage precludes storage for mathematics work; that's something that the Parsoid team is working on.

I cannot promise that there will be mathematics markeup in normal discussion comments. I can promise that there will be collaborative authoring areas in Topics that will accept and store mathematics output.

As had been said, if you can promise wikitext authoring areas embedded in each message, it would be satisfactory. Otherwise, many articles would still be using a "conventional" talk page, although we might have to add additional namespaces.

Thanks for that update.

Thanks for that extra information. The need expressed is to be able to transfer text, including mathematics from an article to a discussion area, discuss it, possibly modify it, and transfer it back into an article. At present this is possible using cut-and-paste on wiki and LaTeX markup. Can you promise that the new system will support something equally convenient?

You will be able to cut-and-paste into the collaborative authoring areas. I feel it is reasonable to assume that this will include LaTeX markup. I expect this will be more convenient but some people are masochists and like to do things the hard way.

I'd like people to stop asking for "promises". It's very difficult to promise anything when code hasn't been written.

Thanks for that assurance. Rather than the word "promise" (which you introduced into this discussion), would you rather say that you have "clear plans" to deliver the capability we require? The precise terminology is not so important, provided that we had a good reason to believe that the need is well understood and reasonably likely to be delivered. The point is that we as editors need a certain amount of clarity about the developers' plans in order to engage effectively and constructively with them, and in particular to warn when the development process seems to us to have gone seriously astray.

That won't solve the problem. If Jorm says something like "At this point in time, I'm tentatively expecting to eat a cheese sandwich sometime next week, subject to availability of time and materials, and assuming an absence of unforeseen contraindications as well as the absence of potentially better alternatives", and he doesn't post a video of himself eating that sandwich along with testimony of people who saw him do it in person, then people come back and complain that he's broken his promise to eat a cheese sandwich.

"Clear plan" means promise to these people. "Plan" means promise. "Expect" means promise. "Hope" means promise. By the time you get through the rumor mill, even "might be possible" means promise. After months of this, I think you can imagine why Jorm is a bit wary about saying anything that could be misinterpreted by other people as meaning that any particular outcome will happen.

What we could get from the WMF (probably not Jorm) is that Flow will not be rolled out, even for beta testing, without certain features working (at least, in alpha test conditions). I would say the minimum feature would be

• Copy/paste between VE, Wikitext, and Flow messages (although, in some cases, it might have to be in Flow as an embedded Wikitext object.) This should include (in theory) anything which generates valid HTML; in practice, it should include < math>, anything tested which generates valid HTML (which includes templates with unclosed tags if they get properly closed by other templates, regardless of Parsoid), and anything you consider a valid Flow message without special workflows.

But I've already said what I expect as a minimum for a functional Flow system

I doubt you'd be able to get any promises along those lines from any employee of the Foundation, actually.

Editors wouldn't be so eager to request such promises if the dev team kept a public, updated list of all features that they're taking into account in their design, where all requests made by the community and acknowledged by the developers could be traced.

You're expected to have that with Agile methods. When you don't have an upfront design, communicating the current status of development at all times is vital, but the dev team has a serious problem of miscommunication with their final users.

If you shift focus from "I promise that final product will have X" to "I acknowledge that you need X", that could solve the problem without the need to make promises.

Even Agile methods should have a closure criterion; acknowledgement that if certain things cannot be done, then the product should be shelved. But "I acknowledge that you need X" would be helpful. So far, on VE, there are at least one "won't fix" and a number of bugs listed as low priority enhancements which fall under the minimum required for (at least, me) to consider using VE for major edits. Flow isn't yet to the point where bugs can be reported, or even feature requests be made.

The people here and there shouts: math-math-math, but nobody clarifies about what precisely do they speak. What is your “math”, indeed? The <math> tag really present a special problem. But articles on many technical (and not only) topics use tens of special templates (I mean: formatting templates, not navboxes), and mathematical articles use them as well and are not exceptional in this sense. Will wiki templates be expanded in Flow or no? Will we have a possibility to use an actual formatting code whether is it mathematical or no?

still waiting for an answer...

The discussion here is relevant.

Rationale does not have a rationale in it. Presumably the rationale is "We believe a modern discussion system will help attract/retain new/active contributors." (Which may be true, but my guess is not. A wiki's contributions must plateau as it approaches 'completeness', the reading standard required rises beyond the average of the readers, and the project morphs into a current events repository.)

How will this "flow" have anything that we expect from talk pages? How would one fix other people's comments? Archive discussions? Revert vandalism? Hat unwanted posts? Also, this is just making WP look more and more like a social network. It's a solution in search of a problem. Newbies already know how to edit talk pages. The worst thing that happens with the current system is newbies forgetting to sign their posts, which doesn't cause too many problems what with SineBot singing posts. IMO the only useful thing coming from flow is being able to watch individual threads. King jakob c 2 (talk) 20:05, 20 December 2013 (UTC)

You may perhaps wish to actually play around with it before you react with such hostility.

You may consider that a) perhaps he or she did play around with it, but didn't save his efforts (or made them as an IP), and b) if you get this kind of hostility, perhaps you may consider why he or she has that reaction instead of just ignoring it. Ignoring negative feedback, even if in part parhaps unfounded, is one of the things that caused the whole VE fiasco (being an extremely immature product was the main reason, but the way WMF handled the deployment and the feedback was a major contributing factor). Treating people who give their feedback here, in the way you just did, is just repeating the same issues.

OK, I've looked around in Talk:Sandbox, and see that I can hat unwanted posts. However, if someone vandalizes my talkpage, I don't want to collapse the vandalism, I want to revert it. And also, I don't want an infinitely long string of messages on my page, which would happen if I couldn't archive it. Furthermore, while I personally archive messages instead of deleting them, others prefer to delete them, which seems to be impossible with flow. Finally, and rather ironically, I find the whole layout to be rather clumsy and counter-intuitive. King jakob c 2 (talk) 13:24, 21 December 2013 (UTC)

Hi King jakob c 2: Thanks for the more detailed feedback. I've added those points to my notes as:

• Want to "delete" some posts (e.g. tests/vandalism, newsletters, etc), rather than "hiding" them.
• Want to be able to "archive" topics (or somehow remove them from the main display).

Both of those have also been mentioned by other editors, and are good points.

Note: Please put further feedback about features at Talk:Flow (or en:Wikipedia talk:Flow), and more detailed comments/suggestions about the layout&design at en:Wikipedia talk:Flow/Design FAQ, so that other editors are more likely to see and be able to contribute. Much thanks!

Thank you.

Is this the new LiquidThreads?

No. LiquidThreads will live or die on its own. The lesson learned from LQT is that it was too aggressive in what it supported and was supposed to do.

Unlike LQT, this is only targeted at User:Talk, not Talk pages and discussions in general, and addresses modalities that hurt user interaction (especially new users). Current wiki conventions to, for instance, replying to a talk message are quite unlike any other web affordance currently in use for user-user/user-group communications. Flow wants to address that while following the core values of a wiki (if you want private talk, take it to e-mail. That would not change).

It's not necessarily a complete replacement to User:Talk. The two might coexist indefinitely and that is not addressed yet in the Echo spec (currently its mostly a design spec with mostly high level engineering). Though the hope is that it will supersede it—at least in usefulness. And some "upgrade path" for those who want to move a user talk discussion to flow or "upgrade" their user talk should be provided.

Note: "upgrade" in quotes because on one hand while you gain some features esp. Echo integration, you do lose things like the free form format of Talk pages.

I hope this clarifies things.

Still, does it consider all the wishlists and problems with LQT (filed in bugzilla)? I don't see most of them here but they'd seem to apply, I hope I don't have to re-file/list all of them on this page. Cheers,

It does not consider all the wishlists/problems. However the lessons learned does apply.

There is no need to re-file/list those bugs because LQT is not killed off (just unsupported at the moment due to resource issues). Flow is a separate project from LQT/LQT3.

My fear is, and I believe it is a lot of other peoples fear, that one day LQT will be incompatible with some future version of MW. This would be an end of story for the wikis utilizing LQT.

However, my impression is that there are quite a lot them around and still counting. This is due to the fact that even the current life supported version of LQT is far better for talk pages than any other solution around (including plain talk pages with no thrills). Besides, LQT was and still is one of the coolest things that came out of development during the past five years.

Basically the problem is, and this is the major cause of emotions here, that all these wikis do not know what to expect with regard to LQT and are being left alone for quite some time now. They are stuck in the darkest uncertainty regarding their wikis.

LQT is beyond the point of no return. We know it, WMF knows it and this is the very big dilemma.

I won't go so far as to say that it is "beyond the point of no return," but I understand your fears and it's reasonable to have them.

I don't think the goals of messaging can replace LQT. In determining editor engagement and features goals, it was clearly obvious that user-user messaging is broken so a project was put in 2012-13 goals to address that. This has been named "Flow" and according to planning will not be worked on directly until early 2013 (all work beforehand is infrastructural, and UI/UX resources are prioritized around notifications).

I want to emphasize that improving User Talk (user:user messaging and discussion) is a fundamentally simpler structure of interaction and requirements than Page Talk or LQT which is many things to many wikis (from a Talk replacement to a full blown forum and discussion system). At some point, things move beyond user-user to discussions, and I (personally) think that LQT rework to incorporate the core architectural and feature changes (Echo/Flow/Global Profile) is closer to a solution here than upgrading/changing a user-user messaging system like Flow.

There are no formal resources for LQT development in this year's planning (there are no formal resources on Flow for half the fiscal year). However, the same people involved with Flow are the ones who have worked on LQT which means that there might be some design guidance and bug prioritization for what needs to be done here and it can be kept up-to-date. (I've tried to give the developer the freedom to update LQT code under the auspices of working on Echo and Flow.)

Be aware mediawiki.org currently uses LQT without any plans on that changing. So while it doesn't mean you'll see LQT on English Wikipedia any time soon, this should keep LQT tracking some of the new features being developed (notifications, at least). Finally, probably the best bang for the buck on LQT improvements would be after the new Visual Editor is integrated in MediaWiki. That won't happen until sometime in 2013 anyway.

As for the WMF resources and the mediawiki community at large. This is part of a large discussion on what is and isn't working with respect to integrating changes coming from the developer community, which is broken far worse with more extensions than LQT. I'll follow whatever comes up from that.

It's my hope that by placing the same people on both Flow and LQT, the developer of LQT will get some guidance on the the LQT bugs/features that should be dealt with.

The LQT developer is left alone without any support from community feedback, infrastructure/ops, and product design and development when it comes to LQT and LQT3 (which was a deferred project before I even joined the WMF). In the past, we've found that when left without support, projects have a tendency to runaway and/or never see the light of day. The WMF plans to not repeat these past mistakes in features (PendingChanges, LQT, LQT3) by providing that support on formal features going forward (AFTv5, Page_Triage, Article_Creation_Workflow, and the VisualEditor being examples of this new approach which will be applied to Flow and Echo this fiscal year).

My understanding is many mediawiki installs like LQT and would love to see some movement here. I have to squeeze this in with the reality of the resourcing here and other priorities. This is the best I can offer. (In terms of developers who know LQT, we are talking about a single part-time student developer.)

meh perhaps we should make a (maintinance) script allowing people to deconvert from LQT (dump all the LQT threads on talk pages), I imagine that would help stop the lock-in fears people have (which from what I can tell seems to be where most of the frustration is coming from). Even if people don't use it, its nice to know one has the option to disable LQT if need be.

Maybe we should just try to really re-energize development! I really would like to help. Maybe there could be somewhere a test instance be installed. I'm trying to setup a debug server at the moment. Maybe there could be done something with jenkins that at the moment is only runnig with mediawiki. It's just the point to do something and not to complaine and to think about what could be done and so on!

I believe there already is a test instance of LQT3 on Labs. Talk to User:Werdna.

"There is no need to re-file/list those bugs because LQT is not killed off". This is not a very satisfactory answer, bugs and feature requests have to be considered now for Flow, not just postponed to a mysterious future, or no, Flow won't incorporate the "lessons learned" at all. LQT has so far 121 "enhancement" bugs besides 141 bugs and many others nobody bothered to file. Please don't waste the time people spent on filing them hoping in the future. Thanks,

Flow is just a step caused by the laziness of developers somehow like "let's make a fast temporary solution to show results" instead of make things right

So instead finishing one project there are others started. That's really bad. I love LQT and it's really accepted on my wikis. The only problem is, that it's still extremly buggy. But the concept and the base to build on is good. Flow is bullshit. Sorry. --DaSch (talk) 12:40, 14 July 2012 (UTC)

Yes, it's frustrating. :-(

But in addition to the bugs, LQT was built without considering the fact that as it is, it can't scale to the size/traffic to a major Wikipedia (for instance, English). That, among other reasons, is the reason that Flow is what it is.

The same people who worked on LQT and LQT3 will be working on Flow, so there is no reason they can't revisit LQT and back port those changes and give LQT some love.

…

One point of clarification. Messaging was determined as a "must have" by Product's 3-year plan to deal with Editor Engagement. Flow came out from that, not a determination to keep or abandon LQT. For the 2012-13 planning/goals, we added Flow at the last minute which is much more aggressive planning that normal (I felt we can safely do Notifications & Global Profile. The latter was pushed out and Flow was added.)

The worry is to continue or repurpose LQT to solve messaging goal would jeopardize actually accomplish that goal to within the aggressive timeline. I felt that it was more likely to accomplish some sort of messaging this fiscal year with the option of backporting to LQT or gradual improvement of Flow would be better than to try to shoehorn LQT and its baggage into the messaging problem.

Perhaps I was wrong, but scalability issues in LQT means that there's a lot more going on there that isn't as simple as addressing reported bugs.

…

Concerning your specific needs. Given that LQT has no official support this fiscal year, we should loop back into discussion concerning some way where community dev contributions on LQT can be incorporated without requiring oversight from the WMF. Theoretically the WMF could freeze on the current version of LQT.

Of course, since it's now all in Git, you can easily fork LQT or LQT3 and know that we can merge those changes back in when the WMF revisits LQT.

>Concerning your specific needs. Given that LQT has no official support this fiscal year, we should loop back into discussion concerning some way where community dev contributions on LQT can be incorporated without requiring oversight from the WMF. Theoretically the WMF could freeze on the current version of LQT.

Last time I checked, LQT was scary, and hence had essentially no volunteers working on it. (Or perhaps that's an artifact of the mysterious LQT3 that will in theory replace LQT which everyone is waiting for, and thus people don't want to work on the "old" version)

That's the point. One day Wikimedia announced LQT3 so everbody thought they will finally make it really great. And after over a year Wikimedia is cancelig the project and what is left is a non-working git-branch and nobody left for maintaining LQT2. That's a bit like walking half the way and then turning back to take the car and drive somewhere else. And we are standing here and no chance to get away. Somehow it's Wikimedia's fault that there is no further development. They took it and killed it.

I don't think its Wikimedia's fault neccesarily. They do not have a responsibility to develop every extension in existence. (I do think they have a responsibility (with in reason) to support volunteers doing LQT development (or more generally any development aimed at Wikimedia wikis)), but the fact of the matter is, with exception of a commit to make LQT work on postgress, nobody in the broader community is developing LiquidThreads whatsoever.

It's not a matter of developing, it's not even maintained at all: «one day LQT will be incompatible with some future version of MW», no it already is.

Is there someone planning a LQT-to-Flow conversion server-script? Even if not, would it be technically possible to implement such feature, in case LQT becomes truly incompatible with the MediaWiki version installed here?

Yup, that is planned. There's no ETA, but it's definitely on the to-do list. :)

Thanks, I'll be waiting for later updates :-)

Of possible interest to you: Grants:IdeaLab/Edit metadata. Thanks!

Will this affect all pages in talk namespaces if it is rolled out Wiki-wide on one of the wikis, or can this be selectively (de-)activated? I know that on English Wikipedia, some people use the talknamespaces to store scratchpad information in subpages, while developing drafts on the subjectspace subpages. -- 65.94.76.126 12:08, 24 May 2013 (UTC)

This is an interesting question. I really can't answer with any authority until we get deeper into development.

I can't imagine that we'd think it a good idea to eliminate scratchpad places. We may actually create special scratchpad places to avoid namespace confusion.

Would every page acquire a scratch: namespace, as they currently have a talkpagespace and subjectpagespace? scratchpagespace. (this would then create a namespace location to store Template workpages that on English Wikipedia currently reside as subpages) ?

I rather like the idea of a Scratch: namespace. I think maybe we'll talk about it.

The problem, though, lies in that we might end up creating a "shadow" discussion zone. Some people who hate Flow (for whatever reason) may decide to only communicate on the Scratchpads. That would be an unfortunate turn of events.

Should I start laughing? Are you actually aware of what you just said?

If people see the need to avoid Flow, this will be because of limitations of this new discussion system. If flow is thought through properly it will fulfill the needs of all editors, therefore making such workarounds unnecessary.

When you already start mistrusting editors at this point (and it's the editors you're writing Flow for, right?) you probably should stop development of Flow immediately.

Patrick: are you telling me that every piece of software we work on should serve every possible use case of every possible editor?

Jorm is not saying "a majority of users will ignore Flow". He is not saying "A plurality of users will ignore Flow". He is saying "even if fifty people resort to scratchpads, we have a problem because discussion has now fragmented". I'm finding the lack of good faith you're continuing to show here frankly disappointing.

No, but for most editors. And as the comments on FLOW show, most editors are concerned with the way FLOW might constrain editing.

I see your point that it might not be a "majority" of users resorting to scratchpads. But if Jorm is considering not implementing scratchpads at all because of those who do, he is afraid it could be a notable amount of editors (not just "fifty people" he would probably not be worried about).

Now explain to me: If Jorm is afraid a notable amount of editors could resort to scratchpad discussion — why is this amount of editors not notable enough to redesign FLOW to fit their needs?

I rather think that something along the lines of English Wikipedia's "talk in article" warning template can be used to warn users of improper use of scratch space. People do that in articles now, and are handled by informing them of the talk page and how to use it.

I can't see that happening. People will leave rather than be told how to work together. Personally I think all the problems listed on the main page could be solved much easily; we already have notifications, make a notification if there is a reply in a section you've commented in. Simple. It can't be that hard to make talk pages autosigning, although what about Project pages, where posts may or may not need to be signed? At least now if you want to add a signature you learn how to do so once and then it's sorted. New users are just going to get more confused. Reply button. The en.wiki teahouse already has one which seems to work fine. Sorted. I could honestly see a consensus, at least on enwiki, to oppose this change and if it is forced upon us, people will leave.

People always threaten to leave. They almost never do. In fact, if you wait a couple of months and go back to the loudest complainers, they often can't even tell you what the differences are.

As for the difficulty of autosigning, you've exactly identified the problem: it is hard to make talk pages autosigning because there's currently no way for the software to know whether your change is one of those that needs to be signed or not. Flow will provide that distinction, and autosign all the ones that ought to be signed.

Well, It basically achieves this by prohibiting changes that wouldn't need to be signed at all, so you can hardly call this a feature.

Oh, and when you start comparing Wikipedia to Facebook (see link) I'll leave immediately... No, actually I won't, but Facebook and Flow are (should be) completely different:

• Facebook wants people to be involved in endless, and pointless discussions as long as possible. Quantity but quality!
• Wikipedia needs an efficient discussion system, so basically the opposite.

Why do you believe that we won't be able to add things that are unsigned? Please go read Flow Portal/Use cases, and pay attention to all that talk about the importance of unsigned stuff like WikiProject banners. Search for the keyword "metadata" on that page: a method of accommodating this need has been planned from the beginning.

I neither said nor implied that we wouldn't be able to add things that are unsigned.

But a default comment will be signed with Flow, and there is nothing to change this behavior. Everything else must go into the unstructured section you are talking about.

So there is no "magic" auto-sign algorithm involved in Flow, just restrictions installed to remove any need of such an algorithm.

Perhaps you would like to explain what "prohibiting changes that wouldn't need to be signed" means, if it doesn't mean "we wouldn't be able to add things that are unsigned."

I don't understand the difference (since one implies the other), but what I was saying is, that we can't edit the posts of others (e.g. to re-indent, fix some link, etc.) so every edit we can make is posting a comment which automatically gets signed.

Everything else we might post goes into the unstructured edit section where signing isn't necessary.

You seem to be assuming a lot here. You're assuming that Flow will have an unintuitive, segmented, and restrictive interface. Seeing as Flow doesn't exist yet, it's difficult to say what it will look like and how it will function, but I doubt it will be as you think.

If you wish to make suggestions to the development team, it makes their job a lot easier if you do not work from your assumptions about what the software might end up looking like, but instead explain to them exactly what you want the software to be able and unable to do, in broad general terms.

The difference is that you will be able to add unsigned material on a talk page—in the unstructured section. You have already been promised the ability to add unsigned material.

There will be much less need to edit other people's comments (e.g., re-indenting), but it is currently planned for at least admins and perhaps other trusted users to be fix problems with comments (although this will be noted, just like it's noted now in the talk page's history). I'm sure that people whose comments have been vandalized (e.g., removing the word not) or wrongly blanked will appreciate this limitation.

I hope that the ability to edit others' comments will be a separate userright that can be given to different usergroups on a per-wiki basis.

Per the discussion at English Wikipedia, it seems that a scratchspacepage for every talkspacepage/subjectspacepage will be required, since FLOW will not render wikicode the same as the subjectspacepage will, so showing examples of sample revisions to the subjectspacepage will need to be placed onto the scratchspacepage as a FLOW based talkspacepage will just not support such things.

That's part of what I was trying to say about Flow. Flow will, at least in Jorm's concept, not be suitable for discussion of article Wikimarkup, and hence not be suitable for article talk pages.

That's not what I've said at all. Please do not spread mis-information while attributing it to me.

I didn't quote you. I said that your concept of Flow (not allowing editing of Wikimarkup and rendering of all Wikimarkup suitable for articles, including templates) would not be suitable for discussion of Wikimarkup.

Do disagree with the statement that your concept of Flow does not allow editing and rendering of all Wikimarkup, including templates?

I'm sorry, but I'm not going to get into discussions wherein the spirit of my words is corrupted to serve a point which I am not making.

It's true that you're not making the point that Flow will not be suitable for article talk pages; nor I think that Arthur wanted to attribute that point to you. We are making that point, based on the words you've used to explain what Flow will and won't be able to do.

I've tried to summarize this issue, over at the end of the w:Wikipedia talk:Flow/Archive 3#Supported Wikitext thread, with a handful of clear examples.

For what it's worth, when the current Flow code "occupies" a talk namespace, /subpages are unaffected. Subject to change, early days, etc.

I'm going to remove this large addition from User:199.255.222.82 and paste it below, because whilst there are some good points in here, it's structured more as a series of discussion points or musings, than as documentation. (I'll ping the user's talkpage to let them know, and give them an opportunity to cut and paste it into their own comment box.)

<paste begins>

Users expect a modern and intuitive discussion interface.

Talk pages—as a discussion technology—appear antiquated and user-hostile.

Their most obvious value is to teach the use of wiki editing and social conventions - so that only one set of skills would be required to edit article pages and also talk pages.

Less obvious advantages, apparent mostly to more experienced users, are the abilities to

• easily merge similar, split multiple, or refactor topics
• quickly determine origins of any character of text in case of abuses
• manage potential problems (such as misattributions, deliberate or not, or immediate corrections by oneself) with social rather than rigid technical means
• embed wiki links or spelling corrections in both one's own, and other's comments, if socially reasonable
• let any user act as moderator, for instance, archiving or refactoring text about disputes that have been settled

When abused however these capabilities can appear as disadvantages. It is largely Wikipedia's cultural norms and sanctions that prevent same. Persons comfortable with wiki source code have a marked advantage in refactoring or name changes or other decisions, as do persons very comfortable with the social conventions and willing to enforce.

Users are surprised by the cultural norms of the community.

Many things about the culture that has grown up around talk pages (such as "talkback" templates or being able to edit other people's comments) are confusing, even disturbing. That is not to say those conventions are wrong, merely not what those users are prepared for.

New users are prone to abuse these features or misinterpret their use. For instance, one well-known user involved in a discussion might correct a spelling error or bad link in someone else's comments, by way of helping them make their point, whether the correcting user agrees or not. Abuse of the exact same ability by a bad-faith editor attempting to make the initial comment appear wrong or stupid is intolerable, but of course there is no way for technical measures to detect the effect of such a correction psychologically or socially. The choice between technical and social measures in mediawiki-based "communities" has always favored the social over the technical means of control. Accordingly, very strong cultural norms have arisen and are very rigidly enforced. Not all instruction or enforcement is polite, nor could it be made polite or exhaustive - the design choices involved are ethical, not technical. The process by which cultural norms are agreed upon is political or social, not engineering.

Accordingly there is no way to make new users familiar with more technical enforcement and less open collaborative media comfortable with the wiki paradigm, until they have actual experience with wiki. Talk pages historically have been a sort of "cold turkey" introduction. Flow has potential to more gently introduce the cultural norms and ethical positions taken by mediawiki communities, while retaining the alternative of wiki-based page editing by trusted users.

We believe that a modern user-to-user discussion system will improve the projects.

Better methods for collaboration will improve collaboration, which will improve all of the projects. Mediawiki is the most widely used groupware in the world and increasingly used "behind firewalls" for corporate and nonprofit use. Many of the cultural norms evolved for Wikimedia Foundation projects are not perfectly suited for these uses, and the ability to support a diverse range of cultural norms in user-to-user discussion, with more technical controls when required, should increase the total number of mediawiki users and possibly displace proprietary pe-wiki "groupware".

Simultaneous support of the best features of "threaded" discussion media and wiki talk pages should accordingly:

1. increase the total number of users of mediawiki, by making new users more comfortable expressing themselves and becoming involved
2. increase the diversity of users of mediawiki, including projects for which more technical controls are required - which will also increase the total number of users
3. decrease the appeal of proprietary mediawiki derivations and clones which have improved collaboration features
4. decrease the appeal of competing groupware including Drupal, Joomla, Wordpress and DokuWiki
5. make talk pages more appealing visually, inclusive, and easy to understand for those unfamiliar with mediawiki

<paste ends>

Hello,

Based on my experience with Wikipedia in French, I have some difficulties to identify how Flow would replace the subpages in the article talk space.

In Flow Portal/Functional Specifications/Boards and Topics#Board, I read "Each MediaWiki page object may have one (and only one) Board associated with it.". What exactly is considered a MediaWiki page? How could we use Flow to replace subpages of talk pages (for which there is no corresponding subpage of the main page)? On WP:FR, we use this a lot for evaludation purposes, such as in the process towards good articles and featured content.

On that same page, I also read "If a Board's associated Page is deleted, the Board itself is deleted.". Well... One case where we use subpages of the article talk namespace on WP:FR is for the Articles for Deletion process. And we definitely need those discussions to survive the possible actual deletion of the article!

I missed that. It's usually the right thing to do, at least on en.Wikipedia; see w:en:WP:CSD#G8 (w:en:Wikipedia:Criteria for speedy deletion#G8. Pages dependent on a non-existent or deleted page).

Subpages: Note that the plan is to not place Flow in any /subpages automatically, but rather to provide some sort of switch so that it can be selectively enabled where it is wanted.

Boards without associated pages: That's a good point. I've taken a look around, and these seem to be examples of what you mean:

• AfD resulting with deletion: fr:Discussion:Solvaxis/Suppression
• AfD resulting with keep: fr:Discussion:Vivre avec Camus/Suppression
• Article evaluation subpage: fr:Discussion:Calcul de la date de Pâques/Article de qualité

We used to do this at English Wikipedia, too, in various places, such as w:Talk:Steve Reich/Comments, but they've been phased out over the years (See w:Wikipedia:Discontinuation of comments subpages). I believe we still do this in various places in non-article namespaces, but I can't find any great examples at the moment.

I'll ping the developers, to let them know.

Deleting Boards: Do note however, that as it says, if a "Board" is deleted, any Topics (threads/content) within will not be deleted - the topics will still be linkable and visible, they just won't all be compiled into a single Board. Deleting those Topics would be an entirely different process. I'll have to check, to find out what would happen to the Header-material, in that circumstance.

We still do it in article namespace as well, e.g. for good article reviews like or .

Sorry for popping up only seldom on the MediaWiki wiki... I just want to confirm that the examples you found indeed correspond to what I had in mind and add some info about the case of a deleted article:

• The (now non-existing) w:fr:Solvaxis page in the main namespace contains a first box listing the journal of moves and deletions, in which there is a link "(Décision PàS)" pointing to the talk subpage containing the AfD discussions and conclusions.
• From what I understood regarding the topics in Flow, we would need a board containing several topics to match the current structured content of the AfD talk subpage for one article on WP:fr. You remind us that the topics would still exist even though the board would be deleted... and I'm not sure that this would be sufficient.

Anyway, thanks (also to the dev's) for looking into this.

I was looking at some of the research mentioned in footnotes for this project and noticed some of the user data came from research in 2004-2008 when the site was quite different than it is now. Other research came from surveys or studies done several years ago.

So, when I'm looking over these usability tests, I'm surprised not to see any date for when the testing occurred. Was this before, during or after the VB interface was rolled out? This would be useful to know, even if it is just a date range (like Dec 2012-Jan 2013).

Thanks!

The videos linked in Flow_Portal/Research/User_Test_Data#Test_Results were all made in January/February 2013. (Date is in topright of the video. :)