3 ms·

I would love to find better metrics than changesets and lines of codes — I agree that both are awful ways of measuring actual software-development work. I have

• m463 6y ago
  I wonder if folks should even look for it, because it will become an employment metric. sorry you spent too much time on "learning", we need more "corbet-curve-units" from you.
  • contingencies 6y ago
    Goodhart's Law (Popular formulation): When a measure becomes a target, it ceases to be a good measure. ... via https://github.com/globalcitizen/taoup https://github.com/globalcitizen/taoup
• lrossi 6y ago
  Thanks for replying! In this case I think a lot of people are wondering what they changed. Would it be possible to extract that info from the paths modified, filtered with some handwritten rules to classify the changes? For example, did they commit driver code for their own hardware, or did they touch other areas of the kernel? How much of each?
• tutfbhuf 6y ago
  I think the best metric is to sort by number of comments on a particular changeset. More comments, more wide spread discussion, more people involved => more impact. WireGuard for example is only a relatively small changeset, but has an huge impact for many uses, you can find many comments, posts, write ups, about it all over the internet. Many knew that this feature was going to be huge, well before merge into linux. On the other hand, if almost no one is discussing a particular change (e.g. the removal of 20k lines of driver code), then the impact will either be very low and unimportant or it will unexpectedly become important, but there was no way you could have known it beforehand.