add maintainers

[catfact]

norns project has had the same group of maintainers / users with write access, for quite some years now. (despite many/most of these folks being not very active for a while.)

personally, i have not really used norns in some years and don't foresee myself having a lot of time to properly review PRs. (i have two kids now, etc.) moreover there are areas of the codebase that i've (thankfully) had less authorship of in recent versions.

i see this latest PR starting to grow rather old, and it spurred me to ask if we might want to add a couple more maintainers with good C/C++ skills and direct knowledge of these codebase areas.

specifically i would like to nominate @tlubke and @Dewb to be able to approve PRs (when and if it's convenient for them of course.)

any thoughts there? @tehn?

[tehn]

i'd be up for having more maintainers and i concur with your nominee suggestions.

[tlubke]

Thanks for the nomination @catfact, I'd be more than happy to step into the role.

[Dewb]

I appreciate the vote of confidence! Also happy to step into the role.

I haven’t had much time for norns dev in the past year or so but I was already planning to ramp back up this quarter (tackling #1802 and #1749 are the next things on my side-project list.) After that further wax and wane cycles are inevitable, but I tend to lurk the GitHub notifications and rubberneck PRs even when I’m busy with other things, so I should be able to keep up with some baseline context.

Is there a list of maintainers somewhere? Does the project have process expectations beyond the old stuff in the wiki?

[catfact]

ah amazing thanks both of you

@Dewb those are great questions. i hope i don't step too far out of line when i say, that at the moment at least:

• there have been no additional formulations of expected process. perhaps this would be a good time to revisit that.

• also no maintainers list; for us it just means people with write access to the repo, not explicitly points of contact for the broader community. but again that could be reconsidered.

• i think norns development has entered a state of indefinite, hm, brumination or slow-mode. (so: there are lots of known issues and nice-to-haves, but we're also not particularly wanting to destabilize and are fine with a very slow pace of change.)

therefore my reasoning is that if we happen to get fix-it contributions, and they land in areas that you are familiar with, and it all looks decent, then lets minimize friction for getting those kinds of changes merged, and not make it contingent on me or brian having time to review.

(of course monome org still needs to perform a solid cycle of testing before release.)

anyways in all of this i would of course defer to @tehn but that's my gut reaction.

[tehn]

thank you both and i concur with what ezra has said.

norns is in "stable"/maintenance mode. there are lots of things we could change but the cost would be too high--- not just with user familiarity, but also with time invested in tutorials and documentation. so while i'm very interested in various fixes, i'm wary of "improvements" as they have to pass a lot of tests.

given the norns shield hardware is open source, this project lives in a sort of limbo between collective management and commercial oversight. we will certainly test releases in-house and also i'll continue to package and announce updates. note that it's been pretty slow this last year, but i'd like to take a moment to actually celebrate that rather than wring hands over an issue list full of feature ideas and relatively tiny bugs.

the wonderful thing about having a stable hardware platform is that nothing should unexpected force us into an upgrade cycle!

thanks for considering putting time into this. looking forward to keeping this project relevant and helping folks make instruments.