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
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
Have you already made a list, or can you improve this one?
On Sep 11, 2013 10:20 AM, "Maryana Pinchuk" <mpinchuk(a)wikimedia.org>
+1 to Steven's skepticism. I also shared some more
concerns on the talk
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(a)wikimedia.org>wrote;wrote:
I added product designers (i.e. anyone making
software for users) as a
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(a)wikimedia.org> wrote:
Begin forwarded message:
*From: *Adam Wight <awight(a)wikimedia.org>
*Subject: **Rough draft of Workflow design*
*Date: *September 10, 2013 5:11:56 PM PDT
*To: *Maryana Pinchuk <mpinchuk(a)wikimedia.org>rg>, fr-tech <
fr-tech(a)wikimedia.org>gt;, Terry Chay <tchay(a)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.
EE mailing list
EE mailing list
Product Manager, Wikimedia Foundation