PR complexity

[volodya-lombrozo]

As far as I know, we get 250 Pulls * 1 HOC for a PR. It's fine except one important thing. Such a metric drives me to get only easy-to implement features like refactoring, writing tests, simple coding, etc. But sometimes we have to implement heavy bug-fixes or complex algorithms. The total HOC in that PR might be extremely small, but the importance is quite high.

[volodya-lombrozo]

I don't know hot to fix that, but probably we can introduce some complexity number that could be added to each PR. In other words it is some sort of points multiplier.

[yegor256]

@volodya-lombrozo this is exactly what we want: to have small easy to understand PRs. Don't solve a complex problem in a large PR. Instead, make increments, smaller steps, produce a number of PRs while moving towards the final solution of a problem.

[yegor256]

@volodya-lombrozo we don't want to "reward" people for solving complex problems in a single PR. Instead, we want to reward people for smart decomposition of tasks into smaller sub-tasks.

[volodya-lombrozo]

@yegor256 but what about bugs investigation? I spent lots of time for debugging

[volodya-lombrozo]

Again, it's simpler just to ignore that issues instead of doing them, because it's hard even to decompose them.

[yegor256]

@volodya-lombrozo read this: https://www.yegor256.com/2016/02/09/are-you-still-debugging.html

[volodya-lombrozo]

@yegor256 About debugging:

In a nutshell, it is a very useful technique … for a bad programmer.

It's a shame :) Ok, I'll try to go through unit-test path then