Proposal: Add White-Label Support to Enable Community Adaptation
Note: This proposal follows the accepted license change to CC BY 4.0 (#1).
Summary
I'd like to propose adding official white-label support to this repository, so that community members can more easily adapt Stack the Deck for their own platform engineering workshops — with different tooling contexts, languages, or organizational branding — while continuing to credit Syntasso as the originator.
Problem Statement
Currently, the repository provides the game assets in their final branded form (Syntasso name and Kratix product references embedded in SVG/PDF/card content).
This creates friction for community members who want to localize, translate, or tool-agnostify the game, and risks inconsistent or non-compliant adaptations in the wild.
Proposed Additions
1. WHITE-LABEL.md — Adaptation Guide
A concise guide covering:
- What to keep: The four platform principles, card categories (inputs, outputs, provisioning actions, process rules, interfaces, destinations), and board layout structure
- What to replace freely: Company name, product name (Kratix), logo, color scheme, and any tooling-specific card examples
- Attribution requirement: A ready-to-use attribution template, e.g.:
Adapted from "Stack the Deck" by Syntasso (https://github.com/syntasso/stack-the-deck), licensed under CC BY 4.0
- Where to place attribution: README, printed board back, inside the card PDF footer, or equivalent
2. Source file availability (if feasible)
If the SVG files were originally produced in a design tool, sharing the source project file (or a link to it) would significantly lower the barrier for community adaptation.
If source files are proprietary or unavailable, documenting the fonts and color values used in the SVGs would allow adapters to maintain visual consistency.
3. examples/ directory (optional but high-value)
A place for community-contributed adaptations — translated versions, tool-agnostic versions, etc. — similar to how CNCF projects maintain i18n/ directories. This would demonstrate the white-label model in practice and build community around the game format.
4. Attribution badge for README
A suggested badge or section format for derivative repositories:
[](https://github.com/syntasso/stack-the-deck)
This gives Syntasso ongoing visibility in any public fork.
My Specific Use Case
I am a platform engineering practitioner based in Japan (Red Hat Japan, CNCF Japan Chapter) and would like to create a Japanese-language, tool-agnostic adaptation of Stack the Deck for use in enterprise platform engineering workshops. Specifically:
- Translate all card text and board labels into Japanese
- Replace Kratix-specific terminology with vendor-neutral equivalents aligned with CNCF Platform Engineering community language
- Adapt example services on the cards to resonate with Japanese enterprise contexts
I would be happy to contribute the Japanese adaptation back to an examples/ directory if that structure is established.
Questions for Maintainers
- Would you be open to merging a
WHITE-LABEL.md contributed by the community (I am willing to draft a PR)?
- Are the SVG source files available in a design tool format, or can you share font/color specifications?
- Would an
examples/ or community/ directory for derivative adaptations be welcome?
Thank you again for building and open-sourcing this game format. The underlying design — mapping platform services to inputs, outputs, provisioning actions, and process rules — is one of the clearest frameworks I have seen for facilitating platform API design conversations, and I believe wider community adaptation will extend its impact well beyond the Kratix ecosystem.
Proposal: Add White-Label Support to Enable Community Adaptation
Summary
I'd like to propose adding official white-label support to this repository, so that community members can more easily adapt Stack the Deck for their own platform engineering workshops — with different tooling contexts, languages, or organizational branding — while continuing to credit Syntasso as the originator.
Problem Statement
Currently, the repository provides the game assets in their final branded form (Syntasso name and Kratix product references embedded in SVG/PDF/card content).
This creates friction for community members who want to localize, translate, or tool-agnostify the game, and risks inconsistent or non-compliant adaptations in the wild.
Proposed Additions
1.
WHITE-LABEL.md— Adaptation GuideA concise guide covering:
2. Source file availability (if feasible)
If the SVG files were originally produced in a design tool, sharing the source project file (or a link to it) would significantly lower the barrier for community adaptation.
If source files are proprietary or unavailable, documenting the fonts and color values used in the SVGs would allow adapters to maintain visual consistency.
3.
examples/directory (optional but high-value)A place for community-contributed adaptations — translated versions, tool-agnostic versions, etc. — similar to how CNCF projects maintain
i18n/directories. This would demonstrate the white-label model in practice and build community around the game format.4. Attribution badge for README
A suggested badge or section format for derivative repositories:
This gives Syntasso ongoing visibility in any public fork.
My Specific Use Case
I am a platform engineering practitioner based in Japan (Red Hat Japan, CNCF Japan Chapter) and would like to create a Japanese-language, tool-agnostic adaptation of Stack the Deck for use in enterprise platform engineering workshops. Specifically:
I would be happy to contribute the Japanese adaptation back to an
examples/directory if that structure is established.Questions for Maintainers
WHITE-LABEL.mdcontributed by the community (I am willing to draft a PR)?examples/orcommunity/directory for derivative adaptations be welcome?Thank you again for building and open-sourcing this game format. The underlying design — mapping platform services to inputs, outputs, provisioning actions, and process rules — is one of the clearest frameworks I have seen for facilitating platform API design conversations, and I believe wider community adaptation will extend its impact well beyond the Kratix ecosystem.