What makes a change PR-worthy?

[mayerrobert]

I think there is an implied goal of limiting the number of PRs, hence my question: what makes a change PR-worthy?

• performance improvement < 1% ?
• performance improvement > 1% ?
• performance improvement > 5% ?
• performance improvement > 10% ?
• bugfix in computing/ counting the primes up to 1.000.000?
• bugfix in computing/ counting the primes up to "weird" sieve sizes such as 10/ 17/ 18/ 127/ 128/ 129?
• adding tests that only confirm that there were no bugs?
• code simplification w/o changes in performance?

Anything else?

Thanks, Robert.

[rbergen]

I think there is an implied goal of limiting the number of PRs, hence my question: what makes a change PR-worthy?

Limiting the number of PRs is not a goal in itself. What is highly appreciated by the maintainers, or at least myself, is if they are indeed correctly setup and worthy of merging. In this context "correctly setup" can be read as being in line with the contributing guidelines where guidelines have been drafted, and common sense where they haven't (yet).

In response to your points:

• Performance improvements to the benchmarked/timed parts of the code are certainly a good reason. I'm not going to pin the "minimum required improvement" down to a percentage, but the bigger the difference the easier the conversation will be. If the differences are smaller (let's say within the boundaries of statistical deviation) then it really helps if it makes sense from a code-level reasoning perspective that the change does improve performance. I don't think there's any way to "codify" that in a way that works for all the programming languages out there, so this is an assessment that is made on a case-by-case basis.

• Bugfixes are also merge-worthy, at least if they apply to the 1,000,000 sieve; those we will merge quickly. If the bug applies to more edge-case scenarios only, I'd be inclined to let the original author of the solution decide.

• Concerning the last two points (adding tests that only confirm that there were no bugs and code simplification w/o changes in performance) the answer is no, unless they are part of a PR that is a) opened by the solution's original author and b) makes sense based on the previous considerations.

[mayerrobert]

Thanks for your quick and detailed answer. You pretty much confirmed my guesses and you also addressed "PR from original author" vs. "PR to someone else's code". This distinction makes sense, I didn't think of that.