Technical
Working on the codebase: the crawler, the validation layer, the ingestion scripts, the profile schema, tests, and tooling. The stack is Python. The right entry point is reading the code and finding something to improve, extend, or specify.
Contribute
Building HeldToStandard
HeldToStandard is in development. Before it becomes public, the project needs careful people to test, challenge, review, and improve it.
The goal is to make practical care questions accessible, while keeping the sources, evidence, and reasoning behind important claims open to inspection. The patient should not have to become a researcher. But anyone who wants to check the work should be able to.
Important to know
HeldToStandard is not medical advice. It does not replace healthcare professionals, care providers, or individual clinical judgement. It is not a treatment guideline.
Contributions that affect treatment profiles, evidence interpretation, or medical claims require clear methodology and careful review. HeldToStandard should be useful because the work can be inspected, not because anyone is expected to accept a new authority.
How to contribute
Contribution paths
These are the ways people contribute to HeldToStandard right now. Paths can overlap and change over time. None of them imply a fixed commitment.
Testing
Running the tool, finding where it breaks, and reporting clearly. This does not require deep technical knowledge. It requires methodical attention and the ability to write a specific bug report: what you did, what happened, what you expected.
Feedback
Reading the documentation, the methodology, and the patient-facing content for clarity, tone, accuracy, and gaps.
- Does the patient-facing page reach the people it is meant for?
- Is the language clear to someone without a medical background?
- Does the methodology hold up to a careful read?
- Where is the reasoning hard to follow or incomplete?
No technical knowledge required. Feedback can be given anonymously.
Advocacy and domain knowledge
If you understand the trans healthcare landscape, what patients actually encounter, what clinicians need from a tool like this, or how evidence gets used or ignored in clinical settings, that perspective is valuable. There is no fixed role for this yet. The conversation is worth having.
Founding recognition
Founding Contributors and Supporters
Anyone who contributes or gives support before the first public release can be recognised as a Founding Contributor or Founding Supporter. It is honorary and opt-in, and is the recognition most people choose.
Founding Contributor
Anyone who contributes in any path before the first public release is a Founding Contributor, if they want that recognition. It does not carry governance authority, legal status, ongoing obligation, or any specific access level.
Founding Supporter
Some people want to show support before v1 without active contribution, or may contribute only occasionally. Founding Supporter is a low-obligation outer ring. There is no minimum activity requirement and no formal role.
How it works
Involvement and expectations
There is no expectation of a particular level of commitment. Some collaborators may be deeply involved for years. Others may have one conversation that changes the direction of the project. Both matter.
You will be invited to the work Discord
The work Discord is where coordination happens: priorities, questions, feedback reports, and the occasional update. It is private and pre-launch. You will get an invite link. If you are not ready to join immediately, say so. There is no deadline.
Access follows need, not status
GitHub access, if needed for your contribution path, is set up when there is something concrete for you to do. It is not automatic. You start with the access your work requires. If that changes, so does your access.
You can step back
If your situation changes, you can reduce your involvement or stop entirely. No explanation required. If you want to take a break and come back later, that is also fine.
What to expect from us
Communication is async. There is no expectation of immediate responses. We will not schedule things without checking availability first. If something is urgent, it will be flagged clearly. Most things are not urgent.
How mistakes are handled
Mistakes should be corrected openly, with the reasoning behind a correction visible. But corrections are not enough: we should also ask how the mistake happened and what can change so the same failure is less likely to happen again. A mistake is not only something to correct. It is something to learn from.
Credit and anonymity
How credit works
Public credit is opt-in. No one is credited publicly without being asked first and confirming how they want to appear. This applies to every contribution type: code, testing, feedback, domain input, support, and anything else.
| Option | What appears publicly |
|---|---|
| Full name | The name you provide |
| Pseudonym or alias | The name you provide |
| GitHub username only | Your GitHub handle |
| Anonymous | Nothing identifying |
| Internal only | Name on file privately; nothing public |
| No credit | Not listed |
The choice is yours. You do not need to explain it.
Anonymity and safety
Some contributors prefer to remain anonymous because of personal safety concerns. That is fully respected and requires no explanation. Anonymous and pseudonymous contributions are treated the same as named ones in terms of how they are received and valued.
Founding recognition and timing
Founding Contributors and Founding Supporters who want public recognition are listed with their founding status noted. Consent is collected privately now. The public record is released when the project decides the time is right. No name goes public before that point, even if consent has been given.
AI and tools
AI is used as part of building HeldToStandard, and is stated openly because hiding it would contradict everything the project stands for.
AI helps with programming, documentation, drafting, and technical workflows. It does not author or determine medical claims, conclusions, or interpretations. Every published claim must stand on its own evidence, sources, methodology, and documented reasoning regardless of what tools were used to build the supporting infrastructure.
For some people, any AI use is a dealbreaker. That is a legitimate position, and it is better to know it now than later. The full explanation is at technical.html.
Get in touch
Start a conversation.
You do not need to pitch yourself. Say what part of the project interests you, what you may be able to help with, and any concerns or limits you want known from the start.