OpenWRT has communication problems. Sometime ago I tried to report a bug in the build system. It took them about two weeks to recognize that there's indeed a problem and went over like this:
/me: Bug in the build system. This is how to reproduce.
/they: Bug in Linux kernel. Not our problem.
/they: Bug is closed, upstream issue.
/me: No, toolchain bug. Here is proof.
/they: need logs
/me: here's logs
/me: here's a clumsy fix
/they: that's so stupid
/they: and your linux installation is broken
/me: no it's not, see here, working as intended
/they: you don't understand cross-compiling
/me: look here, you are setting up the cross-compilation all wrong
/they: kernel bug, fixed upstream
/me: not that again
/me: here's build logs, cross-compilation issue
/they: you are stupid, your linux installation is broken
/me: linux installation is just fine, but you are relying on a debian-ism
/me: here's patch
/they: ok, send to mailing list for review
/they: IRC says patch stupid
/they: we've merged our patch
They really need to work on being not hostile and clannish. Never had any issue on other mailing lists, and those weren't the Kumbaya-required kind with a code of conduct.
I mirror your experience. People are hostile and always interpret in the worst possible way. It is very difficult to defuse a situation, it's like walking on eggshells while blindfolded with a heavy backpack. I don't like their community at all.
The persistent unwillingness to engage and the inclination to dismiss was remarkable. Rachelbythebay had something somewhere about patches kept private and not submitted because no one wants to put up with an unreasonable or arrogant maintainer. All her observations apply here. Who would put up with the concentrated obnoxiousness?
I keep wondering about alternatives to the gate keeper models of governance.
Maybe something like survival of the fittest (Darwinian). Each build attempt runs the gauntlet. Only variations which survive get promoted.
I recently learned about "Test Into Prod", a seemingly effective methodology for mitigating the PR-based workflow bottlenecks.
So sorry, but I can't quickly refind the conference talks. (New laptop doesn't have my old browser history.) The speaker had previously done a fashion startup. Glib? Gilb? Argh. Sorry.
I feel like the way to do this would be to have (1) digital repro format & (2) auto-exec of submitted issues to verify.
Then have the workflow look more like (1) anon q public submits repro file & issue description, (2) auto-test system runs and validates repro file, (3) issue auto-logged, (4) issue cannot be manually unlogged without fix (if upstream, move to side filter, pending upstream fix)
The human triage stage usually seems the most adversarial. So having an automated system take it to "Yup, this is a bug" would be a good start.
This happened to me, but with a different project.. laughed off the mailing list for a dumb patch only to be included in a near term update. I seriously walked away from large open source projects for almost 6 years because of this attitude.
/me: Bug in the build system. This is how to reproduce.
/they: Bug in Linux kernel. Not our problem.
/they: Bug is closed, upstream issue.
/me: No, toolchain bug. Here is proof.
/they: need logs
/me: here's logs
/me: here's a clumsy fix
/they: that's so stupid
/they: and your linux installation is broken
/me: no it's not, see here, working as intended
/they: you don't understand cross-compiling
/me: look here, you are setting up the cross-compilation all wrong
/they: kernel bug, fixed upstream
/me: not that again
/me: here's build logs, cross-compilation issue
/they: you are stupid, your linux installation is broken
/me: linux installation is just fine, but you are relying on a debian-ism
/me: here's patch
/they: ok, send to mailing list for review
/they: IRC says patch stupid
/they: we've merged our patch
They really need to work on being not hostile and clannish. Never had any issue on other mailing lists, and those weren't the Kumbaya-required kind with a code of conduct.