Merge pull request #39 from chris-crone/rework-mds

Rework repository documentation

Author: chris-crone

.github/CODEOWNERS

@@ -0,0 +1,2 @@
+*   @ndeloof
+

CODE_OF_CONDUCT.md

@@ -0,0 +1,127 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+We as members, contributors, and leaders pledge to make participation in our
+community a harassment-free experience for everyone, regardless of age, body
+size, visible or invisible disability, ethnicity, sex characteristics, gender
+identity and expression, level of experience, education, socio-economic status,
+nationality, personal appearance, race, religion, or sexual identity
+and orientation.
+
+We pledge to act and interact in ways that contribute to an open, welcoming,
+diverse, inclusive, and healthy community.
+
+## Our Standards
+
+Examples of behavior that contributes to a positive environment for our
+community include:
+
+* Demonstrating empathy and kindness toward other people
+* Being respectful of differing opinions, viewpoints, and experiences
+* Giving and gracefully accepting constructive feedback
+* Accepting responsibility and apologizing to those affected by our mistakes,
+  and learning from the experience
+* Focusing on what is best not just for us as individuals, but for the
+  overall community
+
+Examples of unacceptable behavior include:
+
+* The use of sexualized language or imagery, and sexual attention or
+  advances of any kind
+* Trolling, insulting or derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or email
+  address, without their explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Enforcement Responsibilities
+
+Community leaders are responsible for clarifying and enforcing our standards of
+acceptable behavior and will take appropriate and fair corrective action in
+response to any behavior that they deem inappropriate, threatening, offensive,
+or harmful.
+
+Community leaders have the right and responsibility to remove, edit, or reject
+comments, commits, code, wiki edits, issues, and other contributions that are
+not aligned to this Code of Conduct, and will communicate reasons for moderation
+decisions when appropriate.
+
+## Scope
+
+This Code of Conduct applies within all community spaces, and also applies when
+an individual is officially representing the community in public spaces.
+Examples of representing our community include using an official e-mail address,
+posting via an official social media account, or acting as an appointed
+representative at an online or offline event.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported to the community leaders.
+All complaints will be reviewed and investigated promptly and fairly.
+
+All community leaders are obligated to respect the privacy and security of the
+reporter of any incident.
+
+## Enforcement Guidelines
+
+Community leaders will follow these Community Impact Guidelines in determining
+the consequences for any action they deem in violation of this Code of Conduct:
+
+### 1. Correction
+
+**Community Impact**: Use of inappropriate language or other behavior deemed
+unprofessional or unwelcome in the community.
+
+**Consequence**: A private, written warning from community leaders, providing
+clarity around the nature of the violation and an explanation of why the
+behavior was inappropriate. A public apology may be requested.
+
+### 2. Warning
+
+**Community Impact**: A violation through a single incident or series
+of actions.
+
+**Consequence**: A warning with consequences for continued behavior. No
+interaction with the people involved, including unsolicited interaction with
+those enforcing the Code of Conduct, for a specified period of time. This
+includes avoiding interactions in community spaces as well as external channels
+like social media. Violating these terms may lead to a temporary or
+permanent ban.
+
+### 3. Temporary Ban
+
+**Community Impact**: A serious violation of community standards, including
+sustained inappropriate behavior.
+
+**Consequence**: A temporary ban from any sort of interaction or public
+communication with the community for a specified period of time. No public or
+private interaction with the people involved, including unsolicited interaction
+with those enforcing the Code of Conduct, is allowed during this period.
+Violating these terms may lead to a permanent ban.
+
+### 4. Permanent Ban
+
+**Community Impact**: Demonstrating a pattern of violation of community
+standards, including sustained inappropriate behavior,  harassment of an
+individual, or aggression toward or disparagement of classes of individuals.
+
+**Consequence**: A permanent ban from any sort of public interaction within
+the community.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage],
+version 2.0, available at
+https://www.contributor-covenant.org/version/2/0/code_of_conduct.html.
+
+Community Impact Guidelines were inspired by [Mozilla's code of conduct
+enforcement ladder](https://github.com/mozilla/diversity).
+
+[homepage]: https://www.contributor-covenant.org
+
+For answers to common questions about this code of conduct, see the FAQ at
+https://www.contributor-covenant.org/faq. Translations are available at
+https://www.contributor-covenant.org/translations.

CONTRIBUTING.md

@@ -3,56 +3,61 @@
 Contributions should be made via pull requests. Pull requests will be reviewed
 by one or more maintainers and merged when acceptable.
 
-The goal of the Compose Reference Implementation is to be a complete and simple implementation of [the Compose Specification](https://github.com/compose-spec/compose-spec/).
-A developer should be able by reading the code: 
- - to understand the main concept of the specification 
- - have concrete examples to develop his own implementation.
-   
+The goal of the Compose Reference Implementation is to be a complete and simple
+implementation of the
+[Compose Specification](https://github.com/compose-spec/compose-spec/) that
+targets the [Docker API](https://docs.docker.com/engine/api/). Contributors
+using this code code should be able to:
+- use it as a test harness to experiment with Compose specification changes
+- understand the main concepts of the specification
+- see a concrete example of how to develop her/his own implementation
+
 ## Successful Changes
 
-We ask that before contributing, please make the effort to ensure you have read the [Compose Specification](https://github.com/compose-spec/compose-spec/blob/master/spec.md) and 
-[Compose Vision](https://github.com/compose-spec/compose-spec/blob/master/VISION.md) to ensure that your change is in keeping with the objectives of Compose. 
-You can coordinate with the maintainers of the project before submitting large proposals 
-or high impact PRs, this will prevent you from doing extra work that may or may not be merged.
-PRs that are just submitted without any prior communication will likely be summarily closed.
-
-While pull requests are the methodology for submitting changes, changes are much more 
-likely to be accepted if they are accompanied by a full justification of what developer 
-problem you are solving. Often times, it helps to first state the problem before presenting 
-solutions.
-
-Typically, the best methods of accomplishing this are to submit an issue, stating the 
-problem. This issue can include a problem statement and a checklist with requirements. 
-If solutions are proposed, alternatives should be listed and eliminated. Even if the 
-criteria for elimination of a solution is frivolous, say so.
-Larger changes typically work best with design documents, these are items which may 
-change the scope or vision for Compose. These should be accompanied with a more detailed 
-overview of the proposal, providing context to the justfication at the time the feature 
-was conceived and can inform future documentation contributions.
+We ask that contributors read the [Compose
+Specification](https://github.com/compose-spec/compose-spec/blob/master/spec.md)
+and [Compose
+Vision](https://github.com/compose-spec/compose-spec/blob/master/VISION.md)
+to ensure that proposed changes are aligned with the objectives of the Compose
+project.
+
+To help maintainers understand what user or developer problem needs to be
+solved, the first step to a contribution is usually submitting an issue. A well
+written issue is one that clearly outlines the developer or user problem that
+needs to be solved along with a list of requirements for resolution of the
+problem. If there are multiple possible solutions to the problem, these can be
+outlined in the issue. Once consensus is reached on how to resolve the issue, a
+pull request can be created.
+
+Pull requests that propose minor changes or improvements may be submitted
+without an associated issue or discussion.
+
+For large or high impact changes, contributors can reach out to maintainers
+before starting work. This will ensure that contributors and maintainers are
+aligned and increase the chance that the change is accepted.
 
 ## Commit Messages
 
-There are times for one line commit messages and this is not one of them.
-Commit messages should follow best practices, including explaining the context
-of the problem and how it was solved, including in caveats or follow up changes
-required. They should tell the story of the change and provide readers
+Commit messages should follow best practices and explain the context of the
+problem and how it was solved-- including any caveats or follow up changes
+required. They should tell the story of the change and provide readers an
 understanding of what led to it.
 
-If you're lost about what this even means, please see [How to Write a Git
-Commit Message](http://chris.beams.io/posts/git-commit/) for a start.
+[How to Write a Git Commit Message](http://chris.beams.io/posts/git-commit/)
+provides a good guide for how to do so.
 
 In practice, the best approach to maintaining a nice commit message is to
 leverage a `git add -p` and `git commit --amend` to formulate a solid
-changeset. This allows one to piece together a change, as information becomes
+change set. This allows one to piece together a change, as information becomes
 available.
 
 If you squash a series of commits, don't just submit that. Re-write the commit
 message, as if the series of commits was a single stroke of brilliance.
 
-That said, there is no requirement to have a single commit for a PR, as long as
-each commit tells the story. For example, if there is a feature that requires a
-package, it might make sense to have the package in a separate commit then have
-a subsequent commit that uses it.
+That said, there is no requirement to have a single commit for a pull request,
+as long as each commit tells the story. For example, if there is a feature that
+requires a package, it might make sense to have the package in a separate commit
+then have a subsequent commit that uses it.
 
 Remember, you're telling part of the story with the commit message. Don't make
 your chapter weird.

README.md

@@ -1,9 +1,14 @@
 # Compose Specification Reference Implementation
+![Continuous integration](https://github.com/compose-spec/compose-ref/workflows/Continuous%20integration/badge.svg)
 
 ![logo](logo.png)
 
-This project host the reference implementation of the Compose specification. It is not designed for production use
-but to demonstrate implementation of Compose Specification on top of Docker API and offer a code base to experiment
-with changes being proposed to the Compose Specification.
+This repository hosts the reference implementation for the Compose
+specification. The purpose of this implementation is to provide a tool for
+Compose specification contributors to test changes to the specification and a
+code example for Compose specification implementers to understand how to
+implement the specification. It is not intended to be used 'as is' by end users
+or in production.
 
-![Continuous integration](https://github.com/compose-spec/compose-ref/workflows/Continuous%20integration/badge.svg)
+Before creating an issue or submitting a contribution, please read the
+[contributing guide](CONTRIBUTING.md).