This was a topic from our Developer day from an offline conversation with an Open Source Software guru. Let’s continue the conversation here.
–
We should have a plan in place to mitigate “maintainer burn out” where people who start contributions end up getting distracted with something else and are unable to maintain the project they started.
Part of this planning will also satisfy a “hit by a bus” problem incase a project lead or maintainer suddenly disappears.
(jumping ahead in my notes for story telling purposes) … he suggested having a “labs” area where anyone can start a new sub project. having a project in the labs area is fairly simple and anyone who is interested can be part of the labs area.
Once a project in labs becomes “mature”, that project can request to be a core part of Meshtastic. Being part of core Meshtastic will come with some governance requirements.
The first requirement is that recruitment of developers to their project (think: meshtastic-ios, meshtastic-web, meshtastic-pygui, etc) will be mandatory and they must have a mentor relationship with the other developers on their immediate team. The developers they mentor will have full rights on their project for things like reviewing PRs and making other decisions for that project.
Second requirement would be that the developer must agree (they can propose it themself) that if someone submits a PR to their project, the PR has to be reviewed within x-days. This will help keep their project alive by further fostering a community around their project.
We can come up with other stipulations, but we should start small how ever it works out.
Do we have interest in creating a “Meshtastic Labs” for anyone’s projects and then once those projects are mature they can request to be an officially a meshtastic core project?
Sorry, missed the dev day event. I’m curious about the Labs idea. Besides the (quite reasonable) reqs for a Labs project, have you discussed motivations for people to work with the Labs framework (as opposed to striking on their own)? E.g. shared testing/deployment infrastructure, etc…?
We had 8 topics around open source software and for the purpose of time, we time boxed them to about 45 seconds each so this wouldn’t take up the whole meeting. At the end of each topic, we polled for thumbs up and anything that gained interest was moved to this forum for further conversation.
My view (feel free to suggest otherwise or agree) would be that anyone who strikes it out on their own, is part of a labs experiment either explicitly stated or otherwise. It could be a project in their own repo or a labs section in the Meshtastic repo, I don’t know if that’s even possible. Either way I think the innovation of the proposal is one for long term support and maintenance. Once someone says “yeah, this software is mature and here’s our plan to keep it maintained” it can be reviewed to be part of of the Meshtastic core set of technologies. That would mean that it’s less likely that we have something that we advice users adopt atrophy over time.
Yes, agree that the maintainer roles should have some expectations on what they are responsible for, reasonable levels of effort, etc. We need to keep the project fun, not a source of stress!
Most of us have day-jobs, so time is limited, but we don’t want to inhibit people from getting involved with their limited time, maybe feeling they cannot live up to the expectations of the community. Having an agreed back-up or deputy helps people handle down-time (holidays, work or personal demands etc).
It’s also a way for non-developers, or up-and-coming devs to take on a role and contribute to the project.