Topic on Talk:Flow Portal/Archive2

I have a question about Flow "workflows". From what I understood, a "workflow" is some facility which eases conducting a specific type of discussion, hardcoded into Flow for each specific use case. Which strikes me as inflexible and impractical. Say we have a deletion workflow. If for some reason the deletion process needs to be changed, this would entail a need to change in software. And we all know that changes to software are slow and painful. The same would apply if for some reason we needed to have a new workflow created.

Meanwhile, on Wikia, I see there are "forums" with a really neat feature: threads attached to ordinary pages. I would do something like that: each Flow thread would have a list of one or more pages it relates to. A "User" discussion would be nothing more than a discussion attached to a user page. A "deletion discussion" would be nothing more than a discussion attached to the page under consideration and a deletion policy page in the project namespace, or even some specially designated page to which deletion discussions are attached. A "newbie asks for help" discussion would be simply attached to both the user's page and the "active newbie requests" page. There would be no need to distinguish "User talk" from other types of discussions at all. Simple, flexible, and integrates neatly with wiki structure.

[Edit: I read a reply below indicating this is pretty much exactly what is planned. Never mind. But then, what are workflows, actually?]

Some time ago on w:WP:VPT I also proposed a "page tagging" feature, for tags like "unreferenced". Talk page banners could be integrated into that. If we wrote such a thing, it could eliminate the need for an "unstructured heading" space too, further simplifying things.

We've been using the term "workflow" rather loosely to refer to any discussion or process on Wikipedia that includes a set of steps that are more or less regular. Examples include the AfD process on English and other Wikipedias (step one: an article is nominated for deletion; step two: users comment with keep or delete; step three: the discussion is closed and summarized, and the appropriate action is taken on the article), or user blocking (step one: user is warned; step two: user gets a block template on their talk page, with the option to request unblock; step three: user requests unblock, which goes into a category for admins to review; step four: user is either unblocked or his/her request is denied).

Some of these processes can be automated with software, and we've done a bit of brainstorming on how this might actually work – check out this doc for an example. But in the first release, we've decided to focus more on the unstructured user-to-user discussion side of things. There are benefits to automation (it can make some processes work faster and more smoothly), but there are also drawbacks – we want to ensure that any automation we create is maximally flexible, configurable by the community, and can evolve alongside the policies and practices that it's meant to serve. That's why we're holding off on the workflow piece of Flow until we can devote our full time and energy to it.

Okay. I have seen the word "workflow" thrown around a lot in discussions regarding this. I assumed it has a technical meaning.

Still, the descriptions I find around there, and in the above reply sound rather complicated. To reiterate, the core, universally-needed features here are:

• Threads and posts clearly separated from each other. [in progress]
• Threads attached to (possibly multiple) pages. [in progress]
• Enumerated options ("votes"). [early plans]
• Discussion closure and closure summary. [early plans]

(I am omitting things like notifications of replies, subscribing to discussion boards/threads separately, etc.)

If I were to support "workflows", I would base everything on these core features, and create a configurable policy (similar to protection levels) for choosing how they are supposed to be used, i.e. who is able to attach or detach a particular page to a discussion thread, and who can close threads attached to particular pages (i.e. anyone can attach a new thread to a "current deletion discussions" page, but only administrators can close and detach threads from it; blocked users cannot attach threads anywhere except the "current unblock requests" page and their own talk page, etc.). Very little of the discussion processes would need to be coded into Flow this way.

And I think there should be a feature for seeing threads attached to "all of the specified pages" (e.g. for when someone is looking for past deletion discussions for a given page: intersection of that page and "past deletion debates") and "either of the specified pages" (someone wants to have a unified view of MfD, TfD and RfD, or a unified Village Pump).

Also, did anyone think about the "page tags" feature? This could replace maintenance tags like "unreferenced", deletion or protection notices, or talk page banners. It could eliminate some problems, and would be great to integrate with Flow, e.g. we could have a tag saying "this article needs to be cleaned up, see [this discussion thread] for details". And the discussion thread would be created by the software while adding the tag, instead of requiring the tag adder to do it manually. The current system of "templates and categories" kinda works, but sometimes it just feels strained. Merges seem especially painful.

The final item on my wishlist: please keep the visuals simple. I like the ascetically compact look of talk pages, certainly more than I like LiquidThreads. I only want posts to be clearly separated from each other, and to be able to collapse threads to take even less space.

And a pink unicorn, please. Need not be invisible.