|
| 1 | +# Contributing to OverReact |
| 2 | + |
| 3 | +Looking to contribute something to the over_react library? __Here's how you can help.__ |
| 4 | + |
| 5 | ++ __[Coding Standards](#coding-standards)__ |
| 6 | + + [General Formatting Guidelines](#general-formatting-guidelines) |
| 7 | ++ __[Using the Issue Tracker](#using-the-issue-tracker)__ |
| 8 | + + [Reporting Bugs](#bug-reports) |
| 9 | + + [Feature Requests](#feature-requests) |
| 10 | + + [Submitting Pull Requests](#pull-requests) |
| 11 | ++ __[Commit Message Standards](#git-commit-message-standards)__ |
| 12 | ++ __[Developer Workflow](#developer-workflow)__ |
| 13 | + |
| 14 | + |
| 15 | + |
| 16 | + |
| 17 | +## Coding standards |
| 18 | + |
| 19 | +A lot can be gained by writing code in a consistent way. Moreover, always remember that code is written and |
| 20 | +maintained by _people_. Ensure your code is descriptive, well commented, and approachable by others. |
| 21 | + |
| 22 | +__ALWAYS__ adhere to the [Dart Style Guide]. _Please take the time to read it if you have never done so._ |
| 23 | + |
| 24 | + |
| 25 | + |
| 26 | + |
| 27 | +### General formatting guidelines |
| 28 | + |
| 29 | ++ __AVOID__ lines longer than 120 characters. |
| 30 | ++ __AVOID__ using `dartfmt` as an excuse to ignore good judgement about |
| 31 | + whether your code is readable and approachable by others. |
| 32 | + |
| 33 | + |
| 34 | + |
| 35 | + |
| 36 | + |
| 37 | + |
| 38 | +## Using the issue tracker |
| 39 | + |
| 40 | +The issue tracker is the preferred channel for [bug reports](#bug-reports) and [feature requests](#feature-requests), |
| 41 | +but __please follow the guidelines:__ |
| 42 | + |
| 43 | + + __Fill out the template we've provided.__ |
| 44 | + |
| 45 | + + __Be Professional__ |
| 46 | + + Please __do not__ derail or troll issues. Keep the discussion on topic and respect the opinions of others. |
| 47 | + |
| 48 | + + __Not that Professional__ |
| 49 | + + Feel free to include _relevant_ animated gifs to drive home your message / request. |
| 50 | + |
| 51 | + |
| 52 | + |
| 53 | + |
| 54 | +### Bug reports |
| 55 | + |
| 56 | +A bug is a _demonstrable problem_ that is caused by the code in the repository. |
| 57 | + |
| 58 | +_Good bug reports are extremely helpful - thank you!__ |
| 59 | + |
| 60 | +__Guidelines for bug reports:__ |
| 61 | + |
| 62 | +1. __Search for existing issues.__ Duplicate issues can become cumbersome, and you'd help us out a lot by first |
| 63 | + checking if someone else has reported the same issue. Moreover, the issue may have already been resolved with a |
| 64 | + fix available. |
| 65 | + |
| 66 | +2. __Record a screencast of yourself reproducing the issue__. |
| 67 | + 1. Be sure the problem exists in over_react's code by building a |
| 68 | + reduced test case that one of the reviewers can pull locally |
| 69 | + and test out. |
| 70 | + |
| 71 | +3. __Share as much information as possible.__ Include operating system and version, browser and version, version of |
| 72 | + `over_react`, etc. where appropriate. |
| 73 | + |
| 74 | +Always include steps to reproduce the bug. |
| 75 | + |
| 76 | +__Example Bug Report:__ |
| 77 | + |
| 78 | +> Short and descriptive example bug report title |
| 79 | +> |
| 80 | +> A summary of the issue and the browser/OS environment in which it occurs. If |
| 81 | +> suitable, include the steps required to reproduce the bug. |
| 82 | +> |
| 83 | +> 1. This is the first step |
| 84 | +> 2. This is the second step |
| 85 | +> 3. Further steps, etc. |
| 86 | +> |
| 87 | +> `<url>` - a link to branch with the reduced test case |
| 88 | +> |
| 89 | +> Any other information you want to share that is relevant to the issue being |
| 90 | +> reported. This might include the lines of code that you have identified as |
| 91 | +> causing the bug, and potential solutions (and your opinions on their |
| 92 | +> merits). |
| 93 | +
|
| 94 | + |
| 95 | + |
| 96 | + |
| 97 | +### Feature requests |
| 98 | + |
| 99 | +Feature requests are welcome. But take a moment to find out whether your idea fits with the scope and aims of the |
| 100 | +project. It's up to *you* to make a strong case to convince the `over_react` team of the merits of this feature. |
| 101 | +Please provide as much detail and context as possible. |
| 102 | + |
| 103 | + |
| 104 | + |
| 105 | + |
| 106 | +### Pull requests |
| 107 | + |
| 108 | +Good pull requests - patches, improvements, new features - are a fantastic help. They should remain focused in scope |
| 109 | +and avoid containing unrelated commits. |
| 110 | + |
| 111 | +__Please ask first__ before embarking on any significant pull request (e.g. implementing features, refactoring code, |
| 112 | +porting to a different language), otherwise you risk spending a lot of time working on something that the project's |
| 113 | +lead developers might not want to merge into the project. |
| 114 | + |
| 115 | +Please adhere to the [Dart Style Guide] for all changes contained in your pull requests. |
| 116 | + |
| 117 | +Adhering to the following process is the best way to get your work included in the project: |
| 118 | + |
| 119 | +1. [Fork](http://help.github.com/fork-a-repo/) the project, clone your fork, |
| 120 | + and configure the remotes: |
| 121 | + |
| 122 | + ```bash |
| 123 | + # Navigate to the directory where you store repos locally |
| 124 | + cd ~/your-local-git-repo-spot |
| 125 | + # Clone your fork of the repo into the current directory |
| 126 | + git clone git@github.com:<your-username>/over_react |
| 127 | + # Navigate to the newly cloned directory |
| 128 | + cd ~/your-local-git-repo-spot/over_react |
| 129 | + # Assign the repo you forked from to a remote called "upstream" |
| 130 | + git remote add upstream git@github.com:Workiva/over_react |
| 131 | + ``` |
| 132 | + |
| 133 | +2. If you cloned a while ago, get the latest changes from upstream: |
| 134 | + |
| 135 | + ```bash |
| 136 | + git checkout master |
| 137 | + git pull upstream master |
| 138 | + ``` |
| 139 | + |
| 140 | +3. Create a new topic branch that will contain your feature, change, or fix: |
| 141 | + |
| 142 | + ```bash |
| 143 | + git checkout -b <topic-branch-name> |
| 144 | + ``` |
| 145 | + |
| 146 | +4. Commit your changes in logical chunks. Please adhere to these |
| 147 | + [git commit message guidelines](#git-commit-message-standards) or your code is unlikely be merged into the master |
| 148 | + branch. Optionally, you can use Git's [interactive rebase](https://help.github.com/articles/interactive-rebase) |
| 149 | + feature to tidy up your commits before making them public. |
| 150 | + |
| 151 | +5. Write tests for your changes. |
| 152 | + 1. There are no exceptions. |
| 153 | + 2. If you're having trouble, reach out in your PR about how to best go about testing your changes. |
| 154 | + |
| 155 | +6. If you have merge conflicts, locally merge the upstream master branch into your topic branch: |
| 156 | + |
| 157 | + ```bash |
| 158 | + git pull upstream master |
| 159 | + ``` |
| 160 | + |
| 161 | +7. Push your topic branch up to your fork: |
| 162 | + |
| 163 | + ```bash |
| 164 | + git push origin <topic-branch-name> |
| 165 | + ``` |
| 166 | + |
| 167 | +8. [Open a Pull Request](https://help.github.com/articles/using-pull-requests/) |
| 168 | + with a clear title and description - following all the [issue guidelines](#using-the-issue-tracker) listed above. |
| 169 | + |
| 170 | + |
| 171 | + |
| 172 | + |
| 173 | + |
| 174 | + |
| 175 | +## Git Commit Message Standards |
| 176 | + |
| 177 | +Below you will find an example commit message that follows the guidelines we would like all over_react contributors |
| 178 | +to follow. |
| 179 | + |
| 180 | +``` |
| 181 | +Capitalized, short (50 chars or less) summary |
| 182 | +
|
| 183 | +More detailed explanatory text, if necessary. Wrap it to about 72 |
| 184 | +characters or so. In some contexts, the first line is treated as the |
| 185 | +subject of an email and the rest of the text as the body. The blank |
| 186 | +line separating the summary from the body is critical (unless you omit |
| 187 | +the body entirely); tools like rebase can get confused if you run the |
| 188 | +two together. |
| 189 | +
|
| 190 | ++ Bullet points are okay, too |
| 191 | +
|
| 192 | ++ Typically a hyphen, asterisk or plus-symbol is used for the bullet, |
| 193 | +followed by a single space, with blank lines in between, but |
| 194 | +conventions vary here |
| 195 | +``` |
| 196 | + |
| 197 | +Write your commit message in the imperative: "Fix bug" and not "Fixed bug" or "Fixes bug." This convention matches up |
| 198 | +with commit messages generated by commands like git merge and git revert. |
| 199 | + |
| 200 | +Further paragraphs come after blank lines. |
| 201 | + |
| 202 | +> [Read this](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html) for more information on why a |
| 203 | +> standardized commit message format is important. |
| 204 | +
|
| 205 | + |
| 206 | + |
| 207 | + |
| 208 | + |
| 209 | + |
| 210 | +## Developer Workflow |
| 211 | + |
| 212 | +The `over_react` developer workflow couldn't be any more simple! |
| 213 | + |
| 214 | +To serve the demos within `web/`, or start the transformer, run: |
| 215 | + |
| 216 | +```bash |
| 217 | +pub serve |
| 218 | +``` |
| 219 | + |
| 220 | +When you're ready to run the tests... run: |
| 221 | + |
| 222 | +```bash |
| 223 | +pub run dart_dev test |
| 224 | +``` |
| 225 | + |
| 226 | + |
| 227 | +[Dart Style Guide]: https://www.dartlang.org/guides/language/effective-dart/style |
0 commit comments