5 ms·
I'm getting pretty good at working that out. Note that this isn't a dig at any particular project, I know FOSS is hard and free time is scarce (and so is fundi
by voltagex_ 8y ago
I'm getting pretty good at working that out.
Note that this isn't a dig at any particular project, I know FOSS is hard and free time is scarce (and so is funding).
Quick ones:
1. Date of last commit to main repo
2. Number of issues open on Trac/Bugzilla/GitHub/Jira whatever (note, I'm taking a point off if you use Trac, only because there's still an instance from 10 years ago sending me emails that I can't unsubscribe from)
Takes more time:
3. Number of open pull requests/mailing list patches and general discussion around them
4. Any kind of clear and updated roadmap.
Edit: number one these days should be an up to date and working CI/CD system with published artifacts, including for Windows.
- saagarjha 8y agoI like to look at the reactions maintainers have to pull requests. Do they usually get merged, or do they end up being dragged through a bureaucratic nightmare and eventually closed?
- voltagex_ 8y agoI've never written anything popular enough to really get pull requests, but I can definitely understand not merging a pull request due to not being able to maintain that code or it taking the project in a different direction to what you want.
- konschubert 8y agoIt's one thing to say "no", it's another thing to say "later" forever.
- voltagex_ 8y agoThat comes back to having a defined plan for where you want the project to go.