Dear Open Hub Users,
We’re excited to announce that we will be moving the Open Hub Forum to
https://community.blackduck.com/s/black-duck-open-hub.
Beginning immediately, users can head over,
register,
get technical help and discuss issue pertinent to the Open Hub. Registered users can also subscribe to Open Hub announcements here.
On May 1, 2020, we will be freezing https://www.openhub.net/forums and users will not be able to create new discussions. If you have any questions and concerns, please email us at
info@openhub.net
My is the number of commits the metric that is presented by default, when looking at the list of the contributors to a particular project?
It seems to me that this metric gives a less faithful indication as to each contributor's ACTUAL contribution, than the number of modified lines of code. Indeed, it is easy to commit hundreds of atomic changes that modify only one line at a time -- which thus creates an artificially high contribution. This is particularly true for automated commits (e.g.m, version number) that get auto-generated each day from one contributor's account.
Anyways, just an idea.
IMHO having scripted commits run on a contributors account is a very bad idea. Maybe it would be good to add the option to hide some accounts in the contributors lists...
Like the number of changed lines is any better metric? Move a file or a folder, import some autotools and you'll have a big boost.
Wouldn't the other developers of a project tend to frown on stupid things like scripting commits of one line each? That is, how would this be a problem in practice?
What about a different metric? Neither the number of lines of code nor the number of commits reflect honestly someone's contributions. Just an example: numerical methods. Can take months to develop (paper/pencil), prototype, test, and in the end, result in only a few hundred lines of code.
Perhaps one way to avoid the dreaded lines of code
metric would be to make kudos specific to a particular section of source code. You might thank someone for writing a clear or highly-optimized subroutine that does heavy lifting but very few people would give out kudos to code that is overwrought or aimlessly designed.
You don't get any kudos for that overwrought idea.