diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS new file mode 100644 index 0000000..945e20f --- /dev/null +++ b/.github/CODEOWNERS @@ -0,0 +1,2 @@ +* @ndeloof + diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md new file mode 100644 index 0000000..4cdb52b --- /dev/null +++ b/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. 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. diff --git a/README.md b/README.md index 2ff998a..0001f24 100644 --- a/README.md +++ b/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) \ No newline at end of file +Before creating an issue or submitting a contribution, please read the +[contributing guide](CONTRIBUTING.md). diff --git a/SECURITY.md b/SECURITY.md deleted file mode 100644 index e2eef87..0000000 --- a/SECURITY.md +++ /dev/null @@ -1,9 +0,0 @@ -# Reporting security issues - -The Compse Reference Implementation maintainers take security seriously. If you discover a security issue, please bring it to their attention right away! - -### Reporting a Vulnerability - -Please **DO NOT** file a public issue, instead send your report privately to security@docker.com. - -Security reports are greatly appreciated and we will publicly thank you for it, although we keep your name confidential if you request it. We also like to send gifts—if you're into schwag, make sure to let us know. We currently do not offer a paid security bounty program, but are not ruling it out in the future. \ No newline at end of file diff --git a/code-of-conduct.md b/code-of-conduct.md deleted file mode 100644 index c480d66..0000000 --- a/code-of-conduct.md +++ /dev/null @@ -1,37 +0,0 @@ -## Compose Reference Implementation Code of Conduct -### Contributor Code of Conduct - -As contributors and maintainers of this project, and in the interest of fostering -an open and welcoming community, we pledge to respect all people who contribute -through reporting issues, posting feature requests, updating documentation, -submitting pull requests or patches, and other activities. - -We are committed to making participation in this project a harassment-free experience for -everyone, regardless of level of experience, gender, gender identity and expression, -sexual orientation, disability, personal appearance, body size, race, ethnicity, age, -religion, or nationality. - -Examples of unacceptable behavior by participants include: - -* The use of sexualized language or imagery -* Personal attacks -* Trolling or insulting/derogatory comments -* Public or private harassment -* Publishing others' private information, such as physical or electronic addresses, - without explicit permission -* Other unethical or unprofessional conduct. - -Project maintainers 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. By adopting this Code of Conduct, project maintainers -commit themselves to fairly and consistently applying these principles to every aspect -of managing this project. Project maintainers who do not follow or enforce the Code of -Conduct may be permanently removed from the project team. - -This code of conduct applies both within project spaces and in public spaces -when an individual is representing the project or its community. - -Instances of abusive, harassing, or otherwise unacceptable behavior in Compose Reference may be reported by contacting the project maintainer. - -This Code of Conduct is adapted from the [Contributor Covenant](http://contributor-covenant.org), -version 1.2.0, available at http://contributor-covenant.org/version/1/2/0/ \ No newline at end of file