I love the direction this discussion is taking. It's really great to get a social critique of the use of technology, I wish it happened more often!

Just for background, Fundraising is considering formal workflows to manage two aspects of our system: First, we want to track each donation using a local model of the payment gateway's state machine. This allows us to actively check for unexpected events, and to say for certain when we are allowed to issue a refund, and so on. The second and less pressing need is to help us design software that is flexible enough to deal with the huge variations in payment gateway behavior, and still have a provable and maintainable system which we can trust to run all of our secondary processing.

The goal of my RFC was to see if our requirements align with the onwiki administrative and discussion stuff.

Whether a formal workflow is good for the editor use cases is an interesting problem. I'd like to see whether the workflow idea can be adapted to provide something helpful without enslaving us to the machine. To start, what is needed?

* Clear and accurate description of a process as it is done in the real world, from the perspective of the participants.

* After negotiating changes to process, a simple means to promote the changes to actual usage.

* Flexibility to deal with all the weird stuff that happens when living humans are involved.

* Helpful tools, depending on the process: easy queue management, alarms for when a grace period elapses, a way to detect when someone short-circuits the process and unilaterally deletes a tag or something...

* Level the field, removing obstacles to people who are not indoctrinated in admin culture or tech skills.

* Customizable across communities, with the option to keep certain central characteristics intact.

Have you already made a list, or can you improve this one?


On Sep 11, 2013 10:20 AM, "Maryana Pinchuk" <mpinchuk@wikimedia.org> wrote:
+1 to Steven's skepticism. I also shared some more concerns on the talk page.

In theory, the Flow project is meant to tackle discussions + workflows. In practice, I've made a conscious effort to shift the focus to discussion first and foremost, which I feel is a way more pressing issue (practically and ideologically). I'm open to hearing other people's take on why automated or semi-automated workflows are equally or more critical, but I'm going to push for a lot more user-centered detail, because I don't feel like I've seen a compelling rationale for how, specifically, this is going to benefit our end-users. If fr-tech needs a workflow engine for its own purposes (Adam, maybe you could provide us with more background on what purposes those are?), that's totally cool and fine and you guys should build one but let's be careful not to end up in the "when you're holding a hammer, everything looks like a nail" situation :)

On Wed, Sep 11, 2013 at 9:28 AM, Steven Walling <swalling@wikimedia.org> wrote:
I added product designers (i.e. anyone making software for users) as a stakeholder.

I am very very very very very very skeptical of this whole workflow language idea. What began as the need for better localization of tools like PageCuration, and a vague but promising idea about using ContentHandler to help give pages more structure, has morphed in to a convoluted and over-architected idea. And that goes for whether the particulars come from fundraising or product or design etc.

I could go on more of a rant here, but suffice it to say I think we're missing a compelling rationale for why we need a workflow language. I commented as much on the Talk page.

On Wed, Sep 11, 2013 at 12:36 AM, Terry Chay <tchay@wikimedia.org> wrote:

Begin forwarded message:

From: Adam Wight <awight@wikimedia.org>
Subject: Rough draft of Workflow design
Date: September 10, 2013 5:11:56 PM PDT
To: Maryana Pinchuk <mpinchuk@wikimedia.org>, fr-tech <fr-tech@wikimedia.org>, Terry Chay <tchay@wikimedia.org>

I've outlined some thoughts about how to design a workflow engine, at

My main concern is that we produce something that is appropriate for general on-wiki use, and for Fundraising's internal needs.

Please review,

EE mailing list


EE mailing list

Maryana Pinchuk
Product Manager, Wikimedia Foundation