On Oct 22, I read the word "Merged" twice. It was my first contribution to Forem (the platform that hosts dev.to). I don't write Ruby. A coding ass...
For further actions, you may consider blocking this person and/or reporting abuse
It’s inspiring how you pushed past the fear of working with an unfamiliar codebase and kept going until your contribution was merged. You don’t have to know everything before making your first contribution. Sometimes, taking that first step is the hardest part.
This is a useful reminder that contribution quality depends on the feedback loop, not language ownership. A small note on how you narrowed the issue, validated the proposed change, and handled maintainer feedback would make the contribution path reproducible for others.
There are 3 parts of the post on this: 1) my 34-issue triage, 2) the CI run, and 3) my question about the extra line. The how-to is the tips list at the end. What was lacking?
Fair point—the structure is there. What I was missing was the decision trail connecting the 34-issue triage to the CI run: which issues were selected, what made them representative, and whether the extra-line question changed the final patch. A short link between those three steps would make the tips easier to apply.
Nice little story describing how you went about this!
Very pragmatic approach - you didn't bother (at least that's what I assume) getting the whole Forem application running on your dev box ... :-)
Maybe you even didn't install Ruby or Rails (because you don't know Ruby anyway) ... :-)
For this (admittedly simple) issue, AI allowed you to bypass all of that!
leo, accurate on both counts.
I had no running Forem and no Ruby installed, and CI was my test machine.
Sure, it was “admittedly simple”, but the price still showed up: CI passed with an unused line in the code, and I did not spot it. For a more complicated problem I would want a running copy. Would you have set one up for this one?
Yeah, “admittedly simple” was certainly not meant to denigrate (but I don't think you took it as such) - on the contrary, I think it's pretty clever and pragmatic how you approached this - the fact that, with the help of AI and CI you could tackle this one without setting everything up locally is absolutely a boon ...
For a more complicated ticket I'd probably want to get it setup and running locally - but for a ticket like this I'd also want to avoid the hassle, if possible :P
leob, I didn’t read it that way. I use the same rule you do: if it’s simple, I don’t bother setting it up. If it’s complex, I would.
Thought already that you didn't read it that way! :-)
That first merged contribution is a great reminder that open source is mostly about reducing uncertainty for maintainers. A focused reproduction, narrow change, and clear verification often matter more than knowing every corner of the language up front.
Congrats on the merge — and thanks for writing up the unglamorous middle part. The bit that stuck with me is verifying the issue was real before writing any code: with 34 open issues and some that weren't bugs at all, that triage step is the actual work. Also, letting CI run the tests and saying so in the PR is genuinely good advice for anyone contributing to a stack they don't run locally.
correction with respect to credit: I never actually reproduced the bug. I had no running copy of Forem.
I had the assistant read the code and it found that the badge and tab counted differently.
That was my check for whether it was real.
The 12 weeks is the real story here. The AI writing the Ruby is the easy part; staying patient through review, rebases and silence is the part nobody can do for you. Also love that your first merge landed in the platform you post on. Congrats!
Twelve weeks, mostly waiting, and CI as the only test machine. That badge mismatch is a neat catch to ship without Ruby installed.
nice story