Merge remote-tracking branch 'origin/main' into features-update

Author: edgonmsft

README.md

@@ -12,12 +12,16 @@ The first format in the specification, devcontainer.json, was born out of necess
 
 Beyond repeatable setup, these same development containers provide consistency to avoid environment specific problems across developers and centralized build and test automation services. You can use the [open-source CLI reference implementation](https://github.com/devcontainers/cli) either directly or integrated into product experiences to use the structured metadata to deliver these benefits. It currently supports integrating with Docker Compose and a simplified, un-orchestrated single container option – so that they can be used as coding environments or for continuous integration and testing.
 
+A GitHub Action and an Azure DevOps Task are available in [devcontainers/ci](https://github.com/devcontainers/ci) for running a repository's dev container in continuous integration (CI) builds. This allows you to reuse the same setup that you are using for local development to also build and test your code in CI.
+
 ### Spec content
 
 You may review the specification in the [specs folder](https://github.com/devcontainers/spec/tree/main/docs/specs) of this repo.
 
 You may also review proposed references in the [proposals folder](https://github.com/devcontainers/spec/tree/main/proposals).
 
+Images used in this repo will be contained in the [images folder](/images). The icon for the [devcontainers org](https://github.com/devcontainers) is from the [Fluent icon library](https://github.com/microsoft/fluentui-system-icons/blob/master/assets/Cube/SVG/ic_fluent_cube_32_filled.svg).
+
 ## Contributing and Feedback
 
 If you are interested in contributing, please check out the [How to Contribute](contributing.md) document.

contributing.md

@@ -4,6 +4,7 @@ We're excited for your contributions to the dev container specification! This do
 
 ## 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](https://github.com/microsoft/dev-container-spec/issues) 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](https://aka.ms/devcontainer.json), which is a JSON with Comments (jsonc) format.
 
@@ -36,6 +37,9 @@ Tool-specific properties are contained in namespaces in the `"customizations"` p
 
 You may propose adding a new namespace for a specific tool, and any properties specific to that tool.
 
+### GitHub Discussions
+If you'd like to discuss the spec, such as asking questions, providing feedback, or engaging on how your team may use or contribute to dev containers, please check out the [GitHub Discussions](https://github.com/devcontainers/spec/discussions) in this repo. 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).
+
 ## Review process
 
 We use the following [labels](https://github.com/microsoft/dev-container-spec/labels):