Voting starts in March for the Drupal Association Board election.
This issue is a continuation of the discussion started at. It may be beneficial to look there for history on this topic.
Currently Core effectively understands two workflow states: published and not published. This is insufficient for all but the most basic workflow implementations. While there have long been contrib modules which attempt to rectify this shortcoming, it would be far more powerful and efficient to build a foundation for workflow support into Drupal Core. A first-class CMS deserves first-class workflow support.
Implement support for defining an arbitrary number of workflows, each containing an arbitrary number of states. Allow each entity to be managed by a different workflow and each revision of an entity to be assigned a different state.
Out-of-the-box, Drupal would have one default workflow. This could be today's two-state workflow—"unpublished" and "published"—but there has been support for increasing this to a three-state workflow: "draft", "published" and "archived".
- Identify common needs of comprehensive workflow systems.
- Design and implement a workflow API in Core.
User interface changes
Much of the UI for managing states could easily be left to contrib to solve. If core moves to a three-state default workflow, then there will need to be some changes to the UI, differentiating between "draft" and "archived," both of which are unpublished.
This will mean the creation of a new API to manage workflows and their associated states. Existing code will also need to be changed to recognize states beyond published/not published. The precise changes required are still TBD.