github

For the past few years, my workflow for editing videos for my YouTube channel was the following:

1. Write and record narration / 'A-roll' using a teleprompter
2. Import recording into timeline, and chop out silent portions manually using the blade and/or range tools
3. Work on the rest of the edit (adding 'B-roll' and inserts).

Step 3 is where the vast majority of editing time is spent, especially when I need to add in charts, motion graphics, etc.

Saying yes is easy—at first.

It makes you feel better. And it makes you feel like you can do anything! And the person you're saying yes to also gets a happy feeling because you're going to do something for them.

Saying no is hard. It's an admission you can't do something. And worse still, you're disappointing someone else who wants you to say yes.

But here's the thing: none of us is a god. We're people. We have a certain amount of mental resources.

Some people are kind of crazy and can do a lot more than you or I can, but nobody can do it all. And sometimes you can burn the midnight candle for a little while, but you're just building up debt. Every 'Yes' is a loan you have to pay off.

Or: Why can't you just merge my ten-line PR already?

I maintain over 200 open source projects. Apparently (this is news to me) I am ranked in the top 200 GitHub users by followers, and there are 18,000 forks and 42,000 stars across my repos.

On an average day, I see between 50-100 emails across my repositories for issues and pull requests, and I filter those down to about 5-10 that I deem worthy of a personal follow-up.

I merge between 5-10 Pull Requests per month, and commit new code or fixes around 166 times per month.

I'm one maintainer, in a tiny corner of the Internet, maintaining a small but broad set of projects from Ansible roles for infrastructure automation to a few small but still-used PHP and Node.js libraries.

Dealing with burnout

There have been a few times I've burned out. That's typical for many maintainers. You either learn coping strategies or burn out completely, and in the best case end up a woodworker or farmer. At least that's what I see most of the time.

For a few of my task-oriented livestreams, I wanted to be able to have an easy-to-follow list of tasks present in an OBS scene, with an indication of which task was currently in-progress.

I had seen a similar overlay on NASASpaceflight's livestreams (example), and liked the simplicity:

I started searching for an OBS plugin I could use to replicate that overlay, but was coming up with nothing. There was some plugin that seemed like it fit the bill, but it had been abandoned a while back. Most of the other overlays were a lot more specific to gaming, had few options for customization, or only worked with services other than OBS.

A week or so ago, I got the following email in my inbox:

Almost exactly one year ago, my GitHub Sponsors account was approved, and I issued a meek call to action:

You can now sponsor my open source work through GitHub Sponsors: https://t.co/h2GXLE9ZP6 #opensource

I just spent the past 6 hours migrating some of my open source projects from Travis CI to GitHub Actions, and I thought I'd pause for a bit (12 hours into this project, probably 15-20 more to go) to jot down a few thoughts.

I am not one to look a gift horse in the mouth. For almost a decade, Travis CI made it possible for me to build—and maintain, for years—hundreds of open source projects.

I have built projects for Raspberry Pi, PHP, Python, Drupal, Ansible, Kubernetes, macOS, iOS, Android, Docker, Arduino, and more. And almost every single project I built got immediate integration with Travis CI.

Without that testing, and the ability to run tests on a schedule, I would have abandoned most of these projects. But with the testing, I'm able to keep up with build failures induced by bit rot over the years and review PRs more easily.

What went wrong with Travis CI?

From the outset, Travis CI was built to integrate with GitHub repositories and offer free open source CI. At one time it was showered with praise on Hacker News and elsewhere for its culture and ethos.

For many new Ansible-based projects, I build my tests in Molecule, so I can easily run them locally or in CI. I also started using GitHub Actions for many of my new Ansible projects, just because it's so easy to get started and integrate with GitHub repositories.

I'm actually going to talk about this strategy in my next Ansible 101 live stream, covering Testing Ansible playbooks with Molecule and GitHub Actions CI, but I also wanted to highlight one thing that helps me when reviewing or observing playbook and molecule output, and that's color.

By default, in an interactive terminal session, Ansible colorizes its output so failures get 'red' color, good things / ok gets 'green', and changes get 'yellow-ish'. Also, warnings get a magenta color, which flags them well so you can go and fix them as soon as possible (that's one core principle I advocate to make your playbooks maintainable and scalable).

For the past few years, the number of issues and PRs across all my GitHub repositories has gone from a steady stream to an ongoing deluge. There are currently over 1,500 open issues across my 194 GitHub repositories, and there's no way I can keep up with all of them.

Initially, I went through each issue in each project's issue queue on a monthly basis (mind you, this was—and is still—done on nights and weekends in my spare time). That slipped to a quarterly task... and has now slipped to only happening for higher-profile projects once or twice a year.

October 2020 Update: This post still contains relevant information, but one update: the community.kubernetes collection is moving to kubernetes.core. Otherwise everything's the same, it's just changing names.

The Ansible community has long been a victim of its own success. Since I got started with Ansible in 2013, the growth in the number of Ansible modules and plugins has been astronomical. That's what happens when you build a very simple but powerful tool—easy enough for anyone to extend into any automation use case.

One thing that was not obvious when I was setting up GitHub Actions on the Ansible Kubernetes Collection repository was how to have a 'CI' workflow run both on pull requests and on a schedule. I like to have scheduled runs for most of my projects, so I can see if something starts failing because an underlying dependency changes and breaks my tests.

The documentation for on.schedule just has an example with the workflow running on a schedule. For example:

Separately, there's documentation for triggering a workflow on events like a 'push' or a 'pull_request':