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(a)wikimedia.org> wrote: -- Steven Walling https://wikimediafoundation.org/

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

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(a)wikimedia.org> wrote: