Apply for AI Grants India

Open source contribution is not limited to senior engineers or people working on famous repositories. A useful documentation fix, reproducible bug report, test improvement, benchmark, translation, or small feature can demonstrate how you investigate problems and collaborate in public. For Indian developers, GitHub contributions also offer a practical bridge between coursework, research, startup work, and production engineering.

The goal is not to maximise green squares or submit the largest pull request. The goal is to understand a project’s needs, make a focused change, and leave the codebase better than you found it. This guide explains how to contribute to open source GitHub repos using a workflow that works for software, data, and AI projects.

Choose a repository you can realistically support

Start with a project you use, understand, or genuinely want to learn. Familiarity with the problem makes it easier to identify useful improvements and respond to review comments.

Before writing code, inspect:

• Recent activity: Check recent commits, releases, issue responses, and merged pull requests. A large repository is not necessarily active or welcoming.
• Contribution guidance: Read README.md, CONTRIBUTING.md, the code of conduct, and any developer documentation. These files often specify setup commands, tests, branch conventions, and issue-selection rules.
• Maintainer responsiveness: Look at closed issues and pull requests. Clear feedback and recent merges are better signals than a high star count.
• Scope: Pick a task that can be explained and reviewed in one pull request. Avoid beginning with a broad rewrite.

Labels such as good first issue, help wanted, documentation, and tests can help, but do not treat them as a guarantee. An issue may already be assigned, outdated, or blocked by a larger change. If you are exploring AI, compare the project with curated lists such as best open source projects for AI beginners on GitHub before committing time.

Documentation and examples are strong starting points. In machine-learning repositories, improving an installation guide, adding a missing edge-case test, clarifying GPU requirements, or fixing a notebook can be more valuable than adding an unrequested model feature.

Read the issue and confirm the intended change

Do not immediately fork a repository and start coding. First, search existing issues and pull requests to learn whether someone is already working on the problem. Read maintainer comments, linked discussions, and project decisions.

For a non-trivial change, comment briefly with what you plan to do and ask whether the approach fits the project. A useful comment identifies the issue, describes the proposed scope, and mentions any uncertainty. This prevents duplicated work and reduces the chance of building a technically correct solution the maintainers do not want.

When reporting a new bug, include:

• Repository version, commit, or release
• Operating system and relevant hardware
• Minimal reproduction steps
• Expected and actual behaviour
• Logs, stack traces, and a small example where possible
• Whether the problem affects CPU, GPU, cloud, or local execution

Do not paste secrets, private data, API keys, or proprietary datasets into a public issue.

Set up GitHub and the local repository

Create a GitHub account with a clear profile and enable two-factor authentication. Configure Git locally with the email associated with your account, then fork the repository if the project uses the standard fork workflow:

git clone https://github.com/YOUR-USERNAME/PROJECT.git
cd PROJECT
git remote add upstream https://github.com/OWNER/PROJECT.git
git fetch upstream

Keep your fork’s default branch aligned with the upstream repository. Before starting work, create a dedicated branch from the latest upstream branch:

git switch main
git fetch upstream
git reset --hard upstream/main
git switch -c fix/short-description

The exact branch name and default branch may differ, so follow the repository’s instructions. Never commit directly to main for a contribution.

Run the project’s existing setup and test commands before changing anything. This establishes a baseline and reveals environment problems early. For AI projects, record Python and package versions, CUDA or accelerator details, model-download requirements, and any external services needed. Do not assume a maintainer can reproduce a failure caused by a local environment.

Make a focused, reviewable change

Read the relevant code before editing it. Trace the call path, inspect nearby tests, and understand the project’s naming, error-handling, and logging conventions. Match the existing style instead of introducing a new framework or abstraction for a small issue.

A strong contribution usually has:

• One clear purpose
• A test that captures the expected behaviour
• Updated documentation or release notes when required
• No unrelated formatting or dependency changes
• A commit history that is easy to understand

For a bug fix, write or update a regression test where practical. For an AI feature, test more than a single successful example: include malformed input, empty data, language variation, resource limits, and deterministic behaviour where relevant. If the change affects model quality, explain the evaluation dataset, metrics, baseline, and known limitations rather than claiming improvement from anecdotal outputs.

Contributors working on Indian-language AI can find useful context in this guide to low-resource Indic natural language processing. The same discipline applies to tokenisation, evaluation, transliteration, and dataset documentation: make assumptions explicit and document coverage gaps.

Commit, verify, and update your branch

Inspect your changes before committing:

git status
git diff
git diff --check

Use a concise commit message that describes the change. Run the full test suite if feasible, along with formatters, linters, type checks, and documentation builds specified by the project. If tests cannot run, state why and report the checks you did complete.

Push only the branch needed for the contribution:

git add path/to/files
git commit -m "Fix concise description of behaviour"
git push -u origin fix/short-description

If the upstream branch changes while your work is in progress, update carefully using the project’s preferred method. Do not force-push a shared branch without understanding the impact.

Open a pull request that maintainers can review

Open the pull request against the correct upstream branch. Use the project template and provide enough information to make review efficient:

• What changed and why
• The issue or discussion it addresses
• Tests and commands run
• Screenshots, benchmark results, or sample outputs where relevant
• Compatibility, performance, or migration concerns
• Any follow-up work deliberately left out

Use closing keywords such as Fixes #123 only when the pull request completely resolves that issue. Keep the title specific and avoid promotional language. A small pull request with a precise description is easier to merge than a large one that mixes refactoring, feature work, and formatting.

Review the automated checks before asking maintainers to look at the PR. If CI fails, determine whether your change caused it and explain unrelated failures clearly. Respond to comments on the relevant lines, push follow-up commits, and mark conversations resolved only after addressing them. Review is collaboration, not a test of personal worth.

Build a credible contribution record

One merged contribution is more meaningful than a pattern of low-value submissions. Keep a short record of the problem, your approach, feedback received, and what you learned. Over time, this becomes evidence of engineering judgement rather than a list of activity.

Indian students and early-career builders can combine upstream contributions with a focused portfolio. Explore Indian student developers building open source AI for ideas, or study how to contribute to AI GitHub repositories in India when the project is connected to the local ecosystem. If you build with public libraries, contributing bug fixes, integrations, or documentation upstream can also reduce long-term maintenance for your own product.

Common mistakes to avoid

• Opening a large unsolicited PR without first discussing the scope
• Ignoring CONTRIBUTING.md or project-specific tooling
• Copying AI-generated code without understanding, testing, and licensing it
• Including secrets, private datasets, or customer information
• Treating maintainers as a support desk for an unresearched question
• Closing a review conversation without making the requested change
• Submitting cosmetic changes that create merge conflicts or distract from active work

AI coding tools can accelerate exploration, but responsibility remains with the contributor. Check generated code for correctness, security, licence compatibility, dependency changes, and hidden assumptions. Never claim tests passed when you did not run them.

A practical first-contribution checklist

Before opening your first pull request, confirm that you have:

• Read the repository’s contribution and code-of-conduct files
• Confirmed the issue is still available and the scope is agreed
• Created a branch from the current upstream base
• Reproduced the existing behaviour or established a baseline
• Added focused code, documentation, or tests
• Run the required checks and recorded the results
• Removed secrets, temporary files, and unrelated edits
• Written a clear pull request description

Start small, communicate early, and make the maintainer’s job easier. That is the repeatable path from a first GitHub contribution to trusted participation in an open-source project.