3 ms·
I evaluate it the same way that I evaluate any other code that I'm bringing into our project: is it robust, extensible, free of obvious errors, covered by compr
by cweagans 11y ago
I evaluate it the same way that I evaluate any other code that I'm bringing into our project: is it robust, extensible, free of obvious errors, covered by comprehensive unit/functional tests, etc.
I would say that "project is open 6 months" is a pretty poor metric, because 6 months is a lot longer than the handful of days that your custom code will have existed when you add it instead.
- bazMVP 11y agoThat makes sense, any time period is probably less valuable than looking at it relative to commits or issue resolution rate.
- cweagans 11y agoEven evaluating it on historical commits or issue resolution rate is not very productive, IMO. They really aren't an indication of future activity unless there are at least 10s of developers working on it constantly for a long period of time (say, > 6 months). I've been burned too many times by getting hopeful about what a project maintainer is going to do in the future, so my criteria is basically taking the code in it's current state and evaluating it like I would any other code. If it's a matter of opening a PR or two to get things cleaned up, and PRs seem to be merged relatively quickly, I might chance it, but I can't wait on an unresponsive maintainer to merge things. I have deadlines to meet. Ain't nobody got time for that.