github.com/deis/workflow-e2e@v2.12.2-0.20180227201524-4105be7001fe+incompatible/CONTRIBUTING.md (about) 1 # How to Contribute 2 3 The Deis project is Apache 2.0 licensed and accepts contributions via Github pull 4 requests. This document outlines some of the conventions on commit message formatting, 5 contact points for developers and other resources to make getting your contribution 6 accepted. 7 8 # Certificate of Origin 9 10 By contributing to this project you agree to the 11 [Developer Certificate of Origin (DCO)][dco]. This document was created by the Linux 12 Kernel community and is a simple statement that you, as a contributor, have the legal 13 right to make the contribution. 14 15 # Support Channels 16 17 Before opening a new issue, it's helpful to search the project - it's likely that another user 18 has already reported the issue you're facing, or it's a known issue that we're already aware of. 19 20 Additionally, see the [Troubleshooting Deis][troubleshooting] documentation for common issues. 21 22 Our official support channels are: 23 24 - GitHub issues: https://github.com/deis/deis/issues/new 25 - IRC: #[deis](irc://irc.freenode.org:6667/#deis) IRC channel on freenode.org 26 27 ## Getting Started 28 29 - Fork the repository on GitHub 30 - Read [the documentation](http://docs.deis.io/en/latest/contributing/hacking/) for build instructions 31 32 ## Contribution Flow 33 34 This is a rough outline of what a contributor's workflow looks like: 35 36 - Create a topic branch from where you want to base your work. This is usually master. 37 - Make commits of logical units. 38 - Make sure your commit messages are in the proper format, see below 39 - Push your changes to a topic branch in your fork of the repository. 40 - Submit a pull request 41 42 Thanks for your contributions! 43 44 ### Design Documents 45 46 Most substantial changes to Deis should follow a [Design Document](http://docs.deis.io/en/latest/contributing/design-documents/) 47 describing the proposed changes and how they are tested and verified before they 48 are accepted into the project. 49 50 ### Commit Style Guideline 51 52 We follow a rough convention for commit messages borrowed from CoreOS, who borrowed theirs 53 from AngularJS. This is an example of a commit: 54 55 feat(scripts/test-cluster): add a cluster test command 56 57 this uses tmux to setup a test cluster that you can easily kill and 58 start for debugging. 59 60 To make it more formal, it looks something like this: 61 62 63 {type}({scope}): {subject} 64 <BLANK LINE> 65 {body} 66 <BLANK LINE> 67 {footer} 68 69 The {scope} can be anything specifying place of the commit change. 70 71 The {subject} needs to use imperative, present tense: “change”, not “changed” nor 72 “changes”. The first letter should not be capitalized, and there is no dot (.) at the end. 73 74 Just like the {subject}, the message {body} needs to be in the present tense, and includes 75 the motivation for the change, as well as a contrast with the previous behavior. The first 76 letter in a paragraph must be capitalized. 77 78 All breaking changes need to be mentioned in the {footer} with the description of the 79 change, the justification behind the change and any migration notes required. 80 81 Any line of the commit message cannot be longer than 72 characters, with the subject line 82 limited to 50 characters. This allows the message to be easier to read on github as well 83 as in various git tools. 84 85 The allowed {types} are as follows: 86 87 feat -> feature 88 fix -> bug fix 89 docs -> documentation 90 style -> formatting 91 ref -> refactoring code 92 test -> adding missing tests 93 chore -> maintenance 94 95 ### More Details on Commits 96 97 For more details see the [commit style guide][style-guide]. 98 99 [dco]: DCO 100 [style-guide]: http://docs.deis.io/en/latest/contributing/standards/#commit-style-guide 101 [troubleshooting]: http://docs.deis.io/en/latest/troubleshooting_deis/