Comprehensive Guide to Contributing to Open Source
Introduction
This post documents the process of identifying, fixing, and submitting fixes for issues in the open-source software I used while developing SceneMaker. I’ve outlined where I found opportunities to contribute, the order in which I submitted my changes, and which ones were accepted.
SceneMaker runs on open-source software. Whether it’s loading models, transcribing speech, or splitting the screen, all these functions rely on tools created by others. As I used the software, I noticed issues, and fixing and resubmitting those fixes is what constitutes a contribution.
As of October 12, 2026, there have been 24 contributions from other developers.
| Type | Count | Details |
|---|---|---|
| Pull Request | 11 | 9 of which were merged |
| Issue | 9 | Problem reports |
| Discussion | 4 | Sharing use cases and asking questions |
Full list → Contributing to the Open Source Ecosystem
This post covers the following topics.
- Where do opportunities to contribute come from?
- The three forms of contribution
- Steps to Submitting a Contribution
- Case Study — From Issue Report to Implementation
- Common traits of merged contributions
- When a Contribution Is Rejected
1. Where Do Contribution Opportunities Come From?
- You don’t have to go out of your way to find places to contribute. They arise from the tools the pipeline actually uses.
-
There are two paths.
-
Stuck while using it — The language identification model returned an error-free result but stopped at the first classification stage. Upon investigating the cause, it turned out to be a problem with the library.
-
Something noticed while reading code — While reading library code to verify its behavior, I discovered that an option present in one part was missing in another.
-
-
Since these are tools I use myself, I know the exact conditions under which the problem occurs. This is the most helpful factor when creating a reproducible example.
2. Three Forms of Contribution
- The form varies depending on what you know.
| Form | When to Use | Example |
|---|---|---|
| Pull Request | You know the cause and how to fix it | Fixing an issue where playback time display breaks for files longer than 10 minutes |
| Issue | The problem is reproducible, but the maintainer must decide how to fix it | Reporting an issue where some videos are rendered as a single frame |
| Discussion | It’s not a bug, but a use case or design question | Sharing how to store video scenes in a vector database |
- If there are multiple ways to fix the issue or if it affects other features, an Issue should be created first, before a PR.
- After reporting it as an Issue, create a PR once the direction is determined. The example in Section 4 follows this order.
3. Steps to Submission
- Reproduction is the first step. Create the shortest example that actually demonstrates the problem, and paste the output exactly as it appears.
- Check for duplicates. Search not only the titles but also the descriptions, checking both open and closed issues. Also check for any open PRs that address the same file.
- Rules vary by repository. Each repository specifies which branch to send the PR to and the format for the change log.
- Keep fixes small. One PR per issue. Report any other noticeable issues separately.
- Include tests. If there are tests that fail before the fix and pass afterward, the reviewer can verify the change themselves.
- Submitting is only half the battle. Respond to reviews, implement requested changes, and log the results.
4. Case Study — From Issue Report to Implementation
- We use SpeechBrain’s language identification model to detect the language in broadcast audio.
- When we configured the system to download the model file directly to a specified folder, the model loaded without errors but stopped after the first classification attempt.
- Reproduction — I created a short example involving the download of a single file. The file was not present at the path returned by the library.
- Cause — The file was saved under its original name, but the library reported that it had been saved under a different name and returned that path. Since the model weights were the same for both names, there was no issue; only the label file with the different name was missing.
- Reporting — I created an issue detailing the reproduction example, the location of the cause, and the verified version.
- Fix — I modified the code to move the downloaded file to the specified name and added one test to verify the same scenario, then submitted it as a pull request.
- Merge — Five days later, the maintainer approved and merged the pull request.
5. Common Characteristics of Merged Contributions
- Small. Of the nine contributions, the largest was 81 lines, and most were around 30 lines. With one exception, each contribution involved three or fewer files.
- Includes tests. All nine contributions included tests.
- They follow existing conventions. The three contributions that added options did not create new methods but aligned with how adjacent features in the same repository were implemented.
- The time it takes varies by repository. Some were merged on the same day they were submitted, while others took over three months.
6. Cases Where the Pull Request Was Not Accepted
- Not all submitted pull requests are accepted. Here’s what I learned from the closed cases:
| Case | What I Learned |
|---|---|
| The same fix had already been submitted in another PR | Before submitting, expand your search to include closed PRs and review the full text |
| The maintainer fixed the issue directly | The issue has been resolved. If the fix isn’t clear, ask via an issue first |
- Some repositories explicitly state that they do not accept contributions written using AI tools. Read the contribution guidelines and policies first, and do not submit to such repositories.
- Do not send multiple pull requests to a single maintainer in one day. It is common for one person to manage multiple repositories.
- Do not remove closed pull requests from the list; instead, note the circumstances. This is to avoid repeating the same mistake.
Conclusion
I’ve summarized my process of contributing to open source while building SceneMaker.
The current status is as follows:
- There have been 24 contributions from other developers, and 9 of those PRs have been merged.
- Contributions stem from tools actually used in the pipeline.
- I reproduce the issue, check for duplicates, make small fixes, and submit them along with tests.
- All merged contributions are small, include tests, and follow the repository’s guidelines.
I continue to contribute. Details for each contribution can be found in the list below.
Contributions to the Open Source Ecosystem
Reference Links)
- https://github.com/vllm-project/vllm
- https://github.com/speechbrain/speechbrain
- https://docs.github.com/en/get-started/exploring-projects-on-github/contributing-to-a-project
This article presents the results of research conducted with support from the Ministry of Science and ICT and the National IT Industry Promotion Agency’s “2026 Open-Source AI and Software Development and Utilization Support Program.”