And don't lock them as stale once closed. Holy shit, it's infuriating seeing projects abuse what is essentially an anti-harrasment tool to prevent people from pinging old issues with relevant information. Especially if said old issue is a top hit on Google for some set of keywords.

Losing the context of the old issue often kills contributions outright.

Even though I'm maintaining Lock Threads [1], I sometimes shake my head when I come across a closed issue that was locked by it, but I also have to admit that all I want is to ask a question quickly and get the information I need, without considering how my shortcuts affect maintainers.

There may be times when there's a legitimate reason for commenting on a long-resolved issue, but unfortunately most of the comments on closed issues are low effort support requests. Locking them as resolved is the best solution we have so far to avoid spending our time retriaging closed issues.

[1] https://probot.github.io/apps/lock/

If maintainers have their email set up to pester them every time someone writes a comment anywhere, that’s the fault of the email setup, not the commenters’ fault.

Instead of locking the topic, consider just leaving a note that future discussion there is likely to be ignored by the team, and then letting users continue to discuss workarounds, etc.; often the issue tracker is the only kind of discussion/help forum available to project users.

Yes, it's just misconfiguration, but when you're configuring these tools you're never thinking about the damage the autolocks do to your project if you're not very careful with the settings. Remember, the people just get turned off from contributing. They don't stick around to give feedback on this being the root cause.

Hell, I never did, and I'm very vocal about autolocking being toxic.

Because I can’t see a reason for automatically dismissing issues you ignore as stale, unless you think the issue count is bad optics for your project.

As well as github’s issue triage piece being non-existent. All you’ve got is a list that shows you 20 things at a time, and it suffers from the social media effect where anyone can add bullshit memes to the thread once someone on twitter has directed the mob to it.

You don’t really see that happen so much outside of github.

I’ve a pull request to Ansible that’s open for ~ 2 years now and I keep on doing commits just to satisfy the CI without getting any actual feedback from the Ansible maintainers whether or not my pull request will be accepted.

And just yesterday I opened a pull request on the Azure cli and the CI pipeline forbids pull requests to master without telling first time contributors the accepted workflow.

My contribution is just a small typo fix in a help text, but adding a sentence of how to create a good pull request in the issue template would actually go a long way.

I would go even further and recommend using some automatic style formatter. That way, you can fail the CI step if the code is not correctly formatted and that problem is trivial to fix (just run the formatter).

This, especially in non-web repos (C/C++) is common mistake of READMEs and docs.

Let's take an example of XFCE-WM project [0]. The main README does not include any information how to compile it, nor provides any link to the documentation how to build this very specific code. If you will google it you might find following wiki page [1], which is general for all repositories. In the COMPOSITOR [2] file you might notice some information about flags that you can provide during building, and that's great such doc has been created, but except that document I couldn't find any information how "fresh contributor" would like to debug and test some change in code that he made in the cloned repository. Download and install some linux distro on virtual machine and then invest (1h+) to configure it accordingly to run it there? Use Xephyr (I guess "fresh contributor" has never heard about this tool)?

In my honest experience, the "how to build" step is probably included in many of repositories, but the "how-to-run" is usually lacking in READMEs and it is what I really would like to see in complex projects (e.g. desktop environment).

> Document your availability. If you have to step away from the project, put this at the top of the README, even if it's temporary. Don't drip-feed interaction - be either on or off.

One more thing related to docs and "how-to-build-&-run" thing. Let's say the project owner have some critical accident that made him unavailable to push progress of development forward for few months or longer. If there isn't any knowledge shared (docs, other contributors) then I guess the project will be stalled and possibly forgotten if there is no clear incentive to use alternative methods of repo maintenance (e.g. fork).

[0]: https://github.com/xfce-mirror/xfwm4

[1]: https://docs.xfce.org/xfce/building

[2]: https://github.com/xfce-mirror/xfwm4/blob/master/COMPOSITOR

[3]: https://en.wikipedia.org/wiki/Xephyr

Yes, sure - it's a mirror, but take a look at original source [0][1]. I haven't found much information about "build & run" either.

> it’s a traditional “./configure && make && make install” type project

Yes, it is but you are talking about "building" not "running", which is also important process in terms of development. Also, deduction (from source code) what kind of combination of commands might be is a no-go argument for many would-be contributors (I looking at few friends who fall in love in npm start), not saying it requires some experience in specific tooling (here, how to build C projects), which not everyone has.

[0]: https://git.xfce.org/xfce/xfwm4/about/

[1]: https://git.xfce.org/xfce/xfwm4/tree/

<rant> Somebody should tell this to Kubernetes developers.

Also, thanks to Github's braindead UI of marking every issue as either "Open" or "Closed", once I click a Google link to any Kubernetes issue I have no idea if (1) the issue is closed because it was fixed in the latest version (so I have to upgrade), or (2) the issue is closed because it turned out to be invalid (so I have to search for something else), or (3) the issue wasn't solved at all, but Kubernetes team decided to tell everybody "Haha we don't care. And to really drive the point home that we don't care, we're gonna auto-close it for lack of activity."

So I have to scroll all the way down and read the discussion. Sorry, that was my pet peeve #168 for Kubernetes. Carry on.

</rant>

I disagree... lots of bug reports actually are not bad at all, but are also not something that you want to prioritize. If multiple parties look at a bug report repeatedly for years and do not prioritize it, its a pretty good sign that it is something that will not be done. Closing bugs that aren't going to be done is a good thing, but it isn't always such an obvious decision on day 1. Of course, they can always be reopened (or duplicated) if the situations change.

That is closing them in a "WONTFIX" state. This is perfectly valid for minor irritations or matters that the maintainers don't agree are bugs at all, though some (entitled) bug reporters will take umbrage with it especially if they've taken the time to actually produce a good bug report rather than just a vague "X doesn't work" or "Y breaks Z".

If closing in a WONTFIX state, a brief explanation added to the ticket is a good idea, to reduce the risk of future time wasted because it is simply reopened as a new bug. For instance: you might be closing it in that state because it will become irrelevant shortly due to other work (perhaps the feature is changing considerably which will render the issue moot), because you don't consider it a bug (i.e. behaviour by design) or fixing to some satisfactory standard is something there isn't time for (i.e. your "not ever likely to be a priority" status). In the "not ever likely to be a priority" case, perhaps suggest that a PR addressing the issue matching your coding standards (assuming you have them documented) would be welcome, though only do that if such a PR would have a change of being given the relevant assessment time.

The only reason I can see to close old bugs is that a project wants to make it seem like it has fewer issues than it does, and hopes that users won't notice the issue.

It is a little more than that in many cases. People judging a project overall by the number of open bugs reports, no matter how minor, isn't really fair if there is considerable development on more important bugs/features/other elsewhere in the project.