Forming a beets "core team"


Hi, everybody,

To my utter shock, I’ve been working on beets for more than 10 years now. I’ve learned a ridiculous amount through developing beets and have deeply enjoyed meeting all of the people in the beets community. In fact, all these years later, I somehow still like working on beets—even fixing Unicode-related crashes!

I can’t ignore, however, that—as much as I enjoy doing it—I can’t devote as much time to the project as I once did. A couple of years ago, I took a job that is known for its tendency to occupy every second of spare time with its all-consuming and infinitely varying demands. This lack of time has led to some sad consequences—most proximately, I haven’t been able to find the time to push a new release out the door in months. And I haven’t been able to hang out on IRC almost at all.

So while I don’t want to leave the project at all, I also would love to stop being a “single point of failure” for the project’s progress. For the last five or so years, the beets community has done an incredible job contributing fixes, features, and documentation—far beyond what I’d be able to do myself. But there is a category of things that the community has not been able to help with, which I’d label as the “core” tasks of maintainership. Things like these:

  • Releasing new versions!
  • Providing timely code reviews on pull requests.
  • Triaging new issues, even when they can’t be handled immediately.
  • Answering questions that come in over the mailing list or Discourse, even when the answer is, “sorry, I don’t think that thing you want is currently possible!”

I propose to create a “core team” of beets maintainers who commit to cover these tasks. Without any specific notions quite yet, I’d like to write down a lightweight process for being designated as a member of this team and what responsibilities that entails. We would open some kind of communication channel for discussing the high-level steering of the project. There would be no compensation beyond the respect and admiration of the beets community.

For more on what I’m imagining here, check out this blog post by Nick Fitzgerald and the other posts it links to at the bottom.

I would love to hear anyone’s thoughts on this plan! If you think this is a good or bad idea, please weigh in and give me any recommendations you have for how to manage this process. That can be independent of actually wanting to serve on this team. I have a few ideas for people I think would be awesome team members, and if this seems like it’s becoming a thing I’ll invite them directly to consider joining up—but feel free to volunteer yourself immediately. :slight_smile:

Thanks for everything, as always,



I do not want to join the core device team but I will say that, yes, this seems the most appropriate direction to move to.

Also thanks for all you’ve done for these years, the software is an invaluable tool to me!


First off, hats off Adrian for creating such a wonderful tool and donating so much time toward improving the lives of fellow music nerds!

I think this is a good idea for beets (and other OSS projects), and am fully supportive.

My python skills aren’t the best, and I’m a bit strapped for free time, but I would be very sad if beets went away which means I should help out however I can :slight_smile:

1 Like

Adrian, please, continue. Or entrust the project to good hands. I wish I could help in some way other than donating.


That would be a great idea @adrian, I’ve been wondering from the start why so few people answered my questions… It was mostly you you and you and @macleodmike And @dorade for which I thank you all. I’m absolutely a noob at coding. I cut and paste code from other solutions and tinker and beg until it works :wink: I’m also not really that experienced yet with Beets to be of any service with support. I do try to post the solutions that I find (with others pointing me in the right direction) to help others that might want to solve a thing like this in the future.
I hope you get a great team together Adrian. Beets is absolutely lovely. Its exciting to see it do it’s magic.

1 Like

I’m interested.

I’m a software dev and, even more relevant, music nerd :slight_smile:

Here’s my Github:


Hi Adrian,

I absolutely think it’s a good idea to have a core team to share the load so that everyone can have fun with the project without any single person having to feel inundated with a deluge of maintenance tasks.

I’m more than happy to help out in whatever form the core team takes. My involvement might be a bit bursty, based on experience finding time to maintain packages in Debian, but I’ll do my best to keep up a a more sustained presence here. I don’t think that will be difficult given the efforts you’ve put in to make the community welcoming :slight_smile:

On practical matters I think a communication channel would be a great starting point, whether it’s a separate area here on discourse or something more like IRC or its more modern equivalents.


1 Like

Yeah, I’ve been thinking about a communication channel as well. Here’s a bit of a confession: I used to use IRC a lot more, but in the era of Slack and its open-source equivalents, I’ve found my patience for IRC’s well-known limitations (even when mediated by a bouncer) have severely decreased. I’d be interested to see how far we can bend this Discourse forum for that purpose, or possibly exploring a more chat-oriented alternative (e.g., Slack itself or Matrix or Spectrum).


I never got into IRC myself, I just mentioned it since I saw you (used to?) use it for beets already. I suspect that a Slack-like format will work better than a threaded forum style for a small team. If you don’t mind adopting a new service and there are hosted options that are easy to set up, then anything sounds fine to me! I’m also aware of Gitter but I’ve only really used Mattermost (not really an option for beets though).


I’m on the edge of a few teams that use Discord, which seems quite nice, and people (well, gamers) often have it already. The Slack client is pretty heavy to leave running all the time (my work one is regularly 1GB+ RAM footprint).


Spectrum and Gitter look pretty similar at first glance. Both support signing in via GitHub and seem to be pretty easy to get up and running. Gitter seems to support natural discovery by linking chat rooms to GitHub orgs. Gitter has native clients for all common platforms, but Spectrum is Mac-only. I think to me Gitter is sounding like the best fit so far.


Alright, let’s give that a try! I initialized a public room just to try things out:

[ANN] beets 1.4.8