Skip to main content
HashnodePainTracker – Privacy First Chronic Pain TrackingPainTracker – Privacy First Chronic Pain Tracking

Command Palette

Search for a command to run...

Contribute

Contribute

Help improve Pain Tracker with code, docs, testing, and accessibility feedback while preserving privacy-first and offline-first principles.

Ways to Contribute

There are several ways to help improve Pain Tracker, whether you write code or not.

Report Bugs or Suggest Improvements

Found something broken or have an idea that would make the app more useful?

  • Open an issue on GitHub
  • Describe what you were doing, what happened, and what you expected
  • Include screenshots or steps to reproduce when possible

Contribute Code

If you work with frontend or web app tooling, code contributions are welcome.

  • Review GitHub Issues
  • Look for items marked good first issue or help wanted
  • Fork the repo, make your changes, and open a pull request

Current stack: React, TypeScript, Vite, IndexedDB, Service Workers, Web Crypto API

Improve Documentation

Clear documentation makes the project easier to use and easier to maintain.

You can help by improving:

  • setup instructions
  • architecture notes
  • README content
  • contributor guidance
  • in-code comments where clarity is needed

Test and Give Feedback

You do not need to write code to contribute meaningfully.

Useful testing includes:

  • trying the app on different devices and browsers
  • checking offline behavior
  • reporting UX friction
  • identifying accessibility issues
  • flagging confusing flows or language

Share Lived-Experience Feedback

Pain Tracker is shaped by real-world use conditions. Feedback grounded in lived experience is valuable.

Helpful input includes:

  • what information you need to track
  • where current workflows fall short
  • what feels supportive versus frustrating
  • what would make the app more usable in difficult conditions

Contribution Principles

Pain Tracker is built around a few core constraints. Contributions should support them rather than work against them.

Privacy-First

Changes should avoid unnecessary data collection, tracking, or external exposure.

Offline-First

Core workflows should remain useful even when connectivity is limited or unavailable.

Low-Friction Use

The product should stay practical, accessible, and usable without unnecessary barriers.

Accessibility and Clarity

Contributions should improve readability, navigability, and usability across different needs and devices.

Maintainable Implementation

Code and documentation should stay understandable enough for other contributors to extend and review.

Contribution Workflow

  1. Fork the repository on GitHub
  2. Create a branch for your change
  3. Make the change and test it carefully
  4. Use clear commit messages
  5. Open a pull request with a short explanation of what changed and why

Repo: github.com/CrisisCore-Systems/pain-tracker

Before You Build

If you want feedback before spending time on implementation, start a discussion first.

Contribution Boundaries

Some kinds of changes are not a fit for this project.

Examples include:

  • features that require mandatory accounts for core use
  • unnecessary telemetry or tracking
  • designs that increase pressure, manipulation, or behavioral coercion
  • features that move sensitive health records into systems the user does not control
  • monetization patterns that restrict core value behind paywalls

Project Conduct

Be respectful, specific, and constructive.

  • critique code and decisions, not people
  • communicate clearly
  • respect privacy and lived experience
  • aim to reduce harm, not add friction

Pain Tracker is an open project, and good collaboration matters as much as technical quality.