Last modified: 2014-02-03 21:45:51 UTC
Per https://www.mediawiki.org/wiki/Flow/Community_engagement and as discussed on https://en.wikipedia.org/wiki/Wikipedia_talk:WikiProject_Hampshire#An_update_on_Flow and https://en.wikipedia.org/wiki/Wikipedia_talk:WikiProject_Breakfast#An_update_on_Flow Schedule https://wikitech.wikimedia.org/wiki/Deployments#Week_of_January_27 Planning https://trello.com/c/lt4QXy32/6-deploy
Change 107553 had a related patch set uploaded by Spage: Enable Flow on two enwiki WikiProject pages https://gerrit.wikimedia.org/r/107553
(In reply to comment #0) > https://en.wikipedia.org/wiki/Wikipedia_talk:WikiProject_Hampshire#An_update_on_Flow I think you mean <https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:WikiProject_Hampshire&oldid=591188573#Flow>. Quite the chorus of agreement you've got there. The other talk page has demonstrated consensus. WikiProject Hampshire... I'm not so sure about.
Regardless of WikiProject consensus, isn't there a larger discussion to be had here? Is this the first non-phase 0 wiki that Flow is being deployed to? I haven't been following Flow too carefully, but I personally thought it was prematurely deployed to the phase 0 wikis. I'm very reticent to see Flow deployed to a production wiki, in any form, currently. Is it ready for a production wiki? I'm wary given the extended history here; i.e., discussion systems being deployed on an opt-in basis to production wikis and the resulting ramifications.
Has there been a proper discussion on en.wiki, and not some small wikiproject talkpage?
(In reply to comment #4) > Has there been a proper discussion on en.wiki, and not some small wikiproject > talkpage? Good question. S, do you know? I don't see a link to any such project-wide discussion in comment 0. A few people have noted that quite recently (within the past few weeks, I suppose) Flow didn't support user blocks and other anti-abuse features. Is Flow ready for a production wiki? Is a production wiki ready for Flow? Key questions here, I think.
Flow can't be enabled on any production wiki anywhere unless there is an exit strategy, i.e. a script to convert Flow discussions back to wikitext. If there isn't such an exit strategy, editors must be clearly told that their discussions are liable to being completely lost forever at any given point in future (be it months or years) and the larger community of the wiki needs to agree with the deployment: se.source docet. http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/55989 In any case, forcing en.wiki as first wiki is delusional at best, or more likely a complete suicide. As for most WMF software projects nowadays, all wikis should be offered to pioneer, volunteering to the experimentation 1 to n project/talk pages with x to y edits per month, for any given n, x and y. Then you'll pick what works best. This said (or rather repeated; we always have to repeat the same things), I quit Flow discussions ages ago and I beg not to be involved in any of them.
Just to answer some of the questions above and (hopefully) clear up some misconceptions: 1) "Is Flow ready for a production wiki?" It's been live on not one but 3 production wikis (mediawiki.org, testwiki, test2wiki) for over a month, so it's a little late for the rhetorical speculation :) 2) "A few people have noted that quite recently (within the past few weeks, I suppose) Flow didn't support user blocks and other anti-abuse features." Flow is currently integrated with both AbuseFilter and spam blacklist and fully supports registered and unregistered user blocks. There was a bug in early January which caused IP blocks to not work, but we fixed it as soon as we spotted it. 3) "Flow can't be enabled on any production wiki anywhere unless there is an exit strategy, i.e. a script to convert Flow discussions back to wikitext." And there is precisely such a script :) 4) "As for most WMF software projects nowadays, all wikis should be offered to pioneer, volunteering to the experimentation 1 to n project/talk pages with x to y edits per month, for any given n, x and y." That's an excellent idea :) Let's do it! So, just to recap: we're only deploying to a couple discussion spaces where the editor community has agreed to trial Flow, and this is explicitly a test of the software aimed at making it better, hence the option to opt back out and return all discussions back to wikitext at any time. This is *not* the final product, and Flow will *not* be enabled globally without extensive feedback from the people who use it and product/design iteration to address that feedback. Any language Wikipedia or sister project interested in participating in this trial phase is welcome to do so (I like Nemo's idea of asking folks to volunteer 1-2 pages to start; I'll see what the rest of the Flow team thinks).
(In reply to comment #7) > 1) "Is Flow ready for a production wiki?" > > It's been live on not one but 3 production wikis (mediawiki.org, testwiki, > test2wiki) for over a month, so it's a little late for the rhetorical > speculation :) No, this is wrong. testwiki and test2wiki are very specifically not production wikis. > 3) "Flow can't be enabled on any production wiki anywhere unless there is an > exit strategy, i.e. a script to convert Flow discussions back to wikitext." > > And there is precisely such a script :) Which script?
(In reply to comment #8) > (In reply to comment #7) > > 3) "Flow can't be enabled on any production wiki anywhere unless there is an > > exit strategy, i.e. a script to convert Flow discussions back to wikitext." > > > > And there is precisely such a script :) > > Which script? https://gerrit.wikimedia.org/r/#/c/107733/ I believe.
(In reply to comment 7) > 2) "A few people have noted that quite recently (within the past few weeks, I > suppose) Flow didn't support user blocks and other anti-abuse features." > > Flow is currently integrated with both AbuseFilter and spam blacklist and > fully supports registered and unregistered user blocks. There was a bug in > early January which caused IP blocks to not work, but we fixed it as soon as > we spotted it. Looking at bug 60218, it seems that it was possible within the past two days to use Flow as a major attack vector, including the capability to edit any page in the MediaWiki namespace of a wiki. This was an immediate security issue discovered only a couple of days ago. The fact that Flow was capable of bypassing MediaWiki's layered security seems to indicate larger fundamental architecture issues with how Flow is being implemented. MediaWiki already has a series of robust APIs that prevent, for example, edits going through without checking user permissions or spam blacklists or the AbuseFilter or page protection or global blocks or range blocks or .... Given that serious security issues continue to be discovered in Flow, it's very difficult for me to see how Flow could be ready for a huge, indisputably production wiki (enwiki).
Copying Chris S. and Erik on this bug report.
(In reply to comment #7) > Just to answer some of the questions above and (hopefully) clear up some > misconceptions: > > 1) "Is Flow ready for a production wiki?" > > It's been live on not one but 3 production wikis (mediawiki.org, testwiki, > test2wiki) for over a month, so it's a little late for the rhetorical > speculation :) > Many would argue those aren't production wikis, but even if you consider them to be - being enabled on a production wiki is not the same as being ready to be enabled on a production wiki. So far in this bug MzMcBride has given quite a compelling argument (imho) that the extension should get a security review before being added to real wikis. re comment 10 >including the capability to edit any page in the MediaWiki namespace of a wiki The bug seems to be about being able to blank any page (Still quite concerning, but not the same type of attack possibilities)
(In reply to comment #12) > re comment 10 >> including the capability to edit any page in the MediaWiki namespace of a wiki > > The bug seems to be about being able to blank any page (Still quite > concerning, but not the same type of attack possibilities) https://www.mediawiki.org/w/index.php?title=MediaWiki:I_hope_this_doesn%27t_work&action=history As I understand it, the vulnerability discovered in bug 60218 applied to any page and the content could be arbitrary content.
(In reply to comment #13) > (In reply to comment #12) > > re comment 10 > >> including the capability to edit any page in the MediaWiki namespace of a wiki > > > > The bug seems to be about being able to blank any page (Still quite > > concerning, but not the same type of attack possibilities) > > https://www.mediawiki.org/w/index.php?title=MediaWiki: > I_hope_this_doesn%27t_work&action=history > > As I understand it, the vulnerability discovered in bug 60218 applied to any > page and the content could be arbitrary content. Any page, but fixed content. It would replace the page with the 'flow-talk-taken-over' message, which in English is: 'This talk page has been taken over by a [https://www.mediawiki.org/wiki/Special:MyLanguage/Flow_Portal Flow board].'
(In reply to comment #14) Indeed, thanks for the correction. This vulnerability is not as bad as I originally thought, but seeing IP addresses editing in the MediaWiki namespace really does seem to point to larger issues at play. Has anyone checked whether Flow interacts appropriately with CheckUser and revision deletion/suppression? It'd also help to revisit the standard deployment checklist. I wonder where that template is...
(In reply to comment #15) > (In reply to comment #14) > > Has anyone checked whether Flow interacts appropriately with CheckUser and > revision deletion/suppression? > Just looked at CU, answer is nope, so I filed bug 60275 for it. Flow has it's own revdel/suppression mechanisms, but I note that bug 58016 is still open...
(In reply to comment #15) > It'd also help to revisit the standard deployment checklist. I wonder where > that template is... == TODO/Check list == Extension page on mediawiki.org: yes Bugzilla component: yes Extension in Gerrit: yes Design review: yes Architecture/performance re-review: no Security re-review: no Screencast (if applicable): no Community support: uncertain The above is a draft and may be wrong, but it's a start. While Flow has already gone through a security review, given the numerous code changes, it should probably go through another before being deployed further.
(Adding in references to past bugs) (In reply to comment #17) > (In reply to comment #15) > > It'd also help to revisit the standard deployment checklist. I wonder where > > that template is... > > == TODO/Check list == > Extension page on mediawiki.org: yes > Bugzilla component: yes > Extension in Gerrit: yes > Design review: yes > Architecture/performance re-review: no https://bugzilla.wikimedia.org/show_bug.cgi?id=57279 (RESOLVED FIXED) though that was only as it pertains to the first set of test wiki pages. Not sure if that needs to be re-done. > Security re-review: no https://bugzilla.wikimedia.org/show_bug.cgi?id=57270 (RESOLVED FIXED) Is it worth re-doing the security review? Large code changes don't always require it, case by case and such. I'll let Chris comment/decide.
(In reply to comment #18) > > Security re-review: no > > https://bugzilla.wikimedia.org/show_bug.cgi?id=57270 (RESOLVED FIXED) > > Is it worth re-doing the security review? Large code changes don't always > require it, case by case and such. I'll let Chris comment/decide. Bug 60218 was bad, and should have been caught by someone before it hit production, but it was missed until lego pointed it out. These vulnerabilities happen, and I'm happy with the teams response to the discovery. At this point, I don't think another full review is going to be worth my time, until/unless there is an architectural shift in how they are doing security. For example, if we can choose a template engine this week, and Flow is willing to implement it, then I would definitely want another full review to ensure their coding patterns are safe. On the admin tools integration, I personally would have liked to see all of the admin tool integration done before the extension was installed. However, the team decided it was worth the risk, and it seems like they are making good progress integrating with the tools. Erik Bernhardson conveyed it is a priority for them, and they are making progress towards the integration.
According to <https://wikitech.wikimedia.org/wiki/Special:Permalink/97099#Week_of_January_27>, Flow is scheduled to be deployed to the English Wikipedia in the evening of Monday, January 27 (PST). I believe that any deployment of Flow to a large production wiki such as the English Wikipedia is premature and unwise. I believe that Flow is not ready, particularly given unresolved bugs such as bug 57512 and bug 60275.
I believe bug 57659 is also a blocker to deployment. In discussion with others, I don't believe I'm alone in this view, though I'm only speaking for myself here.
There's a lot of speculating and conjecture going on in this thread, and, ironically, the only way to clear most of it up is to let real users try Flow in a real setting, aka a highly limited enwiki trial deploy :) Please, let's separate the concerns around Flow being deployed globally, 100%, to all users (which won't happen for a year at the least, after a ton of community-feedback-soliciting, bug-fixing, feature-building, and design-revamping) and the concerns around deploying Flow to https://en.wikipedia.org/wiki/Wikipedia_talk:WikiProject_Hampshire and https://en.wikipedia.org/wiki/Wikipedia_talk:WikiProject_Breakfast as a reversible opt-in trial. As it stands, I see no reason to block deployment to those two pages -- no critical workflows will be disrupted, we passed security review, and in the extremely unlikely event that anything goes wrong, we can easily turn Flow off. As a sidenote, I appreciate that most people's concerns are coming from a good place, but marking a flurry of bugs as blockers like this at the last minute, when a new feature has been live in a production environment for over a month, is unhelpful. In the future, if any of you feel that a critical issue is not being adequately addressed by a features team, please reach out to the product owner (in this case, me) over email, IRC, or in person (especially in those rare, magical moments when we're all in the office together and have ample opportunity to talk face-to-face, as was the case all of last week).
>Please, let's separate the concerns around Flow being deployed globally, 100%, >to all users (which won't happen for a year at the least, after a ton of >community-feedback-soliciting, bug-fixing, feature-building, and >design-revamping) and the concerns around deploying Flow to >https://en.wikipedia.org/wiki/Wikipedia_talk:WikiProject_Hampshire >and >https://en.wikipedia.org/wiki/Wikipedia_talk:WikiProject_Breakfast as a >reversible opt-in trial. Respectfully, I think the people being asked to participate in such a trial should be told of the shortcomings of the current version of the software, so they can give informed consent to participate. Skimming the pages on Wikipedia, I don't see that happening for these issues. >As a sidenote, I appreciate that most people's concerns are coming from a good >place, but marking a flurry of bugs as blockers like this at the last minute, >when a new feature has been live in a production environment for over a month, >is unhelpful. In the future, if any of you feel that a critical issue is not >being adequately addressed by a features team, please reach out to the product >owner (in this case, me) over email, IRC, or in person (especially in those >rare, magical moments when we're all in the office together and have ample >opportunity to talk face-to-face, as was the case all of last week). I appreciate that the sudden furry of negative comments right before planned deployment would be frustrating. However, people tend to give the most feedback about things, when it is about to affect them. The point of the limited trial is to get feedback - well this is also feedback that is being triggered by having the limited trial.
(In reply to comment #22) > As a sidenote, I appreciate that most people's concerns are coming > from a good place, but marking a flurry of bugs as blockers like > this at the last minute, when a new feature has been live in a > production environment for over a month, is unhelpful. It might be because you just filed this bug ten days ago (!), and also because people have been at the summit recently busy with more interesting activities. Leaving more time for people to raise issues would have been thoughtful.
https://wikitech.wikimedia.org/w/index.php?title=Deployments&diff=97379&oldid=97375
The deployment of Flow to two English Wikipedia WikiProject pages has been rescheduled to Monday, February 3 (cf. <https://wikitech.wikimedia.org/w/index.php?title=Deployments&oldid=97702#Week_of_February_3rd>). None of the dependencies of this bug report have been resolved.
Here is my assessment after conversation with/input from the Flow team and Dan Garry: Bug 57512 - Flow not storing database link tables (pagelinks, categorylinks, imagelinks, etc.) * annoying, but not a 100% blocker for this deploy, but most likely for any future expansion Bug 57659 - Flow: API module issues * The team hopes to get more feedback on this from the community through this deploy and formalize that input. * Oliver agreed to send a message to the Bot Admin Group (or such) about this, as a warning ("This may change...") Bug 58016 - Flow: Suppression redacts the wrong username * while weird, not a work-flow breaker (as per Dan G) Bug 60275 - Flow actions don't show up in CheckUser * same as above (per Dan G, a CU) Summary: Still very important issues, but not blocking for this specific deployment. The team agreed to put these on their priority list for the next sprint (as I suggested they would be blockers for any future expansions).
(In reply to comment #27) > > Bug 57659 - Flow: API module issues > * The team hopes to get more feedback on this from the community through this > deploy and formalize that input. > * Oliver agreed to send a message to the Bot Admin Group (or such) about > this, > as a warning ("This may change...") We're going to mitigate that a public api may change without notice by sending a message to only one of the many groups who use the API? I would think the appropriate thing to do (If we must do this) is to include a note in the auto-generated api documentation.
(In reply to comment #27) > Here is my assessment after conversation with/input from the Flow team and > Dan > Garry: > > Bug 57512 - Flow not storing database link tables (pagelinks, categorylinks, > imagelinks, etc.) > * annoying, but not a 100% blocker for this deploy, but most likely for any > future expansion > > > Bug 57659 - Flow: API module issues > * The team hopes to get more feedback on this from the community through this > deploy and formalize that input. > * Oliver agreed to send a message to the Bot Admin Group (or such) about > this, > as a warning ("This may change...") > > > Bug 58016 - Flow: Suppression redacts the wrong username > * while weird, not a work-flow breaker (as per Dan G) > > > Bug 60275 - Flow actions don't show up in CheckUser > * same as above (per Dan G, a CU) > > > Summary: Still very important issues, but not blocking for this specific > deployment. The team agreed to put these on their priority list for the next > sprint (as I suggested they would be blockers for any future expansions). This new extension is having difficulties interacting with four other key extensions....and I have to wonder how many things it has to interact badly with before someone thinks maybe it would be a good idea to fix the interaction problems before releasing to production. I'm fully supportive of it continuing to be available on test sites and mediawikiwiki, of course, so that "hands-on" users can continue to help troubleshoot. But when there's this many interaction issues, and two of them are going to be highly attractive to our problem users, who also read bugzillas and like to test new features....well, I'm concerned.
Change 107553 merged by jenkins-bot: Enable Flow on two enwiki WikiProject pages https://gerrit.wikimedia.org/r/107553
21:34 +logmsgbot: !log bsitu synchronized wmf-config/InitialiseSettings.php 'Enable Flow on two enwiki WikiProject pages'
