It's to be defined if we use the wording of "schemas" within OpenProject. The goal is to address the need users have. The concept for schemas in general need to be defined first.
Main goals:
* Types can have sub-types. Deliver a concept in OpenProject that mirrors the core functionality of Jira Data Center's Workflow Schemes
* Sub types either define own settings or inherit settings from the parent type.
Allow administrators to create, manage, and assign workflow schemes across projects
* Workflows
Ensure that different work package types within a project can follow different workflows
* Screen Reduce repetitive manual configuration
when setting up new projects
* Automations
Support large-scale enterprise deployments with hundreds of projects
* Notification
Concept must be flexible supporting various organizational cultures (centralized and federated structures)
* In case a setting is changed for admins need the parent type this setting is applied possibility to all sub-types that inherit this setting from the parent.
* Sub type is added to the Type indicator, for example:
* `Bug` say if a schema can be overwritten by a project admin or not
* `Bug: Hardware`
* `Bug: Software`
* There is if a new schema was overwritten by a project permission that allows to create and manage sub-types admin it cannot be updated via the global schema anymore (TBC)