github.com/rhatdan/storage@v1.12.13/CONTRIBUTING.md (about) 1 # Contributing to Containers/Storage 2 3 We'd love to have you join the community! Below summarizes the processes 4 that we follow. 5 6 ## Topics 7 8 * [Reporting Issues](#reporting-issues) 9 * [Submitting Pull Requests](#submitting-pull-requests) 10 * [Communications](#communications) 11 <!-- 12 * [Becoming a Maintainer](#becoming-a-maintainer) 13 --> 14 15 ## Reporting Issues 16 17 Before reporting an issue, check our backlog of 18 [open issues](https://github.com/containers/storage/issues) 19 to see if someone else has already reported it. If so, feel free to add 20 your scenario, or additional information, to the discussion. Or simply 21 "subscribe" to it to be notified when it is updated. 22 23 If you find a new issue with the project we'd love to hear about it! The most 24 important aspect of a bug report is that it includes enough information for 25 us to reproduce it. So, please include as much detail as possible and try 26 to remove the extra stuff that doesn't really relate to the issue itself. 27 The easier it is for us to reproduce it, the faster it'll be fixed! 28 29 Please don't include any private/sensitive information in your issue! 30 31 ## Submitting Pull Requests 32 33 No Pull Request (PR) is too small! Typos, additional comments in the code, 34 new testcases, bug fixes, new features, more documentation, ... it's all 35 welcome! 36 37 While bug fixes can first be identified via an "issue", that is not required. 38 It's ok to just open up a PR with the fix, but make sure you include the same 39 information you would have included in an issue - like how to reproduce it. 40 41 PRs for new features should include some background on what use cases the 42 new code is trying to address. When possible and when it makes sense, try to break-up 43 larger PRs into smaller ones - it's easier to review smaller 44 code changes. But only if those smaller ones make sense as stand-alone PRs. 45 46 Regardless of the type of PR, all PRs should include: 47 * well documented code changes 48 * additional testcases. Ideally, they should fail w/o your code change applied 49 * documentation changes 50 51 Squash your commits into logical pieces of work that might want to be reviewed 52 separate from the rest of the PRs. But, squashing down to just one commit is ok 53 too since in the end the entire PR will be reviewed anyway. When in doubt, 54 squash. 55 56 PRs that fix issues should include a reference like `Closes #XXXX` in the 57 commit message so that github will automatically close the referenced issue 58 when the PR is merged. 59 60 <!-- 61 All PRs require at least two LGTMs (Looks Good To Me) from maintainers. 62 --> 63 64 ### Sign your PRs 65 66 The sign-off is a line at the end of the explanation for the patch. Your 67 signature certifies that you wrote the patch or otherwise have the right to pass 68 it on as an open-source patch. The rules are simple: if you can certify 69 the below (from [developercertificate.org](http://developercertificate.org/)): 70 71 ``` 72 Developer Certificate of Origin 73 Version 1.1 74 75 Copyright (C) 2004, 2006 The Linux Foundation and its contributors. 76 660 York Street, Suite 102, 77 San Francisco, CA 94110 USA 78 79 Everyone is permitted to copy and distribute verbatim copies of this 80 license document, but changing it is not allowed. 81 82 Developer's Certificate of Origin 1.1 83 84 By making a contribution to this project, I certify that: 85 86 (a) The contribution was created in whole or in part by me and I 87 have the right to submit it under the open source license 88 indicated in the file; or 89 90 (b) The contribution is based upon previous work that, to the best 91 of my knowledge, is covered under an appropriate open source 92 license and I have the right under that license to submit that 93 work with modifications, whether created in whole or in part 94 by me, under the same open source license (unless I am 95 permitted to submit under a different license), as indicated 96 in the file; or 97 98 (c) The contribution was provided directly to me by some other 99 person who certified (a), (b) or (c) and I have not modified 100 it. 101 102 (d) I understand and agree that this project and the contribution 103 are public and that a record of the contribution (including all 104 personal information I submit with it, including my sign-off) is 105 maintained indefinitely and may be redistributed consistent with 106 this project or the open source license(s) involved. 107 ``` 108 109 Then you just add a line to every git commit message: 110 111 Signed-off-by: Joe Smith <joe.smith@email.com> 112 113 Use your real name (sorry, no pseudonyms or anonymous contributions.) 114 115 If you set your `user.name` and `user.email` git configs, you can sign your 116 commit automatically with `git commit -s`. 117 118 ## Communications 119 120 For general questions, or discussions, please use the 121 IRC group on `irc.freenode.net` called `container-projects` 122 that has been setup. 123 124 For discussions around issues/bugs and features, you can use the github 125 [issues](https://github.com/containers/storage/issues) 126 and 127 [PRs](https://github.com/containers/storage/pulls) 128 tracking system. 129 130 <!-- 131 ## Becoming a Maintainer 132 133 To become a maintainer you must first be nominated by an existing maintainer. 134 If a majority (>50%) of maintainers agree then the proposal is adopted and 135 you will be added to the list. 136 137 Removing a maintainer requires at least 75% of the remaining maintainers 138 approval, or if the person requests to be removed then it is automatic. 139 Normally, a maintainer will only be removed if they are considered to be 140 inactive for a long period of time or are viewed as disruptive to the community. 141 142 The current list of maintainers can be found in the 143 [MAINTAINERS](MAINTAINERS) file. 144 -->