You opened issue #800. It is polite and long. The maintainer who owns that corner of the code has not commented, because they do not watch every issue. A week later you are considering mailing them a link. The link is the problem. It bills them for archaeology.
How maintainers decide among themselves is a different guide — the public thread, the top post, the people whose packages break. This page is the other direction: you are a user. You want one person's judgment. You do not sit on the project.
Do the work, then ask one thing
A busy expert will correct a position in one line. They will not construct one for you.
Arrive with: the version you are on, what you tried, what you expected, what you got, and the one question that remains. "Does 2.4 still support the old config key, yes or no, and I will write the answer back on #800 if you want." That is an ask. "Thoughts on my issue" is a dump.
Write for a cold reader. They do not remember your earlier comments. They may not remember the key. Paste the two lines of config that matter. Do not attach a log file. There is no file path. Trim the log to the dozen lines that show the failure, in the note.
Close the list if you can: supported, unsupported, or "unsupported but here is the workaround." If you cannot close it, you are asking for an opinion, and you should say so.
One person, not the list
Outreach that is not spam fails the swap test on purpose. Would this mail still make sense sent to a different maintainer? If yes, you have not named why it is them.
They need no account. The mail is how they receive it. They reply from the mail or the page. You approve the wording. Your assistant does not write to strangers as you.
If you use Claude and they use ChatGPT, nothing is a shared brain. They read the briefing you approved.
A first message should not demand a call. A call is a large commitment attached to an unknown return. Ask something answerable in a reply.
Do not put a private nickname in the package. Use the name they publish on the project.
Take the answer back to the archive
The public issue is still the record the next user will read. If they answer you, ask whether you may quote it on the issue. If they say no, you have a private answer and you live with that.
Set a default that does not pretend they owe you time. "If I do not hear, I will assume the key is unsupported and document the workaround. No need to reply." Making ignore costless is the right posture for a stranger whose only tie to you is that you use their work.
Follow up once, with a result you got, not a bump.
What this is not
It is not a feature vote. It is not a demand that they merge. It is not a way to skip the tracker so the project loses the archive.
It is not a blast to every maintainer in the org file. One owner, one question.
If your assistant already walked the failure with you, let it draft the scoped page. You read it. Then they can answer without opening #800 cold.