Skip to content

Commit f94e9b4

Browse files
authored
Merge pull request #6 from aaronlademann-wf/add-contributor-stuff
Add contributor docs / guides, add pr + issue templates
2 parents 7ead77e + 6462f18 commit f94e9b4

File tree

4 files changed

+530
-0
lines changed

4 files changed

+530
-0
lines changed

.github/CONTRIBUTING.md

Lines changed: 227 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,227 @@
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+
&nbsp;
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+
&nbsp;
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+
&nbsp;
171+
&nbsp;
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+
&nbsp;
206+
&nbsp;
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

.github/ISSUE_TEMPLATE.md

Lines changed: 11 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,11 @@
1+
> * Issue Type: [BUG, FEATURE REQUEST, etc.]
2+
> * `over_react` Version(s): `x.x.x`
3+
4+
5+
Describe your issue here... _If it is a bug - PLEASE follow our [bug submission guidelines](https://github.com/Workiva/over_react/blob/master/.github/CONTRIBUTING.md#bug-reports)._
6+
7+
8+
---
9+
10+
11+
> __FYI:__ @greglittlefield-wf @aaronlademann-wf @jacehensley-wf @clairesarsam-wf @joelleibow-wf

.github/PULL_REQUEST_TEMPLATE.md

Lines changed: 20 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,20 @@
1+
__Ultimate problem:__
2+
3+
4+
5+
__How it was fixed:__
6+
7+
8+
9+
__Testing suggestions:__
10+
11+
12+
13+
__Potential areas of regression:__
14+
15+
16+
17+
---
18+
19+
20+
> __FYA:__ @greglittlefield-wf @aaronlademann-wf @jacehensley-wf @clairesarsam-wf @joelleibow-wf

0 commit comments

Comments
 (0)