Hey HN,
I've been part of multiple smaller teams doing hobby projects, writing / maintaining open source software, and we've had multiple approaches.
Particularly, I'm wondering what you think are good/bad workflows for source control, issue management, PRs/MRs, reviews, estimation (would you estimate points on issues even in open source?), planning, the "vision" (BDFL?), etc.
This is assuming the team isn't paid much or at all and does it out of their free will, so you can't force them to do a stand-up every morning and force them to use Jira.
- feature branches are necessary, if everyone commits to master that's definitely chaos.
- a develop and a master/main branch make sense sometimes, but can be a bit of a burden without a solid release cycle(?)
- getting people to make an issue before fixing something and then making a branch is extra friction, but should pay off in the long(er) run
- weekly meetings, like a stand-up, can usually be scheduled so most people show up - that helps keep track if someone's stuck
I havent found a way to make people do chores, like reviews, consistently enough. I'm also lacking ideas of how to get your founder/team leader/whatever to stick to the rules. In my experience, the person which full repo access may just abuse that to commit directly to master "because it was easier/important/etc".
Really curious what HN thinks :)