Skip to content

Commit baa3a8a

Browse files
author
travissouthard
committed
Add contributing guidelines
1 parent 948a201 commit baa3a8a

File tree

1 file changed

+148
-0
lines changed

1 file changed

+148
-0
lines changed

CONTRIBUTING.md

Lines changed: 148 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,148 @@
1+
# Guidelines for contributing
2+
3+
## Overview
4+
5+
This document will outline guidelines for contributing to the thirdplaces [codebase](https://github.com/CodeForPhilly/third-places).
6+
7+
## Joining the regular meetings
8+
9+
We host weekly meetings both in person and remotely. This is largely where we make decisions and set up collaborative pairing sessions to get large chunks of work done.
10+
11+
The best way to find out about our meetings is joining the [#third-places-project](https://codeforphilly.slack.com/archives/C051CV94UV8) channel on the [Code for Philly](https://www.codeforphilly.org/) [Slack](https://www.codeforphilly.org/chat/).
12+
13+
## Issues
14+
15+
We use issues to describe our needs and track our work. Writing clear and descriptive issues help make sure our teammates are able to understand the task and complete the work.
16+
17+
We also use issues for tracking our own team needs (e.g. adding documentation).
18+
19+
### Add an issue
20+
21+
Navigate to our [issues page on Github](https://github.com/CodeForPhilly/third-places/issues) and hit the big green `New` button.
22+
23+
### Types of issues
24+
25+
There are two types of issues we currently use: `Bug Reports` and `Feature Requests`. There are templates for each and following those templates is a great way to make sure we are providing enough context for other developers as we write issues.
26+
27+
#### Bug reports
28+
29+
Bug Reports are for reporting bugs in the code.
30+
31+
Most of the issues contributors submit will be bug reports since contributors often poke at the app and use tools like the console and inspector while using the app. Bug Reports need to properly provide context for the environment and conditions the bug us being seen under.
32+
33+
Good instructions for recreation are key to speedy development of fixes.
34+
35+
#### Feature requests
36+
37+
Feature Requests are for asking for new parts of the app, e.g. a notification system.
38+
39+
Clear context of why this new feature is needed and clear descriptions of what is wanted are key to developing new features.
40+
41+
## Making code changes
42+
43+
Changes to our codebase should always address an [issue](https://github.com/CodeForPhilly/third-places/issues) and need to be requested to be merged by submitting a pull request that will be reviewed by at least the team lead or two other contributors.
44+
45+
### Choose an issue
46+
47+
Look through the [issues page](https://github.com/CodeForPhilly/third-places/issues) in the repo.
48+
49+
Find a task that has no current assignees and sounds like a task that either you can confidently take on yourself or involves a new language, framework, or design that you want learn.
50+
51+
For the latter it is best to pair on this with a team member experienced with that thing you want to learn.
52+
53+
### Create a branch for your work
54+
55+
Our default branch to work from is `develop`. To create a new branch for your work:
56+
57+
```sh
58+
# In the docket-dashboard root, go to develop
59+
git checkout develop
60+
61+
# Pull down the most recent commits
62+
git pull
63+
64+
# Make a new branch
65+
git branch <new-branch-name>
66+
git checkout <new-branch-name>
67+
68+
# Or for a one liner (-b creates a new branch when checking out)
69+
git checkout -b <new-branch-name>
70+
```
71+
72+
Branch names should be in kebab case (all lower case, dashes separate words) and are best when short and descriptive.
73+
74+
### Commit your work
75+
76+
Any good work with code involves good commit messages.
77+
78+
The best commit messages read like instructions on how to recreate the code being committed.
79+
80+
Individual commits should be small chunks of work included together as one step in the process.
81+
82+
### Push your work up to the remote repo
83+
84+
When you have completed your work and made good commit messages that read like clear instructions, you will want to push your work up to our remote repository on Github.
85+
86+
```sh
87+
# Make a matching remote branch to push to
88+
# Note: While it is usually `origin`, the remote repo may be named a different alias on your machine
89+
git push --set-upstream origin <new-branch-name>
90+
91+
# Once you have set up a remote branch continue to push changes with:
92+
git push
93+
```
94+
95+
### Create a pull request
96+
97+
In order to merge your work to the `develop` branch you must create a pull request.
98+
99+
Often Github will put up a notification that a new branch has been pushed and give a green "Make a PR" button on any page of the repo. If you don't see this you can go to the [pull requests tab](https://github.com/CodeForPhilly/third-places/pulls) and hit the big green `New` button.
100+
101+
There is a template to follow to make sure that reviewers have enough context about the changes you made and what they fix.
102+
103+
It is vital to provide clear instructions how to test the changes you made.
104+
105+
Please also make sure you tag the issue you are addressing. You can do this when writing the PR by writing `#<number>` in the `Does this close any currently open issues` section.
106+
107+
```md
108+
<!-- For example, for a PR addressing issue #13 -->
109+
Closes #13
110+
```
111+
112+
To make sure reviewers know to review it, finish up by assigning either the team lead or two team members in the 'reviewers' tab in the sidebar or under the PR text depending on your view.
113+
114+
### Reviewed work
115+
116+
The reviewer(s) will either ask for changes or approve the PR.
117+
118+
If changes are requested, please make the changes in your branch and push them up to Github when ready.
119+
120+
```bash
121+
# Tip: If you are fixing something from a particular commit, you can create a !fixup commit with
122+
git commit --fixup <sha-for-commit>
123+
124+
# Then, when approved, before you merge you can use:
125+
git rebase -i --autosquash develop
126+
# to squash your !fixup commits into their corresponding commits and make sure your branch is up to date with develop
127+
```
128+
129+
Once you have pushed up your fixes, let your reviewer know and they will follow up and look again. This may loop a few times.
130+
131+
Once your changes are approved, you can hit the `merge` button to merge to the `develop` branch (unless specified otherwise).
132+
133+
Please also delete the branch from Github (you'll be prompted).
134+
135+
### Clean up
136+
137+
Once you've merged your work go back to your terminal
138+
139+
```sh
140+
# Go to the develop branch
141+
git checkout develop
142+
143+
# Pull down the changes you merged
144+
git pull
145+
146+
# Delete the branch from your local machine
147+
git branch -d <new-branch-name>
148+
```

0 commit comments

Comments
 (0)