Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
88 lines (63 loc) · 3.67 KB

CONTRIBUTING.md

File metadata and controls

88 lines (63 loc) · 3.67 KB
Raw

Contributing

Thanks for taking the time to look at this project. Contributions are genuinely welcome — bug reports, documentation fixes and one-line typo corrections just as much as features.

These are the default guidelines for all public repositories on this account. If the repository you are working in has its own CONTRIBUTING.md, that file takes precedence.

Before you start

Small fixes need no discussion. Typos, broken links, incorrect docs, obvious bugs — open a pull request directly. There is no need to file an issue first.

Larger changes benefit from a conversation. For new features, dependency changes or anything that reshapes how a project works, open a Discussion or an issue first so we can agree on the approach before you spend your evening on it. This is to save your time, not to gate-keep.

Check what already exists. A quick search of open issues and pull requests avoids duplicate work.

Getting set up

Every repository documents its build in its own README.md. As a rule of thumb:

Stack Typical setup
Python pip install -r requirements.txt, run with py -3.12
.NET dotnet restore then dotnet build
Node / web npm install then npm run build
Android ./gradlew assembleDebug
PowerShell No build step; scripts run in place
Browser extensions Load the unpacked directory via chrome://extensions

Most of these projects are developed on Windows. Cross-platform fixes are very welcome — if something assumes a Windows path or a Windows-only tool, that is a bug worth reporting.

Making the change

  • Keep pull requests focused. One logical change per pull request. A bug fix and a refactor in the same diff are much harder to review, and much harder to revert.
  • Match the surrounding code. Follow the existing naming, formatting and structure of the file you are editing rather than introducing a new style.
  • Update the docs alongside the code. If behaviour changes, the README.md and any relevant help text should change in the same pull request.
  • Run whatever tests exist before pushing. If the project has a test suite, it should still pass. If your change fixes a bug, a test that reproduces that bug is the most valuable thing you can add.
  • Do not commit build artifacts, .env files, credentials or API keys.

Commit messages

Explain why, not what — the diff already shows what changed.

Fix crash when the config file is missing on first run

The loader assumed the file existed and threw before the default
config could be written.

Conventional-commit prefixes (fix:, feat:, docs:) are welcome but not required.

Opening the pull request

  • Describe the problem and how you solved it.
  • Link any related issue with Fixes #123.
  • Include a screenshot or short clip for anything that changes the user interface.
  • Note anything you were unable to test — no shame in "I could not test the macOS path", it is far better than a silent assumption.
  • Leave Allow edits by maintainers ticked so small corrections can be applied without a round trip.

Draft pull requests are a good way to get early feedback on work in progress.

Review

This account is maintained by one person alongside a full-time job, so review times vary. A pull request that has gone quiet has not been rejected — feel free to leave a comment as a nudge.

If a change is not accepted, you will get a reason. Forking and going your own way is always a legitimate outcome, and the licence explicitly permits it.

Licensing

By contributing, you agree that your contribution is licensed under the same licence as the repository, as recorded in its LICENSE file.