|
| 1 | +# Contribution Guidelines |
| 2 | + |
| 3 | +## Introduction |
| 4 | + |
| 5 | +This document explains how to contribute changes to the Gitea |
| 6 | +project. It assumes you have followed the [installation |
| 7 | +instructions](https://github.com/go-gitea/docs/tree/master/en-US/installation) |
| 8 | + |
| 9 | +Sensitive security-related issues should be reported to |
| 10 | + |
| 11 | + |
| 12 | +## Bug reports |
| 13 | + |
| 14 | +Please search the issues on the issue tracker with a variety of keywords |
| 15 | +to ensure your bug is not already reported. |
| 16 | + |
| 17 | +If unique, [open an issue](https://github.com/go-gitea/gitea/issues/new) |
| 18 | +and answer the questions so we can understand and reproduce the |
| 19 | +problematic behavior. |
| 20 | + |
| 21 | +The burden is on you to convince us that it is actually a bug |
| 22 | +in Gitea. This is easiest to do when you write clear, concise |
| 23 | +instructions so we can reproduce the behavior (even if it seems |
| 24 | +obvious). The more detailed and specific you are, the faster |
| 25 | +we will be able to help you. Check out [How to Report Bugs |
| 26 | +Effectively](http://www.chiark.greenend.org.uk/~sgtatham/bugs.html). |
| 27 | + |
| 28 | +Please be kind, remember that Gitea comes at no cost to you, and you're |
| 29 | +getting free help. |
| 30 | + |
| 31 | +## Discuss your design |
| 32 | + |
| 33 | +The project welcomes submissions but please let everyone know what |
| 34 | +you're working on if you want to change or add something to the Gitea |
| 35 | +repositories. |
| 36 | + |
| 37 | +Before starting to write something new for the Gitea project, please |
| 38 | +[file an issue](https://github.com/go-gitea/gitea/issues/new). |
| 39 | +Significant changes must go through the [change proposal |
| 40 | +process](https://github.com/go-gitea/proposals) before they can be |
| 41 | +accepted. |
| 42 | + |
| 43 | +This process gives everyone a chance to validate the design, helps |
| 44 | +prevent duplication of effort, and ensures that the idea fits inside |
| 45 | +the goals for the project and tools. It also checks that the design is |
| 46 | +sound before code is written; the code review tool is not the place for |
| 47 | +high-level discussions. |
| 48 | + |
| 49 | +## Testing redux |
| 50 | + |
| 51 | +Before sending code out for review, run all the tests for the whole |
| 52 | +tree to make sure the changes don't break other usage and keep the |
| 53 | +compatibility on upgrade: |
| 54 | + |
| 55 | +After running for a while, the command should print |
| 56 | + |
| 57 | +``` |
| 58 | +ALL TESTS PASSED |
| 59 | +``` |
| 60 | + |
| 61 | +## Code review |
| 62 | + |
| 63 | +Changes to Gitea must be reviewed before they are accepted, no matter |
| 64 | +who makes the change even if an owners or a maintainer. We use github's |
| 65 | +pull request workflow to do that and use [lgtm](http://lgtm.co) to ensure |
| 66 | +every PR is reviewed by at least 2 maintainers. |
| 67 | + |
| 68 | +## Sign your work |
| 69 | + |
| 70 | +The sign-off is a simple line at the end of the explanation for the |
| 71 | +patch. Your signature certifies that you wrote the patch or otherwise |
| 72 | +have the right to pass it on as an open-source patch. The rules are |
| 73 | +pretty simple: If you can certify [DCO](DCO), then you just add a line |
| 74 | +to every git commit message: |
| 75 | + |
| 76 | +``` |
| 77 | +Signed-off-by: Joe Smith <[email protected]> |
| 78 | +``` |
| 79 | + |
| 80 | +Please use your real name, we really dislike pseudonyms or anonymous |
| 81 | +contributions. We are in the opensource world without secrets. If you |
| 82 | +set your `user.name` and `user.email` git configs, you can sign your |
| 83 | +commit automatically with `git commit -s`. |
| 84 | + |
| 85 | +## Contributors |
| 86 | + |
| 87 | +Everyone who sent a PR to Gitea that gets accepted will |
| 88 | +be as a contributor. Please send a PR to add your name to |
| 89 | +[CONTRIBUTORS](CONTRIBUTORS). For the format, see the |
| 90 | +[CONTRIBUTORS](CONTRIBUTORS). |
| 91 | + |
| 92 | +## Maintainers |
| 93 | + |
| 94 | +To make sure every PR have been checked, we make a team maintainers. Any |
| 95 | +PR MUST be reviewed and by at least two maintainers before it can |
| 96 | +get merged. Maintainers should be a contributor of gitea(or gogs) and |
| 97 | +contributed at least 4 accepted PRs. And a contributor should apply as a |
| 98 | +maintainer in [gitter Gitea develop](https://gitter.im/go-gitea/develop). |
| 99 | +And the owners or the team maintainer could invite the contributor. A |
| 100 | +maintainer should spend some time on code reviews. If some maintainer |
| 101 | +have no time to do that, he should apply to leave maintainers team and |
| 102 | +we will give him an honor to be as a member of advisor team. Of course, |
| 103 | +if an advisor have time to code view, welcome it back to maintainers team. |
| 104 | +If some one have no time to code view and forget to leave the maintainers, |
| 105 | +the owners have the power to move him from maintainers team to advisors |
| 106 | +team. |
| 107 | + |
| 108 | +## Owners |
| 109 | + |
| 110 | +Since Gitea is a pure community organization without any company |
| 111 | +support, to keep the development healthly We will elect the owners every |
| 112 | +year. Every time we will elect three owners. All the contributers could |
| 113 | +vote for three owners, one is the main owner, the other two are assistant |
| 114 | +owners. When the new owners have been elected, the old owners MUST move |
| 115 | +the power to the new owners. If some owner don't obey these rules, |
| 116 | +the other owners are allowed to revoke his owner status. |
| 117 | + |
| 118 | +After the election, the new owners should say he agrees with these |
| 119 | +rules on the [CONTRIBUTING](CONTRIBUTING.md) on the [Gitter Gitea |
| 120 | +Channel](https://gitter.im/go-gitea/gitea). Below is the word to speak |
| 121 | + |
| 122 | +``` |
| 123 | +I'm glad to be an owner of Gitea, |
| 124 | +I agree with [CONTRIBUTING](CONTRIBUTING.md). |
| 125 | +I will spend part of my time on gitea |
| 126 | +and lead the development of gitea. |
| 127 | +``` |
| 128 | + |
| 129 | +For a honor to the owners, this document will add the history owners |
| 130 | +below: |
| 131 | + |
| 132 | +2016-11-04 ~ 2017-12-31 |
| 133 | + |
| 134 | + |
| 135 | + |
| 136 | + |
| 137 | + |
| 138 | +## Versions |
| 139 | + |
| 140 | +Gitea has one master as a tip branch and have many version branch |
| 141 | +such as v0.9. v0.9 is a release branch and we will tag v0.9.0 both for |
| 142 | +binary download. If v0.9.0 have some bugs, we will accept PR on v0.9 |
| 143 | +and publish v0.9.1 and merge bug PR to master. |
| 144 | + |
| 145 | +Branch master is a tip version, so if you wish a production usage, |
| 146 | +please download the latest release tag version. All the branch will be |
| 147 | +protected via github, All the PRs to all the branches should be review |
| 148 | +by two maintainers and pass the automatic tests. |
| 149 | + |
| 150 | +## Copyright |
| 151 | + |
| 152 | +Code that you contribute should use the standard copyright header: |
| 153 | + |
| 154 | +``` |
| 155 | +// Copyright 2016 - 2017 The Gitea Authors. All rights reserved. |
| 156 | +// Use of this source code is governed by a MIT-style |
| 157 | +// license that can be found in the LICENSE file. |
| 158 | +``` |
| 159 | + |
| 160 | +Files in the repository are copyright the year they are added and the |
| 161 | +year they are last changed. If the copyright author is changed, just |
| 162 | +copy the head below the old one. |
0 commit comments