Your first open-source contribution as a student, command by command

Choose an issue you can actually close

Filter hard before you start. A good first issue has:

• A label such as good first issue, documentation or help wanted.
• A clear description of the expected behaviour, ideally with a reproduction.
• No open pull request already linked to it, and no one who has said "I'm working on this" recently.
• A maintainer who has responded to someone in the last few weeks. Check the dates on recent comments.

Prefer a project you use in coursework: pandas-adjacent tools, plotting libraries, dataset utilities, or even your college club's public repository. You'll understand the problem faster.

Read CONTRIBUTING.md (or the contributing section of the documentation) completely. It tells you the branch naming, test commands, code style tools and whether you must sign anything before contributing. Skipping it is the most common reason a first pull request gets a long list of review comments.

Say you're taking it

Post one short comment on the issue before writing code:

"Hi, I'd like to work on this. My plan is to add a test for the empty-input case in `load_csv` and change the function to raise a `ValueError` with the message suggested above. Does that approach sound right?"

This prevents duplicate work and often gets you a useful pointer from a maintainer.

The Git sequence

Replace ORIGINAL-OWNER, PROJECT and YOUR-USERNAME with real names. First fork the repository using the Fork button on GitHub, then:

# 1. Clone YOUR fork and enter it
git clone https://github.com/YOUR-USERNAME/PROJECT.git
cd PROJECT

# 2. Point a second remote at the original project, so you can sync later
git remote add upstream https://github.com/ORIGINAL-OWNER/PROJECT.git
git remote -v

# 3. Start from the latest main branch of the original project
git fetch upstream
git checkout -b fix-empty-csv-error upstream/main

# 4. Set up the project exactly as its guide says, for example:
python -m venv .venv
# Windows: .venv\Scripts\activate    macOS/Linux: source .venv/bin/activate
pip install -e ".[dev]"

# 5. Run the existing tests BEFORE changing anything
python -m pytest

# 6. Make your change, then run the tests again
python -m pytest

# 7. Review exactly what you changed, then commit
git status
git diff
git add path/to/changed_file.py tests/test_changed_file.py
git commit -m "Raise ValueError for empty CSV input in load_csv"

# 8. Push the branch to your fork
git push -u origin fix-empty-csv-error

Some points that trip students up:

• Step 3 creates your branch from the original project's main, not from your fork's possibly outdated copy. If the project's default branch is called something else, such as master or develop, use that name.
• Step 4 varies. Some projects use requirements-dev.txt, some use other tools. Follow their guide rather than this example.
• Step 5 matters: if tests already fail before your change, note that in your pull request so reviewers don't blame your code.
• In step 7, add only the files you meant to change. Don't commit your virtual environment, editor settings or data files.

Open the pull request

On GitHub, open your fork; it will offer "Compare & pull request". Write a description reviewers can check quickly:

Fixes #123

What changed
- load_csv now raises ValueError("Input file is empty") for a zero-byte file
  instead of returning an empty DataFrame silently.
- Added test_load_csv_empty_file.

How I checked
- python -m pytest: all tests pass locally (Python 3.12, Windows).
- Tried the reproduction from the issue; it now raises the expected error.

Notes
- I did not change the behaviour for files with a header but no rows;
  happy to handle that too if you want it in this PR.

On GitHub, "Fixes #123" links the issue so it closes automatically when the pull request is merged into the default branch.

Handling review comments

Reviewers will ask for changes. That is normal, not rejection. Make the edits on the same branch, commit, and push again; the pull request updates itself:

git add path/to/changed_file.py
git commit -m "Use the project's error message style"
git push

If the main branch moved while you waited and the project asks you to update, sync with upstream:

git fetch upstream
git rebase upstream/main
python -m pytest
git push --force-with-lease

--force-with-lease refuses to overwrite the remote if someone else pushed to your branch, which is safer than a plain --force. If rebasing feels risky, ask whether a merge commit is acceptable; some projects prefer one or the other.

Reply to each comment briefly ("Done in the latest commit") and don't argue style. If a pull request gets no response for a couple of weeks, one polite follow-up comment is fine.

Putting it on your resume

Link the merged pull request, not just the repository. Describe it in one line:

"Contributed a fix to [project] making empty-file input raise a clear error; added a regression test. Merged PR linked."

Programmes such as Google Summer of Code offer mentored, longer open-source projects for students; check the programme's official site for current eligibility and timelines. A few merged small pull requests in the months before you apply make your application more concrete.

This fork-branch-test-review loop is how client code gets changed on real engagements too, which is why the FDE for Freshers programme teaches Git and pull-request review early. The FDE hub explains the role, and the free skill check shows which of these skills your resume already evidences.