The Cloud Native Platform Engineering Working Group Community is a community of practitioners, vendors, and end-users who are interested in the practice of building and operating cloud native platforms. The community is focused on sharing knowledge, best practices, and tools to help organizations build and operate cloud native platforms effectively.
The community is open to anyone who is interested in cloud native platform engineering, regardless of their level of experience or expertise. The community is a place for practitioners to share their experiences, ask questions, and learn from each other.
This community is primarily focused on Cloud Native Platform Engineering and support of the practice within the CNCF ecosystem. The community is not focused on any specific technology or vendor, but rather on the practice of building and operating cloud native platforms.
Our members represent many diverse roles and personas, including:
- Platform consumers / end-users
- Platform developers, maintainers, and providers
- Internal service providers
- Project maintainers and contributors
- Specialists in other areas such as security, networking, storage, etc. who are interested in how their work fits into the platform engineering practice
For examples of Platform Personas see: [Platform as a Product: Understanding the Personas]({{< ref "/blog/paap-personas/" >}})
- Website:
- Staging site: https://cnpe.netlify.app/
- Production site (not yet deployed): https://www.cloudnativeplatforms.com/
- CNCF Community Page: TBD
- Slack channel: #platform-engineering in CNCF Slack
- Mailing list: TBD
- LinkedIn Page: https://www.linkedin.com/company/cloud-native-platforms/
Every two weeks on Tuesday at 11:00 ET (convert to your local time).
- Agenda and Notes: https://docs.google.com/document/d/1_smeS9-j-SuHJi0VXjx4g9xiD2-tgqhnlwf5oSMDQgg/edit#
- Meeting Link: TBD, please check announcments in the Slack channel.
- Recordings of previous meetings:
(in alphabetical order)
- Atulpriya Sharma (@techmaharaj)
- Colin Griffin (@krumware)
- Chris Plank (@ChrisPlank)
- Humble Devassy Chirammal (@humblec)
- Katie Greenley (@k8tgreenley)
In order to effectively support and manage the diverse needs of the community, we have established several committees. Each committee is responsible for specific areas of the community's activities and initiatives.
- TBD
- TBD
- Abby Bangser (@abangser)
- Josh Gavant (@joshgav)
See Artifacts for a list of key artifacts produced by the community. These include whitepapers, presentations, and other resources that are useful for practitioners and organizations looking to build and operate cloud native platforms.
When a whitepaper, glossary, or other versioned artifact is ready for release, follow this process to tag a new version while preserving document history in git.
-
Merge all draft changes into
latest/. Ensure thelatest/folder contains the final content for the version you want to tag. -
Create a folder for the new version. For example, if you are tagging
v2, create av2/folder alongsidelatest/. -
Move the file from
latest/to the new version folder usinggit mv. This preserves the file's commit history on the new version.git mv latest/index.md v2/index.md
-
Restore the
latest/file from the previous commit. This keepslatest/intact as the working copy for future edits.git checkout HEAD~1 -- latest/index.md
-
Update frontmatter in both files.
- In the new version file (e.g.
v2/index.md): update theurlto include the version (e.g.whitepapers/platforms/v2), settoc_hide: true, and mark the version asactivein theversionsblock. - In
latest/index.md: add the new version to theversionsblock.
- In the new version file (e.g.
-
Repeat for translations. Apply the same
git mvand restore steps to any translated versions of the artifact under the relevantcontent/{lang}/directories. -
Commit and push.
Why
git mvinstead ofcp? Usinggit mvfollowed by restoring the original ensures thatgit log --followtraces the full history of the tagged version file back through all prior edits. A simple copy would start the new file's history from scratch.
When adding a new page to the English site, create a translation stub in each language directory so that the page is accessible in all languages. Without a stub, translated versions of the site will return a 404 for the new page.
-
Create your new page under
website/content/en/as usual. -
For each supported language (
es,zh,ja,ko,fr,de), create a matching file with only frontmatter andoutdated: true:--- title: "Same title as the English page" outdated: true ---
For section pages (
_index.md), also includelist_pages: true. -
The
outdated: trueflag tells the site to display the English content with a "Translation Needed" banner, so you don't need to include any body content in the stub.
Translations are one of the most impactful ways to contribute. Here's how the translation workflow works:
-
Find a page to translate. Look for files with
outdated: trueand no body content underwebsite/content/{lang}/— these are stubs waiting for a translation. -
Replace the stub with your translated content. Keep the same frontmatter fields (especially
type,url, andversionsif present) but translate thetitleanddescription. Remove theoutdated: trueline. -
If the page has already been translated but the English version has been updated since, the file will have
outdated: truewith existing body content. Update the translation to match the current English version and removeoutdated: true. -
For adding a completely new language, open a localization issue and follow the checklist there.
The Community helps coordinate specific initiatives that are have benefits for the broader Platform Engineering community. Some of these initiatives are led by the Community, while others may exist under the CNCF Technical Advisory Groups (TAGs)