Since you know better, how about maintaining your own Wine tree and showing us how it's done?
Self evidently thats what I have to do until some core functionality patches find their way into WineHQ wine. It's not particularly hard, but it is time consuming to manage merge conflicts.
It's very easy to say Alexandre should do this or Alexandre shouldn't do that when you haven't put yourself in his shoes, and tried to do what he's doing.
Fact is, it's a difficult and time consuming job. By reviewing your patches, Alexandre is doing you and everybody else in the Wine community a service.
Secondly, patches that get no response are not "rejected". You should consider them as "not obviously correct" rather than incorrect. The problem may be simply that they're too complex to review and reply to in a short amount of time.
I don't think a web based patch tracking system will work for reasons pointed out by Jeremy in another mail, and that it would be very difficult to integrate it with Alexandre's work flow without wasting more of his time.
So I have some possible ways to enhance the current procedures:
1) When somebody has sent a patch to wine-patches that hasn't been applied for a few days, write to wine-devel and request that others review it.
2) Enter into bugzilla the *problem* that your patch addresses (not the patch itself), and attach the patch to the bug.
These may not be to your liking, but if they're not, fork Wine and maintain your own public Wine tree, as Alexandre's tree is maintained using Alexandre's methods.
Mike