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
Hi, I've outlined some thoughts about how to design a workflow engine, at https://www.mediawiki.org/wiki/RFC/Workflow
My main concern is that we produce something that is appropriate for general on-wiki use, and for Fundraising's internal needs.
Please review, Thanks! Adam
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
Hi, I've outlined some thoughts about how to design a workflow engine, at https://www.mediawiki.org/wiki/RFC/Workflow
My main concern is that we produce something that is appropriate for general on-wiki use, and for Fundraising's internal needs.
Please review, Thanks! Adam
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
+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.orgwrote:
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
Hi, I've outlined some thoughts about how to design a workflow engine, at https://www.mediawiki.org/wiki/RFC/Workflow
My main concern is that we produce something that is appropriate for general on-wiki use, and for Fundraising's internal needs.
Please review, Thanks! Adam
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
-- Steven Walling https://wikimediafoundation.org/
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
Yes, agreed - I think as we build out the discussion system to support different use cases, we should first look at the primary workflows we're actually solving for, and see what lightweight approaches to doing that could look like. For example, better tagging/discovery of discussions independent from the particular page they're associated with will likely make some existing workflows obsolete. I don't think that building a domain-specific language, or DSLL (no idea what that means), or something similar to describe the current mechanisms of doing things necessarily makes sense in light of the fact that those mechanisms were designed under the constraints of a page-based, free-form wikitext system.
Erik
If this is a real request for comment, you need to ask ALL of the stakeholders to comment.
--Tom
On Wed, Sep 11, 2013 at 1:38 PM, Erik Moeller erik@wikimedia.org wrote:
Yes, agreed - I think as we build out the discussion system to support different use cases, we should first look at the primary workflows we're actually solving for, and see what lightweight approaches to doing that could look like. For example, better tagging/discovery of discussions independent from the particular page they're associated with will likely make some existing workflows obsolete. I don't think that building a domain-specific language, or DSLL (no idea what that means), or something similar to describe the current mechanisms of doing things necessarily makes sense in light of the fact that those mechanisms were designed under the constraints of a page-based, free-form wikitext system.
Erik
Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
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?
-Adam
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.orgwrote:
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
Hi, I've outlined some thoughts about how to design a workflow engine, at https://www.mediawiki.org/wiki/RFC/Workflow
My main concern is that we produce something that is appropriate for general on-wiki use, and for Fundraising's internal needs.
Please review, Thanks! Adam
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
-- Steven Walling https://wikimediafoundation.org/
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
-- Maryana Pinchuk Product Manager, Wikimedia Foundation wikimediafoundation.org
On 09/11/2013 04:13 PM, Adam Wight wrote:
The goal of my RFC was to see if our requirements align with the onwiki administrative and discussion stuff.
As I mentioned on the talk page, I am strongly inclined to keep these requirements separate (regardless of whether the on-wiki version is implemented). See https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Workflow#Breaking_o... .
- After negotiating changes to process, a simple means to promote the
changes to actual usage.
This is one of the key things, along with a simple way to *use* the process, which I'll spell out below. Done right, it is easier than user scripts, templates, and bots. Done wrong, it is much harder.
----
* A simple way to use the process. E.g. a simple way to propose a merge, a simple way to nominate for deletion, a simple way to "close as delete", etc.
- 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...
As mentioned on the RFC talk page, we should carefully consider whether these new Workflows should even use templates (tags), or simply user-initiated processes (I want to propose a new name for a page, so I click "Propose rename") with behind-the-scenes states.
- Level the field, removing obstacles to people who are not
indoctrinated in admin culture or tech skills.
This is not impossible, but I'm skeptical. More likely, there will still be a "tech crowd" (maybe a little larger then the current tech crowd that works on wikitext and Lua templates, but probably not a *lot* larger).
This could still be worthwhile if it's easier for these people to implement process changes.
But we should also be sure to optimize for the people using the process (e.g the user who wants to rename a page using a Workflow).
Matt Flaschen