I prefer usual system. I don't want the new system. (I am not very good at English.)
About this board
- Please test at Talk:Sandbox; this page is for discussions and suggestions.
- If you find a bug not yet tracked, report it in Phabricator, or here if you can't.
You can leave your message in any language, but answers will be made in English (or your language if we speak it).
Thank you for your opinion. If you want to explain why you prefer the usual system, please write it. You can write it in any language. :)
How much money was wasted on this failed project?
Has anyone published a guesstimate of the amount of money that was wasted on this terrible idea?
Look at this thread, they actively deny VE on talk pages, probably to push this failed bullshit Flow. This is just a weask forum impersonation, without any of the flexibilities the current system has. Dumbed down beyond recognition to increase the facebookisation.
you summed it up nicely here: "preferred to create shiny new bling instead of boring maintenance".
Flow is a vanity project, just like LT was.
They did a so-called Flow satisfaction survey, but under completely bogus assumptions: They artificially created a rift between wysiwyg and proper talk pages, although that's just a decision by the WMF not to implement it on talk pages, without real merit. They based a lot of the questions ion this bogus assumption, so the answers are just rubbish. Of course asked this way: old fashioned editor or wysiwyg-editor, and the second only possible with flow, you'll get the answers, that were intended by this: I want wysiwyg, so I have to want Flow.
It's this complete dishonesty about projects like Flow that's so frustrating. They seem to do anything, including blatant lies, to push their pet projects against the community. Grüße vom Sänger ♫(Reden) 17:28, 22 January 2017 (UTC)
The WMF should not be allowed to use surveys because they are using them to get the result they want instead of trying to determine what the consensus is.
They use surveys on external servers, and they only invite a small group of people, because they know the majority disagrees with them. We should have an RfC on en.wiki instead.
There was an RfC on enWP already, and Flow was planted in the bin: T148611.
They will probably get the same results on deWP, if they dare to introduce this piece of junk there anywhere.
Bur as you see on this baloney "survey", they don't like real feedback based on facts, they live on those kind of alternative facts like the groper in chief and his lackeys. Grüße vom Sänger ♫(Reden) 14:43, 23 January 2017 (UTC)
@Sänger I do not think we've ever received an official reply to this answer.
No, and I don't expect any. They still maintain this fairytale about a dichotomy between wysiwyg and talk pages, the one that was the base of this completely useless "survey" I mentioned above. They even implemented VE in discussions themselves in the 2017 Community Wishlist Survey, but in this still insist that very discussions with VE that it's not possible and moved this simple wish, that could be done in no time with probably just a simple check in a checkbox, to "not possible", because those who desperately want Flow don't want better real talk pages. Grüße vom Sänger ♫(Reden) 09:28, 9 December 2017 (UTC)
Rollbacking hiding actions
I'm currently facing a case of an IP vandalism my Structured discussions based talk page by hiding comments. Unfortunately, it seems like I can't rollback all the edits in bulk (I'm an admin on Wikidata and therefore have rollbacker rights). See https://www.wikidata.org/wiki/Special:Contributions/188.8.131.52
Is there another good way to deal with vandalism like this in Structured discussions?
Furthermore it seems like unhiding a post makes it go to the top of the talk page. This suggests that it isn't even possible to completely undo the vandalism.
I'm sorry, but there is no way at the moment to deal with that kind of vandalism, except click on "restore" for all edits.
If you unhide the topics, they will indeed be on top of the page, because they are they become the most recently active. It is possible to change the filtering options for your talk page, and switch momentary to Newest topics.
Being able to handle vandalism seems to me like an essential feature. Is there a ticket?
Cleaning up the mess left behind from the failed LQT and Flow experiments
The WMF should focus on cleaning up the mess left behind from the failed LQT and Flow experiments before it starts yet another experiment that is doomed to fail under the new name "Structured Discussions".
No reply whatsoever?
Is there a simple newb's intro somewhere?
Hi, I haven't noticed any straightforward 'how to' (like, with practical screenshot examples and such) to aid users encountering Flow/Structured Discussions for the first time. Does any such exist somewhere?
[I've encountered multiple pages across multiple projects talking about 'Flow' – goals and technicalities and such (for me interest started with mention somewhere on en:Wikipedia and branched out from there) – but this very page here on which we're posting is the first actual example of such I've encountered. Well, multi-user threaded example at least, I did have a brief slightly disorienting solo run-in when I updated a link on my user talkpage before coming here.]
Hi, did you had a look at Help:Structured Discussions/Quick tour?
Concerning your talk page on mediawiki.org, you can add the link to your home wiki talk page on the sidebar ("edit description").
That's 'in the ballpark' and 'heading in the right direction', tnx. I.e. it's the sort of thing I was seeking, but I think the page as presently implemented could use some specific visual examples of how threaded discussions can be expected to appear.
Trizek, thanks for the talkpage tip as well.
Have some visual examples is a good idea. Do you have some suggestions of cases that would be interesting? The challenge is to find ones that match for every language or cultural cases.
I see. Thank you for the idea, I'll work on it soon.
How can the visibility of threads in Structured Discussions be controlled
OTRS already seems to be a tool that can be used well for the use-case of user complaints that should have limited visibility.
I'm currently in the process of writing the equivalent of BLP for Wikidata. As part of the process, I want to have a way where people can contact admins to request information about them to be removed when they think it violates their privacy.
Would it be possible to configure Structured Discussions in a way that only the person who started a thread and users with the admin flag can see a thread?
That sounds like a really bad idea. All active wiki content is supposed to be completely transparent. If something needs to be private, it should be off-wiki exclusively.
My basic intuition is that it's beneficial to bring as much as possible on the Wiki. In this case, this likely means that the way of least effort involves telling people to go to the administrator noticeboard. Given that you are also a Wikidata admin do you have an idea about how you would like a structure to work that would be off-wiki for this use-case?
Many wikis use m:OTRS for things like this. The system seems to be very much built for handling sensitive information. Perhaps Wikidata could use the same system.
(Regarding it being beneficial to bring as much as possible to the wiki, I generally very strongly share that intuition. IMO, things like IRC, Phabricator, mailing lists, etherpads, etc all should be integrated into the wikis. Frankly, even code editing, Gerrit/Diffential, and the occasional WMF video broadcast should all be doable via wikis. But that's getting off-topic, I suppose.)
Okay, it seems that OTRS is the right tool here.
That's an interesting idea, but it would be a pretty profound departure from the philosophical fundamentals of MediaWiki wikis, as @Yair rand points out. I'm not going to refuse outright, but we'd have to have a very serious conversation about such a feature before starting to build it (and building it would itself be very challenging given how much MediaWiki is built around that assumption; I'd vaguely guesstimate that building it would cost about US$250k and take half a year, but that might be a little optimistic depending on details).
If you really want this feature, I'd recommend that you should work with others who might be interested to work up a detailed plan for how such a feature might be developed whilst maintaining product compatibility as much as possible with the rest of MediaWiki, either on a page here or on Phabricator. Sorry this doesn't have an easy answer..
Okay, that doesn't seem to be a reasonable amount of effort for the use-case.
Integration with mailing lists
One of the goals of Flow was to replace discussions that happen inside Mediawiki. In the Wikimedia universe not all discussions happen inside Mediawiki. Both Mailing Lists and IRC provide additional channels to communicate.
Given that the new Structured Discussions is now capable of threading, it should be able to display messages in the same threading that the Mailing List archive currently has. I think it's possible to replace the current mainling list system with a Structured Discussions based system. Nothing would have to change for the user experience for the people who subscribe to the mailing list. The could still get similar emails as they get now, but the mailing list archive could look like Structured Discussions.
+1, this sounds like a great idea.
I like that idea. Add an interface to discuss on Structured discussions using emails is an interesting idea to increase participation, by giving a new way to triage messages and reply to them.
Anciennes sections de ma page perdues ???
Bonjour, je suis incapable de trouver le contenu de ma page de discussion personnelle et donc les différentes sections...
Une aide en français possible SVP ??? ou en anglais pour un "non informaticien"... !!!
D'avance merci, Guy,~~~~
Quel est précisément le souci ? Avez-vous converti votre page de discussion pour utiliser les Données Structurées ? Si oui, comme indiqué lors de l'activation, les discussions existantes en wikitexte sont déplacées dans une archive. Désactiver cette fonctionnalité déplacera le flux de discussion Discussions Structurées dans une sous-page et désarchivera la page de discussion précédente. En savoir plus sur l’activation.
La majorité des pages d'aide concernant les discussions structurées sont disponibles en français.
This is another case of Flow's complicated unholy-hack producing bizarre random problems. There was absolutely nothing wrong here, except that Flow didn't render the page properly.
Not only is Flow broken, not only did Flow break the revert button, but the broken revert button fixed the broken page. And you wonder why people hate Flow?
"Structured discussions" are the status quo, this here is a step backwards, why this misleading rename?
Wikitext discussions use semi-structured layout, a flexible mechanism that provides a self-describing structure. The Structured Discussions project focuses on features that enable full-structured discussions by design, replacing the loose structure of talk pages with the rigid structure of a pre-defined database schema.
Why did you use this misleading new name for Flow, where structured discussions are taking place on most regular talk pages now? They are usually even better structured, and definitely better to restructure, if necessary, than this weak forum impersonator.
A discussion with a structure is a structured discussion. Most discussions on talk pages are such discussions. As the WMF is denying the use of VE on talk pages without any valid reason, it's only possible to structure those discussions in the normal editor. But as they are as flexible as any wiki-page in the wikiversum, unlike this completely inflexible and rigid-like-concrete unstructured forum impersonation formerly known as Flow, they are even able to get restructured to a better arrangement, if this would make the discussion better readable, and the connections between the different edits are open for anybody like everywhere in the wikiverse in the page history.
I have updated the summary trying to focus on answering the question at hand. I have hidden comments that were deviating from the topic. @Sänger, your opinion about the name and about the idea that wikitext discussions are structured too is clear.
The project name is not shown to users wherever this extension is enabled, and in this sense the name doesn't have an impact on actual users of this feature. The name is exposed to developers, admins, and people like us here discussing about a project. Discussions about project names are relatively frequent in the free software movement and other places. Statistically speaking, people just move on.
In any case, please let's keep a respectful and friendly tone.
Semi-structured content doesn't facilitates data-processing as well as a database schema does, but for human-facing content, the looseness and flexibility of a semi-structure is typically an incredible asset, as it allows to use the tool in ways and situations that weren't envisioned by the tool designer.
If the Flow developers want the tool to ever replace talk pages, they should be aware of and honest regarding what features they are removing, not just what they are adding.
Structured Discussions are a work in progress: features are not removed, but progressively added. Some communities are happy to Structured Discussions and are expecting new additions - we are working on it.
I'm afraid you didn't understand what I meant by "removing features"; I was referring to features that would be lost in the change from wikitext pages to Structured Discussions pages.
There's an important feature in the current wikitext-based talk pages, which is that their structure is defined by the community, user-editable, easily reshaped with a text editor, and ultimately optional. This flexibility is seen as an asset by experienced Wikipedia editors, and thus a "feature".
The Structured Discussions team has made clear that they don't want to support a semi-structured tool with lightweight structure requirements defined in wikitext syntax. Thus, there is every indication that the aforementioned feature (let us call it "lightweight structure") is one that will not be made available in Structured Discussions, ever, by design.
"Lightweight structure" created by wikisyntax is complicated to reproduce with all details. This is the blank page effect: you can do anything you want using a blank page, and the visual structuration is then made by humans, progressively, for humans - other humans have to learn how to use the codes and the habits to enter the interaction.
Most machines requests are excluded from that, so as newcomers, alas: as you said, it is for experienced editors. For them, we are not removing talk pages. The new developments are only for Structured Discussions users, aka communities that use Structured Discussions; most of them use them to interact with newcomers.
> The Structured Discussions team has made clear that they don't want to support a semi-structured tool with lightweight structure requirements defined in wikitext syntax.
For this year. As I was saying, features are progressively added: Structured Discussions are a work in progress.
Post a message, reply to it, reply to a previous messages is possible. Reply inside of a message is not possible (and even on unstructured wikitext talk pages, they are not the best practice for readability) but you can manually quote someone.
New developments will allow topic move and messages move. That will allow users to create sub-discussions or new discussions, which is the missing case for user-to-user discussions now. Which other cases from the lightweight structure do you have in mind? That would help for future prioritization. :)
> "Lightweight structure" created by wikisyntax is complicated to reproduce with all details. This is the blank page effect: you can do anything you want using a blank page, and the visual structuration is then made by humans, progressively, for humans - other humans have to learn how to use the codes and the habits to enter the interaction.
I know it's not easy, but it's doable. Many people have requested that the WMF develop tools that would support most newbie-frendly workflows on top of wikitext, like those already available at the en:Wikipedia:Teahouse. Supporting basic lightweight structure at talk pages should be relatively easy, as shown by the fact that we already have some tools that actually do it, and seems fairly feasible for the reduced set of use cases that newcomers would need.
As many have explained, changing the underlying technology forces newcomers to learn to different tools, while a semi-structured discussion system on top of wiki pages would create a platform for new editors to progressively learn about wikitext.
Can you provide an explanation for why the WMF has never devoted resources to approach that kind of tools, many times have been requested by the community, and is using them to develop an entirely separate tool based on entirely different principles?
> For this year. As I was saying, features are progressively added: Structured Discussions are a work in progress.
Are you going to include features in Structured Discussions for lightweight structure? (a.k.a. editing the page structure in markup mode). This is huge news! ;-)
Seriously, "topic move" and "messages move" is less than what is possible in wikitext semi-structured pages; those features only solve a few use cases, but they fall way short from what lightweight structure is being used for in Wikipedia.
> Which other cases from the lightweight structure do you have in mind?
I have provided examples time and again during the last three years, at Talk:Flow and en:Wikipedia talk:Flow. Can you please create a central repository of community-requested use cases, so that we don't need to repeat them again and again?
> Can you provide an explanation for why the WMF has never devoted resources to approach that kind of tools, many times have been requested by the community, and is using them to develop an entirely separate tool based on entirely different principles?
Wikitext structured pages can't provide enough structure to have for example machine readable contents that would allow better interactions (through notifications) or create a sort of inbox for all messages you receive. We are in a loop, I think.
The Teahouse was a test about newcomers retention, not specifically about discussions. One of the aspects was indeed to ease discussions to increase retention, so a specific hack has been created for it. It appears that editors had more success when using the hack that opens windows to reply than regular wikitext. IIRC, it has motivated Flow's kickstart, to create a structured system that would give a more clear interface and more interactions.
> Are you going to include features in Structured Discussions for lightweight structure? (a.k.a. editing the page structure in markup mode). This is huge news! ;-)
Maybe later. We don't know yet. It is a possible option and all options have to be considered. But for this fiscal year, the plans plans are already defined.
> Seriously, "topic move" and "messages move" is less than what is possible in wikitext semi-structured pages; those features only solve a few use cases, but they fall way short from what lightweight structure is being used for in Wikipedia.
Allow me to disagree: if they solve a few use cases, I think they solve most done actions. The majority of interactions done daily in conversations are, I think, 4 types: create a new conversation, reply to someone (just below - regular reply), create a sub-discussion or move the topic to another place. There is of course extended cases, thousands, but they are proportionally a few.
> Can you please create a central repository of community-requested use cases, so that we don't need to repeat them again and again?
In theory, everything has been transferred as product definition on Phabricator or on category:Flow. But there is a lot of things in it and I haven't finished to explore everything.
What's all this talk about machine readability? Do you want to endorse such projects like the Botpedia in Cebuano, i.e. get rid of those lousy editors, who dare to speak up against your fancy bling dreams?
No, machine readability has to be far far down on the list, and machine interactability should go straight to the bin. The Wikiverse is about people, the knowledge of people, who like to aggregate it. Machines may be useful in certain, restricted cases, but that#s it. If machines can't properly discuss, they should just shut up on talk pages.
And as Everything has been transfered as product definition on Phab or in category Flow: No, I don't care about dead projects, I wouldn't do anything to help Flow, as it's DOA. There is only stuff filtered through the eyes of proselytes, not even remotely everything.
And some things are deliberately delayed to promote Flow, like VE on talk pages, and everything related to VE on talk pages. It must not be done according to the Flow prophets, as it's blasphemy. Surveys are done based on deliberate false pretences, like no VE on talk pages without Flow, which is just an arbitrary decision by the WMF, not an axiom from the technique.
Machine readability allows multiple new features.
It allows building features like having a list of all conversations that happen in a different category.
Machine readability makes it easier to display talk pages on mobile clients as talk pages are currently created with the desktop in mind. Given that mobile internet usage rises, it's good to have a structure that makes it easier for mobile users to interact with Wikipedia.
Currently, the act of achieving a discussion breaks links to the discussion. With flow every discussion has a stable ID that survives achieving a discussion. Having a stable ID for discussions is about machine readability. Stable links allow humans to find discussions.
You don't need per-post machine readability for any of those features. Section-level thread detection, like the one available in the current editor, could be used to build them. Moving and renaming threads would require additional support from templates in wikitext, but it's still doable.
Flow/"Structured Discussions" remove nearly all features from normal talk pages and replace them with the very restricted feature we see here.
Indentation is limited, reorganisation impossible, seeing who answered what in huge discussions limited. It's a tool for short exchange and chitchat. Grüße vom Sänger ♫(Reden) 11:18, 14 September 2017 (UTC)
Wikipedia talk pages use what is called a semi-structured layout, as described at en:WP:THREAD.
Just to be super-clear: this is not true. It is not what "semi-structured" means in computer science. Wikitext talk pages are not self-describing machine-readable documents. If a help page on the English Wikipedia says that they are, it's misleading. User help pages should use human language terms rather than computer science ones anyway. :-) That said, I don't see a link from https://en.wikipedia.org/wiki/Help:Talk pages to https://en.wikipedia.org/wiki/Semi-structured_data – am I missing it?
> It is not what "semi-structured" means in computer science.
In science, at some point what's true or false depends on how you define the terms. I still don't know how you define "structured" in a way that wiki talk pages don't have it, but it's good that you're switching to precise terms rather than the loose language used in the description page.
Wikitext discussions are text that "contain markers to separate semantic elements and enforce hierarchies of records and fields within the data", as defined by our article. The closest scientific classification I know for the kind of structure in wikitext discussions is Lightweight Structured Text, i.e. a way of processing the text incrementally to extract its structure from pre-defined parsing rules and expose it to generic tools.
I've created a lightweight text processing rule to parse the comments in a wikitext discussion, and it is doing a very good job extracting the comments, written according to the norms that editors in the community follow. If some part of the page does not follow the norms, the pattern still infers some structure, which may not correctly align with the boundaries of the unformatted comments; and which is just how a human would try to process the norms.
The parsing rule is quite simple; it took me about ten minutes to write the part that extract the nested comments, mostly for remembering the syntax; and a few more minutes to add support for section headers. The rule is not complete, but it should be possible for a development team writing a dedicated parser to include proper recognition of signatures, add support for edge cases, and to degrade gracefully for the parts that don't follow any structure.
line starts ("==") and ends ("==" or ("==" then Whitespace)) or from (":" or "*") starts line to end of (line contains "UTC)") or from (line not (starts (":" or "*" or "=="))) to end of (line contains "UTC)") or or line starts ("==" or Whitespace then "==")
There goes the argument that it is impossible to extract the structure of talk page discussions with software.
A structured discussion is a discussion with a structure, no more, no less. Your insistence on the very narrow and restricted meaning of this broad defined two words are just misleading.
"Structure" has nothing at all to do with machine readability, and machine readability is nothing that is desired as a prime asset on a discussion page. Discussions take place between human beings, and discussion pages have to be designed to best serve human beings while interacting in a discussion, machines don't have to fit in.
Self-describing machine-readable documents is fine for nerds and as a self-serving nonsense, but has nothing in common with what's needed for wiki talk pages. Grüße vom Sänger ♫(Reden) 20:49, 19 September 2017 (UTC)
Also, I've edited the previous discussion summary. According to en:wiki, semi-structured data is "a form of structured data...", so it is not true that wikitext discussions (as used in Talk:space) are not structured: they're merely not database-schema-structured.
@Diego Moya, I'm following the product manager expertise concerning structured discussions: current wikitext discussions are not structured from a technical perspective. The use of colons and other lists is structuring things for a human, but not for a machine. This is a big difference between a classical wikitext talk page, and XML or JSon semi-structured systems given as examples on the Wikipedia article you cite. This is why the discussion summary was written like this.
> current wikitext discussions are not structured from a technical perspective
That's only true if you limit your technical perspective to relational databases, which is a pretty myopic perspective IMHO. The way wikitext conversations are structured is no different from how Python code is structured, for example; and you wouldn't say that Python code is not structured, would you?
It just happens that, since Talk pages are not compiled, users don't feel the need to produce syntactically correct discussions every time (nor they should to). That wouldn't prevent a software that was written for both humans and computers to parse the parts that are syntactically correct, and flag as "syntactically incorrect" and work around the parts that the machine can't understand; yet still make them available to the humans who know what to do with them. Many systems work that way, for example compilers and IDEs, and web browsers to some degree.
This approach would be incredibly more valuable to the community, and it's sad that you have decided to take the easy route without consulting your user base first, merely because the techniques involved are simpler for the developers.
Multiple threading levels
Why not to allow 3rd, 4th, etc. level for messages, as in LiquidThreads?
If user A creates a post, B replies to A, A replies to B and C replies to A's first post, C's reply could be misinterpreted as a reply to A's second post. This is undesirable.
Ricordisamoa: We want whatever we build to work across all the different kinds of devices that people use to access Wikipedia now and 5-10 years from now: desktop, laptop, tablet, phone (mobile phones currently represent ~20-30% of Wikipedia pageview traffic, and this number is steadily growing). Infinite levels of threading display very badly on smaller screens. We're testing 3 levels currently (reply to topic, reply to user, reply to user's reply) to see if this suffices for more complex back-and-forth discussions.
Maryana (WMF): Can't you increase the width of the comment threads a bit? It's somewhat weird: Articles are much more dense in terms of the information contained yet they extend over the entire width of your screen, but discussion threads (here) only get roughly 60% of the normal width of a Wikipedia page.
Maryana (WMF): While I agree with using an optimal reading width; with further nesting levels you run into the issue of the comment being less than the optimal width. I assume the reason for the first nesting level having a smaller font size was to solve this, however you won't be able to just keep lowering the font-size for additional nesting levels.
The easiest solution would be to allow nested comments to extend out further, however this would look pretty messy. So perhaps the solution is to meet it half way and extend the width to a bit greater than optimal, so nested comments are a bit closer to optimal?
184.108.40.206: I mostly agree with your comment right there. Additionally, longer replies get more compressed in such a narrow width.
Since Maryana said it's at approximately 60% width right now, I'd just take a guess that 70%-80% would still look good, and meet half-way with the two opinions on the width.
We were already discussing this as part of Thread structure of Flow needs improvement.
At least a third level of threading will be available soon. If this will suffice we'll see...
nesting seems broken
Given that the acceptance of Flow/Structured Discussions by the Wikimedia community is already hard, why make it harder by not allowing the administrators of wherever it gets installed to decide on the level of nesting?