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):
- User finds a page they want deleted
- User adds the page to the list of "Article Deletion Discussions"
- The page is marked as being under discussion for deletion
- A discussion is opened about the page
- Several editors engage in the discussion, leaving "votes" and/or comments
- 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".