Hacker News Reader

> Don't close bug reports just because they're old. A bug report is either good or bad - that is, the bug is either reproducible or it isn't. A bad bug report is bad from the start; close it quickly - or else, don't close it just because enough time has passed.

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.

You can learn about a maintainer's experience with closed issues that keep being bumped here: https://www.henryzoo.com/an-issue-with-issues/

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/

I get you. I'm a maintainer as well. But I'm not even talking about "long resolved" issues. Last week I saw an issue created by the maintainer themselves to talk about some upcoming milestone or something, that got autolocked before the milestone got there.

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.

There’s no special reason maintainers have to respond to (or even read) every comment on some years-old issue.

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.

When I see projects on Github using the Stale Bot to automatically close issues, I don't bother looking any further. There is something so incredibly infuriating about having an issue closed automatically - when I know it is still a problem but no one has had time to look at it yet. It reminds me very much of the MSDN community threads where the accepted answer is "reinstall Windows and see if that fixes it" with hundreds of replies after that indicate it did not help.

I wonder if this would change if GitHub took the simple step of removing the PR/issue counters from the navigation.

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.

The CI is something that keeps me from contributing. I don’t say it doesn’t do it’s job and I don’t say it’s not useful. What I mean is the CI is often set up to enforce rules that aren’t clear when you create the pull request.

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.

> * Have a style guide. Link it in the README. This saves you time in review.

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).

Oh yeah, good point.

Plus I find that having an impersonal tool tell people that they did something "wrong" makes them a lot more likely to fix it and still be amenable to your future suggestions.

> Document how to build and run it.

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

To be fair, that looks like a mirror that’s been separated from its “intended” location (where there might be a link to these instructions) plus it’s a traditional “./configure && make && make install” type project anyways

> that looks like a mirror

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/

This is the cause of many people giving up contributing to software projects. Clearly pointing to specific versions, distributions used, or (if willing to move one step ahead) prepping a VM Image or container with all the dependencies set is really helpful

> Don't close bug reports just because they're old.

<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>

* Don't close bug reports just because they're old. A bug report is either good or bad - that is, the bug is either reproducible or it isn't. A bad bug report is bad from the start; close it quickly - or else, don't close it just because enough time has passed. (This goes doubly for bug reports with advice.)

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.

Well, then the bug stays open. :shrug: Why is that so bad?

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.

> 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.

It also isn't fair for people who assume a project that has a large number of closed issues is highly active, when in fact, a large number of those issues have just never seen any activity and were closed for being stale.

If the issues are closed with WONTFIX or similar status, as discussed nearby in this thread, then it should still be clear that something is going on. It is then up to the reader to decide if that something is enough for them to worry about or not.

That isn't closing them "just because they're old" though.

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.

These are all sensible rules, and I think plenty of open source projects are doing fine on this front, though its important to note that properly keeping up with these practices is a full-time job.

Yeah, I have a feeling that plenty projects start with this nice set of rules and they get lost along the way...

so true.