# From Zero to First PR: How I Contributed to an Open-Source AI Project as a Beginner > Source: > Published: 2026-07-15 12:24:16+00:00 I stared at the GitHub page for what felt like forever. The repo had thousands of stars, hundreds of issues, and a long list of contributors who clearly knew what they were doing. Me? I had a few small personal projects, some half-finished tutorials, and a nagging feeling that I wasn’t “ready” to contribute to real open-source software. Especially not an AI project with fancy models, complex pipelines, and people publishing papers off the codebase. But I wanted in. I wanted to learn how real-world AI systems are built, to get feedback on my code, and to be part of something bigger than my local src/ folder. So I made a deal with myself: no more waiting until I feel “ready.” I’d go from zero to my first pull request (PR) in one focused push. Here’s exactly how I did it, what I learned, and what I’d tell anyone hesitant about contributing to an open-source AI or machine learning project for the first time. **Step 1: Pick the Right Project (Not the Biggest One)** The biggest mistake I almost made was aiming for the most famous AI repo I could find. Big projects are great, but they can be intimidating and slow for a first-timer. Instead, I looked for: **Active maintenance**: recent commits, issues being closed, maintainers responding. Clear contribution guidelines: a CONTRIBUTING.md or at least a solid README. **Beginner-friendly issues:** labels like good first issue, beginner, or help wanted. Scope I could understand: I didn’t need to grasp the entire codebase, just enough to fix one small thing. **I ended up choosing a mid-sized open-source AI library**: not unknown, not legendary. Perfect. If you’re searching now, try queries like: “awesome open source llm” “open source machine learning projects good first issue” “open source AI tools GitHub” Then scan their issues tab for beginner-friendly tasks. **Step 2: Set Up the Project Locally (Without Panicking)** Once I picked a project, the next hurdle was getting it to run on my machine. The repo had a typical structure: project/ README.md CONTRIBUTING.md requirements.txt pyproject.toml src/ package_name/ **init**.py models/ data/ utils/ tests/ examples/ I followed these steps: Fork the repo to my own GitHub account. Clone my fork locally: git clone [https://github.com/your-username/project-name.git](https://github.com/your-username/project-name.git) cd project-name Create a virtual environment: python -m venv .venv source .venv/bin/activate # or .venvScriptsactivate on Windows Install dependencies: pip install -e ".[dev]" # or: pip install -r requirements.txt Run the tests to make sure everything worked: pytest If the tests passed and the example scripts ran, I knew my environment was sane. Pro tip: if the project uses Docker, use it. A working docker-compose up can save you hours of dependency headaches. **Step 3: Choose a Small, Scoped Issue** I filtered the issues by good first issue and looked for things like: Fixing a typo in docs. Adding a missing example. Improving error messages. Writing a small test. Fixing a clear, isolated bug. I avoided: Huge refactors. Vague “improve performance” tasks. Anything that required deep knowledge of the entire architecture. I picked an issue titled: “Add input validation for TextDataset and raise a clearer error when max_length is negative.” Perfect. One class, one behavior, very testable. **Step 4: Understand the Code (Without Reading Everything)** I didn’t try to read the entire codebase. Instead, I: Searched for the class name (TextDataset) in the src/ folder. Opened the file and read just that class. Looked at existing tests for TextDataset to see how it’s used. Ran a small example from the docs or examples/ folder to see it in action. For my issue, the original code looked roughly like this: class TextDataset: def **init**(self, texts, max_length: int = 128): self.texts = texts self.max_length = max_length ``` python def __getitem__(self, idx): text = self.texts[idx] # truncate or pad to max_length... return processed_text ``` No validation on max_length. If someone passed -1, weird things would happen later. **Step 5: Make the Change (and Write a Test)** I added simple input validation: class TextDataset: def **init**(self, texts, max_length: int = 128): if not isinstance(max_length, int): raise TypeError("max_length must be an integer") if max_length <= 0: raise ValueError("max_length must be a positive integer") ``` python self.texts = texts self.max_length = max_length def __getitem__(self, idx): text = self.texts[idx] # truncate or pad to max_length... return processed_text ``` Then I added a test: import pytest from package_name.data.dataset import TextDataset def test_text_dataset_rejects_negative_max_length(): texts = ["Hello", "World"] with pytest.raises(ValueError, match="positive integer"): TextDataset(texts, max_length=-1) def test_text_dataset_rejects_non_int_max_length(): texts = ["Hello", "World"] with pytest.raises(TypeError, match="integer"): TextDataset(texts, max_length="128") Running pytest confirmed my tests passed and I hadn’t broken anything else. Step 6: Open the Pull Request (Without Overthinking It) I created a new branch: git checkout -b fix/text-dataset-max-length-validation Committed my changes with a clear message: feat(data): validate max_length in TextDataset **I made the requested changes:** if not isinstance(max_length, int): raise TypeError(f"max_length must be an integer, got {type(max_length).**name**}") if max_length <= 0: raise ValueError(f"max_length must be a positive integer, got {max_length}") Added the extra test: def test_text_dataset_rejects_zero_max_length(): texts = ["Hello", "World"] with pytest.raises(ValueError, match="positive integer"): TextDataset(texts, max_length=0) And pushed again. A day later, the PR was merged. **My first contribution to an open-source AI project. Done.** What I Learned (Beyond the Code) You don’t need to be an expert. You just need to be willing to learn and follow the project’s norms. **Small contributions matter**. Docs, tests, and tiny fixes are critical and often overlooked. Maintainers are usually kind. Most want helpful contributors, not perfect ones. Reading real code is the best tutorial. You’ll see patterns, testing styles, and design decisions you won’t find in courses. One PR makes the next one easier. After the first, the fear drops dramatically. **Key Takeaways** Start with an active, beginner-friendly open-source AI or ML project. Set up the repo locally and get the tests running before touching code. Pick a small, well-scoped issue (docs, tests, validation, simple bugs). **Write tests for your changes; **maintainers love that. Treat code review as a learning opportunity, not a judgment. Your first PR doesn’t have to be impressive; it just has to be real. **Ready for Your First PR?** If you’ve been thinking about contributing to an open-source AI or machine learning project but keep waiting for the “right time,” consider this your nudge. What’s one small improvement you could make in a project you already use? A clearer error message, a missing test, or a doc example? If you want, drop the repo you’re eyeing (or the issue you’re considering) in the comments. I’m happy to help think through whether it’s a good first PR and how to approach it.