Contribute
We are a small team. The site is better when you push back on it.
Principle 06 says accountability runs both ways. The corollary is that the project's editorial integrity isn't only ours to maintain — it depends on readers who notice things, fact-check things, and tell us when we got something wrong. This page is the on-ramp.
Why
Why this is open-source civic infrastructure
Almost every well-funded political organization in the country runs on closed software, opaque editorial processes, and donor lists you cannot see. We've built this differently on purpose. The whole site — its code, its content schemas, its briefs, its letter templates, its correction log — is published in a public repository under a permissive license for the code and a clear editorial license for the content. You can read every line. You can fork it. You can challenge it.
That openness is only worth something if there are people on the other end of it. Outside contribution is a real part of how the project stays accurate as policy moves, as bills get reintroduced under new numbers, as state-level patterns shift, as our own framing ages. Help with any of that is help we can use.
How
Five ways in
-
2 minutes
Tell us what's wrong.
If you read a brief, an issue page, or a news post and something is factually off — a misstated bill number, an out-of-date status, a misattributed quote — file a correction. We have a one-form template that asks for the page, the claim, and (ideally) a source. Most corrections are fixed within two business days.
-
5 minutes
Suggest a topic, a bill, a letter.
Something we should be covering and aren't. A bill that should be on a Key Bills table. A letter template the site should have. A state-level pattern worth aggregating. Drop a structured suggestion and we'll evaluate against the editorial calendar.
-
10 minutes — no setup
Edit a single file in the browser.
GitHub lets you fork the repo and edit a file directly in the web interface. This is perfect for typo fixes, adding a missing source URL, adding a state field to a state bill, or updating a bill's status. No local setup required. We've documented the exact steps in CONTRIBUTING.md.
-
30+ minutes
Write a brief, build a feature, fix a bug.
Clone the repo, run it locally, change what needs changing, open a pull request. Code contributions go through a normal review; content contributions go through editorial review. CONTRIBUTING.md has the full setup, the conventions, and the schemas for each content type.
-
Ongoing
Watch the repo, weigh in on PRs.
Star or watch the repo and you'll see new PRs and issues come through. Comment on the ones you can usefully comment on. Pushback from a reader who knows the subject is one of the best signals we get.
Specifics
What we'd love help with right now
These are the kinds of contributions that have outsized leverage at the project's current scale. None require deep development experience.
- State-bill backfills. Many of our Key Bills tables have entries for state-level legislation without a
statefield set. Adding one (e.g.state: "Virginia"in the issue's frontmatter) makes the search link land much more cleanly. Single-file edits, perfect for the web-based fork flow. - Bill-status updates. Every Key Bills row has a free-text
statusfield. Bills move. If you spot one that's progressed, been renumbered, or died, send a one-line correction. - Letter-template improvements. Cleaner argument, more concrete ask, better personalization placeholders. Letters are templates, not finished mail — every improvement helps the people who use them.
- Brief drafts. Short, sourced explainers on a current policy question. Editorial review applies. See CONTRIBUTING.md §"Briefs" for the schema and conventions.
- Accessibility audits. Run a screen reader on a brief. Tab through the homepage. Try the rep-lookup form with voice control. Tell us what's broken — even partial reports are useful.
- Performance and bundle-size work. The site is small but every kilobyte costs someone on a slow connection. Improvements there are quietly valuable.
Won't work
What we won't merge
- Mass identical PRs that change the same line in fifty content files. Use one PR with a clear summary and we'll fan it out.
- PRs that add an analytics SDK, an advertising tag, a third-party script, or anything that would put a tracker on the site. This is a hard project constraint.
- Content drafts that aren't sourced. Even drafts at the idea stage should cite where the underlying claims come from.
- Personal attacks on subjects, opponents, or other contributors in PR descriptions, commit messages, or issues. We won't merge them.
Conduct
The basics
Project spaces (issues, pull requests, discussions) follow a Code of Conduct. The short version: be respectful of people, rigorous about claims, and operate in good faith. Disagreement on the merits is welcome — that's most of what makes the project work. Personal attacks, harassment, and bad-faith argument are not.
Code contributions are licensed under MIT (see LICENSE). Editorial content is licensed under the site's Terms of Use, with full attribution to contributing authors. By submitting a PR you agree to those terms.
Questions that aren't ready to be issues can go in Discussions or to hello@americansforpropriety.org.