Thanks for being curious enough to look at this file. 🐾
This is the default contributing guide for every CuriouserLabs repository. If a project ships its own CONTRIBUTING.md, that one wins — it knows things this one doesn't.
We build educational and developer tools, and we'd rather have a thoughtful question than a rushed patch. Issues, ideas, bug reports, and pull requests are all genuinely welcome.
You don't need to write code to be useful here:
- Report a bug — tell us what you did, what happened, and what you expected instead.
- Suggest an idea — especially if you've hit a real problem our tools should have solved.
- Improve the docs — if a README confused you, it will confuse the next person too.
- Fix something — small, focused pull requests are the easiest to review and merge.
For anything non-trivial, open an issue first. A short discussion up front saves you from building something we were about to change, or solving a problem in a way that doesn't fit where the project is heading. For typo fixes and other obvious small things, just send the pull request.
Check the existing issues before opening a new one — someone may already be on it, and adding your context to an existing thread is more useful than a duplicate.
Good bug reports are specific. Please include:
- What you expected to happen, and what actually happened
- The exact steps to reproduce it (a numbered list is perfect)
- Your environment — OS, browser or runtime version, and the project version or commit
- Any error output, logs, or screenshots
If you can reproduce it reliably, say so. If you can't, say that too — intermittent bugs are still worth reporting, and knowing it's flaky is part of the diagnosis.
- Fork the repository and create a branch off the default branch. Name it for what it does —
fix/login-redirect,docs/setup-steps. - Set the project up locally. Each repository's
READMEcovers how to install dependencies and run it. - Make your change. Match the surrounding code — its naming, its structure, its comment density. Consistency matters more than personal preference here.
- Check your work. Run the project's tests, linter, and build before pushing. If the change is user-facing, actually run the app and look at it.
- Update the docs if your change affects how someone uses or sets up the project.
Write commit messages that explain why, not just what — the diff already shows what changed. A short summary line in the imperative mood ("Fix race condition in health poller"), and a body when the reasoning isn't obvious from the code.
Keep each pull request to one logical change. A PR that fixes a bug and refactors a module and updates dependencies is three PRs wearing a trench coat, and it's much harder to review or revert.
In the description, tell us:
- What problem this solves, and link the related issue (
Fixes #12) - How you verified it works
- Anything you're unsure about, or deliberately left out of scope
Draft pull requests are welcome if you want early feedback on a direction.
We review as promptly as we reasonably can — CuriouserLabs is a small, part-time lab, so please be patient if it takes a few days. Expect questions: review comments are about understanding the change, not about doubting you. If we ask for changes, push follow-up commits to the same branch.
If a pull request goes quiet for a while, a polite nudge on the thread is completely fine.
Each repository carries its own LICENSE file — check it before reusing code. By contributing, you agree that your contribution is licensed under that repository's license.
Be kind, be patient, and assume good faith. People here have different levels of experience and different amounts of free time; "curiouser" is an invitation, not a bar to clear. Harassment or belittling behavior isn't welcome in any of our repositories.
Not sure whether something is a bug, an idea, or just a misunderstanding? Open an issue and ask — a good question is as useful to us as a patch. You can also reach us at geeth.gsm@gmail.com.