Topic on Talk:Collaboration/Workflows

Roan_Kattouw, Pginer-WMF, Quiddity (WMF) (bug? Flow rendered User:Quiddity (WMF) as a redlink when I wrote the post, rendered it as bluelink after saving, now I'm re-editing the post and it renders as a redlink again.)

I'm enthusiastic about the Workflow project, I believe the Community could greatly benefit from the Workflow project, I believe the Community could be enthusiastic about the Workflow project. However I'm concerned that the current, preliminary, plans for Workflow will not successfully meet the needs of the Community.

I had a discussion with the former project manager, asking if Workflows was going to support wikipages. The answer I got, as I understand it, was to equate Workflows with Flow itself, and that Workflows will be non-functional we would not be "served by the product" for any workflow that requires or favors wikipages. I said I think the Community will think the current project direction is wrong. He expressed doubt the various-wiki communities would have that view. One of the last things he did before leaving the project manager position was to invite me to go ahead with cross-wiki RfCs on the topic, if I felt the need.

What I'm hoping for here is one of three things:

1. A good explanation why Workflows shouldn't support wikipages, or
2. Agreement that wikipage support is a central Minimum Viable Product priority for Workflow,
3. If we don't concur on 1 or 2, I'm hoping for openness to WMF-Community engagement to discuss it. Note that I am not the Community, I'm one irrelevant person. I envision "WMF-Community engagement to discuss it" means a non-binding RfC, on at least the largest wiki, where a Community Consensus voice can weigh in on the project direction. I could just start an RfC myself, but (A) I don't feel I could present any reasonable case for the current project direction, and (B) my overarching goal is better WMF-Community discussion&collaboration itself. To quote Flow/Community engagement:

The relationship between the Wikimedia Foundation and the volunteer community shouldn't be about conflict, or about one side having dominance over the other; it should be collaborative. Both the community and the Foundation share a common goal – to grow and improve the sum of all human knowledge. When conflicts arise, the solution is to come to a consensus that brings us closer to that goal. In the past, we have spent too much time in conflict and not enough in collaboration. When staff and the community fail to work together, we don't just foster hostility and grudges; we all waste time, energy, and resources that could have been better spent improving Wikimedia projects. We're not going to promise that, from now on, everyone will always be in agreement on everything, but we will promise to learn from the past and experiment with new ways of doing things that offer us a shot at working together better and more efficiently.

and

What we've learnt so far... Bringing users into the conversation at the end of the development process makes it hard for their feedback to be incorporated. Ideas gather inertia, particularly when implemented, so it's hard to change course.

Pinging Roan_Kattouw, Pginer-WMF, Quiddity (WMF), It's been over a week.

Sorry for the delay. I do plan to reply properly, as soon as possible.

It's been over two and a half weeks here. In your opinion, is that reasonable? (And about seven weeks total since I originally asked on Danny's page and you indicated that community input was "not needed" and apparently not wanted.) It's extremely frustrating how everyone at the WMF consistently ignores or rejects all requests for WMF-Community engagement.

Should I just give up asking for WMF-Community engagement and just post RfC's with an empty sections for WMF participation?

You're asking a question that requires a lot of work/writing to answer (to a level of detail that would be satisfactory). There are a lot of ongoing tasks, and the team is currently missing a key member (PM). Plus flu/sickness season. Please, be patient for a little while longer?

Another week. Could you give me some idea what as soon as possible and a little longer mean? And some idea of what kind of response is in the works?

Regarding of detail that would be satisfactory:

• I don't think it takes a lot of detail to distinguish between two general directions. On one hand there's DannyH's editors will not be served if they find Flow-pages unsuitable for their work, and on the other hand a tool designed to support existing workflows and existing pages (which may also be compatible with Flow if&when editors do find Flow to be useful).
• I don't think it takes a lot of detail to determine if the WMF is welcoming or hostile to community-consensus input on project direction,what functionality is important for our needs, what functionality would be worthless or even negative-value for us. The WMF wouldn't have put pictures of penises and assholes on people's profile pages if they had considered the community a partner and simply asked us whether computer-generated profile pages were a good idea, and what sort of stuff did or did not belong on one.

Hi Alsee. Sorry again, for the delays. Essentially, the team is not working on Workflows right now, as the next quarterly goal focuses on interwiki notifications. There will definitely not be any development on software for workflows until after

1. a lot more research (into finer details of how the multitude of processes are technically accomplished on all the wikis nowadays, and into more details of the technical restrictions/possibilities with each direction that could be taken) and
2. a lot of discussions (based on the research, so that we can talk about details and not abstracts; and with many communities).

I'm currently putting together details for some new FAQ items, based on your questions and similar questions from others, and I commit to saving that here, in the second week of January. I'm hoping to get a lot more details on the technical aspects, from devs (staff and volunteer), in the first week.

One of the main technically complicated details is per-topic actions - from simple watchlisting/notifications, to more powerful/filterable feeds - which according to everything I've learned thus far, is not feasible in the standard ContentModel unless we were to mass-transclude every single section (i.e. hundreds of millions of transclusions), and create a network of bots to track page-moves/heading-changes. That's what I'm working on getting specific details about, from the various levels of dev (from database on up). HTH.

Thanx. I'm eager to see whatever is available whenever it's available. But IMO developing WMF-Community discussions is more important than any single project. I think one of the most important things is to enable WMF-Community dialog before stuff gets built. That's the key openness I'm hoping for. The Workflow project did surveys about our workflows so the WMF could figure out what to give us. Instead it would be nice if the WMF asked what we wanted.

At this point the concept is very vague, and we seem to have different ideas in mind. I'm not sure how ambitious the project plans to be but I found one of the WMF's sketches here: file:1-_Workflow_Pattern_Builder.jpg. That looks very promising, that could create a twinkle-like tool, and it could work perfectly well with existing pages. It could automate exactly what we already do.

Regarding a Flow-based concept, it's likely that EnWiki will be Flow-free very soon. All but two pages are either gone, or will be gone in some dozens of hours. Building a Flow-based-system isn't going to be very useful or popular when Flow deployment is running backwards.