Hacker News Reader

As a OSS author, the problem is that other developers also treat issues as tasks. If you look at anywhere or any kind of rubric that tries to measure the "health" of a repository, things like the number or lifetime of issues play an important role. Even npm shows publicly (open) "Issues" and "Pull Requests". Well, if my project is working as intended, I like that people look at it and see the "Issues" count to be as close to 0 as possible.

That's why I'm so excited/hopeful about Github Discussions, that seems like it was a huge hole in the whole Github and finally being addressed. A place to ask questions, meta questions, show YOUR issues using the library, etc. just a place to have conversations around the library. So you can leave the Issues for bug reports/potential issues.

I closed the Issues tab in two of my most popular libraries because they just got low quality questions where devs were expecting me/others to basically fix their code/do their homework.

Maybe I'm different, but if the repo has some dozens of issues open, I take it as a sign of health. It means people are using it enough to find problems or ask for more features. If there's no issues, it tends to mean I'm treading on new, untested (or at least less tested) ground.

A few dozen issues is one thing, but lots of the major OSS projects have thousands of open issues at any given time. If people think that each open issue is an unfixed bug or missing feature, then thousands of issues would mean that the project is at best unreliable and at worst fundamentally broken or dead. Except most of those issues are from users who should be asking questions on stack overflow.

An another OSS author, I am glad that you think that way (and I agree with you) but unfortunately not all users think that way. I have literally heard stories from users who think that my project is unstable because it had a sizable open issues count (~200). They didn't even look at the fact that 1/3rd are feature requests.

That's why there shouldn't be any "open" or "closed" state.

And yeah, the GP is calling for a forum. Bug reports, feature requests, and interface issues are a topic of discussion first, and a work item as a distant second.

There is some value in once you identify something as a bug to be fixed or an impromevent to be made, to tag the discussion saying if the work is in progress or done, and what release has it complete. None of those tags invalidate the discussion, and it's not realistic to expect all items to have a tag like this.

It's ironic that github sold itself as "social coding" coz while the design was pretty and the usability is good the social aspects are almost programmed to bring the worst out in people.

Their review workflow, for instance, is innately structured as a dehumanizing pipeline for delivering soundbites of impersonal criticism that Must Be Attended To.

It's not that it will ruin your relationships if you work with good people or vice versa but I've seen bad blood and insecurities exacetbated by the workflow that were unnecessary.

> Their review workflow, for instance, is innately structured as a dehumanizing pipeline for delivering soundbites of impersonal criticism that Must Be Attended To.

If you have good relationships with your colleagues/contributors, this will be reflected in the review process.

If you have a bad relationship, the process will be painful.

I don't think this is particularly a technology problem.

GitHub also allows "comments" for points which are suggestions, rather than requirements.

One example I was thinking of was a comment where one coworker left a comment that said "why did you do it like this?". The other coworker took offense at the remark.

The same comment made in person while doing a code review wouldn't have nearly the same effect because the body language would convey additional meaning (e.g. this is an honest question, I'm not indirectly calling you stupid here).

This is often an inherent problem with internet forums which is why people often blow up on them over perceived slights, but there's many ways to mitigate this type of thing, e.g.

* low friction means of expressing appreciation

* some sort of low friction one-click polite programmed responses (e.g. X doesn't understand this area of the code, could you explain it?)

* something monitoring comments and suggesting rewordings

* actually adjusting to textual modes of communication?

I don’t want this to sound trite or disingenuous, and I especially don’t want to assign blame (unless you know me personally, you probably won’t ever encounter an instance of my intentionally assigning blame to individuals), but short-form, semi-synchronous textual communication is just different, to the point that linguists extend the usual classification of discourse from spoken and written into spoken, written, and “IM-ish” (which turns out to be closer to spoken despite using writing). Not all modes of expression are immediately accessible to everybody (I’m constantly anxious over emails, which is tremendously inconvenient), and we should absolutely try and help people adjust, but to say that the mere requirement of adjusting is evidence of inferiority or evil nature is unfair to things that are just not the same as other things (insert UI/UX example here). This is not to say that there are no evil things, just that this particular argument for evilness is so weak as to be tautologically true for almost any thing at all (when I was a child, they would sell vegetables marked “zero cholesterol”).

I mean, “why did [they] do it like this” is one of the most harmless questions to ever exist as far as I can see (provided there’s enough context to figure out what “it” refers to and what “this” specifically is supposed to be surprising, so that it is not disproportionately low-effort or bad-faith obstructive, but that equally applies to spoken interaction). Literally most of my brain-time is devoted to answering questions of this type I ask myself, so when somebody else asks such a question it’s the most unsurprising thing I could imagine. I was similarly baffled when in a recent discussion someone suggested starting a sentence with “I might be wrong, but ...” is perceived as aggressive. How else am I supposed to communicate “I don’t feel competent in this particular area but on general principles I’m fairly sure that ...”, and in what world does warning people of the potential irrelevance of your opinion read as aggressive?

I’d be happy if it turned out I’m just not perceiving a subtlety of language (despite using English for most of my life, I am not and will never be a native speaker), but that’s not what people seem to be saying. A cultural disconnect sounds more plausible (cf. “ ’Splain it to me”), but again “people foreign to the culture can feel uncomfortable or misunderstand” is by itself not a sufficient argument for a change of culture, especially if that culture (chat or comment etiquette) is more or less inherent to the environment (short-form semi-synchronous communication).

[In case the gentle reader is wondering how this comment could ever count as “short-form communication”: I’m like this in person, too. Sigh.]

>I mean, “why did [they] do it like this” is one of the most harmless questions to ever exist as far as I can see (provided there’s enough context to figure out what “it” refers to and what “this” specifically is supposed to be surprising, so that it is not disproportionately low-effort or bad-faith obstructive, but that equally applies to spoken interaction).

I'm pretty sure I could change the meaning of that sentence wildly using intonation and body language. I could certainly make it an offensive statement intended to undermine the listener.

One problem with textual discourse is that people just fill in the body language themselves. Often wrongly. Especially if they let their insecurities fill in the gaps. Which developers with imposter syndrome (i.e. most) will often do.

Emojis help fill in this gap somewhat for some kinds of written discourse (e.g. to intonate sarcasm, "only joking", etc) but on a PR i've never really seen them put to good use.

I think on a PR it might help if the user gets somewhat railroaded into a set of default replies that precisely convey what would otherwise be unstated feeling, emotiom and intent but I'm not totally sure that's how to fix the problem.

It also wouldnt stop wanton dicks from being dicks (not that i think that it's githubs job to fix that).

I do know it is a problem though and i dont think it's on githubs radar at all.

To be fair it used to be much worse before they had comments and every PR comment got treated as a FIXME.

> I was similarly baffled when in a recent discussion someone suggested starting a sentence with “I might be wrong, but ...” is perceived as aggressive.

That's a very standard phrase to signal you're not being confrontational. I don't know how they could perceive that as aggressive.

Are suggesting that code review is a net negative or that having a visual interface for reviewing a patch set brings out worse in people than emailing around patchsets?

Code-bases, especially large ones “Must Be Attended To” and reviews should be impersonal. A good review is inherently inspection and critiquing code, not the author and can present many good learning opportunities for both sides of it.

>Are suggesting that code review is a net negative

Good god no.

I'm, ironically enough, suggesting that misinterpretation of textual content is a bit of a problem :)

>reviews should be impersonal. A good review is inherently inspection and critiquing code, not the author

I can remember hundreds of times I've seen textual code reviews that were "just critiquing code" that were interpreted as a critique of the author.

It's particularly a problem when coders with slightly less social awareness than others write comments and don't pause to think how they might be interpreted. The example I gave in the comment above is just one of these.

> Their review workflow, for instance, is innately structured as a dehumanizing pipeline for delivering soundbites of impersonal criticism that Must Be Attended To.

I'm not at all a fan of GH's PR UI*, but this is a very intense characterization. Could you expand on the flaws you see?

*I think it doesn't do its job of presenting information and letting me navigate the change very well.

I'm not sure you're implementation would actually be useful, and effectively you are doing the same thing as stalebot, just in a less obvious way.

If you have 100 reports created in a month on a form, then it is very difficult to see what is triaged, who is working on what, and what still needs attention. The reporter wants something, which is by definition a task.

The simple reports get resolved quickly, so you post a message saying that it is resolved. In a form that is now the top message. Other team members are more and more likely to click on already resolved issues at the top, which may not obviously be resolved.

Eventually these resolved posts will age out and be paginated away, along with other non-resolved reports. The non-resolved reports are essentially closed by being stale. They have been aged out, and no one looks at old reports because they are mixed with things already actioned.

People will still search the form, just as they do tickets, which is the same either way.

I wish github made it easier to seperate issues into different tabs -- while I can tag issues, by default you click on the 'issues' tab and see 100 (or 1000) issues, sorted by date.

As you say, issues are bugs (which often need fixing ASAP), feature requests, general requests for help, etc. etc. It seem very hard to stop issues piling up to the point where you lose control out of them on any github project.

I never had to use Github professionally until the last 2 years and it's horrible for anything but basic projects. Gitlab has "scoped" labels, for instance "db:mysql" or "mysql:bugfix" "mysql:performance", maybe one day Github will copy that or come up with something unique on their own but with the way github actions is going I don't see it happening.

You can see examples of scoping here. "devops/create" etc, https://gitlab.com/gitlab-org/gitlab-docs/-/issues

It's not perfect, but the GitHub CLI might help you with this. You can list issues filted by tags and potentially use your own tagging conventions to construct useful views.

I hadn't even considered their CLI. Thanks, I've been digging around at other repos examples a lot.

Yep. GitHub Issues is not a scrum board and shouldn't be treated as such. It's for consumers to discuss with authors and other consumers.

If its point is really consumer discussion with authors (I don't think it is) then Issues is a pretty terrible name for it. Given the overall quality of GitHub in literally every other aspect of the product, I find that unlikely.

Yes, I think this is it. It all might have been started as "bugs" or "Issues" but over time, the functionality was extended to have feature requests, different discussions, etc. I don't have an alternative name for this, Notes maybe? But Issues sounds more severe than what it usually is.

I think it's possible to work this way while still having single issues - I usually like to do a two phase resolution of an issue.

First, I triage issues - this should be done relatively quickly (within a day is a good target), and should involve reviewing the issue, determining whether it represents a genuine bug, a misunderstanding, a missing feature, etc., tries to identify where the problem might be occurring, and provides any workarounds, etc. That should happen on every issue without exception.

Second is actually solving the issue, if it wasn't solved during triage. The 60 days can be useful here - as much as we all want to have bug free software, an issue that a single person encountered 60 days ago and hasn't been seen or reported by anyone since might just not be worth fixing or might not even exist anymore. Maybe it's unfair to users, but also keeping an issue open indefinitely can be equally unfair - if you're realistically not going to fix something, better that the user knows now.

There's for sure cases where a single report is actually about multiple bugs, but that's relatively rare and I'm happy treating that as the exception rather than the rule.

Or, what usually happens, is someone like me runs into the bug. I search the issues and find it closed. I consider the maintainer incompetent because the issue was reported and either fixed, but they obviously don’t have regression testing, or the don’t care about actually fixing bugs. Either way, I will probably seek out a different project if I can. If the issue is open, even for years, that’s totally different and understandable.

Does the stalebot check for recent reactions (thumbs up, etc) or just comments? I think it’s the latter, meaning it is closing issues others may have and know that “me too” replies are frowned upon.