Admin: Add Navbox contributing (via update-page on MediaWiki MCP Server)

2026-07-06T04:21:35Z

Add Navbox contributing (via update-page on MediaWiki MCP Server)

← Older revision		Revision as of 09:51, 6 July 2026
Line 101:		Line 101:

	All participation in the Care community is governed by the [<nowiki/>https://github.com/ohcnetwork/care/blob/develop/CODE_OF_CONDUCT.md Contributor Covenant Code of Conduct]. By contributing, you agree to uphold it — be respectful, assume good faith, and help keep the community welcoming.		All participation in the Care community is governed by the [<nowiki/>https://github.com/ohcnetwork/care/blob/develop/CODE_OF_CONDUCT.md Contributor Covenant Code of Conduct]. By contributing, you agree to uphold it — be respectful, assume good faith, and help keep the community welcoming.

			{{Navbox contributing}}

	{{Related}}		{{Related}}

Admin: OHC identity seed

2026-07-04T23:07:34Z

OHC identity seed

New page

{{Doc header
|type=guide
|domain=contributing
|title=Contribution workflow
|order=4
}}

This page walks through the end-to-end path a change takes — from finding an issue to getting your pull request merged. It applies to both the backend ([<nowiki/>https://github.com/ohcnetwork/care ohcnetwork/care]) and the frontend ([<nowiki/>https://github.com/ohcnetwork/care_fe ohcnetwork/care_fe]). If you haven't set up your environment yet, start with the [[Documentation|Contributor's Guide overview]] and the [[Contributing/Local development/Backend setup|backend local setup]].

== 1. Find and claim work ==

Both repositories tag approachable, well-scoped issues so you can find a starting point quickly:

* '''Backend''' — browse the [<nowiki/>https://github.com/ohcnetwork/care/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3A%22good+first+issue%22 <code>good first issue</code>] and [<nowiki/>https://github.com/ohcnetwork/care/issues?q=is%3Aissue+sort%3Aupdated-desc+label%3A%22help+wanted%22+is%3Aopen <code>help wanted</code>] issues on <code>ohcnetwork/care</code>.
* '''Frontend''' — browse the equivalent <code>good first issue</code> and <code>help wanted</code> labels on <code>ohcnetwork/care_fe</code>.

When you find an issue you'd like to take:

* Comment on the issue saying you'd like to work on it, and wait to be assigned. This avoids two people building the same thing.
* Link your pull request to the issue once you open it, so the issue closes automatically when the PR merges. See GitHub's guide on [<nowiki/>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 linking a pull request to an issue].

{{Tip|1=If an issue has been assigned but looks inactive, comment to ask whether it's still being worked on rather than opening a duplicate PR.}}

== 2. Branch off <code>develop</code> ==

<code>develop</code> is the default branch for contributions and the base for every pull request. Always branch from the latest <code>develop</code>, never from <code>main</code>.

<syntaxhighlight lang="bash">git checkout develop
git pull
git checkout -b issues/7001/edit-prescriptions</syntaxhighlight>
The frontend convention for branch names is <code>issues/{issue#}/{short-name}</code> (for example, <code>issues/7001/edit-prescriptions</code>). Using a descriptive branch name keeps your work easy to trace back to its issue.

== 3. Follow the coding standards ==

Each repository ships its own linting and formatting tooling. Run it locally before you push so review focuses on substance, not style.

=== Backend ===

The backend follows PEP 8 and enforces it with [<nowiki/>https://docs.astral.sh/ruff/ Ruff] via <code>pre-commit</code>. Install the hooks once after setting up your environment:

<syntaxhighlight lang="bash">pre-commit install</syntaxhighlight>
Run the hooks against the files you changed on your branch:

<syntaxhighlight lang="bash">pre-commit run --files $(git diff --name-only develop...HEAD)</syntaxhighlight>
With the hooks installed, <code>pre-commit</code> also runs automatically on every <code>git commit</code>.

=== Frontend ===

The frontend uses ESLint and Prettier. Lint and format your changes before committing:

<syntaxhighlight lang="bash">npm run lint
npm run format</syntaxhighlight>
The dev server (<code>npm run dev</code>) also surfaces lint errors in the console as you work.

=== Commit messages ===

Write clear, descriptive commit messages that explain ''what'' changed and ''why''. Use a meaningful pull request title too — the frontend repo favours a short, descriptive title such as <code>💊 Adds support for editing prescriptions</code>.

== 4. Test before you push ==

Run the relevant test suite locally and make sure it passes before pushing.

* '''Backend''' — see the test commands in the [[Contributing/Local development/Backend setup|backend local setup]].
* '''Frontend''' — end-to-end tests run on [<nowiki/>https://playwright.dev/ Playwright]. Install the browsers once with <code>npm run playwright:install</code>, then run <code>npm run playwright:test</code>. Playwright requires a local backend with seeded data; see the [[Contributing/Local development/Backend setup|backend local setup]] for how to run and seed it.

{{Note|1=Frontend Playwright tests need the frontend pointed at your local backend. Set <code>REACT_CARE_API_URL=http://127.0.0.1:9000</code> in your environment before running them.}}

== 5. Open a pull request ==

Push your branch and open a pull request against <code>develop</code>.

* '''Open a draft early.''' Opening a draft PR as soon as you have something to show makes it easy to get early feedback and signals that the issue is being worked on. Mark it '''Ready for review''' when it's complete.
* '''Fill in the PR body.''' Follow the PR template and reference the issue with a closing keyword (for example, <code>Closes #7001</code>) so it links and closes automatically.
* '''Request review.''' For frontend PRs, tag <code>@ohcnetwork/care-fe-code-reviewers</code> for faster resolution.
* '''Attach screenshots.''' For any change that touches the UI, attach before/after screenshots (or a short screen capture) showing the change.
* '''Address feedback promptly.''' Respond to review comments and push follow-up commits. On the frontend, a reviewed PR is labelled '''Needs Testing''' and queued for QA; once QA passes it is labelled '''Tested''' and queued for merge.

{{Tip|1=Keep pull requests focused. A small PR that does one thing is reviewed and merged far faster than a large one that mixes unrelated changes.}}

== 6. Keep your branch in sync with <code>develop</code> ==

While your PR is open, <code>develop</code> keeps moving. If GitHub reports conflicts, sync your branch with the upstream <code>develop</code> and resolve them locally.

If you haven't already, add the canonical repository as an <code>upstream</code> remote. Use the <code>ohcnetwork</code> org in the URL (the frontend repo is shown here; for the backend, use <code>https://github.com/ohcnetwork/care.git</code>):

<syntaxhighlight lang="bash">git remote add upstream https://github.com/ohcnetwork/care_fe.git</syntaxhighlight>
Fetch the latest upstream history and merge <code>develop</code> into your branch:

<syntaxhighlight lang="bash">git fetch upstream
git merge upstream/develop</syntaxhighlight>
If the merge reports conflicts, open the affected files and resolve the conflict markers (<code><<<<<<<</code>, <code>=======</code>, <code>>>>>>>></code>), keeping the correct combination of both sides. Then stage the resolved files and complete the merge:

<syntaxhighlight lang="bash">git add .
git commit</syntaxhighlight>
Push the updated branch to refresh your pull request:

<syntaxhighlight lang="bash">git push</syntaxhighlight>
{{Warning|1=Always merge <code>upstream/develop</code> into your feature branch — never the reverse. Resolve conflicts carefully: deleting the wrong side of a conflict marker can silently drop someone else's work.}}

== Code of Conduct ==

All participation in the Care community is governed by the [<nowiki/>https://github.com/ohcnetwork/care/blob/develop/CODE_OF_CONDUCT.md Contributor Covenant Code of Conduct]. By contributing, you agree to uphold it — be respectful, assume good faith, and help keep the community welcoming.

{{Related}}

Contributing/Contribution workflow - Revision history

Admin: Add Navbox contributing (via update-page on MediaWiki MCP Server)

Admin: OHC identity seed