-
Notifications
You must be signed in to change notification settings - Fork 1
Contributing Guide
This page points you at the authoritative contribution policy and adds the orientation that helps around it. It is for a first-time contributor.
CONTRIBUTING.mdin the repository is the policy. It is short, and you should read it rather than a summary. This page does not duplicate it.
Also read CODE_OF_CONDUCT.md, which sets community expectations. By participating you agree to it.
If you read nothing else, read these. Each one costs a round trip or worse.
Pull requests target dev, never main. main is the release branch and only receives promotion pull requests and hotfixes.
The PR title needs a scope. feat: add patient search passes every local hook and reds the pull request. Write feat(web): add patient search. Scopes: web, api, database, fhir, types, ui, lib, repo, ci, docs.
Never real patient data. Not in issues, pull requests, commit messages, code, tests, fixtures, seed data, screenshots, or logs. Use obviously invented identities, such as "Testina Patientsson", born 1900-01-01. Anything containing real data is scrubbed on sight and treated as a data incident. If you need to report a bug involving real data, reproduce it with synthetic data first and report that.
Never edit an applied Prisma migration. Anything merged to dev or main is applied somewhere. Create a new migration instead. CI enforces this and the error message is clear, but the fix is a rewrite if you have built on top of the edit.
Good first issues are labelled in the issue tracker.
Areas that are approachable without deep clinical context:
-
packages/uihas the clearest conventions and the tightest feedback loop. Storybook makes every change visible immediately. See Component library. -
packages/fhiris pure functions with a strict test harness. Adding a field to an existing mapper is a well-bounded task. See FHIR boundary. - Documentation. The wiki is separate from the repository, but the repository's own READMEs and ADRs take pull requests, and at least one of them is stale in a way a contributor could fix.
Areas that need agreement first, so open an issue before writing code:
- Anything touching
packages/database/prisma/schema.prisma. It is high-collision and the conventions are dense. - Anything adding a route to
apps/api. The permission catalogue, the OpenAPI contract, and the audit path all have to move together. - Anything that reverses or extends a recorded decision. That needs an ADR in the same pull request. See ADR index.
- Getting started gets the application running.
-
Development workflow covers branches, commits, hooks, and the pull request flow in more detail than
CONTRIBUTING.mddoes. - Code quality bar and Testing strategy cover what has to be true before a change merges.
- Troubleshooting covers the traps. The Prisma client and mock mode account for most first-day confusion.
- Glossary is worth keeping open. Clinical and billing vocabulary is the steepest part of this codebase for most developers, and none of it is hard once named.
Bugs. Use the bug report template and fill in reproduction and environment. An incomplete report is much harder to act on.
Features. Open an issue with the feature template before writing significant code, so scope can be agreed first. That protects your time more than anyone else's.
Security vulnerabilities. Never a public issue. See Security policy.
No contributor licence agreement and no sign-off requirement. Submitting a contribution means it is your own work, or you have the right to submit it, and that it is provided under AGPL-3.0-only.
Two maintainers are code owners for the whole repository, with explicit ownership of the governance-sensitive paths: .github/, SECURITY.md, CONTRIBUTING.md, and docs/adr/.
Workflows, Dependabot configuration, and CI files are governance-sensitive. Do not modify them unless that is what the change is for.
openrunic is an open-source operating system for human health. Pre-alpha: do not run it in production, and never put real patient data into it.
Repository · Licence (AGPL-3.0-only) · Security policy · Contributing · Code of conduct
Where this wiki and the repository disagree, the repository is right.