Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/aipoch/open-science/llms.txt

Use this file to discover all available pages before exploring further.

Open Science is built entirely in the open — every design decision, architectural debate, and line of code happens publicly on GitHub, on X, and in Discord. Whether you’re filing your first bug report or landing a deep structural change, all contributions are genuinely welcome, and this is still the stage where individual contributors can have real influence on the shape of the project.

​
Ways to Contribute

Report a Bug

Open a GitHub Issue describing what you expected, what actually happened, your OS and app version, and any relevant logs or screenshots.

Propose a Feature

Start a GitHub Discussion for design-level proposals, or open an Issue for concrete, scoped feature requests. Phase 2 items are the highest priority right now.

Open a Pull Request

Contribute code, documentation, or tests. Keep PRs focused and self-contained, and make sure all required checks pass before requesting review.

Join the Community

Join the Discord server where architecture debates, RFC drafts, and roadmap calls happen in real time — before they ever land in a doc like this one.

​
Before Submitting a PR

All four checks must pass locally before you open a pull request. Run them in order — format writes changes to disk, so run it last to avoid type errors on reformatted files: 
npm run typecheck   # TypeScript type checking (node + web)
npm run lint        # ESLint
npm run test        # Vitest unit tests
npm run format      # Prettier (writes formatting fixes)
npm run typecheck runs both typecheck:node (for the Electron main process and preload) and typecheck:web (for the React renderer) back-to-back — both tsconfigs must pass cleanly. Pull requests are expected to keep type checking, linting, and the test suite green. New behavior should come with corresponding tests. Keep PRs reasonably small and scoped so they are easy to review, and reference any related issue in the description.

​
Commit Message Style

Good commit messages make the project history navigable for everyone. Follow these conventions:
  • Imperative mood — write "Add CSV preview renderer", not "Added" or "Adds".
  • Concise subject line — aim for 50–72 characters so it reads cleanly in git log.
  • Explain the why in the body — the diff shows what changed; use the commit body to explain why the change was necessary or what problem it solves, when that isn’t obvious from the diff alone.

​
Bug Reports

When filing a bug report, include as much of the following as possible so it can be reproduced and triaged quickly:
  • Expected vs. actual behavior — describe what you thought would happen and what actually happened.
  • Reproduction steps — a minimal, numbered sequence of steps to reliably trigger the bug.
  • OS and app version — operating system (including version), and the Open Science version or commit hash.
  • Logs and screenshots — paste any relevant console output or error messages, and attach screenshots if the issue is visual.

​
Code of Conduct

Be respectful and constructive in all interactions. Assume good intent, keep discussions focused on the technical merits, and help make this a welcoming project for everyone.

​
License

By contributing to Open Science, you agree that your contributions will be licensed under the Apache License 2.0 — the same license that covers the entire project.
Setting up the project for the first time? Head to the Development Setup page for a step-by-step guide to cloning the repository, installing dependencies, and running the hot-reload development build.

Build docs developers (and LLMs) love

Get started for freeTalk to us