iTranslated by AI
Reflecting on My OSS Activities Over the Past Year
Introduction
I usually think casually about contributing to OSS in my spare time between work or on weekends. Over the past year, I've made several small contributions and released some of my own tools, so I'd like to write a reflection on this year.
Rather than focusing on implementation techniques, I'd like to talk about my approach to OSS—things like "how I noticed bugs or inconsistencies" and "the process behind getting a PR merged."
Although I am still learning, I hope this serves as a starting point for those who are interested in OSS but find that first step a bit daunting, helping them get a better image of what it's like to contribute.
Contributing to OSS
First, I will write about the OSS I contributed to this year, covering the flow from submitting a PR to it being merged, as well as how I felt at the time.
clap
clap is a CLI argument parser library for Rust. It is widely used as a standard library for building CLI tools in Rust due to its rich features and ease of use.
What kind of bug was it?
clap has a feature to generate completion scripts for various shells.
While developing my own CLI tool, I noticed some slightly strange behavior in this completion generation. Upon investigation, I found a bug where \{ would be displayed in the completion output under specific conditions.
When the type of an argument is defined as an enum:
// Multiple variants
enum Flag {
Foo,
Bar,
}
There was no problem when there were multiple variants like this, but:
// Single variant
enum Flag {
Foo,
}
The bug caused the completion candidates to display incorrectly only when only one variant was defined.
Since it's unlikely to have an enum with only one variant in normal use, it might not have surfaced much in actual production. However, I happened to have such a state in the early stages of developing my own tool, which is how I noticed it.
Investigation process
At first, I had no idea what was triggering it, when it occurred, or what conditions would prevent it.
I checked to see if an issue had already been opened but couldn't find one, so I started by creating a minimal setup to reproduce it.
I built a small reproduction project, tried cases with one enum variant and multiple variants, and checked them across zsh, bash, and fish.
As a result, I discovered that it reproduced only when there was a single enum variant, and that it only occurred in the fish shell.
Issue and PR
Once I understood how to reproduce it, I first opened an issue.
A little while later, I saw that a "help-wanted" label had been added, so I thought, "I'll try fixing it myself," and created a PR.
The cause was an issue with the escaping logic in the part that outputs completion scripts for fish, which wasn't working correctly when there was only one enum variant. I fixed that part, and it was successfully merged.
I feel like this was a bug I only noticed because I was building a CLI tool myself, which once again made me realize the benefits of personal development.
mason-registry
For many Neovim users reading this article, it probably needs no introduction, but Mason is a plugin for managing various tools like LSPs in Neovim, and mason-registry is what manages those tools.
Why I submitted a PR
Since I primarily use fish shell, I discovered that fish-lsp had been released. I thought it would be convenient if I could install it via Mason, but when I checked mason-registry, I noticed it wasn't registered.
I had a similar experience before where I submitted a PR to add a tool and had it merged, so I decided to send a PR this time as well.
The content itself was simple—just adding the fish-lsp information to the registry—but it took about six months for this PR to be merged...
Until the PR was merged
To summarize the process:
- Created the PR.
- Person A commented, "Looks good, but the CI is failing."
- Once the CI passed, I requested a review again.
- Another maintainer approved it.
- Person A, who initially commented, left it as "Changes Requested" and went silent.
- Due to branch protection rules, it couldn't be merged while that person's review was in that state.
- After some time, the owner dismissed that review and merged it.
While it's common for things not to be merged immediately, this time was particularly frustrating because the content itself seemed fine, but the reviewer was busy and didn't come back.
graphql-ruby
graphql-ruby is a library for implementing GraphQL servers in Ruby.
How I noticed
While reading the documentation for graphql-ruby, which I use at work, I noticed a part and thought, "Wait, isn't the meaning of this explanation reversed?"
The explanation for allow_null did not align with the actual behavior, so after comparing it with the code and other descriptions, I concluded that the text was simply inverted.
Creating the PR
Although there was a small chance that the naming of allow_null itself was a mistake, I checked the implementation code and verified the behavior. As expected, I found that the documentation was incorrect and submitted a PR to fix it.
Compared to PRs that modify code, this is quite light, but I like these kinds of documentation fixes because they might save at least one person from getting stuck while using it.
Turborepo
Turborepo is a monorepo management tool by Vercel.
Verifying information with an unreliable LLM
I noticed this while reading the documentation as well. On the page describing the eslint-plugin-turbo settings for ESLint, eslint-config-turbo was introduced as an example package name for installation.
I felt something was off, thinking, "Shouldn't this be eslint-plugin-turbo?" but since there was a possibility that my understanding was wrong, I asked an LLM just in case. Then...
It replied to the effect of: "The documentation says eslint-config-turbo, so your understanding is incorrect."
For a moment, I thought, "Oh, was I mistaken...?" but after re-checking the actual package and usage examples in the code, I felt more strongly that eslint-plugin-turbo was correct.
Ultimately, I created a PR because it seemed like the documentation side was indeed wrong.
Approved in an instant
This PR was approved in 18 seconds.
PR Created: 2025-10-10 13:53:52
Approved: 2025-10-10 13:54:14
It was so fast that it actually startled me.
After this fix was released, my GitHub account name appeared in the "Acknowledgments and community" section of the Turborepo blog. Seeing that made me feel quietly happy.
Personal OSS Projects
From here, I'll write about the OSS projects I created and released this year, including the background of why I made them and how I use them.
pez
Plugin manager for fish (see separate article for details)
I created pez as a plugin manager for the fish shell. Since I've written about it in detail in another article, I'll only give an overview here.
typolice
The "Notation Police" for commonly mistyped proper nouns.
I regularly act as the "notation police," making it a daily routine to point out minor notation errors, such as saying "It's Amazon S3, not AWS S3" or "It's VS Code, not VSCode."
typolice is a CLI tool that detects these types of notation errors in proper nouns.
While it might be useful for checking documents, blogs, or resumes for error-prone notations, I built it more as a joke tool that reflects my hobby of being the notation police.
Usage
The usage is simple: if you pass it text, it will tell you the suspicious notation and the preferred one.
$ typolice --text "AWS S3 is an object storage service."
Typo: AWS S3, Preferred: Amazon S3
Total typos found: 1
$ echo "Chat GPT is mentioned." | typolice --stdin
Typo: Chat GPT, Preferred: ChatGPT
Total typos found: 1
You can also pass a JSON dictionary to check things like your own product names.
$ cat custom.json
{
"My Service": ["MyService"]
}
$ typolice --dictionary custom.json --text "MyService ships soon."
Typo: MyService, Preferred: My Service
Total typos found: 1
Implementation and Use Cases
Internally, it doesn't do any special morphological analysis; it simply checks if any "NG patterns" from a dictionary exist in the text using the Aho-Corasick algorithm.
Since it runs fast, it could potentially be used for a bot that points out notation errors in followers' posts on Bluesky (I haven't done this).
Alternatively, I think it could be used quite practically by turning team-specific notation rules into a dictionary and integrating it into CI or pre-commit hooks (I haven't used it this way at all).
gh-slack-review
gh-slack-review is a GitHub CLI extension that gathers unreviewed PRs assigned to a reviewer and generates a message for posting on Slack.
Why I made it
When you create a PR on GitHub, just assigning a reviewer might result in the notification getting buried, and it might go unnoticed as time passes. Therefore, for important PRs or those I want reviewed quickly, I often follow a workflow of assigning a reviewer on GitHub and then also mentioning them on Slack.
However, I don't necessarily want to send a mention for every single PR; there's a delicate balance where I only want to post to Slack when I want to ask for reviews in bulk.
As a result, I was manually writing similar messages, copying and pasting PR URLs, and adding mentions every time, which gradually became a hassle.
So, I thought, "Wouldn't it be great if there was a command that collects a list of PRs and generates a draft message to post on Slack?" and that's how I created gh-slack-review.
Usage
Here is how to use it.
gh slack-review --slack "@John Doe" --github johndoe
When you run this, it fetches the unreviewed PRs currently assigned to johndoe on GitHub and outputs a message that can be pasted into Slack.
@John Doe
Please review these
https://github.com/org/repo/pull/123
https://github.com/org/repo/pull/456
I usually use it like this to put the output into the clipboard and then paste it into Slack:
gh slack-review --slack "@John Doe" --github johndoe | pbcopy
My Approach to OSS
I've talked about PRs and my own OSS projects so far, but there are really many ways to get involved with OSS, such as:
- Opening an issue
- Fixing typos or examples in documentation
I believe these kinds of things are also valid contributions.
Additionally, I feel that supporting OSS financially through mechanisms like GitHub Sponsors or Open Collective is an important form of involvement.
I contribute small amounts to several projects every month, much like a subscription.
By finding libraries you use daily or maintainers whose activities you appreciate—almost like finding a "favorite" to support—and backing them, you can truly realize how much your daily development is supported by OSS. It’s also simply fun to discover things like, "The person who made that tool also made this one!" It increases your opportunities for code reading and leads to technical learning.
In that sense, I highly recommend becoming a sponsor (within an amount that isn't a burden for you).
Conclusion
This article is just a story about "how it was in my case," and it’s by no means the only correct answer. However, I’d be happy if I could convey the idea that even with a relaxed approach—like digging a little deeper when you have some spare time, or turning things into a PR or a personal tool if they seem promising—you can still contribute to or create OSS.
If you’re interested in OSS but haven’t done anything yet, you could start with fixing a typo in documentation, contributing a small amount via GitHub Sponsors, or even just starring a repository that catches your eye... It’s okay to start with whatever you can manage.
I’m still learning too, but I’d be happy if we could liven up the OSS community together.
Discussion