I see that the Workflows page has not been updated for about eight months. Is there any progress on this project?
I'm also interested to know if there there are any plans to move forward on this in the foreseeable future.
For what it's worth, my impression is that this seems to be inactive with no specific plans at the moment. The 2016 Strategy Community consultation asked about interest in working on tools for the community, and the result was "medium", behind some other priorities. The final report on it is currently a redlink, but it's supposed to show up at Critical question synthesis (2016) when it's done. Presumably that will state whether these tools are or are-not planned to be an active priority this year.
Hi, I've updated the page now. Thanks for the reminder and sorry for the delays in both replying and in updating. The team is currently planning some of the goals for both the upcoming quarter and year ahead, with a focus on research on and improvements to some of the edit review workflows. Workflows as a whole, is so important and so complex, that it is best to go as slowly and thoroughly as possible with the resources available. We do hope to resume work on this broader goal, when community interest increases and when resources are available. Thanks again.
Thank you for that. This is of course an extremely complex question and will require a very great deal of research to scope out the very ambitious system that you ultimately want to build. The fact that only a limited amount of preliminary investigation has been done, that as far as I can tell no further research is in train, and that you are moving slowly (your word not mine) towards a limited and very partial goal suggest to me that this project is not being undertaken in a way that can possibly lead to success. Workflows based on wikitext and wikitext editor are evolving, and will evolve, faster than you can capture them at this rate. If you are not prepared to invest the time effort and money required to succeed, then I earnestly suggest that you drop the ambition now. Your current approach will consume resources for no measurable benefit.
Workflow wikipage support
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:
- A good explanation why Workflows shouldn't support wikipages, or
- Agreement that wikipage support is a central Minimum Viable Product priority for Workflow,
- 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.
- 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.
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
- 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
- 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.
Looking forward to this!
It's been several months since Wikimania, but I just wanted to come here and say that your introduction of the 'Workflows' project in Mexico was a personal highlight. Not only do I agree that giving these kinds of community-created processes (that have arisen organically to fill the needs of the project) some design and software-development attention would make them easier to participate in, but I believe it will also have important flow-on effects...
- Simplifying the procedures required to maintain workflows like AfD on english Wikipedia will help decrease the bureaucratic workload on those people who undertake those tasks. This will reduce stress in general and also enable those people to be more efficient with their time. They are key people for the community's health after-all.
- Making the processes themselves easier to understand and interact with, will decrease their 'intimidation factor' and increase the number of people who are willing to contribute to the discussions themselves. By definition this will also increase the diversity of people contributing and the diversity of their views.
What I'm trying to say is that I think this project, if successful, would have a very real and important impact on broader issues like the gender-gap and declining retention-rates. The current systems have evolved by, and for, the people who use them most. Consequently they reinforce the ability of the existing community who are comfortable with those processes to express their opinions, and unintentionally marginalise newer community members or those who simply couldn't be bothered to work out how to transclude a template etc. I'm not saying that the existing system is designed with malicious intent or to be deliberately confusing - and I think that's where the tone of the presentation at Wikimania went a bit wrong because it made the existing workflow-operators feel like they were being attacked - but I am saying that the existing workflows create a reinforcing cycle of 'in-group' consensus.
So - I'm looking forward to the progress of the Workflow project and would love to help wherever I can.