|
1 | | -# Contributing |
| 1 | +# Contributing Guide |
| 2 | +How to set up code test review and release so contributions meet our Definition of Done |
2 | 3 |
|
3 | | -## Branching |
4 | | -Use `feature/<short-name>` for work branches |
| 4 | +## Code of Conduct |
| 5 | +We will work with respect and clarity. No harassment. No abuse. Speak up if something is off. |
| 6 | +Report concerns to the rest of the team and the project partner. For private concers use direct email. |
5 | 7 |
|
6 | | -## Reviews |
7 | | -Open a PR early request review when ready at least one reviewer must approve |
| 8 | +## Getting Started |
| 9 | +Prereqs |
| 10 | +- Git installed |
| 11 | +- Python 3.11 or newer |
| 12 | +- Node LTS |
| 13 | +- A terminal and an editor |
8 | 14 |
|
9 | | -## Coding Standards |
10 | | -Keep modules small and testable write short docs for any public API |
| 15 | +Backend setup |
| 16 | +- open a terminal |
| 17 | +- cd svc |
| 18 | +- python -m venv .venv |
| 19 | +- activate the venv |
| 20 | +- pip install -r requirements.txt |
| 21 | +- copy .env.example to .env |
| 22 | +- run python main.py |
| 23 | +- open http 127.0.0.1 8000 docs and test GET health |
11 | 24 |
|
12 | | -## Commits |
13 | | -Use clear messages in the imperative voice |
| 25 | +Frontend setup |
| 26 | +- open a new terminal |
| 27 | +- cd web |
| 28 | +- npm install |
| 29 | +- npm run dev |
| 30 | +- open the URL that Vite prints |
14 | 31 |
|
15 | | -## CI |
16 | | -CI must be green to merge |
| 32 | +## Branching and Workflow |
| 33 | +We use a light trunk model with short lived feature branches |
| 34 | +- default branch is main |
| 35 | +- create branches as feature short name or fix short name |
| 36 | +- rebase small branches before merge if there are conflicts |
| 37 | +- do not force push main |
| 38 | + |
| 39 | +## Issues and Planning |
| 40 | +We track all work in GitHub Issues |
| 41 | +- write a clear title, and one sentence summary |
| 42 | +- add labels, feature, fix, docs, chore |
| 43 | +- link to related PRs, and meeting notes |
| 44 | + |
| 45 | +## Commit Messages |
| 46 | +Keep messages short and clear |
| 47 | +- describe what you changed, and why it matters |
| 48 | +- one focused change per commit, when possible |
| 49 | + |
| 50 | +- keep each commit focused on one change |
| 51 | +## Code Style, Linting, and Formatting |
| 52 | +Python |
| 53 | +- follow PEP 8 style |
| 54 | +- keep functions short and clear |
| 55 | +- use type hints for public functions |
| 56 | +- run tests before pushing |
| 57 | + |
| 58 | +Web |
| 59 | +- use TypeScript types, avoid any |
| 60 | +- keep components small and simple |
| 61 | +- never include secrets in code |
| 62 | + |
| 63 | +## Testing |
| 64 | +Required tests |
| 65 | +- service |
| 66 | + - update or add tests for any code change |
| 67 | + - test both normal use and one error case |
| 68 | +- web |
| 69 | + - do a quick manual check for now |
| 70 | + - add unit tests later when the UI is stable |
| 71 | + |
| 72 | +How to run |
| 73 | +- svc pytest -q |
| 74 | +- web run the app and make sure it runs properly |
| 75 | + |
| 76 | +## Pull Requests and Reviews |
| 77 | +Before you open a PR |
| 78 | +- branch is up to date with main |
| 79 | +- code runs locally |
| 80 | +- tests pass locally |
| 81 | +- update docs if the user sees a change |
| 82 | + |
| 83 | +PR requirements |
| 84 | +- use the PR template in the repo |
| 85 | +- small PRs are preferred |
| 86 | +- request at least one reviewer who is not the author |
| 87 | + |
| 88 | +Review rules |
| 89 | +- at least one approval |
| 90 | +- all review comments resolved |
| 91 | +- no red CI checks |
| 92 | + |
| 93 | +## CI/CD |
| 94 | +Current CI |
| 95 | +- file .github workflows ci.yml |
| 96 | +- runs on push and pull request and confirms the pipeline is wired |
| 97 | + |
| 98 | +Required before merge |
| 99 | +- CI is green |
| 100 | +- svc tests pass locally pytest -q |
| 101 | +- web builds locally npm run build |
| 102 | + |
| 103 | +We will expand CI to run pytest and a web type check. Until then reviewers must run these locally. |
| 104 | + |
| 105 | +## Security and Secrets |
| 106 | +- never commit secrets or API keys |
| 107 | +- do not paste keys in issues or PRs |
| 108 | +- use .env files that are ignored by git |
| 109 | +- report security bugs privately to the lead and partner |
| 110 | +- keep dependencies current when possible |
| 111 | + |
| 112 | +Prohibited |
| 113 | +- hard coded credentials |
| 114 | +- copying key material into sample code |
| 115 | + |
| 116 | +## Documentation Expectations |
| 117 | +Update docs when something changes |
| 118 | +- update README for setup or usage changes |
| 119 | +- update quick start guide for researchers |
| 120 | +- add short docstrings for important functions |
| 121 | +- note visible changes in the PR description |
| 122 | + |
| 123 | +## Release Process |
| 124 | +We make tags when needed |
| 125 | +- tag format: v0.minor.patch |
| 126 | +- update README if needed |
| 127 | +- add a short summary of changes in the PR |
| 128 | +- to undo a release, revert the merge commit |
| 129 | + |
| 130 | +## Support and Contact |
| 131 | +Need help? |
| 132 | +- ask in the team Discord first |
| 133 | +- if stuck for more than a day, post in the issue and tag the lead |
| 134 | +- for project questions, contact Dr. Pierson or Alex |
0 commit comments