Topic on Talk:Flow Portal/Archive2

I'd like to let you know, if you don't already, of a system that would necessarily need to be adapted. In order to heed warning levels on user talk pages, all standard warning messages contain hidden text indicating the warning level, that bots and scripts can read from the source talk page. This is critical to wikipedia's anti-vandalism efforts. No detection of last warning level means no escalation of warnings means vandals aren't reported to w:WP:AIV means vandals are not blocked.

So, this is a perfect example of something that Flow will handle and make better. You're describing a "warning" workflow. In this scenario (and I'm throwing cheese around; pseudo-code), a user would initiate a "Vandal" workflow on the user. That workflow would then remain active until manually closed by a privileged user (or maybe expired via time, depending on the level).

Once that workflow was enabled, it wouldn't be able to be "deleted". Bots or other users wouldn't have to search histories or hidden text; they could just query the user's Board for specific workflows (tags) and they'd appear. Additional attempts to initiate the same workflow would bring the existing, working one to the front, and automatically escalate it.

We could even do things like require that the user acknowledge the warnings before they are permitted to continue editing (though that could lead to denial of service attacks).

What would be a privileged user? The person who posted the warning, or just administrators? And on English Wikipedia, many people who post incorrect warnings never bother to remove them instead they currently say, "sorry, remove it yourself". So, then, wouldn't this flood the administrator's notice board with requests to remove incorrect warnings?

Usually, when you design something like this, you make it configurable by the sys admins who are setting it up. "Who gets this privilege?" is a policy question, not a software question. Policies are set by the people who run and use each individual wiki. The software developer is not setting the policy for every single Flow installation in the world.

This isn't "Flow for the English Wikipedia". This isn't even "Flow for WMF projects only". This is "Flow for thousands of wikis". So a business running this might let anyone have this particular privilege. A school might let anyone except students have this privilege. And similarly, each of the WMF projects could choose to have a different system. One might make this function available to admins only; another might make all warnings expire automatically based on time; a third might allow any admin plus the individual user remove warnings; a fourth might allow any autoconfirmed user to have the warning-removal privilege; a fifth might allow anyone at all to remove a warning.

Okay, I'm going to stop you right there, because this theme that the WMF should be creating software intended to be used on "thousands of wikis" keeps cropping up. I thought we all just went through this narrowing focus exercise, didn't we? Where it was determined that the WMF would support the WMF movement? Why are we spending our donor dollars creating software that is being genericized instead of customized for our projects?

I hold Jorm in the highest respect, but this is fancy software for the high-speed Western world. Visually, it looks like a cross between LiquidThreads and Facebook, the former being unscaleable and widely disliked software, and the latter now slowly morphing into Myspace. I do not understand how the driving rationales have brought us to the point where users are supposed to sort through a pile of mixed threads on their "board" rather than selectively reviewing things through their watchlist. I can see lots of features here that would be useful, but I'm really not seeing any rationale for creating this mélange of topics in one place. I don't think anyone asked for that as a design principle, did they?

Risker, in this instance, at least, making it "generic" is the simplest and most obvious way to make sure that each project has the ability to customize it.

We have no indication that customization is possible or even considered an option, WhatamIdoing; in fact, at this point, it seems that the key issues that a project would want to customize aren't even under consideration or, alternately, are not options. Templates? no, unacceptable. Usable by the visually handicapped? Maybe sometime, but not a priority. No Javascript? No communication. The absence of a method by which to communicate with other users that does not require javascript means that this project is actively working against its own objectives. At this point, I'm ready to spend donor dollars to send our engineering team to the Philippines for two weeks and require that they use computers built before 2010 and dial-up, and accept only code that works effectively and pulls up pages in a reasonable time. This won't.

The more time I have spent looking at this, the less I find it a worthwhile replacement for talk pages; in fact, the more I dig, the less persuaded I am that this is going to improve communication and collaboration. Facebook doesn't improve communication and collaboration. LiquidThreads didn't either. Collaboration has never really been that much of a problem, comparatively speaking. I'm hard-pressed to understand why this is a big focus.

Jorm said months ago that there would be a fallback for users who don't have Javascript. The exact features were unknown, of course, as was just about everything else at that time. Am I really the only person who saw those messages?

As for sending them off to the Philippines: perhaps they would all enjoy it.

In answer to your question, what Jorm said months ago is kind of moot when he's said just this weekend that he doesn't really know how it will be done, or whether or not anyone will be able to respond absent javascript. His comment below

Reply to Risker, quoting in places:

Okay, I'm going to stop you right there, because this theme that the WMF should be creating software intended to be used on "thousands of wikis" keeps cropping up. I thought we all just went through this narrowing focus exercise, didn't we?

There are still around 800+ wikis underneath the Foundation's umbrella. It is not "thousands" but it's still quite a large number, and I do not believe that our "narrowing focus" exercise does not absolve us from supporting them. It is actually easier to make the software customizable for every wiki than to build for 800 disparate instances.

Why are we spending our donor dollars creating software that is being genericized instead of customized for our projects?

That's the point: we are spending donor dollars to ensure that the software is customizable for our projects.

I hold Jorm in the highest respect

Thanks!

, but this is fancy software for the high-speed Western world. Visually, it looks like a cross between LiquidThreads and Facebook, the former being unscaleable and widely disliked software, and the latter now slowly morphing into Myspace.

I do not understand how the driving rationales have brought us to the point where users are supposed to sort through a pile of mixed threads on their "board" rather than selectively reviewing things through their watchlist.

I've heard you say something like this before and I thought I had cleared it up, but the fact is that what I think you are afraid of simply isn't true. In fact, in the first planned rev of the feature, it is assumed that you will continue to utilize your watchlist to follow topics and pages.

The inclusion of a "feed" view is an additional feature - it's simply a way for you to view all discussion activity in situ without resorting to the watchlist and being forced to open a gazillion tabs to keep up with things.

Assuming Flow feeds will be anywhere close to what LiquidThreads offers as "New Messages" (all watched and updated threads collected in one feed) I'm a little skeptical about that feature, too.

Actually it encourages to discuss – but one often looses overview about what one was actually discussing (was it Flow in general? Or the prototype? Or was it some completely different discussion regarding VE?). Doesn't matter! Just write what you think! The Flow will go on – and sometimes steer the discussion into a dead end where much was said but little gained.

Threads are not closely enough bound to pages for my taste. One gets discussions everywhere and I'm afraid it could lead to users contribute to whatever pops up in their feed. While producing more "Flow" this probably won't increase the quality of contributions but will hide the useful contributions between the many "say something" answers.

Edit:
Actually I just did it myself!: The thread was about warning levels. Now I'm talking about feeds in a discussion that is already nested in seven layers! I have serious concerns if threaded discussion will actually aid the type of discussions we have going on Wikipedia...

Wikipedia discussions are threaded discussions. I'm not sure how adding structure to those threads is a bad thing.

Sorry, I intended another meaning.

The current talk pages are self contained with all text on one page.

Flow will be split in threads and comments that will be "wildly" distributed across pages, will get included in feeds of all sorts, etc.

I don't know if this really adds structure. Personally I think to keep threads exclusively to one page already adds a huge amount of structure – which Flow will just give up.

If you like seeing all of the discussions about [Page X] in one place, then why wouldn't you just go look at them? Flow offers you a feed. You are not required to use it.

Sorry, but this reply wasn't too thoughtful, was it?

I assume we're discussing to improve Flow for everybody to get a discussion system fit for it's job. I don't think the way how I personally use Flow will influence the problems beginners might face. This might become a serious problem and you'd rather think about solutions then to fob me off with "if you don't like it don't use it".

What Risker above hinted is that you're generalizing over a wrong axis, because you have created and already committed to a design solution based on wrong assumptions (like "Wikipedia discussions are threaded discussions" - that's only one of the many use cases). This happened because you created your solution before gathering requirements, and thus you're solving a wrong problem -or rather, only a sub-problem of the whole thing.

By forcing the tool upon the community, you're going to eliminate all the possibilities of the tool that you didn't take into account from the beginning. Editors who care about the project are trying to warn you about this outcome, and so far it seems that we have failed to convey this message in a way you can understand. Diego Moya (talk) 12:21, 17 July 2013 (UTC)

Can you give an example of a non-threaded discussion at the English Wikipedia?

Threaded discussions are the normal approach. Sometimes this takes the form of you post, I reply, you reply, I reply again. Sometimes this takes the form of you post, and a dozen people reply (e.g., !votes), sometimes with replies to those replies (e.g., when the original poster wants to argue with the people who !voted the wrong way). But I don't think I've seen a non-threaded discussion, unless you count the occasional newbie who creates a new section/new discussion for every single reply, and they stop that as soon as someone explains how to reply properly.

> Can you give an example of a non-threaded discussion at the English Wikipedia?

Why should I do that? The problem with Flow is that English Wikipedia talk pages are used for collaborative tasks that are not "discussions" at all, threaded or otherwise, and the current proposed design includes little or no support for them.

I'm talking about user-created classification silos and review backlogs such as those typically created by Wikiprojects (tables of discussions requiring attention, various newsletters and other tools that get posted to talk pages, or tools like the AfD voting statistics), that typically depend on transcluding tables and other rich formatted data that don't fit a "threaded discussion" model. (P.S. there's also everything by Quiddity).

There is some talk about allowing sticky shared notes and an "unstructured" section, but those are poorly defined lacking use cases and features; and given the amount of features from wikitext that are being dropped in Flow, it's likely that the current tools will cease working, and it's not at all clear that they can be adapted to the new paradigm that is not designed to support them.

All this wouldn't be a problem if Flow was not intended as a complete replacement for talk pages, and therefore imposing a design that only supports threaded discussions for a collaboration tool that is used for other communication models. Solving it would be as easy as associating each talk page or thread with a free-form sandbox supporting the same content that can be displayed at articles.

P.S. Watching this thread below it looks like some options are being considered to support this kind of free-form collaboration tools that are not threaded.

2 quick notes:

Newsletters and other Bot-messages are included in the Flow Portal/Use cases page. The newsletters shouldn't be using tables for columns/formatting, so hopefully that will be fixed as part of the transition. Edwardsbot already uses css/divs for formatting some newsletters, eg.

The pages created by ScottyWong's tools (w:User:Snotbot/AfD's requiring attention, and w:User:Snotbot/Current AfD's, and AfD stats) and all the other bots, need to be kept in mind for the future, but don't impact usertalk pages (afaik).

I'm a little surprised that everyone is so worried about ScottyWong's tools. So at the risk of repeating myself, what Snotbot is doing will get easier under Flow. Instead of needing to "transclude" AFDs, it will just need to "tag" them, and everything else will happen automatically. You won't lose any functionality here. There is also nothing inherent in a "discussion" system that will prevent ScottyWong from tallying up !votes in AFDs. Again, this might even get easier with a Flow system that is tailored specifically for AFDs rather than free-form text that he has to carefully parse. The same tasks can be achieved in Flow, even though the exact mechanism for doing them will be different.

"Workflow"? Can you please use English, instead of MBA-speak? And "they could just query the user's Board for specific workflows" is doubly incomprehensible. It's rather amusing that wiki-markup takes only seconds to figure out, but the explanation of the new system reads like something that was run through a machine translator a couple times.

I'm not sure that there really is a plain English word. It's a kind of technical concept. "A workflow" is "one kind of thing you do".

So if you're washing laundry, you have "a workflow" that involves several steps: sort the laundry, put the laundry in the washing machine, add soap, run the machine, remove the clothes, and dry them. That's your "workflow".

That workflow is similar to, but differs from, washing the dishes in an automatic dishwasher: You probably add scraping the plates, but skip sorting the items. You still put things in the machine, add soap, run the machine, and remove the dishes, but drying might have been done by the machine.

I can't think of another word that describes the abstract concept of an orderly process of things you do to accomplish a particular goal. Can you?

Yes I can. Procedure. Course of action. Method. Process. System. Practice. Technique.

A.k.a Workflow! (Also, many of the words you listed have ambiguous meanings, or do not primarily/precisely describe an ordered-sequence-of-steps.)

Well, what I am seeing is the term "workflow" to describe multiple things, and it is not actually being used correctly. Workflows have rigid ordering of steps that must be done in a specific order or the end result is not correct. Much of what we do on our projects that is being described as a workflow isn't really. For example, when we block a user, we complete the block form, we may or may not leave a notice on the page (either personally written or using a template), we may or may not revert edits, we may or may not ask for revision deletion or suppression, and none of these has to be done in a specific order, or within a specific timeframe. Yet, this would be described as a workflow. There is no sequence, the only step that is mandatory is the actual completion of the block form (whose fields can be completed in any order), and the end result is the same whether or not any of the non-mandatory steps are taken.

I added an anchor to a comment Jorm made at w:Wikipedia talk:Flow#What Flow actually is, which might help.

I don't think the conceptual workflow modules are intended to be rigid procedures; they're intended to streamline the bits that can be streamlined (that currently require multiple disjointed steps and large pages of instructions to remind us exactly what order we're meant to do things in, like AfD), whilst still allowing whatever nuanced customizations each process often requires.

And more than that, the workflows will have hooks for alerting anyone who wants to be alerted about [an afd in the medical field / an afc request that needs copyediting / an rfc that is related to MOS:QUOTE / etc], hence increasing our awareness of what's going on, but without adding to anyone's workload.

We're going to be building the workflow modules, and requesting whatever features we need. The devs are just building the lego-blocks of features, that we'll put together in whatever ways we need/desire.