Bug triage as entry point

I'm the main person doing bug triage for Codidact, which means I go through bug reports and requests that our users have made on our sites and, for the ones that will require code changes, file and tag GitHub issues for our developers. I tend to do these in batches and, unless it's urgent, with a delay -- sometimes the community wants to discuss different solutions first, so we let that play out.

I've been doing a batch of triage over the last few days. Sometimes a bug looks small and easy and I think "you know, fixing that would be less effort than writing it up and tagging it". Sometimes that's actually right. (I have three small PRs open right now.) Other times my attempt to fix it is followed by me writing up the bug. :-) Either way I'm learning stuff, which is pretty cool. Mostly I've been learning about front-end stuff, focusing on the "V" in "MVC". I hope to advance to Ruby/Rails; there are features I want that we haven't gotten to yet and maybe some of them are small enough for a beginner.

Someone asked me if triage is a chore. It's not; I actually like doing what I'm doing, because it's not just copying but analysis and refinement. I'm finding that I can bring a fair bit of architectural knowledge and history to the process. A bug report is a symptom, and sometimes the issue I end up filing is different (with a paper trail). I might not write much code, but I'm pretty happy with my GitHub contributions. :-)