A quick followup to my previous missive.

Triage

I’ve lined up a handful of other Github users for each of my major repos, granted them the triage bit in most cases, and am easing into a weekly review cadence.

  • In one case, I gave a couple folks more privileges as I’ve already collaborated with them for a while - though until more of the below is taken care of, it’s largely symbolic.
  • Since the folks involved all have their own lives to live, the speed at which things are moving differs between projects - but the approach is already paying off in at least one area so it’s a good sign.
  • Trying to figure out (ideally limited) behind the scenes discussion is a challenge - I’m using Github’s newish org/team-level discussions feature for now, but it’s basically just a repositioned version of their Issues framework, which isn’t superb.
    • Naturally, other tools have their own issues - either they’re proprietary (Slack), require manual hosting labor (most OSS solutions), or are too easy to lose track of / very difficult to backfill (email).

Feature release planning

As part of the above, I’ve got a small list of low-difficulty high-impact Paramiko PRs lined up to review for its next feature release.

However! I want to give Fabric and Invoke some more love first, as they haven’t had any releases yet this year. Fabric 2 especially needs some features added so it’s not quite so sad looking - heck, in replying to a mailing list email earlier today, I was reminded of multiple missing features (large AND small) that are just crying out to be hacked on.

(A whole ’nother blog post: the uncomfortable tension between “I should hack on $thing” and “but what if somebody has already filed a PR for $thing and it’s not quite what I had in mind?”. It makes “just getting stuff done” on OSS that much more painful for us maintainer types…)

Admin changes

I’m in the middle of trying out a pile of administrative changes on a smaller project (Lexicon) which should give me a useful checklist to roll through for the bigger ones:

  • As noted in the last post, I am trying out Circle-CI, both because Travis fired all their senior staff a few years ago, and because Circle has some legit neat tech that Travis doesn’t (or didn’t last I looked - they do seem to have changed their .yml some lately).
    • E.g. using orbs to refactor my various CI YAML files seems like it could be a decent win, as is the option to use custom Docker containers.
  • I’m likely moving from setup.py to Poetry-driven pyproject.toml after some success using it at the dayjob.
    • It has a lot of rough edges still (yes, like I should talk) but so far none that can’t be worked around, and the core benefits of smarter dependency management and streamlined environment use are something I immediately missed when coming back to OSS from work projects.
    • There’s a chance some of my more complex setup.py files will not be amenable to this change, but I’ll find out. The overall packaging world is moving away from executable packaging code either way, so…
    • I’m anticipating this throwing a wrench in the works of some/all OS package maintainers.
      • My relationship to such folks has not been as concrete as I’d prefer anyhow; if this describes you, please email me to say hi! I need to build a contact list.
  • Also as noted prior, renaming master to main.

Eyes on the collaboration prize

Building on the above, I want to make it clear that the NEXT batch of admin changes will be aimed at streamlining collaboration with both privileged and unprivileged contributors:

  • More rigorous CI: automate as much as possible so there’s less “please add docs here” type busywork for triagers, myself or others, and less frustrating ticket tennis for PR submitters (or at least, they get to play tennis with an immediately responsive CI result or bot instead of every-few-days maintainer chat).
  • Ticket bots. If only so the numbers of open things don’t look so heinous. I don’t love the sweep-it-under-the-carpet feelings here, but it helps nobody to have tickets moulder forever in an open state if they’ll never rise to the top of the priority stack.
  • Automated releasing: I’ve already got Invoke task collections for this that make releasing mostly turnkey. However I need to remove that “mostly” qualifier, so that releasing is even easier for me and eventually others. I also need to tie releases into other APIs such as Tidelift.