> So I can find a bug, I can fix it, but I am not allowed to tell them how exactly I did it.
Pin pointing the issue is way more than valuable than code. If you wrote a fix, you have analyzed the bug. The value is there, not in the fix. Sharing your fine analysis is the maximized contribution. Code is an optional bonus at most.
'I applied this change to my local fork as a temporary workaround, in case it's useful to consider' is the way to express this.
In one memorable case, by presenting it as problem+tempfix and inviting discussion, the developer argued that I should focus on repairing the other software that was the cause of brokenness. I agreed with them, we mutually closed the issue, and my code was (correctly) discarded.
Code is a secondary and optional part of the feedback process. Yes, it can be a more precise language for conveying a problem report. No, it is not necessarily a boon. Code never carried significant intrinsic value — the motivation of the author to show up and interactively participate with the project that was infinitely more valuable than any one patch! — and now with AI, code carries negative intrinsic value, indicative of drive-by patches with no likelihood of future participation.
The most effective contribution I made this month to a project was to spend three weeks reproducing a bug and then informing them of the process to repro it themselves. They were head over heels grateful, not only because I bothered to write a bug report, but because I followed up a week later when I managed to create a second repro case of the exact same issue under wholly different circumstances. The issue is, at its core, a reasoning error about a protocol handshake-setup-command process across 2+ devices, and patching their code to fix it is meaningless compared to the value I provided by simply showing my work in tracking down the problem.
Pull requests are, these days, more often an expression of entitlement ('I deserve praise, be grateful for my code, comply with my designs, or else') than of free-time invested into the project ('Hi, we've been working together in various bug reports for a while, and I saw this problem and felt like it would be a fun side project to hack on') and so I wholly endorse their decision to refuse them.
exactly. a _proposed_ code fix is a good indicator where the problem is (analysis) but more often than not the actual maintainable and sustainable solution will look different.
a code owner may choose a very different way of fixing things, even for what looks like a trivial fix.
Pin pointing the issue is way more than valuable than code. If you wrote a fix, you have analyzed the bug. The value is there, not in the fix. Sharing your fine analysis is the maximized contribution. Code is an optional bonus at most.