TrueCloudLab/distribution
14
0
Fork 3
Code Issues 2 Pull requests Projects Releases 2 Packages Wiki Activity Actions

Initial open-design proposal

Browse source
This commit is contained in:
Olivier Gambier 2014-10-21 13:33:28 -07:00
parent e31b7d8d9a
commit 2b7b8fa2ca
2 changed files with 8 additions and 9 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

13
CONTRIBUTING.md
View file

@ -12,14 +12,14 @@ Please first try any of these support forums before opening an issue:
First check if your problem was already reported in the issue tracker. First check if your problem was already reported in the issue tracker.
If it's already there, please refrain from adding "same here" comments - these don't add any value and are only adding useless noise. **Said comments will quite often be deleted at sight**. On the other hand, if you have technical, relevant informations to add, by all means do! If it's already there, please refrain from adding "same here" comments - these don't add any value and are only adding useless noise. **Said comments will quite often be deleted at sight**. On the other hand, if you have any technical, relevant information to add, by all means do!
Your issue is not there? Then please, create a ticket. Your issue is not there? Then please, create a ticket.
If possible the following guidelines should be followed: If possible the following guidelines should be followed:
* try to come up with a minimal, simple to reproduce test-case * try to come up with a minimal, simple to reproduce test-case
* try to add a title that describe succintly the issue * try to add a title that describe succinctly the issue
* if you are running your own registry, please provide: * if you are running your own registry, please provide:
* registry version * registry version
* registry launch command used * registry launch command used
@ -29,7 +29,6 @@ If possible the following guidelines should be followed:
* `docker version` and `docker info` * `docker version` and `docker info`
* run your docker daemon in debug mode (-D), and provide docker daemon logs * run your docker daemon in debug mode (-D), and provide docker daemon logs
## You have a patch for a known bug, or a small correction? ## You have a patch for a known bug, or a small correction?
Basic github workflow (fork, patch, make sure the tests pass, PR). Basic github workflow (fork, patch, make sure the tests pass, PR).
@ -37,19 +36,19 @@ Basic github workflow (fork, patch, make sure the tests pass, PR).
... and some simple rules to ensure quick merge: ... and some simple rules to ensure quick merge:
* clearly point to the issue(s) you want to fix * clearly point to the issue(s) you want to fix
* when possible, prefer multiple (smaller) PRs adressing individual issues over a big one trying to adress multiple issues at once * when possible, prefer multiple (smaller) PRs addressing individual issues over a big one trying to address multiple issues at once
* if you need to amend your PR following comments, squash instead of adding more commits * if you need to amend your PR following comments, squash instead of adding more commits
## You want some shiny new feature to be added? ## You want some shiny new feature to be added?
Fork the project. Fork the project.
Create a new proposal in the folder open-design/specs, named DEP_MY_AWESOME_PROPOSAL.md, using open-design/specs/TEMPLATE.md as a starting point. Create a new proposal in the folder `open-design/specs`, named `DEP_MY_AWESOME_PROPOSAL.md`, using `open-design/specs/TEMPLATE.md` as a starting point.
Then immediately submit this new file as a pull-request, in order to get early feedback. Then immediately submit this new file as a pull-request, in order to get early feedback.
Eventually, you will have to update your proposal to accommodate with the feedback you received. Eventually, you will have to update your proposal to accommodate the feedback you received.
Usually, it's advised not to start working too much on the implementation itself before the proposal receives sufficient feedback, since it can significantly altered (or rejected). Usually, it's not advisable to start working too much on the implementation itself before the proposal receives sufficient feedback, since it can significantly altered (or rejected).
Your implementation should then be submitted as a separate PR, that will be reviewed as well. Your implementation should then be submitted as a separate PR, that will be reviewed as well.

2
open-design/ROADMAP.md
View file

@ -1,6 +1,6 @@
# Roadmap # Roadmap
## 24/11/2014: alpha ## 11/24/2014: alpha
Design and code: Design and code: