Scoring deleted code with a lower weight

[seroperson]

Continuing the discussion from #545.

Currently deleting code scores the same as deleted code itself. Deleting code == introducing code. In the PR I proposed to score deletion with x0.25 multiplier to address the following issues:

• Deleting code is not that hard as introducing code, and logically it should not be scored the same.
• It directly nerfs "only-deletion" PRs, which remove dead code and receive overwhelming score for that.

We stayed with label-multipliers approach as for now, but here is an issue to continue the discussion.

[seroperson]

@anderdc addressing your concerns: #545 (comment)

The asymmetry also creates a new, worse gaming vector. Rewarding additions at 100% and deletions at 25% makes the rational strategy: add more code, delete less. Write new abstractions beside old ones instead of replacing them. Add workarounds instead of fixing root causes. Leave cruft in place because nobody wants a 75% score cut for cleaning it up.

PR I implemented doesn't punish you for deleting code. Deleting code is still scored and still adds something to the total score, so I don't see a reason why people may start "add more code, delete less" and why people may want to avoid code deletions.

That directly contradicts every software engineering principle about keeping codebases lean, and the resulting bloat is harder to spot in review than the current 'cleanup-gaming' is.

It's completely possible both with and without proposed changes, and introducing lowered weight for deletion doesn't touch this case at all.

A flat deletion discount can't distinguish the work it's penalizing. The AST diff treats all deleted lines as equivalent, but deletions come from very different places:

• Refactor PR that only removes dead code (the gaming vector you flagged)
• Bug fix that rewrites a buggy function (30 old lines removed, 25 corrected ones added)
• Feature that consolidates three helpers into one (200 removed, 80 added)
• Optimization that replaces a complex algorithm with a simpler one (100 removed, 30 added)

Three of those four are high-value work where the deletion IS the feature. There's no AST-level signal that separates "pure cleanup" from "feature-with-deletions". Intent lives with the label not necessarily the diff.

Is it a problem? I see this an improvement actually: bugfix which deletes a function and introduces completely a new one, should not be rewarded additionally with the full score of deleted function. It will receive a lowered score of deleted function, but not the full one. The same for other cases.

---

Honestly, as these concerns are likely a result of AI review, I guess it just started to think towards defending fully-scored deletions because bots polluted the PR discussion with statements that it's bad.

[MkDev11]

thanks for opening this issue, I agree with the goal of reducing “cleanup-only” score gaming

I’m a bit worried that a global deletion discount (e.g. 0.25x) could under-reward high-value simplification work (bug rewrites, consolidation, algorithm simplification). could we try a hybrid approach:

1. keep deletion at 1.0 by default
2. apply a lower deletion factor only for refactor/chore-type PRs (you already did it)
3. backtest both approaches on recent merged PRs and compare miner ranking changes

if the backtest shows lower gaming without penalizing legit refactors, we can ship it confidently

[seroperson]

thanks for opening this issue, I agree with the goal of reducing “cleanup-only” score gaming

I’m a bit worried that a global deletion discount (e.g. 0.25x) could under-reward high-value simplification work (bug rewrites, consolidation, algorithm simplification). could we try a hybrid approach:

1. keep deletion at 1.0 by default
2. apply a lower deletion factor only for refactor/chore-type PRs (you already did it)
3. backtest both approaches on recent merged PRs and compare miner ranking changes

if the backtest shows lower gaming without penalizing legit refactors, we can ship it confidently

Yea, but I think we can just "extract" dozen of real PRs data and see how algorithm's changes affect their score. Actually that's what I did in the meanwhile: I've revisited the PR implementation, did some deeper testing once again and from what I see it doesn't give the intended results.

The plain multiplying both score and line count may just cancel out multipliers in some cases, so some additional logic must be considered for this to work. I'm yet unsure what logic exactly.

---

As I think, the fair deletion calculation must result in the following values:

• Plain deletion PRs got their scores heavily reduced (like x0.25)
• Mixed PRs must be reduced depending on what their score consists of. If the whole score was built solely on deletions, and the only additions were like padding with spaces, such scores must be heavily reduced too.
• Additions-only scores are untouched.

In other words:

• Deletions should contribute to the score with lower values.
• Deletions must affect the density (?) as before, but introducing new deletions must be profitable to not let people avoid deletions.

The question is how to implement this correctly, as plain multipliers to the deletions don't work.

The fact that we should not punish for the new deletions makes me think that deletions must be scored separately from additions, like we do with tests and non-code changes. Likely deletions must have their own density and their own score, which then must be somehow summed with the rest of scores, respecting the existing caps.