Presumably, the maintainer wants the best for the product and its users. So they have a definite interest in documenting a todo list.

Presumably, the user wants the best for the product and their ability to use the product. So they have a definite interest in documenting a todo list.

It doesn't make sense for the two to be at war with each other. It is no big deal for the maintainer to ask a favor. It's not too big of a deal for the user to decline. There's no need to attack.

I have often dropped a note to the maintainer of a project I bumped into. I'm sure they would prefer a bug report in their official forge. But I don't really use their software except for this one time. I'm not willing to jump through the hoops to create an account in yet another SaaS just to file this one report. Just dropping them an email was a courtesy. But often they don't interpret it that way. I'm perfectly un-insulted if they just delete my note and never "fix" the issue because it didn't come through proper channels.

No attacks. No war. Just well wishes. But I might very likely avoid the product if I'm ever back in those woods. Not out of anger or retribution. Just because I'll remember that the product had at least one sharp edge for my use case and the maintainer was a bit overwhelmed by the weight of supporting my niche use case. That doesn't make the maintainer a bad person or even a bad maintainer.

If the maintainer is trying to write something RFC-compliant, and someone reports a violation of the RFC, it sure seems reasonable for the maintainer to want to track that.

If they don't want to, that's certainly their right, but it also tells us something about that project.

Because they're the ones asking for the administrative burden of refiling a basic RFC violation bug?

If they're doing this and bothering to interact with tickets at all, presumably they've willingly taken on a duty to the software's quality and all that that entails.