Topic on Talk:Structured Discussions

What are the acceptance criteria for Flow?

• Be as flexible and diverse as current talk pages
• Automatise signing
• Automatise indention

The first is a must, the other two are nice-to-have

Thanks. Is there any ability to add/remove acceptance criteria, or are they fixed? Are there any per-wiki/per-platform acceptance criteria, or are they all product-focussed?

You'll have to ask Danny Horn what the acceptance criteria are.

You have to ask the communities what the acceptance criteria are, they have to have the last word, not some bureaucrats in SF.

Flexibility is the trickiest bit. Flow refactoring discussions lags behind, as pointed out here and there.

If you have any other concerns you should

1. Raise them here, make sure it is filed as a bug.
2. Advocate for them to be fixed over the course of a few weeks and months, politely.
3. Put up a page at your local wiki suggesting which Flow changes you consider absolutely necessary, and blocking. Have community consensus on that.
4. On your wiki, find "how do I get involved?" pages and link to a Flow TODO there.

Bottom line, Wikimedia Engineering is only a small fraction of the userbase and people being involved in the development is a good thing. I feel all our sister projects underuse their sidebar - we should all have a "Develop for <sister project name here>" in the sidebar with a link to technical TODO. We should be whining about people getting involved in the development as much as we can as long as it is not annoying to the users.

Flow is meant to support various kinds of workflows, with the current basic "discussion workflow" being just one of them (others include actual collaborative work, voting and polling, etc.).

Probably the acceptance criteria at the level of the overall Flow software project should remain in WMF hands while those at the level of each workflow should be set by the communities.

One could even imagine that the criteria for a given workflow may be slightly different from one to another community... meaning Flow should support configurable workflows instead of rigid ones (and that's an acceptance criteria at the software project level).

Flow is meant to support various kinds of workflows, with the current basic "discussion workflow" being just one of them (others include actual collaborative work, voting and polling, etc.).

As all this has to be ready to have it deployed to real WP-lemma talk-pages (all this use-cases are possibly there at some time for any article), it's probably really some years from deployment in the real world. So far it's just fit for some users talk pages, who want them this restricted, and perhaps some external, thus not so important, wikis, that only need blah-blah talk-pages.