Topic on Talk:Flow/Interactive prototype

Before starting development, at least start a widely publicized discussion about this and whether or not the community wants to implement it before forcing it onto everybody. This just isn't Wikimedia/Wikipedia. Also "mark abusive"? What? Are comments just going to be randomly censored because someone doesn't like them? Is there going to be a never ending backlog of these that needs to be reviewed? What about editing other's comments for technical corrections or copyrighted content? Please, please don't implement this. I don't even like the interface I'm editing right now here. Please also see the "Too much stuff" section below me and the "Interface wastes too much space, doesn't fit into Wikipedia" section.

There is a widely-publicized discussion that is happening right now - and you're part of it, especially by coming here.

Flow portals have been created on three distinct wikis (mediawiki.org, enwiki, and meta). Announcements have been made in various forums and Village Pumps, as well as a blog post, and then emails sent to Wikimedia-l and Wikitech-l, as well as to the Wikitech Ambassadors.

It really isn't possible for us to try to publicize it more without resorting to central notice (which we may end up doing, just not yet).

Jorm is right, there are various announcements spread across many Wikimedia projects.

However, I'm feeling there is still not enough input by far. I assume this talk page es well as the one located directly at Talk:Flow Portal are supposed to be the places were most of the discussion should be happening right now?

However there's only input by few people so far and even that seems to be not properly accounted for. There's mainly criticism right now, but it appears to me the developers of Flow (or mainly you, Jorm, since there don't seem to be many developers actively contributing to the discussions right now) are mainly trying to explain themselves instead of responding to the constructive feedback and trying to implement some of the proposed changes.

Well. There are no developers (yet); we're in the design phase. I am the one on point for the project at this time; there will be more people getting involved as things ramp up further. That said, "implement proposed changes" doesn't make a lot of sense in this context; there's nothing to implement. I could update the interactive prototype (and am), but it's just that: a prototype, with no backing. Focusing on visual design criticism doesn't have a lot of value at this point in the game and that's really the only thing I could "implement".

OK, I wasn't aware of that. I thought there was a small team at WMF working on Flow, I didn't know it was that small.

But you have to respond to feedback (and if you provide an interactive prototype, visuals are the thing people notice first, espiacially if most other things are not working yet). Defending the decisions you made so far is not helping the project at all. It only gives the impression you're not really caring for the needs of the community but trying to overrun it with an all-new discussion system that the WMF thinks is best for the community.

I'm confused. Brandon has spent a large number of hours sat on this talkpage, largely without staff support, having a conversation with you about what the plans are. Do you think he'd be doing that if he felt that he didn't owe editors a conversation about this in which they could participate? The very fact that we're having this discussion somewhat undermines the argument here.

I agree there needs to be more input, and we'll be throwing it out a lot more widely and in a lot more detail once we're in the next phase. But at the moment we're just throwing ideas around; the fact that your suggestions haven't been implemented in the prototype doesn't mean we're not listening, it means we're having a discussion. Yes, we're going to have energy spent on explaining our thinking behind features, and defending those features, because that's what "discussion" means; both sides setting out their case. Us implementing whatever people wanted instantly without thought would not be a discussion, it'd be software design by committee - and I'd note that when we're criticising LiquidThreads, one of the big things that brought it down was design by committee.

Well, I'm a little confused, too, that's what I wanted to make clear in my posts.

You're requesting feedback, but instead of discussing how this feedback could be implemented best in the final Flow, most of the replies by Jorm are reasons why the requested features won't get implemented. He spends time to defend his decisions instead of reconsidering his decisions based on the given feedback. This is just pointless in my opinion.

I didn't follow the discussion around LiquidThreads and I'm not completely sure what you mean by "design by committee" but in my opinion the new Flow should include the features the community wishes for, redacted and planned by the WMF but based on the ideas of the community. Instead I have the feeling WMF (or Jorm) are planning on their own and present the community with a fait accompli.

I'm sorry that you think I'm ignoring the comments and defending the decisions made. You are correct in your (unspoken, but I believe it to be true) assumption that there have been decisions made. However, I am not trying to "defend" them; I am trying to explain them.

All design - especially product design, which is what we're talking about here - operates under a series of constraints. Walls that we must account for. Many of those constraints revolve around performance and scalability as well as future proofing.

For example, one of the reasons why LiquidThreads (this discussion system) is so slow is that every comment is stored and managed as its own Wikitext Page. In order to display a LiquidThreads discussion, the following happens:

1. All threads to be displayed are located.
   1. For each thread, find the current revision and retrieve it
   2. For each thread, find the posts that belong there
      1. For each post, retrieve the current revision
         1. Run each post through the wikitext parser to produce HTML
      2. Assemble each post in correct order for each thread
2. Display

It's ridiculously slow and is absolutely not scalable in any way, shape, or form.

The slowest part is the actual processing of each post through the parser - turning the wikitext into HTML. We can achieve a speed increase along several orders of magnitude - *thousands of percent faster - by skipping this step. That means storing each post as pre-parsed HTML (e.g., we parse it on the way in and not the way out, which is how the Parsoid project works (kind of - it's complicated)).

Parsoid does not do well with templates. Ergo, we are designing with the assumption that we can't use templates.

Future proofing requires that we use the VisualEditor now so that people don't splatter in a stuff that the VisualEditor can't process. We have to ensure that we're "VE-proof" from the beginning.

And so forth.

Thank you for this post since it really gave me some insight on your motivations.

However it made it clearer than ever that decisions were made on your side and you won't reconsider them anymore, knowing they may not resemble the communities wishes. That's sad, and it will inevitably lead to differences between WMF and community and to rejection of the whole Flow system.

I don't know your reasons to hazard these consequences, but I hope those are good reasons...

Personally, I have a very simple and driving reason: the continued survival and viability of the movement's projects in service of the greater mission. Relying on a dwindling technical priesthood is clearly not the solution; we must move out of the year 1999 and into the year 2015.

Let's hope you'll not want to get back to the future when it's due...

If something contains copyrighted content it seems like precisely the kind of thing that should be marked as abusive - and as for copyediting, why is that a requisite feature? Let's be clear, here, that we're in an early design stage. Statements like "there will be a mark-as-abusive feature" are just that; statements, not explanations of the underlying workflow. If you've got an idea of how the workflow for removing problematic posts would work in an ideal world, say it and we'll see what we can do about it :). See Brandon's comment below: Ideally, clicking on that link (and the terminology there is obviously open for discussion) will start a workflow that helps a user define if a comment is abusive, vandalism, off topic, whatever. I have intentionally not spent a great deal of time on anti-vandalism workflows because I wanted to get more information about how people would like to see that work; this is my fault for showing something half-baked."