Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why users cannot create Issues directly

github.com

Post reply on HN
Print view View original

181–190 of 320 posts

Re: Why users cannot create Issues directly

#181

Post by xpe »

timcobb wrote: post #178

Great post. This should be the default configuration, community can make discussions, contributors can make issues.

> Great post. This should be the default configuration, community can make discussions, contributors can make issues.

1. We often say 'should' too easily. The post isn't making such a claim is it? I would shift away from saying 'should' to saying: start somewhere that works for your project, gather feedback and evidence, and adjust thoughtfully. You'll end up in a place that feels authentic.

2. If anything, I would prefer the default be random. Then projects end up being natural experiments. See [1]

3. At a meta level, this reminds me of Brian:

> Brian: Look, you've got it all wrong! You don't need to follow me. You don't need to follow anybody! You've got to think for yourselves! You're all individuals!

> Crowd: Yes! We're all individuals!

> Brian: You're all different!

> Crowd: Yes, we are all different!

> Man in crowd: I'm not...

> Crowd: Shhh!

[1]: https://en.wikipedia.org/wiki/Natural_experiment

Re: Why users cannot create Issues directly

#182

Post by wpietri »

skobes wrote: post #147
mitchellh wrote: post #59

Earlier quoted context omitted.

Note that this is an active discussion where we're trying to get to a point of clarity where we can promote to an issue (when it is actionable). The discussion is open and this is the system working as intended! I want to clarify though that there isn't a known widespread "memory leak issue." You didn't say "widespread", but just in case that is taken by anyone else. :) To clarify, there are a few challenges here: 1.…

This illustrates the difficulty of maintaining a separation between bugs and discussions: > To be clear, I 100% believe that there is some kind of leak affecting some specific configuration of users In this case it seems you believe a bug exists, but it isn't sufficiently well-understood and actionable to graduate to the bug tracker. But the threshold of well-understood and actionable is fuzzy and subjective. Most bu…

Is the distinction arbitrary? It sounded like issues are used for clear, completable jobs for the maintainers. A mysterious bug is not that. The other work you describe is clearly happening, so I'm not seeing a problem with this approach other than its novelty for users. But to me it looks both clearer than the usual "issue soup" on a popular open source project and more effective at using maintainer time, so next time I open-source something I'd be inclined to try it.

Re: Why users cannot create Issues directly

#183

Post by lijok »

layer8 wrote: post #162
lijok wrote: post #69

A couple of big projects in the python space use this approach. Pisses me off as a power user. I find what are clearly bugs all the time, and am forced through a funnel that places the burden on me. Stinks of arrogance to think your project is that rock solid you should add friction for reporting bugs. Especially in “forever v0” projects. But, I am super lazy.

How is opening a discussion more friction than opening an issue?

In the python projects in question, unlike with the Ghostty project, there isn't an "issue triage" discussion category that maintainers look at. They have just discussions, and everything is treated as such. So when you raise an issue in discussions, it either goes to the void or people come in looking for a discussion of alternative approaches to do what you're trying to do that don't hit the bug, rather than treating the bug as a bug.

At a high level - the audience of discussions is the community at large, the audience of issues is the maintainers.

What Ghostty is doing with a dedicated category for issue triage should work just fine, despite it being an additional hop.

Re: Why users cannot create Issues directly

#184

Post by ozim »

machomaster wrote: post #136
ozim wrote: post #87

Earlier quoted context omitted.

I believe most of it is people expecting stuff to work differently, not having time to wrap their head around proper usage of system, because they need specific outcome and they don't need mastery of the tool. Downside is that "Facebookization" created a trend where people expect everything to be obvious and achievable in minimal amount of clicks, without configuring anything. Now "LLMization" will push the trend for…

It is weird to push the idea that Facebook is some kind of pinacle of good and easy to use UI. That's the first one. It's quite the opposite, with people constantly complaining how bad, clunky and confusing Facebook is. And it is not the recent trend either. It has always been this way and e.g. VK has always had a better UI/UX that Facebook (and Telegram's is better that Whatsapp's).

Not as pinnacle of good - but pinnacle of “you don’t have to think, just scroll, occasionally like something” ;).

Then people expect accounting software to be just login click one or two buttons.

Re: Why users cannot create Issues directly

#185

Post by xpe »

rorytbyrne wrote: post #170
mitchellh wrote: post #59

Earlier quoted context omitted.

Note that this is an active discussion where we're trying to get to a point of clarity where we can promote to an issue (when it is actionable). The discussion is open and this is the system working as intended! I want to clarify though that there isn't a known widespread "memory leak issue." You didn't say "widespread", but just in case that is taken by anyone else. :) To clarify, there are a few challenges here: 1.…

I spotted Ghostty using 20GB+ memory a few days ago on MacOS (according to Activity Monitor). I went through all my tmux sessions, killed everything, it was still 20GB+ so I re-started Ghostty. If I see it happen again, I'll take some notes.

On some level, that's impressive. Any idea of how long Ghostty was alive? Maybe this a new feature where Ghostty stores LLM model parameters in the terminal scrollback history? /s

Re: Why users cannot create Issues directly

#186

Post by locknitpicker »

timcobb wrote: post #178

Great post. This should be the default configuration, community can make discussions, contributors can make issues.

> Great post. This should be the default configuration, community can make discussions, contributors can make issues.

I'm not so sure. I think this sort of discussion mostly falls within the realm of bike shedding. I'll explain why.

There's such a thing as a ticket life cycle. Ticketing flows typically feature a triage/reproduction stage. Just because someone creates an issue that doesn't necessarily mean the issue exists or isn't already tracked somewhere else, or that the ticket has all the necessary and sufficient information to troubleshoot an issue. When a ticket is created, the first step is to have someone look at it and check if there's something to it. This happens even when tickets are created by internal stakeholders, such as QAs.

GitHub supports ticket labels, and the default set already cover these scenarios.

https://docs.github.com/en/issues/using-labels-and-milestone...

To me this discussion sounds like a project decided to update their workflow to move triage out of tickets and into a separate board. That's fine, it's the exact same thing but with a slightly more complex process. But it's the same thing.

Re: Why users cannot create Issues directly

#187

Post by evanjrowley »

g947o wrote: post #156
sleekest wrote: post #68

Earlier quoted context omitted.

One difference is that if I submit an issue, and it requires some back and forth to figure out the actionable improvement, then suddenly the issue is very noisy. Whereas if it goes via a Discussion first, the back and forth happens elsewhere. Arguably an separate issue could still do this, but it being a discussion sets the expectation better.

This kind of thing happens in Jira or any company's internal bug tracker, and GitHub Issues is not any different. If you want a certain kind of "hygiene", you can always do that in the existing system instead of inventing a whole different solution. > Arguably an separate issue could still do this, but it being a discussion sets the expectation better. People do that all the time in bug trackers.

As someone wearing the post-sales support hat for a non-OSS product, I appreciate use of "ready" tags in Jira. Unlike OSS, our engineers prioritize KPIs to be compensated for their work, and so we must find a way to track the triage discussions within Jira. In a significant way, Jira is solid proof that work happened, even if no actual code was pushed into the repo. If the support team has an unconfirmed bug that requires a technical deep dive, then the "non-ready" Jiras seem like a good fit. I'm open to a better way of doing this and would like to learn more about alternatives, but for now, this is how the teams engage.

Re: Why users cannot create Issues directly

#188

Post by jamietanna »

We've been doing this on the Renovate project for years, and it's been hugely useful - we get a lot of reports that users feel to be a bug, but are often misunderstanding or expectations about behaviour that isn't necessarily true.

There are absolutely bugs that get reported - either in functionality or documentation - but by requiring a level of triage in Discussions before promoting them up to Issues is a great way to keep things more actionable for folks wanting to come in and contribute fixes that the maintainers do agree are needing a fix

Re: Why users cannot create Issues directly

#189

Post by Aurornis »

asdfaoeu wrote: post #149
codeflo wrote: post #124

Earlier quoted context omitted.

> Most bug trackers have ways to triage submissions. When a rando submits something, it has status "unconfirmed". Developers can then recategorize it, delete it, mark it as invalid, confirm that it's a real bug and mark it "confirmed", etc. As far as I'm aware, most large open GitHub projects use tags for that kind of classification. Would you consider that too clunky?

This still puts the onus on the developers to categorise the issues which I'm guessing they don't want to do.

There are several automation solutions for GH issues. You could have an automatic “unconfirmed” tag applied to every user-created issue if you wanted.

Re: Why users cannot create Issues directly

#190

Post by dceddia »

mitchellh wrote: post #59
quantummagic wrote: post #8

Earlier quoted context omitted.

That's a shame to hear. I had to give up on Ghostty because of its memory leak issue. Granted, it was on an 8GB system, but that should be enough to run a terminal without memory exhaustion a few times a week. Foot has been rock solid, even though it lacks some of Ghostty's niceties.

Note that this is an active discussion where we're trying to get to a point of clarity where we can promote to an issue (when it is actionable). The discussion is open and this is the system working as intended! I want to clarify though that there isn't a known widespread "memory leak issue." You didn't say "widespread", but just in case that is taken by anyone else. :) To clarify, there are a few challenges here: 1.…

Is it possible for Ghostty to figure out how much memory its child processes (or tabs) are using? If so maybe it would help to surface this number on or near the tab itself, similar to how Chrome started doing this if you hover over a tab. It seems like many of these stem from people misinterpreting the memory number in Activity Monitor, and maybe having memory numbers on the tabs would help avoid that.
Post reply on HN