WI: Workflows module roadmap

I think both #2830736: Add indication of where workflow is being used to workflow edit form and #2830737: Add link to workflow on bundle edit screen are redundant if #2843083: Select entity type / bundle in workflow settings is completed.

In https://www.drupal.org/core/experimental it is listed Workflows needs to be stable by 8.4.0, only giving it 6 months to become stable, rather than the usual 1 year.

I've done a scan over the issues tracked here and closed the ones I don't think are relevant. I've also added a few "could haves" based on the open issues I'm looking at as well.

Moving some of the priorities around.

Can we please add #2843785: EntityResource: Provide comprehensive test coverage for Workflow entity to the list of issues that must happen before this module can achieve beta-level stability? It's important to have that test coverage issue committed, to ensure the API-First support of Workflows does not change in the future, which would cause BC breaks. Thanks to this test coverage, we'd know when we regress!

Thankfully, @Sam152 beat me to it — he did just this in #13 :)

Given it's already RTBC, can't see a reason not to do this!

Also, updating target version to 8.4.

There are a few follow-ups to #2849827: Move workflow "settings" setters and getters to WorkflowTypeInterface which I think make sense to be in the must-have category, based on them being API clean-ups that are only possible as a result of the refactor. Will make sure the roadmap is updated with those once that gets in.

Forcing issue summary links to update.

Added the four follow ups to #2849827: Move workflow "settings" setters and getters to WorkflowTypeInterface to the issue summary. Those all represent BC breaking changes that would be great to address before stable.

@Sam152 - could these go in "should have"? I think they (and even #2849827: Move workflow "settings" setters and getters to WorkflowTypeInterface) could be done in a BC way, although I agree it'd be awesome to get them done in 8.4.x.

Based on #1977498: Add version tracking for configuration schema and data, I don't think we could do #2849827 in a BC fashion with any level of sanity.

The follow ups are probably in order of importance, I think if we can avoid shipping with a bunch of deprecated methods right out of the gate, that'd be awesome. If the big one gets in, I will be able to work on the follow-ups this week, in time for the deadline.

Updating link status in IS

Moving #2896722: Leverage PluginWithFormsInterface to encapsulate @WorkflowType schema and clean up state/transition form methods. to "should have". I think it's going to take some work and discussion to get right. Hopefully there is a BC way to do that , possibly make WorkflowTypeFormInterface @internal in the meantime?

Added the "WI critical" tag to the follow-up BC breaks which look like they'll get committed quickly anyway.

I think we should add #2896722: Leverage PluginWithFormsInterface to encapsulate @WorkflowType schema and clean up state/transition form methods. to the must-haves, as it represents a major API change. Patch coming soon.

#2896722: Leverage PluginWithFormsInterface to encapsulate @WorkflowType schema and clean up state/transition form methods. is most must-have and should-have ATM.

Yep, down to one now #2896722: Leverage PluginWithFormsInterface to encapsulate @WorkflowType schema and clean up state/transition form methods.

All the dependencies are done, Workflows can now be marked stable!

#2897130: Mark workflows module as stable

Yaah! this is looking happy:

So to mark a module stable, we need:

1. Completion of all must-haves and most should-haves. Here are the outstanding should-haves:
   • #2830584: Use modals for creating, updating, and deleting workflows, with a new DialogFormTrait -- an architectural improvement that has an alpha/beta deadline but can go in 8.5.x is necessary
   • #2758623: [meta] Redesign workflow configuration page to better visually describe the flow -- a big UI discussion that (if the product team agrees) can simply be approached as a stable feature improvement for 8.5.x.
2. Frontend and backend architectural review/signoff of the final code (I think this is especially important given the scope of rework the module just underwent
3. Review of all the core gates (usability, accessibility, testing, performance, and documentation)
4. Signoffs from key stakeholders (afftected subsystems, the module authors, affected contrib, committers, Dries

We are definitely ready for the module to be beta (I did so now in https://www.drupal.org/core/experimental), but before we mark it stable, we need to do some final review of the module overall. I reached out to Wim Leers and @tim.plunkett since they work on subsystems implemented here.

On the docs gate, https://www.drupal.org/docs/8/core/modules/workflows/overview is looking a teeny bit thin. I suggest a must-have issue for someone to work on it.

Uupdating the roadmap Thanks @Sam152!

To help the docs gate I've updated the docs: https://www.drupal.org/docs/8/core/modules/workflows/overview

There's little to document, because from a site builders point of view Workflows does nothing on it's own.

Moving #2758623: [meta] Redesign workflow configuration page to better visually describe the flow to "could have". It's clearly a nice-to-have improvement that can be done in a later release and should not block a stable release.

Hm, I'm not sure about moving #2758623: [meta] Redesign workflow configuration page to better visually describe the flow to "Could have". It's clearly a high priority for usability. It could certainly be a feature addition in 8.5.x and as a "Should have" it's already not a blocker. Let's check with the product managers before making that change.

I understood this as being the roadmap for stability and thus these are the "must have" "should have" and "could have" issues for a stable release.

The #2758623: [meta] Redesign workflow configuration page to better visually describe the flow issue is refinements from the original designs in #2830584: Use modals for creating, updating, and deleting workflows, with a new DialogFormTrait, and doesn't affect data or backwards compatibility, so I can't see there being any issues with this going in after Workflows is maked stable in 8.4.0

"Beta" is the threshold that indicates BC and API stability. "Stable", however, means "production-ready", and that the overall user experience of the module meets with product expectations. I agree it would be totally fine for a feature like #2758623: [meta] Redesign workflow configuration page to better visually describe the flow to be added in 8.5.x if Workflows is stable in 8.4.x, from a BC perspective. However, it's up to the product and usability teams to decide whether the module is production-ready without it.

So for now, I've moved #2758623: [meta] Redesign workflow configuration page to better visually describe the flow back to "Should" with a note. I personally would be totally fine with this advanced design work happening for 8.5.x+, but let's get input from the UX and product maintainers first.

ok, so leaving that one off the table for now, the remaining "should have" is #2830584: Use modals for creating, updating, and deleting workflows, with a new DialogFormTrait which has just been round a few rounds of nit picks.

IIRC @yoroy is on vacation, so we're kinda dependent on @Bojhan for UX review, then product maintainer review, but hope you agree, Workflows is looking pretty good for stable in 8.4.0.

Then Content Moderation, I know it has it's own roadmap issue (#2755073: WI: Content Moderation module roadmap) but to summarise. There are 4 remaining should haves

• #2873287: Dispatch events for changing content moderation states which has a good patch, but waiting on #2881645: ContentModerationState 'workflow' column empty for all non-default translations. which is already RTBC.
• #2862041: Provide useful Views filters for Content Moderation State fields which has a good patch too, but waiting on #2896381: "TranslationLanguageRenderer" uses the wrong table for the "langcode" column with entity revision views which is also RTBC.
• "Usability test of entire feature since it’s a 90% feature. This will likely uncover all kinds of other things (e.g. does the tabs pattern work, vs. the yellow box thing in D7?)." never had an issue created, if we're talking physical in person usability testing, then I hope it can be pushed to 8.5.x.
• #2890380: Remove descriptions of permissions in Content Moderation came from a text bullet point here, so created an issue a few weeks ago, not sure what the background is, assume consistency with other permissions, but it's RTBC.

So I think Content Moderation is looking good for stable too.

We had a product management meeting a couple of weeks back, and unfortunately looks like we forgot to comment back here. Sorry!

From our POV, the Workflow team has been doing great work on addressing the remaining known usability concerns. The biggest remaining one here was the dropbutton -> select box + button change, and that just went in recently.

The team has also been on numerous of the weekly usability meetings, showing off their work periodically and requesting guidance along the way. Their code is also in production in a large enterprise organization. While the two of these are not "usability testing" in the dictionary definition sense, they certainly work to help build confidence in the solutions being developed.

So given those factors, as well as the discussion the other week with the product management team being gung-ho to get this into 8.4.0 as stable functionality, marking this as signed off from a product management perspective. We can continue to iterate on the UI in later releases, as needed.

GO, TEAM! :D

Woohoo.

Personally, I agree that #2758623: [meta] Redesign workflow configuration page to better visually describe the flow is a could-have. We don't have any precedence for features like that.

Thanks @larowlan.
=
I've filed #2899553: Architectural review of the Workflows module (documentation cleanups) as a catch-all for overall issues, pinged a few people that aan help, and added them here.

Many thanks @webchick for #44, I was mostly worried about accidentally skipping over product needs that hadn't quite been raised to "must-have", but it looks like the product team is comfortable with all of them being in later releases. Since yoroy is on vacation, that means removing the "usability review tag on his behalf. (Hopefully that's okay and he'll correct it if it's still a concern for the module overall.

I also added an explicit issue for the architectural review issue to ensue the signoff from framework and subsystem maintainer, or get ideas for future issues: #2899553: Architectural review of the Workflows module (documentation cleanups)

FInally, I looked at the remaining open WI Critical issues. These are:

1. #2893888: Content moderation state entity field data not removed when the host field data is moderation bug of the "stale data" data integrity sort of problem
2. #2898913: Review a11y concerns in ContentModerationConfigureForm our review for that core gate
3. The postponed #2862041: Provide useful Views filters for Content Moderation State fields which I assume will be simply be a targeted feature as a feature for 8.5.x+.
4. #2899553: Architectural review of the Workflows module (documentation cleanups) our new issue :)

Including the above, we are adding:

• 4 major bugs. The two not yet listed above are #2897148: Remove @internal from workflowHasData/workflowStateHasData and use those methods for access control and configuration validation. and #2896726: Expand the entity access model for workflow states and transitions.
• 10 normal issues: https://www.drupal.org/project/issues/search/drupal?project_issue_follow...

Here's all information to take into account when marking it stable. :)

@xjm - #2862041: Provide useful Views filters for Content Moderation State fields is waiting on #2896381: "TranslationLanguageRenderer" uses the wrong table for the "langcode" column with entity revision views which is also RTBC. They both should be possible for 8.4.0.

Adding some clarifications/notes to the issues linked above.

Re: #2862041, this is currently only blocked by an RTBC views issue. It would be great to get this in.

Edit: beat me to it :)

@timmillwood and @Sam152, that's great to hear! So hopefully a matter of committing the one and then the other once it's ready. Are they both specifically Conent Moderation vs. Workflow issues? (I just looked at the tag.) If so, if the Views one is still a critical, then let's move it up on the other roadmap appropriately and also include the link the issue blocking it there.

Added the four must-haves from the architectural review to the roadmap.

As well as the parent issue.

The top link to https://www.drupal.org/project/workflows in "The proposal here is to add a Workflows experimental module into core." does not work.

To be honest, I spend hours today trying to figure out what the status is and where to find what. It still dazzles me in terms of Workflow(s), Workbench, Content Moderation, Workspaces etc.

Main confusion is the https://www.drupal.org/project/workflow project that is not the Workflow Initiative.
Than here it is: https://www.drupal.org/docs/8/core/modules/workflows/overview except the module is called Content Moderation.

So for a visitor of Drupal there are 4 separate initiatives that are not easy to figure out:

- Workflow
- Workflows (Workflow Initiative) or Content Moderation
- Workbench
- Workspace (part of Workflow Initiative)

Some are linked, for example since Drupal 8.2.x the Workbench Moderation module is now in core as "Content Moderation".

Maybe an idea is to always include the 's' for Workflows Initiative? Now that things are more clear I will continue my search what to use in Open Social; Workflows or Workbench.

Thanks for all your hard work :)!!

I think the most up to date status for all the issues will now be the normal queues.

A better status for this issue is "Closed (fixed)", which will happen in about two weeks after this comment :)