Topic on Talk:Flow Portal/Archive2

How will this affect talkpagespace using administrative processes? On English Wikipedia, polls/consensus discussions frequently take place on talk pages. These need to be marked closed when a conclusion is reached. (processes such as suggested moves, splits, mergers; or other less regimented discussions, like RFCs)

Also on English Wikipedia, there is something called Articles for Creation, a process that uses the talkpage to store a draft version of an article, which multiple people edit, and isn't a talk thread. And other people outside of AFC also use talkspace to store draft articles, which multiple people edit (there's even a template for marking such things on English Wikipedia), will this still be possible with a FLOW rollout?

As well, some of these processes have malformed structure, which other editors then go about to correct, and use templates as part of the structure. Since other editors need to fix the templates, it would mean editing someone else's contribution. (as well as remove them to close marked discussions)

Is this still possible in FLOW, or does a separate second talkspace need to be added for these?

First off, I want to re-iterate that phase one of Flow is only concerned with "User talk" and user-to-user communication. Process discussions like you've described - "!vote procedures" (pronounced "bang vote", or "not a vote") - they are being thought about but we want to learn what we can about how Flow is used in the real world before we begin thinking very deeply about those kinds of discussions.

That said, we have been thinking about how to handle these discussion types (even though we're not there yet, we have to avoid "painting ourselves into a corner", as it were), so our designs today account for future growth.

Now, what I'm about to say may get too technical, and if so, feel free to ask me to be clearer.

What you're talking about is actually wrapped up heavily in what we are calling the "Workflow Description Language Module". This is a going to be a kind of "scripting" language that will allow local wikis to define workflow processes for themselves (the reason being that the Foundation cannot possibly hope to account for all the myriad workflows that exist on all wikis, and forcing everyone to follow a singular workflow is crazy).

Let's take the example of a "Request for Deletion". Such requests follow a workflow, even if it isn't apparent. Let's say it goes like this (we'll ignore the actual technical events that happen, like "posting templates", as we want to focus on what happens, not how it happens):

1. User finds a page they want deleted
2. User adds the page to the list of "Article Deletion Discussions"
3. The page is marked as being under discussion for deletion
4. A discussion is opened about the page
5. Several editors engage in the discussion, leaving "votes" and/or comments
6. An administrator closes the discussion and makes a decision about to keep or delete.

That's actually a fairly straightforward workflow.

Where people trip up is thinking that the way this workflow is currently handled (with templates and star-indentation and twinkle and so forth) is the only way it could be handled. The current system exists in the way it does simply because there were no better ways to do it.

So let's create one.

With "user to user" talk, we describe a single type of "Flow Object" - a "Discussion Topic". Let's say that Discussion Topics have the following elements:

• A title
• A creator
• Where it was created
• When it was created
• A summary (maybe)
• A "lock state"
• 1 or more Discussion Post objects, which have
  • An author
  • Post text
  • Create date
  • In reply to designator

(Discussions are also workflows, mind you.)

Let's say we want to describe a "Request For Deletion" object, instead. With a different workflow. A Request for Deletion object may have:

• A title
• A creator
• A pointer to the page being discussed
• A reason for the deletion (text, added by the creator)
• A closing summary (at the end)
• A closing admin (at the end)
• A closing state (at the end)
• 0 or more Enumerated Vote Comments, which have:
  • A "vote state" (say, a pulldown that you can select: keep, delete, strong keep, strong delete, merge, comment, etc.)
  • A comment author
  • A short comment (say, 500 characters)

This defines a very simply workflow object for an RFD. Obviously, my example here isn't fully fleshed out and doesn't account for all situations, but I hope I've been illustrative. Local admins will be able to define any number of automatic workflows that will just. . . flow. . . through your feed.

The short answer to your question is "Yes, these things are totally possible with Flow." The long answer is "We're going to make them so much better".

First of all (please don't take that personal):
I want to re-iterate that phase one of Flow is only concerned with "User talk" and user-to-user communication. — Stop that silly sentence! Everybody knows that there is no point in maintaining different concepts of talk pages for user-to-user discussion in contrast to article discussion or project pages, etc. If you're talking about implementing Flow in user-talk pages, we're talking about Flow being implemented on all talk pages eventually. It doesn't matter in which time frames this will happen, it will happen at some point (unless Flow ends in a disaster and is abolished).
To prevent the disaster from happening we have to discuss usability of Flow for general discussion, independently of the user-talk pages example that you try to keep in mind. And we have to discuss general usability now, before starting with any "phase" at all. The whole "phase" partitioning is eyewash that is detrimental for the goal of a working future discussion system.

Regarding your Workflow concept:
It sounds interesting, but at the same time it sounds as if it was an unnecessary specialization. You're always assuming that we're currently doing things with the old system the way we do them because "there were no better ways to do it". Actually we're able to do all these things because our current system is not specialized at all! When introducing any form of specialization, even if it is thought through very well as you're suggesting, you're removing certain degrees of freedom from the system, since that's the definition of specialization after all. It might simplify certain workflows, but I'm almost sure we'll find certain workflows that will be limited by the new system. Therefore we'll need to develop new workarounds to meet our needs again or adapt the system further. A vicious circle...

I'm not going to stop using that sentence because that's exactly what is going on here. We are looking at user-to-user discussion in the first set of deployments because user talk pages are the simplest workflows we can encounter. We are planning to develop for that, and then take what we learn from that process - what's good and bad - and apply it to other areas going forward.

I'm not going to lie to you or sugar coat it: You should achieve zen acceptance that talk pages, as they currently exist, are going to disappear. I don't have a time frame for when that is going to happen. I can't tell you what phase 2 (what we focus on next) will be. I have nothing to say other than "user talk is the first phase." It's not eyewash. It's practical planning.

Because of the way this has to be scaffolded, it simply isn't possible to trot out a complete package, covering all bases (which seems to be what you're asking for). The problem is very big and very complex and it has to be broken down into segments in order to be understood. We focus on one part and get the processes and experiences correct for that, while also allowing for future growth, and then move on to the next part.

I'm going to point you to the way that "Unblock requests" are handled on the English Wikipedia for an example of a totally, completely broken workflow that exists in the way it does simply because there are no better tools. Wikitext and templates are rarely the "best" answer to these problems; they're just the tools that are currently available. I'm unsure why you would object to having additional, better tools at your disposal.

I don't meant that planning in phases was eyewash. I said your so beloved "don't care for that now, that's not part of phase 1" sentence is eyewash. The phases are of no interest to the editors, they are a purely internal thing with importance to only developers.

If you have no idea how to solve certain problems today, that will maybe not matter in phase 1 tomorrow, but will probably be a design issue the day after tomorrow. And I already hear the crying that will happen then: "We can't make it work satisfactory because we didn't thought it through at the beginning, but we are too far in the process to revert the changes so we have to live with it". Don't make that error!

The two extremes that you need to avoid are:

Ready, Fire!, Aim.

Ready, Aim, Aim, Aim, Aim, Aim, Aim, Aim, Aim...

One problem is, that user talk pages cannot be dealt with as an isolated problem. The decisions that you make now will foreclose options when it comes to deal with later phases of what you are saying is an inevitable process that all us poor users must simply lie down and accept. We need a system that can deal with the hard things like admin boards or article talk pages, where users have to be able do do the same things that they can do in articles, not something that may work at first but cannot be expanded later on, or is only going to work by removing large amounts of functionality.

Clearly this is true, and clearly we're thinking about it. The back end structure as is being designed (there's an architecture document) accounts for this.

One question regarding the new backend:

You said before, that content will be converted to something similar to HTML when it enters the system. How can we solve things like maintenance categories and the like? Things that can change after the document got first created.

Right now we have the wonderful possibility to change templates afterwards and pages will update to reflect those changes. I assume this will be hard to impossible with the new system?

Why would you apply a maintenance category to a discussion topic? You can't do that now, with the current technology, so why is this a concern?

As I've said multiple times, there will be an "unstructured" section on each board where things like maintenance templates and categories go.

Well there are some maintenance templates, that go into a discussion (e.g. edit requests). But I assume most of the cases could actually be solved with the "unstructured" section.

I'm unsure however if this will not add again complexity you're trying to avoid, since an "unstructured" section will be unstructured by definition (the opposite of what you want Flow to be).

Would it be an option to have an unstructured section per topic, that can be easily referenced from within the comments on the thread (I have some sort of "see figure 1" in mind)?

Some of these workflows happen on talk pages attached to the object for which they are being applied to, unlike deletion requests, in the current usage at any rate. And users keep screwing them up. With a specialized workflow implementation as you suggest using the example of a page deletion process, we'd need to make sure that users actually use these tools, instead of how they currently act, by randomly starting a poll on the talk page, and then someone comes along later, and corrects it by properly registering it into the various processes (such as Requested Moves). If the specialized workflow is not started at the beginning of the discussion, then all that came before is effectively lost. As well, the originating nominator's name will not be attached to the new workflow unless we allow users to attach other user's identities as the "creator", or create a new set of workloads for our administrators (who I assume would have such a right, if the general user does not)

Is there a list of the (short- and long-term) targeted workflows?

There's Flow Portal/Use cases which might be what you are looking for. I don't believe there is a detailed roadmap/timeline, at the moment. There are other interesting/insightful pages linked in the sidebar, though. (Bear in mind that all the docs are brainstorming-notes, and many are more than a few months old, so they are not definitive at all.)