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".
About this board
- Please conduct testing at Talk:Sandbox, retaining this page for discussions and suggestions.
- If you find bugs not yet tracked, report in Phabricator if you can, and 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).
Cleaning up the mess left behind from the failed LQT and Flow experiments
Making VisualEditor Default Inside Flow
How do you make visual editor default inside Flow instead if wikieditor.
I have VE set as default on main namespace but I still get wikiteditor as default in flow talk pages.
Just switch to VE, create a new topic or a reply and next time it will be the default editor.
To be more specific:
- I'm virtually certain that the initial default is VE.
- After that, Flow remembers and defaults back to whatever editing mode you used(*) last time.
(*) In order to "use" a mode you need to make some sort of change in that mode, and click save. Typing in wikitext mode, switching to visual, and saving with no new changes, would count as wikitext mode.
@TitusiMW, you mean in a Wikimedia wiki, or in a third-party wiki?
In a Wikimedia wiki, you have to switch to visual editing mode and the wiki remembers this choice. In another configuration, it may be different.
My question was for a private hosted wiki. I understand how to switch between modes. I woould like to make VE default for all users of my wiki. Is there a way to do that?
I wish you luck with that. We have been asking the WMF for a way to make wikitext the default, and the WMF doesn't want to fix the dysfunctional "start in an effectively random mode" design.
Set order in wgFlowEditorList
@Wargo I dont think that really works. I already have
$wgFlowEditorList = array( 'visualeditor', 'none' );
But this only makes VE available. WikiEditor is still the default editor until each user specifically switches to VE.
Page is incredibly convoluted
This page mixes the concept of "FLOW" the tool, and FLOW's implementation in WMF foundation wikis, and that's why its attracting inaccurate edits.
It is an anti-pattern of many pages in mediawiki.org, and leads to considerable confusion about what the software can do, and what WMF developers allow it to do in their sites.
"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.
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.
Date of the message
If any bot will correct templates in old messages - date of the message will change too? Can Flow-bots not change date of the message?
Based on my own message "JSON data structure" below it doesn't. I posted first and then corrected a small typo (lof to lot) and it didn't change the original time stamp - rather, a new revision has been added to the history. Try https://www.mediawiki.org/w/api.php?action=flow&submodule=view-topic&page=Topic:Semm2wei2gey0m4o and view at http://jsonviewer.stack.hu/
Surely developpers may know better.
Maybe it also depend on your message
A flow is started by a trigger (usually either New Message or Catch-all), and starts a series of actions, such as Send a Message in response.
Regarding [https://www.mediawiki.org/w/index.php?title=Structured_Discussions&type=revision&diff=2567214&oldid=2566922 this edit]
@Jdforrester (WMF): I think your edit is wrong in nearly all it's aspects.
- Of course a talk page has textual content, nothing else. It's a wiki page like every other wiki page as well. They are just not only encyclopedic content pages, but pages for discussions and article improvements.
- Talk pages have a structure, everybody can see that they are structured: They have headlines and sub-headlines, they have indentation and signatures, they have a clear structure for everyone to see; everyone but machines that is. If you reduce the universal word structure to the very small aspect of fully machine readability, say so clearly in making this restriction of the word known.
- VE on talk pages is of course possible, in the thread you tried a hostile close on on the VE-Flowpage it was shown (by Diego Moya in his enWP sandbox nearly exactly a year ago) that editing with VE on talk pages is indeed possible. Why do you continue with the lie that it is fundamentally impossible?
As Flow cannot work with normal linking in the headlines, here's the proper link: this edit
I agree with the above, and let me also add that I see a number of things wrong with this sentence that was added: "Though they may appear in parts to be "semi-structured" to expert users through the cunning abuse of bullet lists and/or definition lists, this is unintelligible to software."
- I don't know what "expert users" means here - if there's a page with progressive indentation of different people's comments, I would think a 6-year-old could see the structure there and understand its meaning.
- I don't understand "cunning abuse" either. Was ":" originally meant just for glossary definitions? Even if it was, it clearly was quickly adopted as general-purpose indentation syntax. I see nothing hacky about its use for that in talk pages.
- I would love to know what the purpose would be of some theoretical software that could analyze talk page discussions. Let's say we can tell for sure that some user's comment was a direct response to another user's comment. So what? What could possibly be done with that information?
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
Interwiki links display like external links
Interwiki links display like external links in Flow. This is not a conscious design feature but is not considered a major blocker either, because interwiki links are an intermediate category between internal links and external links. phab:T97552 tracks this design issue.
See e.g. this thread. Is it intentional that Flow displays interwiki links like external links?
As the nice IP has summarized the topic, it is tracked as T97552. It is not intentional, and while it is not a major blocker (basically because it is an external link to another wiki), it hasn't been fixed.
Flow has been abandoned after it became clear it was a failure. Sorry.
News circulated at Wikimania 2017 that Flow is back in active development...!
The option "source editing" should propose the same taskbar / menu bar (specially with the edittools) than our current "edit source" in wikitext.
Thank you for your feedback. I've reported it.
Yes indeed, my concern is the lacks of Edittools, rather than the blue toolbar. Sorry if I was not clear.
What is necessary for a project, to get completely rid of Flow?
I just got aware, that the software for Flow is installed even on projects, that don't want it at all. What is necessary for a project, to completely uninstall anything of the extension from the project software?
P.S.: Possible options:
Structured discussions ("Flow") will not be activated on wikis that didn't previously use it. No structured discussion board will be created on German Wikipedia unless if the community requests it.
Uninstalling the Flow software from a wiki is a moderately complicated option that would require precious developer time. We are not going to spend this time groundlessly to remove Flow from wikis. We will continue to work on the extension to improve it for those that use it. We will focus on communities that expect to see changes on the structured discussion systems they use.
We are not going to spend this time groundlessly to remove Flow from wikis.
Flow was uninstalled from EnWiki based on what was essentially an amicable agreement between myself, Quiddity, and whomever Quiddity reported to. We agreed that an RFC would clearly result in consensus to uninstall. We agreed that it was in the best interest of good-relations between the community and WMF to reach an amicable resolution, forgoing the planned RFC on the subject.
Flow was uninstalled from MetaWiki based on an overwhelming RFC consensus.
@Jdforrester (WMF), my question is whether:
- A DeWiki Umfrage (a low formalities RFC) is sufficient grounds to remove Flow; or
- a DeWiki Meinungsbild (an extremely formalized RFC) is sufficient grounds to remove Flow; or
- are you reversing the WMF's position and asserting that community consensus no longer constitutes grounds for uninstalling Flow?
There are tons of structured discussions on deWP, just not with this extreme inflexible Flow junk, but normal structured ones. Stop with this straw-man about structured discussions, this Flow is just some weak forum impersonation, not even remotely something like a "structured discussion".
Start implementing VE on talk pages, don't go on deliberately omit it there to give Flow some rigged advantage. And let the devs do something useful instead of wasting time for Flow, let them develop indentation and auto-signing for VE, to improve the existing structured discussion pages in all wikis. Grüße vom Sänger ♫(Reden) 21:37, 6 September 2017 (UTC)
@Sänger, I've asked you before to improve your tone. I suggest you revise your post to "Please stop with this straw-man about...".
I believe you will find it much more effective and rewarding to maintain a professional tone, and when necessary, organize a community consensus.
We are powerless when we come here as ranting individuals. We are powerful when we come here as servants of community consensus.
But the insistence on the creation of a rift between a structured discussion and normal talk pages, that usually are structured discussions, is nothing but a en:Straw man.
Flow creates a deep rift between completely inflexible pages called Flow pages, designed for just the one proclaimed goal to make chit-chat easier, with disregard for every other use-case and the look-and-feel of the rest of the wikiverse with its everywhere nearly the same page behaviour.
Implementing VE on talk pages on the other hand would make the structuring of discussions on talk pages probably easier, would keep the coherent look-and-feel across the wikiverse, and keep the talk pages as flexible as they are needed. Grüße vom Sänger ♫(Reden) 13:33, 7 September 2017 (UTC)
Your "But..." doesn't matter. "Shut up" is considered an abusive tone. You should remove those words. You should also maintain a more professional tone in the future.
I believe you know that you&I are generally in agreement about the technical issues. I believe you know you that I found Superprotect to be offensive, abusive, and unacceptable. If that is not sufficiently clear, I will make it clear: The WMF can do almost anything because they hold the power switch. However the one thing they can never do is shut off all editing. It would be a severe error if the WMF were to repeat a Superprotect type Nuclear war. The community holds the bigger nuclear weapons, and the community may decide not to withhold nuclear retaliation next time. A nuclear conflict could escalate to the point that the community posts banners on all articles: "Please stop donating, the Foundation is wasting and misusing your money." That banner would include a graph showing the shocking and exponential growth in Foundation donations. That would be headline news across the globe. That would be bad. Everyone loses a nuclear war. However the WMF would lose the nuclear war AND lose the issue they were fighting over.
Personal attacks are also considered unacceptable. Any staff member would be fired if they talked to us with the language and tone that you use against WMF staff. If you continue to use that kind of language and tone, you may be blocked from editing mediawiki. Your efforts clearly are not working. Your tone only undermines the efforts of myself and other community members, when WMF staff members view the community as unreasonable and abusive.
It is reasonable to disagree with the WMF. It is appropriate to criticize actions. But maintain a professional tone and avoid personal attacks. They do not work. They are counter productive. They are unacceptable. They will get you blocked.
This wiki is covered by the Code of Conduct, as you have been warned before. Your comment is not in keeping with its requirements for respectful, civil discourse. Please edit your reply to comply with the community standards of this wiki. If you continue to speak in this fashion, I will report this issue to committee
Is there anything in the code of conduct about employees of the communities, who impersonate decision makers, for what they< are only entitled with full vetting by the highest entities, that is the community?
What could be done with people, who act against the communities by withholding technical solutions for personal and/or institutional vain from the communities, like it's done with the VE on talk pages? And who refuse to give meaningful answers in discussions, that don't aghrere with their POV? Grüße vom Sänger ♫(Reden) 04:25, 7 September 2017 (UTC)
I believe any discussion showing a reasonable consensus will be acceptable. The WMF has been activating Flow on some wikis based on informal discussions with just two or three 'support' comments.
(Really, you should remove Flow from MediaWiki as it complicates the consumer-developer communication… Did noone ever think about this?)
I don't really understand why you say uninstalling Flow on dewiki isn't an option if enwiki and meta did it before. Can you please explain that to me?
@Sänger: I don't know if you're aware of this, but the wikimedia tech community has a consentual opinion that insulting each other instead of an reasonable conversation isn't helpful at all and will be banned quite fast. Sadly, dewiki built a tolerance towards such behavior, but that doesn't mean you can behave like this elsewhere and don't get negative feedback.
I deleted the insulting part, at least I think so. What's still insulting?
I think it is insulting to proclaim VE is not for talk pages, while this is just not the case.
It is insulting to talk about this software as "structured discussions", while nearly all talk pages contain structured discussions, some even more and better structured than Flow is able to deliver.
It is insulting to make a survey based on completely bogus assumptions like the on that was carried out about Flow.
It was insulting to force the MV on deWP with pure might and never even apologize for this rude, insulting and destructive behaviour.
It's insulting not to talk to the point, but circumvent the problems.
I meant this as a general advice, because it wouldn't be the first time I see a German Wikipedian banned because of his tone on Phabricator or here, it wasn't that specific.
I have too admit that Sänger is right. That VisualEditor can't handle talk pages isn't that inherent in its concept, but by design: I think it would be entirely possible to check, if I'm on a talk page (ns overridable by magic word) and change ve a bit to make talk page feature more prominent there. (Your signature and indent-related things)
I haven't been getting involved in the VE-on-talkpages issue because I don't use VE much, because I've been trying to deal with bigger issues, and because it's so hard to get the WMF to adjust course. However I fundamentally agree with Sanger and MGChecker.
Deliberately crippling VE is a symptom of a general ideological and strategy error. I sometimes find VE valuable, and it is absurd-bordering-on-malicious that the WMF prohibits me from using VE to edit content. The WMF's error is imagining that content is supposed to be on one page, and discussions on another. A page is a page. Editing content on talk pages is a core workflow, which shows up within almost any other workflow at any time. We also often have discussions on non-talk pages. Any given page should be presumed to contain simultaneous content&discussion. The WMF's efforts to rip the wiki in two are a major source of conflict between the WMF&community.
Questions from a neutral view:
- Why do we want to uninstall Flow? Unless the first board get's created (Trizek said, it won't unless consensus is reached) there is no effect here. But:
- Why was it installed then? I mean the only effect was that the flow user was created, and it created two templates, but for which reason did you setup an extension then which is not that easy to remove again?
Additionally: I read through phab:T63729. The only work there was, because there were already flow boards. At dewiki there was no board created yet, so uninstalling it would not cause any additional workload, than just change two dblists and SWAT it. Non flow-developers can do that as well.
My main problem is lack of trust towards the devs and deciders at WMF. They simply don't seem to get it,that the communities, not them, have the last word in the Wikiverse.
The last times they developed some bigger software stuff, they nearly always failed massively:
- VE first installation against the advice of the community: an epic disaster. Only after they started to listen, it became useful.
- MV, a pet project without real use, massive problems with legal necessities, but pushed massively by some individuals for personal vain, was forced on the communities with brutal abuse of power, and up to now they have not even apologized for this extreme bad and hostile behaviour.
- SuperProtect, something that should have been ditched within the hour and the hostile, anti-community-scheming bad devs should have been kicked out asap, lasted for over a year before it got finally half-heartedly deleted.
- Now the next pet project without real use cases is pushed massively, again with complete disregard for the input from the communities, even deliberately biased "surveys" to make it look better and the deliberate and unreasoned block of the VE from talk pages, just to make Flow look better.
SuperProtect... anti-community-scheming bad devs
Lighten up on the devs. Paid devs had to do what their boss said. That boss was Eloquence. Eloquence lost his job here. Eloquence was acting with the support of Executive Director Lila. Lila was fired. Lila was acting with the endorsement of the Board of Trustees. The community fired three of those board members, and I think all board members other than Jimbo have been replaced. Almost everyone responsible for Superprotect is gone.
- Why was Flow installed: I'm not WMF, but I'll offer my view. Flow was installed on every wiki because the long term plan was to kill wikitext talk pages and switch all wikis to Flow.
Wikipedia started with several years of exponential growth. Exponential growth always hits a wall. After the peak the editor base declined for a while, then appears to have roughly stabilized. However a bit of panic set in at the WMF during the decline. There was fear that the decline would continue into a crash. Based on some really lousy research they concluded that wikitext was the problem. A theory emerged that vast numbers of "regular" people would think
skydiving was a fun hobbywriting-an-encyclopedia was a fun hobby, if only they didn't have to deal with wikitext. The WMF initiated a strategy. I quote: "deprecate wiki syntax as the primary input method". The vision was that VisualEditing would be the core platform for editing, and that wikitext talk pages would be replaced with more conventional forum-style software. The lead designer for Flow said he "would dearly love to kill off Wikitext". He told us to seek "Zen acceptance" that Flow would not have proper wikitext support, and that it was the WMF's decision to deploy Flow whether we wanted it or not.
To save the WMF the trouble of repeating themselves: After the anti-Flow shitstorm as well as the Superprotect conflict, the WMF has been giving repeated assurances that they currently have no plans to activate Flow pages without local community consensus. However Flow's proponents still clearly expect Flow will eventually be fully deployed. They have Faith that we will want Flow, if they just keep spending enough money working on it.
- Why do we want to uninstall Flow: An immediately practical reason is that uninstalling the unused extension improves the security and stability of the wiki. Flow is an exceptionally large, complex, and intrusive extension hooking into many parts of the wiki software. Furthermore the WMF has laid out massive development ideas for Flow, development that would have major entanglements with all parts of the wiki. There have been severe security bugs in the past, and the new work would will inevitably create new security and stability bugs. There is no reason that wikis which aren't using Flow should be subject to those bugs.
However probably the main driving reason for uninstallation is that the overwhelming majority of editors hate Flow and want it gone. Really truly gone. (87% in the Meta RFC.) Most people don't want an "upgraded" version activated in the future, and many have said they don't want the WMF wasting money continuing to develop it. There is a common view that Flow is a dead end, like LiquidTreads. There is a common view that the WMF is going to keep pushing the Flow agenda, even if the WMF isn't currently forcing Flow pages. If the major wikis progressively have Flow uninstalled, the WMF will soon be forced to face reality.
I agree with Alsee, completely seconded.
If you are aware of security issues, please report them.
Flow's developments are not for everyone but only for wikis that have it and use it. Force the communities which don't use Flow now to use it is a waste of time, like uninstalling it. We will not do either.
Flow development is a waste of time, just uninstall it ;)
That's your personal opinion. Not the opinion of communities which use it daily and want improvements to be done. ;)
I do not recall anyone requesting that Flow be uninstalled from communities that want it. Although I do question the WMF spending resources on continued development, given the apparent low interest and long term viability of the project.