Vijit Dua

Portfolio

Apps

Projects

Music/YT

Blog

About

Contributing guidelines

Repositories (Codebases) where external contributions are welcome, plus contributing guidelines.

TL;DR

  • Only projects listed on /open-source are open to contributions.
  • Reporting a bug but not contributing code? Use /support — not GitHub.
  • Open a GitHub issue when you are sending a PR or need a detailed technical thread. One problem per issue; include reproduction steps when you can.
  • Keep PRs small. Name the branch or title so the issue number is obvious (e.g. fix/42-login-bug). Use the PR template below.
  • If you find a security issue, see /open-source/security. For serious issues, contact me privately.
  • Check the repo LICENSE. Major work may show up on /contributions at my discretion.

Before you start

  • Make sure the project appears on this site’s /open-source hub. A public GitHub repo does not mean it is actively maintained or accepting contributions; it may have been abandoned or be read-only archival.
  • Search existing issues and pull requests to prevent duplicate work.
  • Read the LICENSE file in the repository.
  • Ownership and copyright are retained unless the license says otherwise (tbf most open source projects are MIT-licensed or similar so dw).

GitHub issues

  • Open a GitHub issue when you are planning a PR, or when the bug needs a long technical write-up. Otherwise, use /support.
  • One problem per issue. Include reproduction steps, expected vs actual, and environment details when they matter.
  • Use the issue template on this page as a starting point.

When not to use GitHub

  • Not working on code? Personal help, account questions, or “hey, this feels off” are totally fine to ask about — just use /support instead of opening a GitHub issue :)
  • If the app has its own bug or feature button, use that first. GitHub is for repo work: a proper issue or a PR.

Opening a PR

Fork the repository, create a branch, open a Pull Request.

  • Check the README, default branch, and release tags to see where to branch from.
  • I usually work on develop or main and recommend basing your PRs on those.
  • End user clients typically run on the release or production branch.
  • If the bug only shows up on a release build, check develop first in case it is already fixed.
  • Each repo is set up differently, so verify obvious conventions yourself.
  • Use branch names and PR titles like 42-short-name (GitHub issue number plus a short description).
  • Open an issue first when you can, and base the PR on it. That makes tracking and PR reviews much easier.
  • Use the PR template on this page.
  • One change per PR.
  • Provide good justification in issues and PRs for unrelated refactors or dependency bumps.

Expectations

In case this page did not make it obvious, I do a lot of things and stay busy. I maintain my open source for free, without donations, and it takes a lot of time.

I might not get to non-critical issues or PRs right away. Sometimes even really helpful ones sit for days or weeks. That is not me being ungrateful; I just cannot do everything at once.

Contributions are always welcome. I am genuinely appreciative of any and all of them — thank you for understanding :D.

Credit

Sometimes contributions show up on /contributions. If you care how you are credited, drop your preferred social links in the PR; otherwise I will use your GitHub username.