Fix #1127 - Rename to Open Workflow Specification#1155
Conversation
Signed-off-by: Ricardo Zanini <ricardozanini@gmail.com>
ca492e9 to
d637d2b
Compare
There was a problem hiding this comment.
Pull request overview
This PR implements the initial rebranding of the project documentation and supporting materials from “Serverless Workflow” to “Open Workflow”, as part of the rename effort tracked in #1127.
Changes:
- Updates project naming across core docs (README, governance, contributing, DSL docs) to “Open Workflow”.
- Updates examples/use-cases and community documentation to reflect the new branding.
- Adjusts a few metadata strings (e.g., CI validation package author) to match the new name.
Reviewed changes
Copilot reviewed 18 out of 18 changed files in this pull request and generated 10 comments.
Show a summary per file
| File | Description |
|---|---|
README.md |
Rebrands the project overview and ecosystem documentation to “Open Workflow”. |
dsl.md |
Rebrands the DSL document text to “Open Workflow DSL”. |
dsl-reference.md |
Rebrands the DSL reference text to “Open Workflow DSL”. |
schema/workflow.yaml |
Updates schema description branding to “Open Workflow DSL”. |
SECURITY.md |
Rebrands security policy text to “Open Workflow”. |
GOVERNANCE.md |
Rebrands governance wording and maintainer contact label. |
MAINTAINERS.md |
Rebrands maintainer headings to “Open Workflow”. |
contributing.md |
Rebrands contribution guide title and versioning wording. |
ctk/README.md |
Rebrands CTK documentation to “Open Workflow CTK”. |
examples/README.md |
Rebrands examples directory README to “Open Workflow”. |
comparison.md |
Rebrands comparison doc references and tables to “Open Workflow”. |
community/contributors.md |
Rebrands community contributors doc to “Open Workflow”. |
use-cases/README.md |
Rebrands use-cases overview to “Open Workflow”. |
use-cases/managing-github-issues/README.md |
Rebrands the use case narrative to “Open Workflow”. |
use-cases/multi-agent-ai-content-generation/README.md |
Rebrands the conclusion narrative to “Open Workflow”. |
adr/v1.0-adr-shared-workflow-editor.md |
Rebrands ADR references to “Open Workflow Specification”. |
adr/v1.0-adr-migration-tool.md |
Rebrands ADR references to “Open Workflow”. |
.ci/validation/package.json |
Updates the package author string to the new name. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Signed-off-by: Ricardo Zanini <ricardozanini@gmail.com>
Signed-off-by: Ricardo Zanini <ricardozanini@gmail.com>
|
FYI @riaankleinhans |
Signed-off-by: Ricardo Zanini <ricardozanini@gmail.com>
|
@ricardozanini I check and both openworkflow.io and openworkflow.org is not available. |
Signed-off-by: Ricardo Zanini <ricardozanini@gmail.com>
@riaankleinhans, let's follow up on slack! |
|
I'm strongly in favour of this change 🎉🎉🎉 |
| One key aspect of runtime expressions is their ability to adapt to runtime data and context. This means that expressions can access and manipulate data generated during the execution of a workflow, enabling dynamic decision-making and behavior based on real-time information. | ||
|
|
||
| Runtime expressions in Serverless Workflow can be evaluated using either the default `strict` mode or the `loose` mode. In `strict` mode, all expressions must be properly identified with `${}` syntax. Conversely, in `loose` mode, expressions are evaluated more liberally, allowing for a wider range of input formats. While `strict` mode ensures strict adherence to syntax rules, `loose` mode offers flexibility, allowing evaluation even if the syntax is not perfectly formed. | ||
| Runtime expressions in Open Workflow Specification can be evaluated using either the default `strict` mode or the `loose` mode. In `strict` mode, all expressions must be properly identified with `${}` syntax. Conversely, in `loose` mode, expressions are evaluated more liberally, allowing for a wider range of input formats. While `strict` mode ensures strict adherence to syntax rules, `loose` mode offers flexibility, allowing evaluation even if the syntax is not perfectly formed. |
| ``` | ||
|
|
||
| Serverless Workflow defines several default functions that **MUST** be supported by all implementations and runtimes: | ||
| Open Workflow Specification defines several default functions that **MUST** be supported by all implementations and runtimes: |
| ### System | ||
|
|
||
| The system is a GitHub-based issue management workflow designed to automate the lifecycle of an issue. It leverages Serverless Workflow (SW) DSL to handle various stages, from assignment and development to review and closure. | ||
| The system is a GitHub-based issue management workflow designed to automate the lifecycle of an issue. It leverages Open Workflow DSL to handle various stages, from assignment and development to review and closure. |
| ## Conclusion | ||
|
|
||
| This use case illustrates the powerful capabilities of Serverless Workflow in automating complex processes such as GitHub issue management. The workflow is flexible, scalable, and easy to maintain, making it an ideal choice for orchestrating tasks in modern development environments. By leveraging Serverless Workflow, teams can ensure efficient and consistent handling of issues, improving productivity and achieving better project outcomes. No newline at end of file | ||
| This use case illustrates the powerful capabilities of Open Workflow Specification in automating complex processes such as GitHub issue management. The workflow is flexible, scalable, and easy to maintain, making it an ideal choice for orchestrating tasks in modern development environments. By leveraging Open Workflow Specification, teams can ensure efficient and consistent handling of issues, improving productivity and achieving better project outcomes. No newline at end of file |
| ## Context | ||
|
|
||
| The Serverless Workflow specification has undergone a significant architectural redesign between versions 0.8/0.9 and 1.0.0. The 0.8/0.9 versions used a **state-based model** with explicit state machines and transitions, while version 1.0.0 introduces a fundamentally different **task-based model** with implicit flow control and declarative task composition. | ||
| The Open Workflow specification has undergone a significant architectural redesign between versions 0.8/0.9 and 1.0.0. The 0.8/0.9 versions used a **state-based model** with explicit state machines and transitions, while version 1.0.0 introduces a fundamentally different **task-based model** with implicit flow control and declarative task composition. |
| ## Licensing | ||
|
|
||
| - Apache 2.0 (consistent with Serverless Workflow specification) | ||
| - Apache 2.0 (consistent with Open Workflow specification) |
| ### Maintainers | ||
|
|
||
| - Initial maintainers from Serverless Workflow specification maintainers | ||
| - Initial maintainers from Open Workflow specification maintainers |
Please specify parts of this PR update:
Discussion or Issue link:
Fix #1127
What this PR does:
Just a renaming/rebranding change - the specification review will come in a follow-up PR.
Additional information:
Perhaps we should change from
Open WorkflowtoOpen Workflow Specificationtoo? I think it will be even clearer the name of the project since "Open Workflow" is just a broader term.