|
| 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