Specification
How to contribute to the Development Container Specification
We’re excited for your contributions to the Dev Container Specification! This document outlines how you can get involved. We also welcome you to join our community Slack channel.
Spec Contribution approaches
If you’d like to contribute a change or addition to the spec, you may follow the guidance below:
- Propose the change via an issue in this repository. Try to get early feedback before spending too much effort formalizing it.
- More formally document the proposed change in terms of properties and their semantics. Look to format your proposal like our devcontainer.json reference.
Here is a sample:
| Property | Type | Description |
|---|---|---|
image |
string | Required when using an image. The name of an image in a container registry (DockerHub, GitHub Container Registry, Azure Container Registry) that VS Code and other devcontainer.json supporting services / tools should use to create the dev container. |
- PRs to the schema, i.e code or shell scripts demonstrating approaches for implementation.
Once there is discussion on your proposal, please also open and link a PR to update the devcontainer.json reference doc. When your proposal is merged, the docs will be kept up-to-date with the latest spec.
Contributing tool-specific support
Tool-specific properties are contained in namespaces in the "customizations" property. For instance, VS Code specific properties are formated as:
// Configure tool-specific properties.
"customizations": {
// Configure properties specific to VS Code.
"vscode": {
// Set *default* container specific settings.json values on container create.
"settings": {},
// Additional VS Code specific properties...
}
},
You may propose adding a new namespace for a specific tool, and any properties specific to that tool.
Formatting Guidelines
When contributing an official doc or referencing dev containers in your projects, please consider the following guidelines:
- Refer to the spec as the “Development Container Specification”
- All capital letters
- Singular “Container” rather than plural “Containers”
- The term “dev container” shouldn’t be capitalized on its own
- It should only be capitalized when referring to an official tool title, like the VS Code Dev Containers extension
- Signify
devcontainer.jsonis a file type through backticks - Features and Templates should always be capitalized
- Refer to the CLI as the “Dev Container CLI” (note the caps)
- Use bolding for emphasis sprinkled throughout sections, rather than try to use it to always bold certain terms
Review process
We use the following labels in the spec repo:
proposal: Issues under discussion, still collecting feedback.finalization: Proposals we intend to make part of the spec.
Milestones use a “month year” pattern (i.e. January 2022). If a finalized proposal is added to a milestone, it is intended to be merged during that milestone.
Community Engagement
There are several additional options to engage with the dev container community, such as asking questions, providing feedback, or engaging on how your team may use or contribute to dev containers:
- GitHub Discussions: This is a great opportunity to connect with the community and maintainers of this project, without the requirement of contributing a change to the actual spec (which we see more in issues and PRs)
- Community Slack channel: This is a great opportunity to connect with the community and maintainers
- You can always check out the issues and PRs (and contribute new ones) across the repos in the Dev Containers GitHub org too!
- Community collections: You can contribute your own Templates and Features to our community index!