Archives |
---|
Threads older than 15 days may be archived by Lowercase sigmabot III. |
Contents
Conversion back from Flow, or another set of false WMF promises
Wikipedia talk:WikiProject Breakfast is shutting down their Flow experiment (against the wishes of some members, for ideological reasons) after an RfC. Problem is that no one at WMF knows how a Flow page should be shut down.
The simple solution would be to move it to an archive (in Flow mode) and fully protect it. Disadvantage is that this works for one or two pages, but wouldn't work if Flow should be totally disabled and the Topic namespace removed. Other disadvantage is that no one seems to know whether a Flow page can be moved anyway. It certainly can't be done here, you get "The "Create Flow boards in any location" permission is required to move a Flow board." even if you want to move it to another Flow-enabled place (I know, I tested). Strangely, when you try to move a Flow board, you also don't get the "Leave a redirect behind" box, it is grayed out. While leaving a redirect wouldn't be wanted in this case, in general it is something that should be standard when moving many talk pages.
The apparently harder solution is to convert the page back to a standard wikiproject talk page, with history and all preferably. This is easy, according to all WMF statements, until it is actually needed, and then it is very hard, like here, and needs to be developed. In Wikipedia talk:Flow/Archive 11#Can Wikipedia talk:WikiProject Breakfast be easily switched back? (from September 2014), the question was asked, and Erik Moeller and Quiddity indicated that it was "certainly doable" and that "The script to convert content back was updated at the end of June, and was locally tested by the dev". An actual test the next week was catastrophic (section "Deletion of Wikipedia:Teahouse/Questions/Flow test" a bit lower), but the Flow manager at the time (and other WMF people) didn't respond to any questions about it, even when pinged.
As can be seen from e.g. this phabricator page, apparently the claims from the WMF from September 2014 were, as could be expected, false (let's call them "severely exaggerated"), which was noted a few days later by the non-WMF people but only realised at the WMF now apparently.
So, at the moment, two years after the first Flow deployments and more than a year after we were assured that moving back to wikitext wasn't a problem, it can't be done in a somewhat correct way at all. What a surprise...
On 23 November 2013, Okeyes(WMF) changed the Wikipedia:Flow/FAQ[1] to include the following (in the "Can I opt-out?" section):
If you convert to using Flow during the trial period (in a WikiProject discussion space), we'll be able to convert the content back into a normal talkpage if needed.
This was before the trials here in Wikiproject discussion space started. The above text can still be found on the FAQ (which I tagged as "historical" this week because it is totally outdated in many aspects). So before the WMF asked us to start a temporary trial on some Wikiprojects, they explicitly and clearly promised that conversion was possible. By September 2014, they still said it was doable and they had a tested script which only needed a little tweak to update it. But now that we actually want it, it's panic in the streets of San Francisco apparently.
And people wonder why we don't trust the WMF... Fram (talk) 10:56, 14 January 2016 (UTC)
- I'm ok with giving them some time to update the conversion software and sort out the first use of it. On Phabricator T90075 matthiasmullie claimed this task and moved this task to In Development on the Collaboration-Team-Current workboard. It looks like work is active on this. Assuming this is resolved in a reasonable time frame I'd give the WMF credit rather than complaints here. Alsee (talk) 22:53, 14 January 2016 (UTC)
- The individuals now working on it, fine. The WMF? No way. They made the promises, they lied. They claimed it worked, they claimed it was tested, and the first time it was needed here (September 2014), it failed badly. No communication followed about this, no improvements were made, the claim that this was no problem remained in the FAQ, and now that it is needed, they'll start to work on it to see if it is even possible? Screw them. If these things, which were said to be possible, written and tested more than two years ago, turn out to be completely incorrect, then it is another argument to shut down Flow completely (together with the 997 other arguments already on Phabricator). But of course, we can't. Fram (talk) 07:51, 15 January 2016 (UTC)
Apparently the current situation is that they can convert the final "text" of the page to a wikitext page, but are unable to recreate the history (not surprising, considering how poor the history is on Flow pages). Their "solution" is to create a text archive without history, and keep the Flow page (and all the topics) as well for the history. So at the moment it is not possible to remove Flow from your wiki if you don't want it anymore after the trial. Well thought out, obviously, this implementation. Fram (talk) 08:08, 15 January 2016 (UTC)
- Quick work! They already completed a test-conversion of Project Breakfast. (Copy it from here and paste into a wiki page for preview.) As expected, the rely structure is often hard to follow, but aside from that it turned out significantly better than I expected. There are mixed discussions across different Phab pages on whether they will replicate the history or just snapshot the final page. I asked on Phab for clarification on that point. For Project Breakfast losing the history would be.... sub-par but tolerable. If for some reason this were to get broader use then history would be a necessity. Alsee (talk) 13:50, 15 January 2016 (UTC)
The page has now been converted back. Sorry again, for the long delay. Hopefully we can discuss any issues here, and let that WikiProject get back to focusing on content collaborations. Quiddity (WMF) (talk) 01:36, 18 February 2016 (UTC)
MfD nomination of Wikipedia:Gather/User Feedback
Wikipedia:Gather/User Feedback, a page which you created or substantially contributed to, has been nominated for deletion. Your opinions on the matter are welcome; you may participate in the discussion by adding your comments at Wikipedia:Miscellany for deletion/Wikipedia:Gather/User Feedback and please be sure to sign your comments with four tildes (~~~~). You are free to edit the content of Wikipedia:Gather/User Feedback during the discussion but should not remove the miscellany for deletion template from the top of the page; such a removal will not end the deletion discussion. Thank you. Fram (talk) 15:36, 20 January 2016 (UTC)
Should we draft an RFC now?
Most Flow pages have been deleted. Project Breakfast has consensus to end the Flow trial and convert back to a talk page. The Gather page is currently at deletion discussion with unanimous delete votes. Assuming I haven't missed anything, that only leaves the Flow Test board and Wikiproject Hampshire. Wikiproject Hampshire has a grand total of one project-related post in the last five months, plus a few incidental updates posted about Wikiproject X.
Do we want to start a Village Pump RFC about Flow? And if so, does anyone want to collaborate on drafting it? I was thinking of making a subpage here for drafting discussions. I was considering a series of questions: Do we want to enable the WMF's new system that lets people opt-in to Flow for their user talk? Should any new Flow deployments be required to go through Village Pump discussion? Should we end the Hampshire Flow trial (convert back to talk)? Should we remove Flow from both Hampshire&Test_page, and remove the Flow Extension completely? Alsee (talk) 02:19, 21 January 2016 (UTC)
- My opinion is that current Flow instances should be converted back to wikitext, Flow should be removed, and new Flow pages should require a full RfC. In November I drafted an RfC to this effect here. If you think it would be useful as a first draft and you wish to collaborate on it, let me know. BethNaught (talk) 08:01, 21 January 2016 (UTC)
- I say keep the test page and nothing else. The test page has a valid purpose here, but should have a note that Flow shouldn't be used anywhere else. User:BethNaught, your draft RFC is good, but change Support/Oppose to Disable Flow/Keep Flow or similar. Oiyarbepsy (talk) 23:07, 21 January 2016 (UTC)
-
- The test page could be a redirect to the WMF Flow testing page. I don't think we should have the infrastructure of an entire major extension installed just to support one page - especially a test page with a rather circular purpose. Alsee (talk) 03:09, 22 January 2016 (UTC)
- @Alsee: How much of an impact is there from having Flow enabled but not used? That could be included in the rationale. If it's important, I think the option of redirecting the test page should be mentioned in the proposal, so that it's clear there will still be a place for testing it. Also, is disabling it technically easy to reverse if the community changes its mind in the future? Sunrise (talk) 23:22, 23 January 2016 (UTC)
- Sunrise, if we weigh the pros and cons, it doesn't take much on the con-side to outweigh no real benefit to having an unused Flow extension installed. If the only purpose is to host a testing page, a redirect to the WMF's test page covers that rather well. On the con side, I can say as a programmer that having a large chunk of unneeded code is a bad idea in general. Things should be as complex as necessary, and never more complex than necessary. Having a large chunk of beta-quality code is even worse. There are a thousand open Flow bugs and tasks listed at Phabricator. It would take days just to skim them for known issues, not to mention some huge number of unlisted issues. Then there's the fact that people at the WMF have fallen into the temptation of creating Flow pages simply because someone on some project thought it was a dandy idea, even after the WMF declared that Flow pages would not be created without consensus requesting it. But my primary concern relates to new project development. If Flow isn't even installed, then it is crystal clear up front that they need to talk to the community before expecting to create and deploy new projects that are dependent upon Flow. For example the WMF plans a Workflow project. I have been following it closely and discussing it with various staff. It could be a valuable and popular new toolset for us, IF the WMF builds it to support existing pages. Their current plan for Workflow is that it would only work on Flow pages. We would, quote, "not be served" by the project if we don't switch everything to Flow. As long as Flow is installed they have this background-presumption that we merely haven't completed the switch yet, and that new projects can/should simply be built as Flow-only. Alsee (talk) 06:21, 24 January 2016 (UTC)
- Thanks Alsee. I should have been more specific - as a non-programmer, I'm not really able to evaluate the first part of your reply. Are there potential consequences to regular editors, e.g. degrading performance in other parts of WP? If Flow is buggy but isn't used anywhere, could that still cause problems? Would leaving the code in make it harder for programmers to maintain other things? I asked since the responses here so far sound like the community might conclude that the test page causes no harm (which was my own first intuition as well). Sunrise (talk) 08:07, 24 January 2016 (UTC)
- Sunrise any performance impact should be negligible, but I can't say for certain from this end. Removing Flow definitely simplifies maintenance. That frees up dev time to handle other bugs or community requests. I don't know what's in the list of one thousand Flow bugs and tasks, but removing Flow would instantly fix any known negative impact. All complex code contains hidden bugs, possibly serious bugs that pop up unexpectedly, so it avoids that risk of disruption. Removing any extension also reduces what is known as "attack surface" - that means it reduces the chance that someone can find a security hole. That's less chance that someone could hijack admin powers, get root system access, steal passwords, or deliberately crash the site. Removing Flow also allows us to drop the entire Topic: namespace, and whatever else was added to support Flow. I'm not making a firm argument that any of those things are major or high risk, those are routine facts that come along with any useful new addition. However those are all dead-weight costs if we're not actually going to be using Flow. And as I mentioned, my main motivation is that removing the extension removes an unwanted-creep-forwards with Flow. If the WMF has awesome ideas about advancing with Flow then it's clear they need to talk to us, to see if we agree those ideas actually are awesome. If Flow is uninstalled then I expect the WMF will realize that the Workflow project really does need to include support for our existing pages. If we don't consider Flow to be a viable option then building a Flow-only Workflow is a steaming pile of useless. An expensive steaming pile of useless. Alsee (talk) 18:01, 24 January 2016 (UTC)
- Thanks Alsee. I should have been more specific - as a non-programmer, I'm not really able to evaluate the first part of your reply. Are there potential consequences to regular editors, e.g. degrading performance in other parts of WP? If Flow is buggy but isn't used anywhere, could that still cause problems? Would leaving the code in make it harder for programmers to maintain other things? I asked since the responses here so far sound like the community might conclude that the test page causes no harm (which was my own first intuition as well). Sunrise (talk) 08:07, 24 January 2016 (UTC)
- Sunrise, if we weigh the pros and cons, it doesn't take much on the con-side to outweigh no real benefit to having an unused Flow extension installed. If the only purpose is to host a testing page, a redirect to the WMF's test page covers that rather well. On the con side, I can say as a programmer that having a large chunk of unneeded code is a bad idea in general. Things should be as complex as necessary, and never more complex than necessary. Having a large chunk of beta-quality code is even worse. There are a thousand open Flow bugs and tasks listed at Phabricator. It would take days just to skim them for known issues, not to mention some huge number of unlisted issues. Then there's the fact that people at the WMF have fallen into the temptation of creating Flow pages simply because someone on some project thought it was a dandy idea, even after the WMF declared that Flow pages would not be created without consensus requesting it. But my primary concern relates to new project development. If Flow isn't even installed, then it is crystal clear up front that they need to talk to the community before expecting to create and deploy new projects that are dependent upon Flow. For example the WMF plans a Workflow project. I have been following it closely and discussing it with various staff. It could be a valuable and popular new toolset for us, IF the WMF builds it to support existing pages. Their current plan for Workflow is that it would only work on Flow pages. We would, quote, "not be served" by the project if we don't switch everything to Flow. As long as Flow is installed they have this background-presumption that we merely haven't completed the switch yet, and that new projects can/should simply be built as Flow-only. Alsee (talk) 06:21, 24 January 2016 (UTC)
- @Alsee: How much of an impact is there from having Flow enabled but not used? That could be included in the rationale. If it's important, I think the option of redirecting the test page should be mentioned in the proposal, so that it's clear there will still be a place for testing it. Also, is disabling it technically easy to reverse if the community changes its mind in the future? Sunrise (talk) 23:22, 23 January 2016 (UTC)
- The test page could be a redirect to the WMF Flow testing page. I don't think we should have the infrastructure of an entire major extension installed just to support one page - especially a test page with a rather circular purpose. Alsee (talk) 03:09, 22 January 2016 (UTC)
-
- Seconded: keep the test page as an archive, for testing, for the curious. But remove it from any other page, i.e. WP Hampshire, and do not add it to any other. In particular if users could add it to their own user pages it would just confuse people, and in its half-finished state then a lot of things would stop working and as it is currently inactive they are unlikely to be fixed.--JohnBlackburnewordsdeeds 03:14, 22 January 2016 (UTC)
- Test page can probably be kept. As for that RfC, if memory serves that Signpost announcement was not completely accurate with regards to the status of Flow; there was a follow up statement from the WMF here on this page I think. Also, may be worth mentioning meta:Community Tech/Global cross-wiki talk page here - even if it isn't implemented though Flow, enwiki may lose the control over its user talk pages from this change.Jo-Jo Eumerus (talk, contributions) 09:54, 22 January 2016 (UTC)
- Seconded: keep the test page as an archive, for testing, for the curious. But remove it from any other page, i.e. WP Hampshire, and do not add it to any other. In particular if users could add it to their own user pages it would just confuse people, and in its half-finished state then a lot of things would stop working and as it is currently inactive they are unlikely to be fixed.--JohnBlackburnewordsdeeds 03:14, 22 January 2016 (UTC)
- I made some modifications to BethNaught's Draft Flow RfC. Inviting Naught and anyone else to review and contribute. Alsee (talk) 04:34, 23 January 2016 (UTC)
-
- Strongly agree. If Flow beta function still unable in English Wikipedia, I would like to call WMF to change the policy. My suggestion is, the Flow beta can skipped community consensus and allow for users to enable in some days (in major language versions). If the feedback's result is OK, the Flow beta function can still exist.--Shwangtianyuan (talk) 01:04, 3 February 2016 (UTC)
Is this alive or not?
I've been asking around to get info about editors needs and Wikipedia's toolset and intentions to end with the mess that Talk pages and discussions in general are. In my opinion, the current state is unacceptable. I've been reading this talk page and still is not clear to me what's the real situation of this project. I see that some significant design choices have been made (I don't know by whom) and that now it's just a bent tree. I'm a dev that wants (or wanted, I don't know after reading too many nonsensical decisions) to create an standalone open source webapp for editors to have a tool that's useful to discuss, argue, edit and basically not scare off new users or make your eyes bleed when you're trying to make sense of some consensus or arguments. Are there any devs interested in that? Because this -> http://i.imgur.com/BdNxXvS.png is unacceptable. Nmaxcom (talk) 04:33, 11 February 2016 (UTC)
- The reason stuff is hard to follow is that it's complex and messy with lots of opinions and few facts. The problem is the complexity of the topic, not the complexity of the method used to discuss the topic. Forums (at other websites) generally are talking because they like talking—they are not working on solving an actual problem. A mailing list discussion is generally working out who is going to do what, or is polling opinions on someone's suggestion. Such discussions seldom involve a large group of people arguing about each word.
- There have been some suggestions for how the current system could be improved rather than erased. For example, software could make a best-effort guess at how to indent and sign a reply, with a user-preference that disables such assistance. One issue is that if a contributor cannot learn how to handle a few colons and tildes, they are unlikely to be able to do more than fix an occasional typo in an article—why should there be one procedure for editing an article and a different procedure for editing a talk page? By the way, the convention is to click "new section" at the top of the page when wanting to create a new topic. That puts it at the bottom and handles edit conflicts. Johnuniq (talk) 04:58, 11 February 2016 (UTC)
- Hi @Nmaxcom: I feel your pain and share it, but I don't think Flow is the solution. See the Teahouse. Notice the "Join this discussion" at the top of each thread? The tools to solve the most egregious part of the problem do exist, it's all about using them or not.
- I wonder if it's time to propose at the Village Pump that we add that widget by default in all talk pages as a vaccine against Flow at en.wiki, to deactivate the primary reason why it is being pushed around. Maybe it should be part of that that Flow RFC that some guys here are talking about. Diego (talk) 10:36, 11 February 2016 (UTC)
-
- I think working on the syntax highlighter or a related feature would also be helpful. @Nmaxcom: you might find it useful, since your image link shows you haven't enabled it (Preferences -> Editing -> Syntax highlighter on enWP). It has a bigger impact for articles, but it makes talk pages at least a bit easier to read as well. I'm also sure it could be improved - there are several useful features like that which I think deserve more support. Sunrise (talk) 04:01, 16 February 2016 (UTC)
-
-
- Hi @Diego Moya:, @Johnuniq: and @Sunrise:. Thanks for joining in the conversation.
- I'm sorry, but I think we're missing the important point. It's not about patching this or that or enabling a preference or two... The current editing system gets in the way of good human interaction, reasoning and fruitful debates. Please try to look beyond the efforts you've already made to get used to this clumsy and complex set of tools. It's pure madness.
- We're missing out on good people, smart contributors that would enrich the content and make this place even better. I understand the logic behind the "well, if they can't know, learn, understand and strictly follow dozens of rules, use different tools and have a horrible experience fighting the heinous UX... they aren't that good", but it's wrong. It's not true. I agree some filtering is good, but this improvised filter of torture is not a solution.
- Do you know the kind of people I think Wikipedia is losing for no good reason? At least two types come to mind that will drop out or never get in:
- * People with great knowledge in a particular field or theme but not very motivated with computers or coding-like writing
- * Busy people! With time enough to enrich a particular discussion but not enough to get a damn PhD so then he/she can suffer through intricate syntax and rules and not enjoy the process at all.
- Not only the English Wikipedia will be way poorer than it could be, but other languages that don't have as much traffic have even worse articles and are prone to less surveillance and biases. Not to mention, all the other Wikimedia projects. It's all governed by this horrible, outdated system.
- I mean no disrespect to the work that has been put here. I mean that. If someone finds my criticism too harsh, please forgive me. But it's time to check the calendar, it's 2016. Why does this have to look and work like it's 1992? When is this going to be addressed? Nmaxcom (talk) 07:23, 20 February 2016 (UTC)
- @Nmaxcom: We understand the problem, we're not missing it. I have written many times about it and I agree that it's a problem, and that's why I've become a regular to this project talk page for more than a year.
- Believe me when I say, Flow is not the solution to that problem. For a start, it does not look like any other forum system, and it doesn't look like any of the other pages on this site (you'll agree that is a problem for lack of consistency, right?). Moreover, in practice it has proven itself lacking in its ability to support basic workflows which are typical in Wikipedia, such as keeping track of a series of proposals to edit the article (which is the core function of Wikipedia discussion pages), reading new posts in a thread where you have already participated, or voting in a straw poll to decide which alternative course of action should be taken. All these scenarios are badly accomplished with the Flow interface, and it alienates the experienced users that understand the fine details of editing the encyclopedia.
- An interface that makes it easy for beginners to participate should still keep all the powerful features of the wiki system on which Wikipedia is built on. Wikis are by its nature one of the simplest ways to collaborate on building content, so the mediawiki platform is really close to allowing an easy interface on top of it; see for example the Wikipedia:Teahouse/Questions page, where newcomers can participate without learning mediawiki syntax. I've made this draft for a request for comments to activate that gadget in all talk pages, as a way to improve the interface for beginners and smooth the learning curve. I'm convinced that other improvements could be made without migrating to an entirely different software platform (that would miss almost all of the current functionality), in special now that the Visual Editor is mature. Diego (talk) 20:05, 21 February 2016 (UTC)
-
I've made it, I've drafted a RfC proposal to activate the Teahouse gadget at talk pages, complementary to User:BethNaught/Draft_Flow_RfC proposal to deactivate Flow; I'll post it if Beth's RfC is published. Suggestions are welcome. Diego (talk) 13:32, 24 February 2016 (UTC)
-
-
-
-
- @Diego Moya: We definately agree on the problem but not on the solutions proposed. I see your good intended efforts as yet another half measure. Yet another patch over the patch over that other patch. Even your patch were to be implemented, it'll be just another drop in the ocean. Damn, even the Flow monster was just a bad patch, as I think you agree.
-
-
-
-
-
-
-
- The lack of vision and action by the appropriate agents is honestly disappointing. Not to mention the amount of f***s that are given by discussions like this one. RIP Wikipedia Innovation. Nmaxcom (talk) 02:39, 2 March 2016 (UTC)
- Yes, I definitely see nothing wrong with patching systems that work to make them work better, so I guess we disagree there; the advantage of software that evolves organically is that it is perfectly suited to the needs of those who use it, even for obscure cases that the designers could have never thought of.
- Yes, such system will be much more difficult to maintain, and it will expose some rough edges and quirks. Yet throwing everything away and creating a new tool from scratch is prone to suffering the second system effect. It can be done, but it's better approached with care, as a sidetrack project which may or may not get traction; and which should replace the original only when most people agree is a genuine improvement over the original.
- I wouldn't oppose such effort, and I have indeed participated in this very talk page with considerations of what Flow would require to be such a system; although the designers never explained the technical aspects enough to assess if my ideas were viable.
- The benefit of the stopgap solution I propose in the RfC is that we could have it in no time, as the hard work has already been done, and it has shown in practice that it works. Fixing paper cut bugs does improve the overall usability of a system, and an imperfect solution tomorrow is better than a perfect solution 10 years down the line. Diego (talk) 11:28, 2 March 2016 (UTC)
- The lack of vision and action by the appropriate agents is honestly disappointing. Not to mention the amount of f***s that are given by discussions like this one. RIP Wikipedia Innovation. Nmaxcom (talk) 02:39, 2 March 2016 (UTC)
-
-
-
MFD: WikiProject_Breakfast/Flow_archive
Any interested parties are invited to comment at MFD: WP:Miscellany_for_deletion/Wikipedia:WikiProject_Breakfast/Flow_archive
The WMF converted the Flow discussion page for WikiProject_Breakfast back into a Talk page after RFC - Remove Flow from WikiProject Breakfast? reached an affirmative consensus. There now exist a Talk page and a Flow page with identical content. The WMF explicitly left it to us to decide whether to keep or delete the duplicate Flow version. Alsee (talk) 21:22, 20 February 2016 (UTC)
I removed info about Flow the "planned release" from another page.
Based on the failed proposal box on the WP:Flow page and my skimming of the top of this current talk page, I deleted the following from Wikipedia:Wikimedia Foundation § Recent rollouts and planned new features:
*Wikipedia:Flow is a planned release, and you can test it out at Wikipedia talk:Flow/Developer test page.
I trust there are no objections? BTW, the notice box in WP:Flow still promotes it as testable, but it is right below the failed proposal box, so it's debatable IMO whether it needs changing at all. Thanks for all your hard work being bold'n'stuff. —Geekdiva (talk) 04:50, 23 February 2016 (UTC)