"Proof of Work"

[purpleKarrot]

In review comments, it was brought up that there is a "Proof of Work" requirement for certain areas of the code to be touched. I read this in conflict with the review guidelines, which clearly state that the review should be about the idea, not about the person proposing it.

Consider this thought experiment: What if all PRs were made anonymously? There would be no other way than to discuss it on its merit alone, because the author, including his previous work, remains unknown.

Note that I am not proposing to make code submissions actually anonymous. But it would be a good guideline to review code as-if it was.

[maflcko]

Maybe I am misunderstanding, but asking for "proof of work" is not about asking the person having some past track record of work, but rather the proposed idea, or the proposed code change having some evaluation work on top of it, to back it.

The idea is that there is an endless number of changes that make sense on their own, but they may conceptually (or literally) conflict with other changes or alternative approaches. It helps the changes if they are backed by some work on top of them. Otherwise, they risk being reverted or revisited later on, in the meantime eating review resources and possibly delaying other work.

[purpleKarrot]

Maybe I am misunderstanding, but asking for "proof of work" is not about asking the person having some past track record of work, but rather the proposed idea, or the proposed code change having some evaluation work on top of it, to back it.

That understanding of proof of work is reasonable. I have seen places where it was used explicitly in the sense of a track record.

[maflcko]

That understanding of proof of work is reasonable. I have seen places where it was used explicitly in the sense of a track record.

I can imagine it could serve as a good-enough proxy, but I wouldn't mind to clarify the contrib guide via something like:

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 93be109951..e7bca69485 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -270,7 +270,8 @@ behaviour of code within the pull request (bugs must be preserved as is).
 Project maintainers aim for a quick turnaround on refactoring pull requests, so
 where possible keep them short, uncomplex and easy to verify.
 
-Pull requests that refactor the code should not be made by new contributors. It
+Pull requests that refactor the code require a strong rationale, and possibly
+some proof of work on top of them to show that they are worth it. It
 requires a certain level of experience to know where the code belongs to and to
 understand the full ramification (including rebase effort of open pull requests).
 

(However, such doc changes have the risk of bike-shedding, and I guess one could already interpret the current docs in this way, so I won't propose this diff myself)

[l0rinc]

I have seen places where it was used explicitly in the sense of a track record

It's both: "do 10x the work you're requesting from others". We have to earn other people's help and time. Comments and ACKs have depth, it's a meritocracy, pseudonymous makes sense here, but anonymous is meaningless because it erases history: if someone I know personally states that they have tested something locally that's a lot more valuable than an anon AI stating the same.
Opening PRs without proper justification (and shaming them if they haven't read our blogpost) is just giving others homework without giving something back first.