The maintainer may see issues as "something that they should fix", vs "something that could be fixed". If they see it as the former and have no intention of working on it, then closing makes sense. I don't think there's a universal code of conduct on how to handle Github issues.

Is it a human closing it or a bot? If you run an open source project there's a natural tendency to install a bot to auto-close all of the issues which people open because they didn't read the docs, want you to do free consulting for their business, have an irreproducible bug report, etc. and since most projects are short on labor that makes it somewhat inevitable that someone will enable the bot first and never get around to configuring it to, for example, not close an issue tagged as verified.

A bot, but

> someone will enable the bot first and never get around to configuring it to, for example, not close an issue tagged as verified.

I don't understand this part. Aside from the fact that it's trivial to exclude certain tags (it's the same config file, and it's in the first example they give), doing this effectively makes your issue tracker useless as an issue tracker. Why not completely disable the issue tracker instead then?

Oh, I'm not saying it's great. What I'm saying is that the process often looks like this:

1. Release a project on GitHub

2. Get busy with other things / deluged in issues

3. “I don't have time for this. Let me install the auto-close bot!”

4. Issues get closed

5. [sometimes never] “I better configure the auto-close bot to only act on untriaged issues”

They meant Mozilla having revenue, not GitHub.

So did the person you're replying to.