This treatment of issue-as-a-task is made worse by corporate micromanagement frameworks like Agile, which encourage metrics on how many of these issues-as-tasks are closed, which leads to ill-advised features like this that close them automatically because "Duh, no one said anything in 30 days".
If I were to design this myself, I would argue that the correct way to treat an issue is not to have it have a closed or open state at all. If the issue spawns a task or related tasks, you can close those. Or you can provide feedback on the issue that states that it is invalid. The user has already experienced a problem or wants a feature, there is no value in putting a red label that indicates "I'm done with this, please go away". It unnecessarily invalidates the experience of users who have their provided valuable time to report something to your software project. I think this is similar to the approach used by forums like Discourse, where a thread about a problem will usually not be closed or locked, but will just age out of current discussion if nobody brings it up.
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.
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.
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.
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.
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
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'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.
That's a very standard phrase to signal you're not being confrontational. I don't know how they could perceive that as aggressive.
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.
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.
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.
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.
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.
You can see examples of scoping here.
"devops/create" etc, https://gitlab.com/gitlab-org/gitlab-docs/-/issues
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.