Update: Tackling a large volume of simple problems in an Open Source project

Last time on "Tackling a large volume of simple problems in an Open Source project", your hero left off with 263 endpoint items needing to be investigated. Since then, more than 140 items have been sifted through. Stay tuned for the next thrilling installment of... this project!

As you may expect, the first task in a project like this is to triage the items. I've been going through these as I have time, trying to sort the work to be done. So far, the items I've processed fit into one of four categories:

1. Ones that do need more work (this is the vast minority of them)
2. Ones which don't have a semantic API function, and therefore can't be fixed because they don't exist in the library... but probably could be useful to add later (pin in that)
3. Ones which don't have a semantic API function, and certainly shouldn't have one because they're legacy or deprecated functionality in the API
4. Ones which have already been fixed 🎉

Let's break these down.

Ones which do need more work

For these endpoints, I'm going to start off with a test. While I can tell from just reading the code whether or not a 204 will break it, the test solves a number of problems outside of this proof.

1. I get a quick and easy indication of whether the fix is there
2. Prevent regression if a later merge breaks stuff
3. Adds to overall test coverage, which promotes the health and well-being of the project

Once I have a test, if it fails then I know that I need to apply a fix. Once I apply the fix, the test should pass.

Ones lacking a semantic API function

There are two groups of endpoints lacking a semantic API function: ones which shouldn't be added, and ones which eventually may be helpful to add.

I'm skipping all of these endpoints for this project, as the scope of this project is to find and fix 204 errors with no HTTP response body. However, I am noting which ones I think could benefit from being added, and I'm going to discuss this with the maintainer once I'm done with this project. It could be fun to add some of this in future projects.

Ones which have already been fixed

There are a small handful of items which were fixed before starting this larger audit. Those ones have been merged, and are still awaiting release.

Because this is a potentially larger undertaking, I'm going to be submitting independent PRs for each one I find, which will allow me to contribute back fixes that are usable even if I end up getting distracted (I get distracted a lot, between stuff going on with my kids, and with work, etc).

Am I still having fun?

When I started this project, I did it knowing that this wasn't going to be the most enjoyable thing I could do. This is the sort of thing I do at work regularly as part of larger initiatives. It's not my favorite, but it's often necessary in order to improve the project.

I'm not enjoying the triage aspect. I am, however, really enjoying contributing back to this project. octocrab is a really great project for anybody who wants to learn Rust, and for someone like me who spends large amounts of time automating stuff in GitHub, this library is essential.

Fin.

Quality open source is only achieved by folks doing the sometimes boring work that it takes to get there. We should do more to highlight the tedium so that maintainers aren't the only ones stuck doing the boring parts.

Join me! Find a project, and add some tests, or write some documentation. Help the maintainers with some of the chores. It will make the world a better place.