Rework CONTRIBUTING

Signed-off-by: Christopher Crone <christopher.crone@docker.com>

Author: chris-crone

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.