README.md, CONTRIBUTING.md, license, tests, and local conventions over general guidance on this page.Ways to contribute
Use and report
Test a real workflow. File a reproducible defect, broken link, unclear claim, mobile issue, or browser incompatibility.
Improve access
Fix keyboard navigation, labels, contrast, reduced-motion behavior, responsive layouts, or plain-language explanations.
Add knowledge
Review scientific assumptions, cite sources, improve an explanation, add test vectors, or map a simulation to a curriculum.
Build a focused tool
Add a self-contained utility or simulation that solves a defined problem and fits an existing store category.
Strengthen platforms
Work on SDKs, Workers, databases, auth, publishing, compliance, tests, observability, or deployment automation.
Improve the commons
Write documentation, examples, translations, contributor onboarding, issue templates, or release notes.
Choose the right contribution level
Low setup: static tools and simulations
Many knowledge and utility stores use self-contained HTML, CSS, and JavaScript. These are good places for a narrow bug fix, accessibility improvement, clearer explanation, or new focused experience. Avoid unnecessary frameworks and external dependencies.
Moderate setup: storefronts and content systems
Storefront changes can affect catalog rendering, search, metadata, navigation, and deployment. Check how registry data is generated before manually editing generated output.
Advanced setup: platform repositories
App, game, web, and agent platforms include Cloudflare Workers, SDKs, CLIs, databases, Durable Objects, R2, authentication, CI, and publishing workflows. Read architecture and deployment documentation before changing contracts or infrastructure.
Before writing code
- Confirm that the issue belongs to the repository you found.
- Search existing issues and pull requests for duplicate work.
- Read local contributor and development instructions.
- For a large feature, open an issue with the user problem and proposed scope before implementation.
- For a small fix, make the smallest complete change and include verification.
What a strong pull request contains
- A clear statement of the user-visible problem.
- A focused implementation without unrelated formatting or refactoring.
- Tests or manual verification appropriate to the risk.
- Screenshots for visual changes, including mobile where relevant.
- Accessibility and privacy impact notes.
- Source and license information for new assets, datasets, models, or dependencies.
- Migration and rollback notes for database, API, auth, or deployment changes.
Quality expectations
Correctness
Educational simulations should state simplifying assumptions and, where possible, link to authoritative references. Calculators need boundary cases and known-answer tests. AI-generated content is not evidence of correctness.
Accessibility
Use semantic HTML, visible focus, keyboard-operable controls, useful labels, sufficient contrast, responsive layouts, and reduced-motion support where animation is not essential.
Privacy
Keep processing local when practical. Explain network requests. Do not add trackers directly to tool source. Never commit credentials or collect data merely because it may be useful later.
Dependencies
Static stores favor self-contained files. Platform repositories use their established package managers and patterns. Do not introduce cross-store runtime dependencies; proven shared patterns are vendored and adapted.
Design
Follow the store's design system and existing interaction patterns. A contribution should feel native to its target product, not introduce an unrelated visual system.
Licensing and authorship
By contributing, you certify that you have the right to submit the work under the repository's license. Free-store source is generally MIT licensed, but verify the target. Do not copy proprietary code, unlicensed images, restricted datasets, copyrighted books, or model weights with incompatible terms.
AI-assisted contributions are allowed. The submitting human is responsible for understanding the code, checking provenance, testing behavior, and responding to review.
Good first contributions
- Fix a confirmed broken link or inaccurate public claim.
- Add keyboard support and labels to a canvas or custom control.
- Add a known-answer test to a calculator or simulation.
- Document browser support and a graceful fallback.
- Improve a tool's empty, loading, error, and export states.
- Add a source citation and assumptions section to an educational experience.
- Reproduce an issue across two browsers and narrow its cause.
Review and release
Maintainers may ask for scope reduction, stronger evidence, changes to fit local conventions, or separation into multiple pull requests. Acceptance depends on correctness and maintenance cost, not only whether a feature works once.
Merging does not guarantee immediate deployment. Stores have different release and deployment workflows. Never include production secrets or attempt infrastructure changes outside the documented process.
Maintainer responsibilities
Maintaining is different from contributing. A maintainer is expected to triage reports, review changes fairly, preserve compatibility where promised, coordinate releases, document decisions, respond to security issues, and retire unsupported behavior explicitly. Ownership should be bounded to a store or capability rather than assumed for the entire ecosystem.
Content and community standards
Contributions must not include harassment, malware, credential theft, deceptive interfaces, non-consensual intimate material, illegal exploitation, discriminatory targeting, plagiarism, or content whose primary purpose is bypassing safety or access controls. Educational security, crypto, and AI material should be scoped to legitimate learning and defensive use.
Disagreement is expected. Reviews should address behavior, evidence, scope, and maintainability rather than the contributor. Repeated bad-faith behavior may result in issue closure or loss of participation access.
Translations and localization
Translations are useful when the underlying source is stable and the contributor can maintain meaning, not only literal wording. Preserve technical notation, units, warnings, citations, and accessible labels. Locale-sensitive finance, legal, date, number, and educational content needs explicit regional context.