Forming a beets "core team"

Development
1

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,

Adrian

9 Likes
2

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!

3

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
4

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

5

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
6

I’m interested.

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

Here’s my Github: https://github.com/zachvalenta

2 Likes
7

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.

Cheers,
Carl

1 Like
8

8 posts were split to a new topic: Choosing a development chat platform

13

I have a couple of ideas for making it easier to attract/recruit contributors, a lot of which actually stems from the blog you linked.

  1. Revamping the contributing/“hacking” wiki page
    • I have some ideas myself, after just going through the process, and am willing to go through and make some suggestions or touch-ups I where I feel they may be useful. We can talk more about this here, or I can open up a PR and we can discuss on github.
  2. Adding the gitter to the repo, and making it more “official”.
    • So a few things on this, I think it’s worthwhile to decide what should go on the gitter vs discourse vs github issue tracker and begin to enforce it or create a standard. IMO, gitter should be used for dev chat (to include new devs that may be confused or need help contributing), discourse for general or meta discussion and support/help, and github issue tracker for bugs and feature requests.
    • As far as making the gitter chat more accessible, you could add a sidecar to the repo. Another option could be to just include a link on the contributing page that new contributors or potential maintainers could use to find help/join the team. If you don’t want to restrict the gitter chat to just devs, then creating rooms within gitter and then redirecting or communicating with users from there could be a nice idea too.
  3. Setting up some kind of newcomer-friendly program and advertising it
    • One example of this is specifically marking issues as first-timers-only This could be in addition to the byte-sized label beets currently issues to maybe do a bit more hand-holding for those that have never contributed to an open-source project before. These issues could also be announced via twitter or something whenever they pop up.
    • Beets could also register on sites such as https://up-for-grabs.net/#/
  4. Utilizing other people.
    • Once you have people that have spoken up as willing to help, or have just contributed, start assigning them to issues/PRs or giving them other tasks they can tackle. Right now you’re doing an awesome job by yourself, and I don’t understand how you find the time to seemingly be everywhere at once. One of the reasons I am attracted to this project is because I was met with kindness from you and I noticed how much effort you were putting into it. So for all of that, I have a great deal of respect and appreciation for what you do! Just be willing to teach/delegate every once in a while, and eventually you’ll find you won’t need to have a second input on every issue :slight_smile:

Forming a team of experienced programmers as a leadership-core can be just as valuable as attracting newcomers that have a positive experience and then go on to learn and become core maintainers themselves.

I use beets all the time and very much want to see it succeed and continue to succeed in the future. I also recognize the issue of having a single point of failure and the potential burnout it can cause. Hopefully some of the ideas I presented can be helpful to you and your quest to spread the load out a little.

14

Hi, @jtpavlock—these are all really great suggestions; thank you for your thoughtfulness!

Most actionably, revamping the “hacking” wiki page (and probably turning it into a proper CONTRIBUTING.md) would be a great place to start, and yes, discussing here or on a GitHub issue sounds excellent.

As for Gitter, that too was how I was imagining it: it’s hard to imagine doing just normal chit-chat about beets on Gitter, but coordinating between developers seems great there. Of course, by its nature it’s not as good for longer writing… so maybe we could decide that “discussion” issues or a separate category here on the Discourse for development would complement Gitter. In any case, I really like the idea of clarifying that (1) support/bugs/features go to issues, (2) development is based on Gitter, and (3) less categorizable discussion goes here. While we’re at it, we should clarify that we mostly no longer use IRC or Google Groups, to which some links still linger…

I certainly also think we should rename the “bite-sized” label to one of the labels that have emerged as de facto standards. I don’t completely understand the difference in between first-timers-only and good-first-issue but we should do something like that.

Finally and most broadly, while you’re very kind about my appearing to pop up everywhere, it’s very true that I’m not good at delegating. I’ve mostly carried over my old habits from when beets was a much smaller project and it made sense to try to handle everything myself, which is not really sustainable as the project somehow continues to grow. I need to figure out how to do that, but at the very least, I like your suggestion to assign issues to other willing developers…

15

opened https://github.com/beetbox/beets/pull/3643

I’m fine with bite-sized, or the concept of it at least, doesn’t really matter to me what you call it. I hadn’t realized good-first-issue was also commonplace, but basically the idea is that first-timers-only is more explicitly reserved for those that haven’t contributed to open source before, with those issues having a great deal more hand holding and guiding than normal.

Hopefully a dev chat room can start to gain some traction and we can get a couple of willing developers :slight_smile:

Speaking of… I was looking into gitter some more as I hadn’t used it before, and it seems like it relies on a web-based platform for mobile apps i.e. deprecating their current android/ios apps. May be something to consider if you aren’t hard set on gitter already. I personally like discord, it’s more widespread and has more features, but I can see its propensity towards gaming being offputting… someone broke down a nice set of pros/cons here

edit: discord also supports bots for github which could be useful

If you want, I could setup/handle the admin stuff of the discord but obviously have you as a full permissions owner.

1 Like