Skip to content
This repository was archived by the owner on Mar 22, 2022. It is now read-only.

Commit 2555949

Browse files
authored
Merge pull request #39 from chris-crone/rework-mds
Rework repository documentation
2 parents 4f1e64e + c7755ce commit 2555949

File tree

6 files changed

+178
-85
lines changed

6 files changed

+178
-85
lines changed

.github/CODEOWNERS

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,2 @@
1+
* @ndeloof
2+

CODE_OF_CONDUCT.md

Lines changed: 127 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,127 @@
1+
# Contributor Covenant Code of Conduct
2+
3+
## Our Pledge
4+
5+
We as members, contributors, and leaders pledge to make participation in our
6+
community a harassment-free experience for everyone, regardless of age, body
7+
size, visible or invisible disability, ethnicity, sex characteristics, gender
8+
identity and expression, level of experience, education, socio-economic status,
9+
nationality, personal appearance, race, religion, or sexual identity
10+
and orientation.
11+
12+
We pledge to act and interact in ways that contribute to an open, welcoming,
13+
diverse, inclusive, and healthy community.
14+
15+
## Our Standards
16+
17+
Examples of behavior that contributes to a positive environment for our
18+
community include:
19+
20+
* Demonstrating empathy and kindness toward other people
21+
* Being respectful of differing opinions, viewpoints, and experiences
22+
* Giving and gracefully accepting constructive feedback
23+
* Accepting responsibility and apologizing to those affected by our mistakes,
24+
and learning from the experience
25+
* Focusing on what is best not just for us as individuals, but for the
26+
overall community
27+
28+
Examples of unacceptable behavior include:
29+
30+
* The use of sexualized language or imagery, and sexual attention or
31+
advances of any kind
32+
* Trolling, insulting or derogatory comments, and personal or political attacks
33+
* Public or private harassment
34+
* Publishing others' private information, such as a physical or email
35+
address, without their explicit permission
36+
* Other conduct which could reasonably be considered inappropriate in a
37+
professional setting
38+
39+
## Enforcement Responsibilities
40+
41+
Community leaders are responsible for clarifying and enforcing our standards of
42+
acceptable behavior and will take appropriate and fair corrective action in
43+
response to any behavior that they deem inappropriate, threatening, offensive,
44+
or harmful.
45+
46+
Community leaders have the right and responsibility to remove, edit, or reject
47+
comments, commits, code, wiki edits, issues, and other contributions that are
48+
not aligned to this Code of Conduct, and will communicate reasons for moderation
49+
decisions when appropriate.
50+
51+
## Scope
52+
53+
This Code of Conduct applies within all community spaces, and also applies when
54+
an individual is officially representing the community in public spaces.
55+
Examples of representing our community include using an official e-mail address,
56+
posting via an official social media account, or acting as an appointed
57+
representative at an online or offline event.
58+
59+
## Enforcement
60+
61+
Instances of abusive, harassing, or otherwise unacceptable behavior may be
62+
reported to the community leaders.
63+
All complaints will be reviewed and investigated promptly and fairly.
64+
65+
All community leaders are obligated to respect the privacy and security of the
66+
reporter of any incident.
67+
68+
## Enforcement Guidelines
69+
70+
Community leaders will follow these Community Impact Guidelines in determining
71+
the consequences for any action they deem in violation of this Code of Conduct:
72+
73+
### 1. Correction
74+
75+
**Community Impact**: Use of inappropriate language or other behavior deemed
76+
unprofessional or unwelcome in the community.
77+
78+
**Consequence**: A private, written warning from community leaders, providing
79+
clarity around the nature of the violation and an explanation of why the
80+
behavior was inappropriate. A public apology may be requested.
81+
82+
### 2. Warning
83+
84+
**Community Impact**: A violation through a single incident or series
85+
of actions.
86+
87+
**Consequence**: A warning with consequences for continued behavior. No
88+
interaction with the people involved, including unsolicited interaction with
89+
those enforcing the Code of Conduct, for a specified period of time. This
90+
includes avoiding interactions in community spaces as well as external channels
91+
like social media. Violating these terms may lead to a temporary or
92+
permanent ban.
93+
94+
### 3. Temporary Ban
95+
96+
**Community Impact**: A serious violation of community standards, including
97+
sustained inappropriate behavior.
98+
99+
**Consequence**: A temporary ban from any sort of interaction or public
100+
communication with the community for a specified period of time. No public or
101+
private interaction with the people involved, including unsolicited interaction
102+
with those enforcing the Code of Conduct, is allowed during this period.
103+
Violating these terms may lead to a permanent ban.
104+
105+
### 4. Permanent Ban
106+
107+
**Community Impact**: Demonstrating a pattern of violation of community
108+
standards, including sustained inappropriate behavior, harassment of an
109+
individual, or aggression toward or disparagement of classes of individuals.
110+
111+
**Consequence**: A permanent ban from any sort of public interaction within
112+
the community.
113+
114+
## Attribution
115+
116+
This Code of Conduct is adapted from the [Contributor Covenant][homepage],
117+
version 2.0, available at
118+
https://www.contributor-covenant.org/version/2/0/code_of_conduct.html.
119+
120+
Community Impact Guidelines were inspired by [Mozilla's code of conduct
121+
enforcement ladder](https://github.com/mozilla/diversity).
122+
123+
[homepage]: https://www.contributor-covenant.org
124+
125+
For answers to common questions about this code of conduct, see the FAQ at
126+
https://www.contributor-covenant.org/faq. Translations are available at
127+
https://www.contributor-covenant.org/translations.

CONTRIBUTING.md

Lines changed: 40 additions & 35 deletions
Original file line numberDiff line numberDiff line change
@@ -3,56 +3,61 @@
33
Contributions should be made via pull requests. Pull requests will be reviewed
44
by one or more maintainers and merged when acceptable.
55

6-
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/).
7-
A developer should be able by reading the code:
8-
- to understand the main concept of the specification
9-
- have concrete examples to develop his own implementation.
10-
6+
The goal of the Compose Reference Implementation is to be a complete and simple
7+
implementation of the
8+
[Compose Specification](https://github.com/compose-spec/compose-spec/) that
9+
targets the [Docker API](https://docs.docker.com/engine/api/). Contributors
10+
using this code code should be able to:
11+
- use it as a test harness to experiment with Compose specification changes
12+
- understand the main concepts of the specification
13+
- see a concrete example of how to develop her/his own implementation
14+
1115
## Successful Changes
1216

13-
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
14-
[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.
15-
You can coordinate with the maintainers of the project before submitting large proposals
16-
or high impact PRs, this will prevent you from doing extra work that may or may not be merged.
17-
PRs that are just submitted without any prior communication will likely be summarily closed.
18-
19-
While pull requests are the methodology for submitting changes, changes are much more
20-
likely to be accepted if they are accompanied by a full justification of what developer
21-
problem you are solving. Often times, it helps to first state the problem before presenting
22-
solutions.
23-
24-
Typically, the best methods of accomplishing this are to submit an issue, stating the
25-
problem. This issue can include a problem statement and a checklist with requirements.
26-
If solutions are proposed, alternatives should be listed and eliminated. Even if the
27-
criteria for elimination of a solution is frivolous, say so.
28-
Larger changes typically work best with design documents, these are items which may
29-
change the scope or vision for Compose. These should be accompanied with a more detailed
30-
overview of the proposal, providing context to the justfication at the time the feature
31-
was conceived and can inform future documentation contributions.
17+
We ask that contributors read the [Compose
18+
Specification](https://github.com/compose-spec/compose-spec/blob/master/spec.md)
19+
and [Compose
20+
Vision](https://github.com/compose-spec/compose-spec/blob/master/VISION.md)
21+
to ensure that proposed changes are aligned with the objectives of the Compose
22+
project.
23+
24+
To help maintainers understand what user or developer problem needs to be
25+
solved, the first step to a contribution is usually submitting an issue. A well
26+
written issue is one that clearly outlines the developer or user problem that
27+
needs to be solved along with a list of requirements for resolution of the
28+
problem. If there are multiple possible solutions to the problem, these can be
29+
outlined in the issue. Once consensus is reached on how to resolve the issue, a
30+
pull request can be created.
31+
32+
Pull requests that propose minor changes or improvements may be submitted
33+
without an associated issue or discussion.
34+
35+
For large or high impact changes, contributors can reach out to maintainers
36+
before starting work. This will ensure that contributors and maintainers are
37+
aligned and increase the chance that the change is accepted.
3238

3339
## Commit Messages
3440

35-
There are times for one line commit messages and this is not one of them.
36-
Commit messages should follow best practices, including explaining the context
37-
of the problem and how it was solved, including in caveats or follow up changes
38-
required. They should tell the story of the change and provide readers
41+
Commit messages should follow best practices and explain the context of the
42+
problem and how it was solved-- including any caveats or follow up changes
43+
required. They should tell the story of the change and provide readers an
3944
understanding of what led to it.
4045

41-
If you're lost about what this even means, please see [How to Write a Git
42-
Commit Message](http://chris.beams.io/posts/git-commit/) for a start.
46+
[How to Write a Git Commit Message](http://chris.beams.io/posts/git-commit/)
47+
provides a good guide for how to do so.
4348

4449
In practice, the best approach to maintaining a nice commit message is to
4550
leverage a `git add -p` and `git commit --amend` to formulate a solid
46-
changeset. This allows one to piece together a change, as information becomes
51+
change set. This allows one to piece together a change, as information becomes
4752
available.
4853

4954
If you squash a series of commits, don't just submit that. Re-write the commit
5055
message, as if the series of commits was a single stroke of brilliance.
5156

52-
That said, there is no requirement to have a single commit for a PR, as long as
53-
each commit tells the story. For example, if there is a feature that requires a
54-
package, it might make sense to have the package in a separate commit then have
55-
a subsequent commit that uses it.
57+
That said, there is no requirement to have a single commit for a pull request,
58+
as long as each commit tells the story. For example, if there is a feature that
59+
requires a package, it might make sense to have the package in a separate commit
60+
then have a subsequent commit that uses it.
5661

5762
Remember, you're telling part of the story with the commit message. Don't make
5863
your chapter weird.

README.md

Lines changed: 9 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1,9 +1,14 @@
11
# Compose Specification Reference Implementation
2+
![Continuous integration](https://github.com/compose-spec/compose-ref/workflows/Continuous%20integration/badge.svg)
23

34
![logo](logo.png)
45

5-
This project host the reference implementation of the Compose specification. It is not designed for production use
6-
but to demonstrate implementation of Compose Specification on top of Docker API and offer a code base to experiment
7-
with changes being proposed to the Compose Specification.
6+
This repository hosts the reference implementation for the Compose
7+
specification. The purpose of this implementation is to provide a tool for
8+
Compose specification contributors to test changes to the specification and a
9+
code example for Compose specification implementers to understand how to
10+
implement the specification. It is not intended to be used 'as is' by end users
11+
or in production.
812

9-
![Continuous integration](https://github.com/compose-spec/compose-ref/workflows/Continuous%20integration/badge.svg)
13+
Before creating an issue or submitting a contribution, please read the
14+
[contributing guide](CONTRIBUTING.md).

SECURITY.md

Lines changed: 0 additions & 9 deletions
This file was deleted.

code-of-conduct.md

Lines changed: 0 additions & 37 deletions
This file was deleted.

0 commit comments

Comments
 (0)