diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index ca907f0..98bdcb7 100644 --- a/CONTRIBUTING.md +++ b/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.