The pleasure of repo maintenance…
What do I mean by that? I mean there is an enjoyable balance between being able to edit public repositories at GitHub and leaving appropriate time for your co-maintainers to comment, edit, and just simply add ‘another set of eyes’ to your changes.
In Summer 2020, I on-boarded as a co-maintainer of the Library Carpentry SQL Lesson on GitHub – which I mentioned in a post in August 2020. The summer before, in 2019, I became a Carpentries Certified Instructor, a logical next step in my relationship and growing interest with the Carpentries community. After that on-boarding, the new SQL lessons maintainers, some of whom had been there a while and are happy when fresh hands show to help maintain a decent number of issues related to the repo. This is mostly a labor of love, all of us, I think, have full time gigs, this, like most of our academic professional engagement contributes to our development as professionals and aids our learning about topics in the field at large (in my, case, the technical services side of librarianship). We used that ‘fresh’ energy to tackle a number of issues with the repository: some as simple as clarifying wording, some about adding better examples, and some abut testing and updating the lesson for reasons of technology shift in one place or another. We reduced the number of issues by half in what is commonly called a ‘sprint’ – wherein we set apart a number of hours to ‘get things done.’ Yay!. It was successful. But there is still more work to do.
I have a tendency to want to jump in quickly and get things done – I still have that tendency because I think and move quickly. Maybe a strength, sure, but this may also be a hindrance and hobble a relationship from time to time. I admit this and want to get better in this area where appropriate. But, one of the true pleasures of these kinds of collaborations is that fantastic and simple solutions are brought to the fore.
My case-in-point is the back-and-forth I had with a co-maintainer I had on Monday, 04 January 2021 about some language clean-up and clarity under the heading, ‘More Terminology,’ I made a number of changes and asked for feedback. I got an ‘all good’ but with the caveat that the qualifier I had already refined from language that was there previously, may not be necessary. I agreed and made the change, as well as a couple other language tweaks.
The result: Tighter and more direct language that should lead to less confusion for the folks who use the lesson over time. The real point is that even in this little edit, it was good to have ‘another set of eyes’ on my suggestion and to wait for the comments to be made. Again, this is not terribly important, the change itself. This post is about the community aspect of the work – which, as the post title says, is a pleasure. Thank you to my co-maintainers.
As a side-bar, I note that many of the changes I make to GitHub repositories, I make from the command line (CLI). This just involves a process of downloading, via some commands in the terminal shown below, the repository from GitHub (or wherever the repo is), and making a local copy of it on your own machine, making changes to the files of whatever form, and pushing the changes back to the repo via other commands. Not in itself that complicated, but thanks to another fellow Carpentries community member’s tutorial last year on this skill, I was able to take my repo skills up a notch and edit repos via the CLI. Another big shout out to the Carpentries community.
This is not anything important really, but I draw attention just because it reveals the flow of specific code-bases and attempts to archive said code (meaning, code deemed meaningful to a wide spectrum of users globally – or something like that).
I have been working on the Library Carpentry SQL curriculum code and language because I was recently on-boarded as a co-maintainer of the SQL curriculum. The co-maintainers had a sprint on Friday, August 14, 2020 – during which we threw a lot of time into closing issues and determining the nature of some of the work ahead of us. We closed almost half of the issues. This work then, as it updated the specific repositories in GitHub, then got included in the code being sent routinely to the GitHub Arctic Vault for archiving.
Again, not a big deal, but I was thus given a ‘badge’ for contributing to code that is being archived in that vault. I ONLY note this because it reveals the flow of code and intentions to keep around for the long term (thus the archive). I think this is pretty interesting to see the process ‘live.’
Thank you for reading