|
1 |
| -# Contributing |
2 |
| -Welcome to Omnibus! To get started, follow these steps: |
| 1 | +# Contributing to Omnibus |
3 | 2 |
|
4 |
| -1. Clone this repo. |
5 |
| - * If you have git configured with SSH, run `git clone [email protected]:waterloo-rocketry/omnibus.git` |
6 |
| - * If you don't have git configured with SSH (or you're not sure what that means), run `git clone https://github.com/waterloo-rocketry/omnibus.git` |
7 |
| -2. Enter the newly-cloned repo with `cd omnibus` |
8 |
| -3. Run `pip install wheel`, which will help install the rest of the packages more quickly. |
9 |
| -4. Install Python dependencies with `pip install -r requirements.txt`. If you get a permissions error, try `pip install --user -r requirements.txt` instead. |
10 |
| -5. Install the Omnibus library locally with `pip install -e .`. Don't forget the `.`! This allows the sources and sinks (and you) to import Omnibus. |
| 3 | +## Setting Up Your Environment |
11 | 4 |
|
12 |
| -You should now be ready to start developing! |
| 5 | +### Cloning the Repo and Installing Dependencies |
13 | 6 |
|
14 |
| -* To run unit tests: `pytest` |
15 |
| -* To launch the Omnibus server: `python -m omnibus` |
16 |
| -* To run a source/sink: `python sources/name/main.py` |
| 7 | +Please follow the steps listed in the [README](https://github.com/waterloo-rocketry/omnibus/blob/master/README.md#installation). |
17 | 8 |
|
18 |
| -# Style guide |
19 |
| -If you'd like to contribute to Omnibus, please take a moment to read through this style guide. Otherwise, happy devving :) |
| 9 | +## Contributing Code |
20 | 10 |
|
21 |
| -### Python |
22 |
| -We generally conform to [PEP8](https://pep8.org/) guidelines for how we format our Python code. The repository contains a custom formatting script (`tools/format.sh`) - you should run this optionally before commits, and definitely before creating pull requests and/or merging to master. |
| 11 | +### Taking Issues |
23 | 12 |
|
24 |
| -When adding code, make sure to add unit tests to match! It's generally a good idea to run the full suite of unit tests before creating a PR (which can be done with the `pytest` command). If you don't, CI will run it for you, but it'll take much longer. We'll get a Slack notification if a failing build makes it to master (but this is fairly unlikely), so don't be too scared of breaking things. They're always fixable :). |
| 13 | +The best way to get started on contributing to Omnibus is to take on an issue. Simply go to the [Software Master Project](https://github.com/orgs/waterloo-rocketry/projects/2), expand the Omnibus section and find an unassigned issue that interests you. Some issues may be lacking context or background info so feel free to DM the current Software Lead or whoever opened the issue for some more info. Once you've found an issue that you would like to work on, then set yourself as the issue's assignee and once ready, change the status of the issue from "Todo" to "In Progress". |
25 | 14 |
|
26 |
| -### Git |
27 |
| -Generally, commit messages should follow guidelines laid out by Chris Beams [here](https://chris.beams.io/posts/git-commit/). Additionally, |
28 |
| -* Pull requests should be squashed and merged to be added as commits to master. If the PR pertains to code inside the `omnibus/`, `sources/` or `sinks/` directories (_not_ the main repo), the commit message should be of the form `<subsystem>: <Commit message> (#XX)`, where `<subsystem>` is the folder that the code is relevant to and `XX` is the PR number. `<Commit message>` is the commit message as normal, following regular message guidelines (capital first letter, no period, etc). |
| 15 | +### Creating Branches |
29 | 16 |
|
30 |
| - An example commit message could be `plotter: Add custom dashboards (#42)`, for a PR that affects code inside the `sinks/plotter/` directory. |
31 |
| - Commit messages for code outside the `omnibus/`, `sources/` or `sinks/` directories don't need to follow this format. This is mainly to ensure that changes are immediately recognizable reading commit messages from the top level of the repository. |
| 17 | +The repo follows the branch naming convention of `{name}/{issue_num}-{description}`, e.g. `oraazi/157-update-readme-contributing` |
| 18 | + |
| 19 | +- `{name}` is the part of the branch name that identifies its author. Please use your **WatIAM username** (the combination of your first intial, possibly some numbers, and the first few letters of your last name that comes before `@uwaterloo.ca` in your email). |
| 20 | +- `{issue_num}` is the issue number of the issue that you are trying to fix or implement. If this branch is not associated with an issue, then you do not need to specify anything for this (e.g., just `oraazi/update-readme-contributing` is fine) |
| 21 | +- `{description}` is a short description of what this branch is fixing/implementing. Be sure to keep it short, as good practice is to keep the entire branch name under 30-40 characters. |
| 22 | + |
| 23 | +### Formatting and Linting Your Code |
| 24 | + |
| 25 | +This repo conforms to [PEP8](https://pep8.org) guidelines for Python code. We have a script to automatically enforce these guidelines (`tools/format.sh`). It is **mandatory** to run this before pushing your branch or opening a PR, and *recommended* before every commit. |
| 26 | + |
| 27 | +### Publishing PRs |
| 28 | + |
| 29 | +When you have written up your code and are ready to get it revieweda and merged to `master`, then you can [open a PR for your branch](https://github.com/waterloo-rocketry/omnibus/compare). Here's a few things that you should make sure to do when creating your PR: |
| 30 | + |
| 31 | +- All branches being merged to `master` must pass all their unit tests (they are run automatically when you open a PR). |
| 32 | +- Assign yourself as the assignee for the PR. |
| 33 | +- Assign the `omnibus-reviewers` team as a reviewer for your PR. This will assign the people in charge of Omnibus as reviewers. Additionally, if desired, assign others as reviewers to the PR if you want them specifically to review it or if the reviewer is not in the `omnibus-reviewers` team. |
| 34 | +- Make sure to link the PR to the relevant issue, if possible. The easiest way is [by using keywords in the PR description](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword), e.g. you can link the PR to Issue 157 by writing "closes #157" somewhere in the description. |
| 35 | +- Since your task is now in a review state, make sure to move the project status of the issue that this PR is linked to from "In Progress" to "Needs Review". If this project is not linked to an issue, add the PR to the "Software Master Project" Project under Omnibus and set its status accordingly. |
| 36 | + |
| 37 | +### Merging PRs |
| 38 | + |
| 39 | +Once your PR has passed all unit tests, and has been reviewed and approved, you can merge it to `master`. Merge using the "Squash and Merge" option so that all the commits from your branch are "squashed" into one commit containing all the changes. Congrats, you're now free to take on another issue and continue to make Omnibus better! |
0 commit comments