Merge pull request #38 from glours/awesome_compliance
Compliance with awesome repository requirementsmaster
Chris Crone
5 years ago
committed by
GitHub
commit
78d807cb84
@ -0,0 +1 @@
|
|||||||
|
* aiordache glours
|
||||||
@ -0,0 +1,103 @@
|
|||||||
|
# Contributing
|
||||||
|
|
||||||
|
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 Awesome Compose is to provide a curated list of application
|
||||||
|
samples that can be easily deployed with [Docker Compose](https://github.com/docker/compose).
|
||||||
|
|
||||||
|
## Missing an example?
|
||||||
|
|
||||||
|
You can request a new example of an application by submitting an issue to our GitHub repository.
|
||||||
|
|
||||||
|
Before submitting a new application, check if there isn't already application sample matching your need.
|
||||||
|
|
||||||
|
If there is one, consider updating it instead of creating a new one.
|
||||||
|
|
||||||
|
If you would like to submit a new application example, please start by submitting a proposal as an issue.
|
||||||
|
The maintainers will then use this issue to discuss what the the most valuable example for the application,
|
||||||
|
technology, language, or framework would be.
|
||||||
|
|
||||||
|
After the choice has been made, you can submit a pull request with the example remembering to:
|
||||||
|
- include an example README.md to describe the application and explain how to run/use the sample.
|
||||||
|
- edit the global README.md to add your sample in the repository main list.
|
||||||
|
|
||||||
|
## Commit Messages
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
[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
|
||||||
|
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 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.
|
||||||
|
|
||||||
|
## Sign your work
|
||||||
|
|
||||||
|
The sign-off is a simple line at the end of the explanation for the patch. Your
|
||||||
|
signature certifies that you wrote the patch or otherwise have the right to pass
|
||||||
|
it on as an open-source patch. The rules are pretty simple: if you can certify
|
||||||
|
the below (from [developercertificate.org](http://developercertificate.org/)):
|
||||||
|
|
||||||
|
```
|
||||||
|
Developer Certificate of Origin
|
||||||
|
Version 1.1
|
||||||
|
|
||||||
|
Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
|
||||||
|
660 York Street, Suite 102,
|
||||||
|
San Francisco, CA 94110 USA
|
||||||
|
|
||||||
|
Everyone is permitted to copy and distribute verbatim copies of this
|
||||||
|
license document, but changing it is not allowed.
|
||||||
|
|
||||||
|
Developer's Certificate of Origin 1.1
|
||||||
|
|
||||||
|
By making a contribution to this project, I certify that:
|
||||||
|
|
||||||
|
(a) The contribution was created in whole or in part by me and I
|
||||||
|
have the right to submit it under the open source license
|
||||||
|
indicated in the file; or
|
||||||
|
|
||||||
|
(b) The contribution is based upon previous work that, to the best
|
||||||
|
of my knowledge, is covered under an appropriate open source
|
||||||
|
license and I have the right under that license to submit that
|
||||||
|
work with modifications, whether created in whole or in part
|
||||||
|
by me, under the same open source license (unless I am
|
||||||
|
permitted to submit under a different license), as indicated
|
||||||
|
in the file; or
|
||||||
|
|
||||||
|
(c) The contribution was provided directly to me by some other
|
||||||
|
person who certified (a), (b) or (c) and I have not modified
|
||||||
|
it.
|
||||||
|
|
||||||
|
(d) I understand and agree that this project and the contribution
|
||||||
|
are public and that a record of the contribution (including all
|
||||||
|
personal information I submit with it, including my sign-off) is
|
||||||
|
maintained indefinitely and may be redistributed consistent with
|
||||||
|
this project or the open source license(s) involved.
|
||||||
|
```
|
||||||
|
|
||||||
|
Then you just add a line to every git commit message:
|
||||||
|
|
||||||
|
Signed-off-by: Joe Smith <joe.smith@email.com>
|
||||||
|
|
||||||
|
Use your real name (sorry, no pseudonyms or anonymous contributions.)
|
||||||
|
|
||||||
|
If you set your `user.name` and `user.email` git configs, you can sign your
|
||||||
|
commit automatically with `git commit -s`.
|
||||||
@ -0,0 +1,37 @@
|
|||||||
|
# Awesome Compose maintainers file
|
||||||
|
#
|
||||||
|
# This file describes who runs the docker/awesome-compose project and how.
|
||||||
|
# This is a living document - if you see something out of date or missing, speak up!
|
||||||
|
#
|
||||||
|
# It is structured to be consumable by both humans and programs.
|
||||||
|
# To extract its contents programmatically, use any TOML-compliant parser.
|
||||||
|
#
|
||||||
|
# This file is compiled into the MAINTAINERS file in docker/opensource.
|
||||||
|
#
|
||||||
|
[Org]
|
||||||
|
[Org."Core maintainers"]
|
||||||
|
people = [
|
||||||
|
"aiordache",
|
||||||
|
"glours"
|
||||||
|
]
|
||||||
|
[Org.Alumni]
|
||||||
|
people = [
|
||||||
|
]
|
||||||
|
|
||||||
|
[people]
|
||||||
|
|
||||||
|
# A reference list of all people associated with the project.
|
||||||
|
# All other sections should refer to people by their canonical key
|
||||||
|
# in the people section.
|
||||||
|
|
||||||
|
# ADD YOURSELF HERE IN ALPHABETICAL ORDER
|
||||||
|
|
||||||
|
[people.aiordache]
|
||||||
|
Name = "Anca iordache"
|
||||||
|
Email = "anca.iordache@docker.com"
|
||||||
|
GitHub = "aiordache"
|
||||||
|
|
||||||
|
[people.glours]
|
||||||
|
Name = "Guillaume Lours"
|
||||||
|
Email = "guillaume.lours@docker.com"
|
||||||
|
GitHub = "glours"
|
||||||
Loading…
Reference in New Issue