They're often quick fixes, taking no more than 10 minutes to fix. I usually deploy them on Write.as once they're done and I've verified the fix. I know the software well enough to feel confident deploying new code so quickly, but of course, there are always blind spots.
So I'm going to start making these small changes with pull requests, instead of committing directly to develop. This puts them on the same field as everyone else, and gives everyone visibility into what's going into the codebase (remember, you can watch the GitHub repo to get these notifications, or follow @firstname.lastname@example.org in the fediverse).
This is the main reason I'd like to do it this way — to notify everyone and provide a comment period, rather than a formal code review like we do with larger features.
I'm going to leave these pull requests open for a week, and then merge if no one brings up any issues. If it turns out that the change caused some kind of regression, etc., we can fix it and reference the original pull request.
I got the number of open issues on WriteFreely down below 10 again today, after reaching its high of 13. After some time maintaining this project, I think keeping this number low is actually kind of important.
We tell everyone that Github is only for reporting bugs, and that we're very responsive there. Keeping this number low backs this up.
A low number of issues makes it easy for others to find bugs they might've encountered, as well.
Keeping this number low signals that the project is active and moving forward.
For a #FOSS project like ours, with a strong vision / direction to follow and core developers pushing that forward, I'm finding this setup really works well for us. We gather input on our forum, turn that into long-term plans in Phabricator, and adjust to real world usage on the platform that's closest to it all, Github.