|
| 1 | +# Contributing |
| 2 | + |
| 3 | +## Guidelines |
| 4 | + |
| 5 | +Guidelines for contributing. |
| 6 | + |
| 7 | +### How can I get involved? |
| 8 | + |
| 9 | +We have a number of areas where we can accept contributions: |
| 10 | + |
| 11 | +* Work on [missing features and bugs](https://github.com/ewilde/faas-ecs/issues) |
| 12 | + |
| 13 | + |
| 14 | +### I've found a typo |
| 15 | + |
| 16 | +* A Pull Request is not necessary. Raise an [Issue](https://github.com/ewilde/faas-ecs/issues) and we'll fix it as soon as we can. |
| 17 | + |
| 18 | +### I have a (great) idea |
| 19 | + |
| 20 | +The maintainers would like to make faas-ecs the best it can be and welcome new contributions that align with the project's goals. |
| 21 | +Our time is limited so we'd like to make sure we agree on the proposed work before you spend time doing it. |
| 22 | +Saying "no" is hard which is why we'd rather say "yes" ahead of time. You need to raise a proposal. |
| 23 | + |
| 24 | +**Please do not raise a proposal after doing the work - this is counter to the spirit of the project. It is hard to be objective about something which has already been done** |
| 25 | + |
| 26 | +What makes a good proposal? |
| 27 | + |
| 28 | +* Brief summary including motivation/context |
| 29 | +* Any design changes |
| 30 | +* Pros + Cons |
| 31 | +* Effort required up front |
| 32 | +* Effort required for CI/CD, release, ongoing maintenance |
| 33 | +* Migration strategy / backwards-compatibility |
| 34 | +* Mock-up screenshots or examples of how the CLI would work |
| 35 | + |
| 36 | +If you are proposing a new tool or service please do due diligence. |
| 37 | +Does this tool already exist? Can we reuse it? For example: a timer / CRON-type scheduler for invoking functions. |
| 38 | + |
| 39 | +### Paperwork for Pull Requests |
| 40 | + |
| 41 | +Please read this whole guide and make sure you agree to our DCO agreement (included below): |
| 42 | + |
| 43 | +* See guidelines on commit messages (below) |
| 44 | +* Sign-off your commits |
| 45 | +* Complete the whole template for issues and pull requests |
| 46 | +* [Reference addressed issues](https://help.github.com/articles/closing-issues-using-keywords/) in the PR description & commit messages - use 'Fixes #IssueNo' |
| 47 | +* Always give instructions for testing |
| 48 | +* Provide us CLI commands and output or screenshots where you can |
| 49 | + |
| 50 | +### Commit messages |
| 51 | + |
| 52 | +The first line of the commit message is the *subject*, this should be followed by a blank line and then a message describing the intent and purpose of the commit. These guidelines are based upon a [post by Chris Beams](https://chris.beams.io/posts/git-commit/). |
| 53 | + |
| 54 | +* When you run `git commit` make sure you sign-off the commit by typing `git commit -s`. |
| 55 | +* The commit subject-line should start with an uppercase letter |
| 56 | +* The commit subject-line should not exceed 72 characters in length |
| 57 | +* The commit subject-line should not end with punctuation (., etc) |
| 58 | + |
| 59 | +When giving a commit body: |
| 60 | +* Leave a blank line after the subject-line |
| 61 | +* Make sure all lines are wrapped to 72 characters |
| 62 | + |
| 63 | +Here's an example: |
| 64 | + |
| 65 | +``` |
| 66 | +Add secrets to provider |
| 67 | +
|
| 68 | +We need to have the ability to pass secrets to faas-ecs securely. |
| 69 | +This commits adds secrets support using AWS Secrets Manager API. |
| 70 | +
|
| 71 | +Resolves #1 |
| 72 | +
|
| 73 | +Signed-off-by: Edward Wilde <[email protected]> |
| 74 | +``` |
| 75 | + |
| 76 | +If you would like to ammend your commit follow this guide: [Git: Rewriting History](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History) |
| 77 | + |
| 78 | +**Unit testing with Golang** |
| 79 | + |
| 80 | +Please follow style guide on [this blog post](https://blog.alexellis.io/golang-writing-unit-tests/) from [The Go Programming Language](https://www.amazon.co.uk/Programming-Language-Addison-Wesley-Professional-Computing/dp/0134190440) |
| 81 | + |
| 82 | +**I have a question, a suggestion or need help** |
| 83 | + |
| 84 | +Please raise an Issue. |
| 85 | + |
| 86 | +**I need to add a dependency** |
| 87 | + |
| 88 | +We use vendoring for projects written in Go. |
| 89 | +This means that we will maintain a copy of the source-code of dependencies within Git. |
| 90 | +It allows a repeatable build and isolates change. |
| 91 | + |
| 92 | +We use Golang's `dep` tool to manage dependencies for Golang projects - https://github.com/golang/dep |
| 93 | + |
| 94 | +## License |
| 95 | + |
| 96 | +This project is licensed under the MIT License. |
| 97 | + |
| 98 | +### Copyright notice |
| 99 | + |
| 100 | +Please add a Copyright notice to new files you add where this is not already present: |
| 101 | + |
| 102 | +``` |
| 103 | +// Copyright (c) Edward Wilde 2018. All rights reserved. |
| 104 | +// Licensed under the MIT license. See LICENSE file in the project root for full license information. |
| 105 | +``` |
| 106 | + |
| 107 | +### Sign your work |
| 108 | + |
| 109 | +> Note: all of the commits in your PR/Patch must be signed-off. |
| 110 | +
|
| 111 | +The sign-off is a simple line at the end of the explanation for a patch. Your |
| 112 | +signature certifies that you wrote the patch or otherwise have the right to pass |
| 113 | +it on as an open-source patch. The rules are pretty simple: if you can certify |
| 114 | +the below (from [developercertificate.org](http://developercertificate.org/)): |
| 115 | + |
| 116 | +``` |
| 117 | +Developer Certificate of Origin |
| 118 | +Version 1.1 |
| 119 | +
|
| 120 | +Copyright (C) 2004, 2006 The Linux Foundation and its contributors. |
| 121 | +1 Letterman Drive |
| 122 | +Suite D4700 |
| 123 | +San Francisco, CA, 94129 |
| 124 | +
|
| 125 | +Everyone is permitted to copy and distribute verbatim copies of this |
| 126 | +license document, but changing it is not allowed. |
| 127 | +
|
| 128 | +Developer's Certificate of Origin 1.1 |
| 129 | +
|
| 130 | +By making a contribution to this project, I certify that: |
| 131 | +
|
| 132 | +(a) The contribution was created in whole or in part by me and I |
| 133 | + have the right to submit it under the open source license |
| 134 | + indicated in the file; or |
| 135 | +
|
| 136 | +(b) The contribution is based upon previous work that, to the best |
| 137 | + of my knowledge, is covered under an appropriate open source |
| 138 | + license and I have the right under that license to submit that |
| 139 | + work with modifications, whether created in whole or in part |
| 140 | + by me, under the same open source license (unless I am |
| 141 | + permitted to submit under a different license), as indicated |
| 142 | + in the file; or |
| 143 | +
|
| 144 | +(c) The contribution was provided directly to me by some other |
| 145 | + person who certified (a), (b) or (c) and I have not modified |
| 146 | + it. |
| 147 | +
|
| 148 | +(d) I understand and agree that this project and the contribution |
| 149 | + are public and that a record of the contribution (including all |
| 150 | + personal information I submit with it, including my sign-off) is |
| 151 | + maintained indefinitely and may be redistributed consistent with |
| 152 | + this project or the open source license(s) involved. |
| 153 | +``` |
| 154 | + |
| 155 | +Then you just add a line to every git commit message: |
| 156 | + |
| 157 | + Signed-off-by: Joe Smith <[email protected]> |
| 158 | + |
| 159 | +Use your real name (sorry, no pseudonyms or anonymous contributions.) |
| 160 | + |
| 161 | +If you set your `user.name` and `user.email` git configs, you can sign your |
| 162 | +commit automatically with `git commit -s`. |
| 163 | + |
| 164 | +* Please sign your commits with `git commit -s` so that commits are traceable. |
| 165 | + |
| 166 | +If you forgot to sign your work and want to fix that, see the following guide: |
| 167 | +[Git: Rewriting History](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History) |
0 commit comments