Note: speaking more for FPC than for lazarus.
Absolutely right and that's very sad!
Sometime even nobody of the team responded to a patch which easily leads to the impression that help is not wanted.
That's the problem with language design. It is quite a minefield. But a lot of it is self-inflicted. They have been warned. Nevertheless, when it happens it is a tragedy. For both sides.
Would also help to have a list with rejected features/patches and a reason WHY it was rejected.
If people wade in to disputed areas (usually: copying syntax from other languages or totally ad-hoc syntax enhancements) after being warned, I don't really think that some list somewhere in the wiki will detract them.
Quite often it is not rejected per se, but the amount of work is simply to daunting for a committer. Specially if he can't do it during normal hours, but really has to set aside holidays to review something that is big or with big consequences.
IMHO the recent problems with rejections is because aspiring developers try to do too much to soon, without getting a feel for the project.
Start small. Ask questions a lot. Learn proper procedures. And, most importantly, don't reformat code unnecessarily, keep patches to the point and as small as possible. It doesn't matter if it is in a git branch or a submitted patch.
Having some kind of rejected patches/features would help new people to get a better feeling about FPC. Might also reduce duplicate question for feature X...
If you feel that way, start a wiki page.
But I think it is more a sign of the times. For some reason all new contributors want to play with expanding language, the bigger the better. 10 years ago, new contributors were more about new targets, and often were already deeper into that field than core contributors.
That had several important consequences
1) what they didn't, mostly affected the new target, not everything, and the consequences for support etc would be
2) they usually knew what they were doing (wrt that target) better than core anyway.
3) they usually had already quite a string of patches and rearrangements, often for related targets.
It is much easier to let such contributor get commit bits than the current batch that seems to be overly focussed on language (with the dialect backwards compatibility as a Sword of Damocles haging over it).
Just look what happened to similar contributions a few years ago. Where are the case <string> of committers?
And, most importantly, don't reformat code unnecessarily, keep patches to the point and as small as possible. It doesn't matter if it is in a git branch or a submitted patch.
Many delays come due to unclean patches.
Unclean patches could be cleaned by devs if the feature is working, takes less time than asking to submit a new patch which might not fit your rules also...as there are no contribution rules, or?
Most of these people have submitted more trivial stuff before, so they now about cleanliness rules.
Keeping changesets minimal as possible is a fairly universal rules in open source (or even: multi person projects).
Anyway, while I don't think a rejected patch list will do much good, I do think that the current policy of officially welcoming any patches is bankrupt. It worked in the past when the new developers either had or acquired the same mindset as the old bunch in time, but it doesn't seem to work like that any more.