|
| 1 | +# Contributing to Saturn |
| 2 | + |
| 3 | +Please take a moment to review this document in order to make the contribution |
| 4 | +process easy and effective for everyone involved! |
| 5 | + |
| 6 | +## Using the issue tracker |
| 7 | + |
| 8 | +Use the issues tracker for: |
| 9 | + |
| 10 | +* [bug reports](#bug-reports) |
| 11 | +* [feature requests](#feature-requests) |
| 12 | +* [submitting pull requests](#pull-requests) |
| 13 | + |
| 14 | +Please **do not** use the issue tracker for personal or commercial support requests. |
| 15 | + |
| 16 | +## Bug reports |
| 17 | + |
| 18 | +A bug is either a _demonstrable problem_ that is caused by the code in the repository, |
| 19 | +or indicate missing, unclear, or misleading documentation. Good bug reports are extremely |
| 20 | +helpful - thank you! |
| 21 | + |
| 22 | +Guidelines for bug reports: |
| 23 | + |
| 24 | +1. **Use the GitHub issue search** — check if the issue has already been |
| 25 | + reported. |
| 26 | + |
| 27 | +2. **Check if the issue has been fixed** — try to reproduce it using the |
| 28 | + `master` branch in the repository. |
| 29 | + |
| 30 | +3. **Isolate and report the problem** — ideally create a reduced test |
| 31 | + case. |
| 32 | + |
| 33 | +Please try to be as detailed as possible in your report. Include information about |
| 34 | +your Operating System, as well as your `dotnet` (or `mono` \ .Net Framework), F# and project versions. Please provide steps to |
| 35 | +reproduce the issue as well as the outcome you were expecting! All these details |
| 36 | +will help developers to fix any potential bugs. |
| 37 | + |
| 38 | +Example: |
| 39 | + |
| 40 | +> Short and descriptive example bug report title |
| 41 | +> |
| 42 | +> A summary of the issue and the environment in which it occurs. If suitable, |
| 43 | +> include the steps required to reproduce the bug. |
| 44 | +> |
| 45 | +> 1. This is the first step |
| 46 | +> 2. This is the second step |
| 47 | +> 3. Further steps, etc. |
| 48 | +> |
| 49 | +> `<url>` - a link to the reduced test case (e.g. a GitHub Gist) |
| 50 | +> |
| 51 | +> Any other information you want to share that is relevant to the issue being |
| 52 | +> reported. This might include the lines of code that you have identified as |
| 53 | +> causing the bug, and potential solutions (and your opinions on their |
| 54 | +> merits). |
| 55 | +
|
| 56 | +## Feature requests |
| 57 | + |
| 58 | +Feature requests are welcome and should be discussed on issue tracker. But take a moment to find |
| 59 | +out whether your idea fits with the scope and aims of the project. It's up to *you* |
| 60 | +to make a strong case to convince the community of the merits of this feature. |
| 61 | +Please provide as much detail and context as possible. |
| 62 | + |
| 63 | + |
| 64 | +## Pull requests |
| 65 | + |
| 66 | +Good pull requests - patches, improvements, new features - are a fantastic |
| 67 | +help. They should remain focused in scope and avoid containing unrelated |
| 68 | +commits. |
| 69 | + |
| 70 | +**IMPORTANT**: By submitting a patch, you agree that your work will be |
| 71 | +licensed under the license used by the project. |
| 72 | + |
| 73 | +If you have any large pull request in mind (e.g. implementing features, |
| 74 | +refactoring code, etc), **please ask first** otherwise you risk spending |
| 75 | +a lot of time working on something that the project's developers might |
| 76 | +not want to merge into the project. |
| 77 | + |
| 78 | +Please adhere to the coding conventions in the project (indentation, |
| 79 | +accurate comments, etc.) and don't forget to add your own tests and |
| 80 | +documentation. When working with git, we recommend the following process |
| 81 | +in order to craft an excellent pull request: |
| 82 | + |
| 83 | +1. [Fork](https://help.github.com/articles/fork-a-repo/) the project, clone your fork, |
| 84 | + and configure the remotes: |
| 85 | + |
| 86 | + ```bash |
| 87 | + # Clone your fork of the repo into the current directory |
| 88 | + git clone https://github.com/<your-username>/Waypoint |
| 89 | + # Navigate to the newly cloned directory |
| 90 | + cd Saturn |
| 91 | + # Assign the original repo to a remote called "upstream" |
| 92 | + git remote add upstream https://github.com/<project-username>/Waypoint |
| 93 | + ``` |
| 94 | + |
| 95 | +2. If you cloned a while ago, get the latest changes from upstream, and update your fork: |
| 96 | + |
| 97 | + ```bash |
| 98 | + git checkout master |
| 99 | + git pull upstream master |
| 100 | + git push |
| 101 | + ``` |
| 102 | + |
| 103 | +3. Create a new topic branch (off of `master`) to contain your feature, change, |
| 104 | + or fix. |
| 105 | + |
| 106 | + **IMPORTANT**: Making changes in `master` is discouraged. You should always |
| 107 | + keep your local `master` in sync with upstream `master` and make your |
| 108 | + changes in topic branches. |
| 109 | + |
| 110 | + ```bash |
| 111 | + git checkout -b <topic-branch-name> |
| 112 | + ``` |
| 113 | + |
| 114 | +4. Commit your changes in logical chunks. Keep your commit messages organized, |
| 115 | + with a short description in the first line and more detailed information on |
| 116 | + the following lines. Feel free to use Git's |
| 117 | + [interactive rebase](https://help.github.com/articles/about-git-rebase/) |
| 118 | + feature to tidy up your commits before making them public. |
| 119 | + |
| 120 | + |
| 121 | +5. Make sure all the tests are still passing. |
| 122 | + |
| 123 | + ```bash |
| 124 | + dotnet tool restore |
| 125 | + dotnet tool build |
| 126 | + ``` |
| 127 | + |
| 128 | +6. Push your topic branch up to your fork: |
| 129 | + |
| 130 | + ```bash |
| 131 | + git push origin <topic-branch-name> |
| 132 | + ``` |
| 133 | + |
| 134 | +7. [Open a Pull Request](https://help.github.com/articles/about-pull-requests/) |
| 135 | + with a clear title and description. |
| 136 | + |
| 137 | +8. If you haven't updated your pull request for a while, you should consider |
| 138 | + rebasing on master and resolving any conflicts. |
| 139 | + |
| 140 | + **IMPORTANT**: _Never ever_ merge upstream `master` into your branches. You |
| 141 | + should always `git rebase` on `master` to bring your changes up to date when |
| 142 | + necessary. |
| 143 | + |
| 144 | + ```bash |
| 145 | + git checkout master |
| 146 | + git pull upstream master |
| 147 | + git checkout <your-topic-branch> |
| 148 | + git rebase master |
| 149 | + ``` |
0 commit comments