_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
HTML Visit Hacker News on the Web
COMMENT PAGE FOR:
HTML Why users cannot create Issues directly
tarkin2 wrote 20 min ago:
So how do the maintainers and contributers know when a Discussion
details a bug ready to be worked on? Seems like, as with issues,
they'll still be sorting though them and looking for the most active
ones?
Edit: after reading the contributors doc, it seems that feature
requests are discussions which should help. Unreproducible bugs, too;
although I would wager that a lot of users believe they can reproduce
bugs but in fact can't consistently, or believe their feature request
is a bug.
It seems this approach is better but still requires someone to sort
through the discussions before they're moved to the cleaner issues
pile.
One big pile with filters, or a chaotic pile and a clean pile. That
seems to be the end result of this, unless I'm missing something.
jwr wrote 30 min ago:
This makes perfect sense and is so much better than getting a flood of
half-baked "issues" and then closing them automatically with a bot for
"inactivity".
konhi wrote 43 min ago:
The motivation for that is very convincing, yet a quick glance at
Issues tab makes me understand it without any additional explanation.
It looks great. As mentally easy to process as Jira tasks. Or even
better, cause it was written by a good "PM", which is not always a case
commercially.
nikanj wrote 55 min ago:
Just do the Apple / Google / MS model where anyone can freely open
tickets, and then those bugs are never seen or addressed by any
developers. Essentially use the bug tracker as a honeypot to keep the
users happy
harvie wrote 59 min ago:
This is much better than the stale-bot bs irreversibly closing
perfectly valid issues just because the reporter have not replied for
couple weeks.
arccy wrote 1 hour 2 min ago:
If only you could have project boards with their different views be the
top level tabs instead of just open issues and pull requests...
creatonez wrote 1 hour 50 min ago:
People complain about Github not allowing you to turn off issues and
pull requests entirely, but I've always seen it as a positive. It means
the truth about code quality, potential caveats, and better forked
revisions can disseminate freely even when the author disappears. It
becomes a spamfest at times, but is still probably a net positive for
the ecosystem.
That being said, as long as you still have the discussion tab,
auto-deleting all issues by default is not a big deal.
WhyNotHugo wrote 1 hour 59 min ago:
Personally, I find the distinction between âissuesâ and
âdiscussionsâ annoying.
For one, it duplicates the efforts in checking for prior reports. I
might try 5â6 sets of keywords, but now I have to do so for 2
separate trackers.
Tickets cannot be moved between trackers, so instead folks resort to
duplicating it and moving discussions⦠which is entirely opaque if
youâre following up via email: you wonât get any more notifications
and your future replies are silently discarded.
As a maintainer, having two trackers per project never made sense to
me, so Iâve disabled discussion everywhere.
This is mostly a criticism of how GitHub implemented this feature, not
of the decision taken here.
arccy wrote 1 hour 5 min ago:
behold the best way to search github issues. Using Google or whatever
decent search engine:
site:https://github.com/org/repo key words
botanical76 wrote 39 min ago:
Does this actually work? I would think it will be out of date by at
least weeks, and I'd be surprised if their crawlers actually
iterate through every issue page.
xixixao wrote 1 hour 45 min ago:
At the very least I think what matters here is the process. The same
exact process could be implemented via, for example, issue labels. It
would not be hard for maintainers to search for issues with label
"bug", which only maintainers can assign. There are clear UX
tradeoffs between the two approaches.
spinningarrow wrote 1 hour 54 min ago:
Why would checking be duplicated? One would need to check only the
discussions in this case, since issues will be created from
discussions once something is ready to be worked on (as I understood
it)
layer8 wrote 32 min ago:
Thatâs only for non-maintainer submissions. When a maintainer
notices a bug or decides on a new feature, they can open an issue
for that right away, without prior discussion.
ChrisMarshallNY wrote 2 hours 7 min ago:
This makes sense.
Personally, I use GH Issues for my own work, but thereâs very few
issues, so itâs not a burden. Iâm a non-fan of JIRA.
I have seen GH Issues turn into Reddit-like flamefests (every now and
then, someone posts a particularly entertaining one, here). Not my idea
of productive work.
euroderf wrote 2 hours 30 min ago:
It's a good idea to reserve issues for well-defined, actionable stuff.
IRL every dev issue tracker needs a front-end bozo filter to handle the
low-hanging fruit and the misunderstandings and the failures to RTFM
and the cases of PEBCAK.
Eikon wrote 2 hours 33 min ago:
What I often do on ZeroFS [0] is to convert issues to discussions, it's
a one click operation on github and helps reduce the noise for
ill-defined issues.
[0]
HTML [1]: https://github.com/Barre/ZeroFS
snudan wrote 3 hours 7 min ago:
Why not use labels for this? Discussions seem to be a bad use case for
bug reports, but I can understand using it for feature request
bob1029 wrote 3 hours 9 min ago:
> 80-90% of what users think are bugs are either misunderstandings,
environmental problems, or configuration errors by the users
themselves.
Who does this project actually serve? The "users", or someone else?
If I'm getting overwhelmed with hundreds of issues per week about some
confusion around installation or use, I think those issues are
completely justified. Something should probably be fixed if the happy
path is this obscure. Pushing this reality into another bucket is not
the solution for me.
randyrand wrote 1 hour 43 min ago:
It serves the open source maintainers, who enjoy working on it.
Hendrikto wrote 3 hours 3 min ago:
Did you also read the part about using Discussions instead? Itâs
not that users are not allowed to voice feedback, make request, or
ask questions. They should just do so in a different place.
> Any Discussion which clearly identifies a problem in Ghostty and
can be confirmed or reproduced will be converted to an Issue by a
maintainer
franciscop wrote 3 hours 3 min ago:
As an OSS maintainer myself, while the amount of tickets about a
specific topic _might_ be loosely related to the quality of the
docs/installation/etc, this hasn't been true in my observations.
It's one of those explanations that sound very plausible on paper,
but if you see real world issues it just doesn't happen, users will
ask questions that are clearly explained in the first paragraph of
the readme, en masse.
burnt-resistor wrote 3 hours 28 min ago:
Sure, issues for tasks and discussions for conversations.
And then there are developers who idly complain about normal
participation on the work of issues and coordination of testing and
feedback because it sends them a notification that they turned on.
Unconstructive bitching drives users and collaborators away. They could
solve their notification problem rather than impose a burden and
emotional bullshit on everyone else.
goku12 wrote 3 hours 40 min ago:
This is the natural way to do it. I have had to use the issue tracker
for asking questions (support requests) or informing the developer of
something (like of implementing a related feature in another software).
Clearly, those aren't issues at all, and the normal workflow steps like
closing the ticket doesn't make much sense at all. They belong to the
discussions list.
Issue trackers should be used exclusively for earmarking and tracking
the progress of actionable items. This is somewhat similar to the
integration between email clients and task managers, like how it's done
in Gmail, Zoho, etc. You read the message first. If it requires an
action from your side, create a task from it and link them.
There are other projects that do this too. A good example is the 'mise'
project. Sourcehut projects use this workflow almost exclusively since
it's the default by design. I think sourcehut had if before github did.
What I would like to see is better integration between
discussions/messages and task/issue lists on all these platforms.
OmarShehata wrote 3 hours 15 min ago:
I think this is the natural process, but how you implement it doesn't
matter. A lot of GitHub repos use "unlabelled issue" === "a
discussion thread". The benefit is that instead of having to search
two separate systems, you can just search one (if you can have an
aggregate search over both then it really doesn't matter), these two
implementations are isomorphic
cjk wrote 4 hours 0 min ago:
Having maintained a relatively popular open source project for a bunch
of years, I love this idea. Totally stealing this for future projects.
RockieYang wrote 4 hours 8 min ago:
Great approach. It can also prevent negative energy leak to passionate
maintainers.
larusso wrote 4 hours 20 min ago:
âItâs not a bug itâs a feature!â
Just the first thing that popped into my head reading the reasoning. I
think it makes a lot of sense to do it like this. Especially for a
product which is cross platform that emulates / replaces other known
products and on top has extensive configuration options. I also
switched over from kitty a couple of weeks back and really like it.
BrenBarn wrote 4 hours 40 min ago:
I've seen other projects that do this, and it makes a lot of sense. A
discussion forum is a good place to start. It seems though that many
projects don't have the Github "discussions" activated.
firesteelrain wrote 5 hours 5 min ago:
I didnât know GitHub had discussions. This is great
gorgoiler wrote 6 hours 15 min ago:
A lot of bugs where I work have the same pattern: one person writes up
either what they found to be broken or what they couldnât do due to a
missing feature, then a shadow task is created that describes the bug
and what needs to be changed to fix or implement it. Iâve never had
problem with both the report and the work-tracker being in the same
place but I can see why GitHub calling the product âIssuesâ might
not have been a great name.
lijok wrote 6 hours 19 min ago:
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.
layer8 wrote 20 min ago:
How is opening a discussion more friction than opening an issue?
skywhopper wrote 2 hours 13 min ago:
The arrogance in in users like yourself who think they know better
than the project owners how to run their issue tracker. This is just
a variation. Itâs not a barrier, itâs an attempt to improve the
quality of the issues that are filed in a way thatâs more useful
for everyone.
lijok wrote 26 min ago:
To be clear, I am not telling Mitchell how to run his project. I am
providing info on how a change like this can be perceived from the
other side. Do with the information what you will.
arendtio wrote 2 hours 43 min ago:
Maybe you should become part of the project if you find bugs
regularly ;-)
burnt-resistor wrote 3 hours 34 min ago:
Your feedback is very important to us. Please fill out this long ass
form and provide mountains of telemetry as barriers to participation.
Etheryte wrote 5 hours 17 min ago:
I always struggle to understand this level of entitlement. No one is
forcing you to use any of these projects. The vast majority of the
time, drive-by bug reports by users are a complete waste of time
because they're either a user error or not described in sufficient
detail to debug. In other words, mostly noise, and adding more noise
isn't really helpful.
If you want to contribute, a much better way is to work on bugs that
are already well defined. There is generally no shortage of known
bugs in software, there is however a shortage of people fixing them.
Mawr wrote 3 hours 39 min ago:
There's zero entitlement expressed by the parent, he's just trying
to help the project, but is encountering unnecessary friction.
It's not that he has some inner urge to contribute in some way, he
just encountered a bug while using the software and wants to report
it. The alternative isn't coding â it's no contribution at all.
skywhopper wrote 2 hours 12 min ago:
How is âsubmit your issue to this nearly identical discussion
tool in the same web appâ a burden?
ncruces wrote 2 hours 40 min ago:
Maintainers did a bunch of useful work for them and they refuse
to report issues the way maintainers find the most useful,
because it's a burden to help maintainers do all their free work.
Etheryte wrote 2 hours 51 min ago:
I think this is exactly the point most people miss. No
contribution is better than bad contribution. Most issues people
file are bad. I previously worked at a major OSS company and the
vast majority of bug reports are just noise. It takes time to
sift through them and they add no value, just waste time. If
people did less of that, that would be a good outcome, not a bad
one. Sure, there's useful reports there sometimes, but it's more
rare than you'd think. On top of that, many of those are dupes of
issues we've already found and filed, just haven't had time to
fix yet.
gertop wrote 6 hours 0 min ago:
To be fair it also stinks of arrogance to think that you have the
skills to know "what is clearly a bug" 100% of the time in projects
you don't own.
pbhjpbhj wrote 3 hours 4 min ago:
Fwiw, you might have misinterpreted the idiomatic expression "all
the time" as meaning "100% of the time". It just means "often" or
"commonly". The parent is just saying they often find bugs, they
know they're bugs through experience.
Of course anyone can make a mistake. Maybe you prefer the
'discussions' route because it's only seemingly then possible for a
projects own devs to make a mistake in creating an issue.
RobotToaster wrote 3 hours 11 min ago:
>90% of the time it's usually pretty clear if something is a bug,
especially if there's log files full of errors.
Const-me wrote 4 hours 25 min ago:
> to know "what is clearly a bug" 100% of the time in projects you
don't own
Owning a project is counter-productive for QA. If itâs your
project, you know where to click and where to not click.
OTOH, you donât need to know anything about a project to conclude
that a crash with access violation, or hang with 100% CPU usage,
are clearly bugs.
bsnnkv wrote 6 hours 53 min ago:
I'm a fan of this. My own projects on GitHub have an action[1] which
autocloses and autolocks any opened issues until they have been
reviewed and accepted by me, and I only consider feature requests from
sponsors.
The real miss here is that there isn't a way on GitHub to only allow
maintainers to create issues, instead we are left with these subpar
workarounds.
[1]
HTML [1]: https://github.com/LGUG2Z/komorebi/blob/master/.github/workflo...
shevy-java wrote 7 hours 18 min ago:
I think this is ok. They attempt to add a barrier here, with the
attempt to increase the quality of the issue suggested. This may not be
the only goal; one may be to have fewer issues raised in total. But
there may be several advantages, as well as disadvantages with that
approach - it is simply a trade-off.
In particular when I maintain an open source project, I have a lack of
time in general so I need to move quickly. I actually don't mind issue
discussions on my project, but people can not expect me to invest a lot
of time into managing all of those; whether this is a discussion or an
issue directly, is not so important, but I know that some project
owners don't like open issues that remain open for years. It is kind of
a difference in philosophy here.
One trade off is that I am not so likely to get involved in such a
project. I may start a discussion, but in general I am very chaotic and
may never follow up on discussions I started, simply due to lack of
time, too many things to do, forgetting too much too (I do keep notes
locally, but these files just keep on growing!).
Animats wrote 7 hours 18 min ago:
This is a good AI application - something which accepts user problem
reports and tries to group them together. Maybe even reproducing the
bug in a sandbox if the description is good enough. Engaging with the
complainant to get more info.
This could be useful if not used for enshittification, where you have
to get past the chatbot to reach anybody useful.
pella wrote 7 hours 38 min ago:
2025-12-30 [1] "Slop drives me crazy and it feels like 95+% of bug
reports, but man, AI code analysis is getting really good. There are
users out there reporting bugs that don't know ANYTHING about our
stack, but are great AI drivers and producing some high quality issue
reports.
This person (linked below) was experiencing Ghostty crashes and took it
upon themselves to use AI to write a python script that can decode our
crash files, match them up with our dsym files, and analyze the
codebase for attempting to find the root cause, and extracted that into
an Agent Skill.
They then came into Discord, warned us they don't know Zig at all,
don't know macOS dev at all, don't know terminals at all, and that they
used AI, but that they thought critically about the issues and believed
they were real and asked if we'd accept them. I took a look at one, was
impressed, and said send them all.
This fixed 4 real crashing cases that I was able to manually verify and
write a fix for from someone who -- on paper -- had no fucking clue
what they were talking about. And yet, they drove an AI with expert
skill.
I want to call out that in addition to driving AI with expert skill,
they navigated the terrain with expert skill as well. They didn't just
toss slop up on our repo. They came to Discord as a human, reached out
as a human, and talked to other humans about what they've done. They
were careful and thoughtful about the process.
People like this give me hope for what is possible. But it really,
really depends on high quality people like this. Most today -- to
continue the analogy -- are unfortunately driving like a teenager who
has only driven toy go-karts."
"Examples: [2] "
HTML [1]: https://x.com/mitchellh/status/2006114026191769924
HTML [2]: https://github.com/ghostty-org/ghostty/discussions?discussions...
otterley wrote 7 hours 47 min ago:
(2014)
purpleidea wrote 7 hours 47 min ago:
How is the technical block done? Just a bot closing issues or is there
some github setting for this?
eduction wrote 7 hours 58 min ago:
> 80-90% of what users think are bugs are either misunderstandings,
environmental problems, or configuration errors by the users
themselves. For what's left, the majority are often feature requests
(unimplemented features) and not bugs (malfunctioning features).
Do I ever make mistakes?
No. Itâs the users who are wrong.
anttiharju wrote 3 hours 49 min ago:
I think the main point is that all issues are ready for contributors
to work on
gertop wrote 5 hours 55 min ago:
Those modern terminal projects have weird defaults and quirky
behaviors just to be different.
So to me it's easy to believe that a user expects something to work a
certain way, does minimal or no research about it, and go directly to
report a bug when in reality it's intented behavior.
8n4vidtmkvmk wrote 6 hours 58 min ago:
I can believe this. I think it depends on the project, but there are
certainly some with very high false positives. Maybe that's
indicative of a confusing app, I don't know.
gizmo686 wrote 8 hours 8 min ago:
I have never worked on projects that give non members write access to
our bug tracker.
This includes both our open source project not giving the public
access. And our entirely closed source internal projects not giving
other developers within the company write access.
Groxx wrote 8 hours 13 min ago:
Hmm. I like it.
When I have a clear "Issue" which I've already researched, it's a bit
of friction, but it doesn't seem like any more work to dump exactly the
same text into a Discussion... and yea. Issues becoming a dumping
ground is a real issue. This seems like a reasonable strategy /
experiment.
ok123456 wrote 8 hours 30 min ago:
100% agree.
If it's someone else's project, they have full authority to decide what
is and isn't an issue. With large enough projects, you're going to have
enough bad actors, people who don't read error messages, and just
downright crazy people. Throw in people using AI for dubious purposes
like CVE inflation, and it's even worse.
throwaway81523 wrote 3 hours 30 min ago:
The trouble here is that github issues is crap. 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. Github issues is mostly a discussion system
that was so inadequate that they supplemented it with another
discussion system.
christophilus wrote 1 min ago:
I take the Basecamp philosophy of, âIf itâs important enough,
we wonât be able to ignore it, and itâs ok for anything else to
fall through the cracks until someone feels like working on it.â
Well, thatâs a paraphrase, but I remember reading that rough idea
on their blog years ago, and it strikes me as perfectly fine for
many kinds of projects.
codeflo wrote 2 hours 31 min ago:
> 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?
asdfaoeu wrote 55 min ago:
This still puts the onus on the developers to categorise the
issues which I'm guessing they don't want to do.
philipallstar wrote 11 min ago:
That's always the case. Who else should triage?
dymk wrote 49 min ago:
How is that different from other bug tracking systems? The devs
have to triage submitted tickets there too
trinix912 wrote 2 hours 5 min ago:
IMO it still has poor discoverability, constant filtering between
the triage status flags and non-flagged stuff, stuff that might
not have been flagged by accident, reporters putting tags on
issues themselves, issues can only be closed by non-admins rather
than truly deleted, random people complaining about this or that
on unrelated tickets...
It all stems from the fact that all issues are in this one large
pool rather than there being a completely separate list with
already vetted stuff that nobody else can write into.
smallnix wrote 1 hour 35 min ago:
Sounds like it could be fixed by making it configurable to hide
all issues without a certain tag (or auto-apply a hiding tag)
for the issues "landing page".
ozim wrote 4 hours 27 min ago:
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 forward. If I can make a video
with Sora by typing what I want in the box, why would I need to click
around or type some arcane configuration for a tool?
I don't think in general it is bad - it is only bad for specialist
software where you cannot use that software without deeper
understanding, but the expectation is still there.
machomaster wrote 1 hour 47 min ago:
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).
twelvedogs wrote 46 min ago:
facebook literally obfuscates their UI to stop you turning off
"features" they want to push on you
it is a UI designed to be hard to use
philipallstar wrote 1 hour 28 min ago:
But still, compared to something like email, the previous
standard for most people, Facebook was an unbelievable step
forward. People complain about anything.
Hendrikto wrote 3 hours 15 min ago:
> If I can make a video with Sora by typing what I want in the box
IME, people cannot even articulate what they want when the know
what they want, let alone when they donât even understand what
they want in the first place.
cik wrote 6 hours 28 min ago:
You're 100% correct. I had a CVE reported to me in ~2022, shortly
after the ChatGPT launch. I spent 4 hours slicing and dicing the
issue, responding to how it was wrong, linking to background
information, specific lines in the code, and then asking for or what
am I missing. The response was literally "shrugs AI". Good for them.
stinkbeetle wrote 3 hours 23 min ago:
Yeah but the article / post linked does not say that they won't
look at reports of bugs or security problems, just that they are
using issues to manage things they have decided are issues that
should be worked on, and so public reporting using issues tickets
will mess up that system they have. It's purely about their
project's use of the issues system in github.
Unfortunately there is no such magic bullet for trawling through
bug reports from users, but pushing more work out to the reporter
can be reasonably effective at avoiding that kind of time wasting.
Require that the reporters communicate responsively, that they test
things promptly, that they provide reproducers and exact recipes
for reproduction. Ask that they run git bisect / creduce / debug
options / etc. Proactively close out bugs or mark them
appropriately if reporters don't do the work.
NewJazz wrote 7 hours 31 min ago:
Yeah but a good issue tracker should be able to help you filter that
stuff out. That ghostty finds discussions to be a better way to
triage user requests/issues is somewhat quirky, although a perfectly
valid option. As is just using issues, imo. Just good to make sure
users know how to report an issue, and what information to include.
mitchellh wrote 6 hours 47 min ago:
To be clear, I think discussions on the whole as a product are
pretty bad. I'm not happy having to use them, but given my
experience trying different approaches across multiple "popular"
projects on GH, this approach has so far been the least bad.
Although I'm still sad about it.
> Yeah but a good issue tracker should be able to help you filter
that stuff out.
Agreed. This highlights GitHub's issue management system being
inadequate.
(Note: I'm the creator/lead of Ghostty)
nutjob2 wrote 7 hours 42 min ago:
Don't forget the rude, entitled, and aggressive, they are legion.
It's simply a great idea. The mindset should be 'understand what's
happening', not 'this is the software's fault'.
The discussion area also serves as a convenient
explanation/exploration of the surrounding issues that is easy to
find. It reduces the maintainer's workload and should be the default.
lawgimenez wrote 9 hours 3 min ago:
How about using issue types?
HTML [1]: https://docs.github.com/en/issues/tracking-your-work-with-issu...
paxys wrote 9 hours 7 min ago:
So they are using Issues as a project board to track and manage ongoing
work items, but Projects is built for exactly that. May be better in
the long term to move project management to Projects and let people
file bugs with as little friction as possible.
rbbydotdev wrote 9 hours 13 min ago:
I wonder if just tagging and filtering automatically via a GitHub
setting which currently doesnât exist could serve the same purpose
cortesoft wrote 9 hours 15 min ago:
Is this fundamentally different than just using tags on issues to
separate ready to work on things from initial user submissions?
skywhopper wrote 2 hours 16 min ago:
Yes. Even for casual users looking for help, itâs nice to know that
the âissuesâ tab is just real issues and not random, duplicated
complaints and questions. Especially on a project like this that
attracts a lot of attention and is highly sensitive to the userâs
very specific environment. Most issues are going to not be bugs, or
even something the maintainers can work on directly. Instead of
trying to cram everything into Issues, why not use the underutilized
Discussions tool? Now the Issues list is much more useful as an
active tracker of workable items, and as a historical reference of
relatively deduped problems.
sleekest wrote 6 hours 23 min ago:
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.
g947o wrote 40 min ago:
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.
jonahx wrote 8 hours 16 min ago:
I feel like "technically, no" but "practically, yes".
Somehow the distinction of just adding a tag / using filters doesn't
communicate the cultural/process distinction in the same way.
eviks wrote 9 hours 20 min ago:
> This pattern makes it easier for maintainers or contributors to find
issues to work on since every issue is ready to be worked on.
How is this not trivially solved via a "ready-to-be-worked-on" tag?
onion2k wrote 5 hours 34 min ago:
An non-issue raised as an issue can never be closed, because the
person who reported it will just open another one saying "Why did you
close my issue without fixing it?" If that user is also raising
valid, useful issues then you don't want to just ban them.
Consequently your issues list will become unmanageable.
Kwpolska wrote 5 hours 7 min ago:
Reporting valid issues does not grant you the right to abuse the
issue tracker.
onion2k wrote 4 hours 55 min ago:
I'm not saying it does. I'm saying that banning a user who is
making a mistake in one area means you lose the value they
provide in another (which might be valid issues, but equally it
might be 90% of your revenue or something), so it's not always an
obvious decision to just wield the ban hammer every time. Moving
discussion of issues before they're created to a separate place
helps keep the issue tracker focused on issues that are likely to
be addressed.
An additional benefit of that is that a user whose discussion
leads to a real issue being created will feel like they're
genuinely being listened to. That creates a good customer
experience, which is good for your brand's reputation. It's a
positive experience. Closing non-issues in the tracker is a
negative experience.
mitchellh wrote 6 hours 50 min ago:
Because I don't want my default view to be "triage." If GitHub
allowed default issue views (and reflected that in the issue count in
the tabs as well), then maybe. But currently, it doesn't work. I've
tried it at large project scale across many (multiple projects with
more than 20K stars and millions of downloads).
Compared to that, this system has been a huge success. It has its own
problems, but it's directionally better.
em-bee wrote 7 hours 20 min ago:
that solution is not trivial because it requires permission for
anyone to comment on issues, which invites irrelevant or unhelpful
comments or even complaints. the separation allows issues to be
limited to developers only, those who actually work to fix the
issues.
technically, messages are messages. this approach no more than
grouping messages into different forums. it could also all be under
discussion with a sub forum for issues, one for features, one for
other topics, etc, and then there would need to be a permission
system for each sub forum.
so all this does is to create two spheres of access for users and
developers. and that's the point.
in the end it's really a matter of taste and preference.
eviks wrote 7 hours 13 min ago:
That's not true, you can limit comments to collaborators if you
don't like them. Although note that it's something you've made up,
comments are not part of the original list of reasons. Moreover,
comments aren't limited in the actual issues, so nothing prevents
unhelpful comments, leaving your issue unresolved
em-bee wrote 7 hours 5 min ago:
well that's exactly what they did, limit comments to
collaborators. anyone else can comment in the discussion forum.
eviks wrote 7 hours 2 min ago:
Well, that's not what they did, did you not read the last
sentence of my previous comment (or checked for yourself)?
8n4vidtmkvmk wrote 7 hours 34 min ago:
For one, it might require several rounds of back and forth before its
ready to receive the tag, but now the details are spread across
several comments instead of neatly at the top
lrem wrote 3 hours 6 min ago:
Don't worry, I'm willing to bet that there's an AI integration in
the works for this...
Too wrote 5 hours 16 min ago:
GitHub desperately needs a feature to pin comments in issues or
sort by reactions.
Very often in those infamous bugs that has been open for years,
having hundreds of âme tooâ comments, there are gems with
workarounds or reproductions, unfortunately hidden somewhere under
4 iterations of âclick to load 8 more commentsâ, making it
difficult to find. This generates even more âanyone know how to
solve thisâ spam, further contributing to the difficulty to find
the good post.
eviks wrote 7 hours 26 min ago:
No, you can always summarize details neatly at the top, you can
edit comments, you know?
NewJazz wrote 7 hours 9 min ago:
Yes but the person who is qualified to summarize might not be the
person who initiated a discussion.
eviks wrote 6 hours 59 min ago:
No again, the person qualified can edit the initial comment.
NewJazz wrote 6 hours 53 min ago:
Hmm didn't realize that repo owners could edit other folks'
comments
voxl wrote 8 hours 9 min ago:
How is it not trivially solved by a discussion section? Why is your
solution better for someone else's work flow? Why do you feel like
you get to impose your way of doing work on an open source project?
eviks wrote 7 hours 59 min ago:
Why do you feel like it's ok to make up nonsense about imposing?
How can I impose anything on that project? Why break the
expected/established workflow of users if the explanation doesn't
work? Why are you asking 3 questions without answering 1?
orangeisthe wrote 6 hours 0 min ago:
> Why break the expected/established workflow of users
Is it really that hard to open a discussion?
em-bee wrote 7 hours 15 min ago:
each project has its own workflow. no established workflow is
broken. github traditionally imposed a different workflow because
initially it didn't even have discussions.
1123581321 wrote 9 hours 26 min ago:
I agree with the general philosophy about user submissions. Browsing
closed discussions looks a lot like browsing closed issues. So I'm not
sure that the policy is successfully turning bug reports into
discussions. But it's at least keeping Issues free from noise for
contributors. Github could do more to nudge users into approaching
Discussions differently.
HTML [1]: https://github.com/ghostty-org/ghostty/discussions?discussions...
nine_k wrote 9 hours 18 min ago:
The point is the opposite, AFAICT. Any user complaint starts as a
discussion. If an actionable bug report results from it, it goes to
the tracker, which serves as list of problems to work on. A lot of
discussions do not end this way, even though they may solve a user's
issue anyway, e.g. by providing advice and reference.
Definitely discussing things could also happen in the issue tracker,
and some tag could be used to mark issues that are ready to work
upon. But I suspect that Discussions are better suited for, well,
discussions, while the facilities of the issue tracker can then be
used by maintainers / contributors.
I find this separation pretty smart.
drob518 wrote 8 hours 57 min ago:
Agreed. IMO, it makes sense to have a way to triage possible
issues, confirm that they are, in fact, legitimate, and then create
issue records to reflect them. As long as users have a way to
report anomalous behavior, then, as you say, itâs really no
different than using tags on issues. Po-tay-to, po-tah-to.
literatepeople wrote 9 hours 27 min ago:
Seems great to me. Perhaps GitHub should look into incorporating this
into the UX somehow? So many projects are issues linking to other
issues, I would love to see other projects adopt this to make github
task tracking more usable.
g947o wrote 43 min ago:
Why would GitHub do that just because one project thinks is a good
idea, especially when there is absolutely no concrete evidence that
this is any more effective or efficient than using issues? All that
we have is project maintainers' own beliefs. Bear in mind that these
things can be studied and measured quantitatively.
The current "issues" system works fine for most small-medium projects
and even many large projects. Any project who looks for a more
"serious" solution would have its own Jira/bug tracker system, and
you can find plenty of them.
Maxious wrote 9 hours 36 min ago:
For example, memory leak investigation is currently spread across
discussions, x/twitter and discord [1] [2] [3] [4] but has not
graduated to issue worthy status
HTML [1]: https://x.com/mitchellh/status/2004938171038277708
HTML [2]: https://x.com/alxfazio/status/2004841392645050601
HTML [3]: https://github.com/ghostty-org/ghostty/discussions/10114
HTML [4]: https://github.com/ghostty-org/ghostty/discussions/9962
eapotapov wrote 4 hours 48 min ago:
For those who have the issue.
I reported the issue in discussions some time ago, but had no
reaction/response.
I was able to reproduce the leak consistently. Finally I've got all
the reports done by me, Ghostty sources and Claude Code and tried to
fix it.
For the first couple of weeks there were no leaks at all, now it
started again but only 1/10 of the times it was before. [1] There are
some logs and a Claude Code review md file that might be useful.
Hope it will help someone investigate further.
HTML [1]: https://github.com/ghostty-org/ghostty/discussions/9786
hitekker wrote 9 hours 11 min ago:
The author says in the first link he only heard it reported twice,
which I'm guessing is the latter two links (the two discussions)
Your second link looks like an X user trying to start a flamewar; the
rest of the replies are hidden to me.
quantummagic wrote 9 hours 26 min ago:
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.
mitchellh wrote 7 hours 3 min ago:
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. The report at hand seems to affect a very limited number of
users (given the lack of reports and information about them). There
are lots of X meme posts about Ghostty in the macOS "Force Close"
window using a massive amount of RAM but that isn't directly useful
because that window also reports all the RAM _child processes_ are
using (e.g. if you run a command in your shell that consumes 100 GB
of RAM, macOS reports it as Ghostty using 100 GB of RAM). And the
window by itself also doesn't tell us what you were doing in
Ghostty. It farms good engagement, though.
2. We've run Ghostty on Linux under Valgrind in a variety of
configurations (the full GUI), we run all of Ghostty's unit tests
under Valgrind in CI for every commit, and we've run Ghostty on
macOS with the Xcode Instruments leak checker in a variety of
configurations and we haven't yet been able to find any leaks. Both
of these run fully clean. So, the "easy" tools can't find it.
3. Following point 1 and 2, no maintainer familiar with the
codebase has ever seen leaky behavior. Some of us run a build of
Ghostty, working full time in a terminal, for weeks, and memory is
stable.
4. Our Discord has ~30K users, and within it, we only have one
active user who periodically gets a large memory issue. They
haven't been able to narrow this down to any specific reproduction
and they aren't familiar enough with the codebase to debug it
themselves, unfortunately. They're trying!
To be clear, I 100% believe that there is some kind of leak
affecting some specific configuration of users. That's why the
discussion is open and we're soliciting input. I even spent about
an hour today on the latest feedback (posted earlier today) trying
to use that information to narrow it down. No dice, yet.
If anyone has more info, we'd love to find this. :)
sesm wrote 9 min ago:
Regarding point 4: why the user should be familiar with the
codebase to investigate it? Shouldn't they create a memory dump
and send it to dev team?
skobes wrote 58 min ago:
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 bugs, in my experience, start with some amount
of investigative work, and are actionable in the sense that some
concrete steps would further the investigation, but full
understanding is not achieved until very late in the game, around
the time I am prototyping a fix.
Similarly the line between bug and feature request is often
unclear. If the product breaks in specific configuration X, is it
a bug, or a request to add support for configuration X?
I find it easier to have a single place for issue discussion at
all stages of understanding or actionability, so that we don't
have to worry about distinctions like this that feel a bit
arbitrary.
xlii wrote 1 hour 26 min ago:
I have a one bit that might be useful that I learned from
debugging/optimizing Emacs.
macOS' Instruments tool only checks for leaks when it can track
allocations and it is limited to ~256 stack depth. For recursive
calls or very deep stacks (Emacs) some allocations aren't tracked
and only after setting malloc history flags [0] I started seeing
some results (and leaks).
Another place I'm investigating (for Emacs) is that AppKit
lifecycle doesn't actually align with Emacs lifecycle and so
leaks are happening on the AppKit and that has ZERO to do with
application. Seems that problem manifests mostly on a high end
specs (multiple HiDPI displays with high variable refresh rate,
powerful chip etc.)
Probably nothing you haven't investigated yet, but it is similar
to the ghost (pun intended) I've been looking for.
[0]:
HTML [1]: https://developer.apple.com/library/archive/documentatio...
ohyoutravel wrote 3 hours 39 min ago:
Iâve been a very happy user for 2025, with some edge cases
around the terminal not working on remote shells. I havenât
seen any memory leaks, but wanted to say I appreciate this
detailed response.
marksomnian wrote 3 hours 16 min ago:
In my experience, the remote shell weirdness is usually because
the remote shell doesnât recognise ghosttyâs
TERM=xterm-ghostty value. Fixed by either copying over a
terminfo with it in, or setting TERM=xterm-256color before
sshâing:
HTML [1]: https://ghostty.org/docs/help/terminfo
withinboredom wrote 5 hours 57 min ago:
Valgrind wonât show you leaks where you (or a GC) still holds a
reference. This could mean youâre holding on to large chunks of
memory that are still referenced in a closure or something. I
donât know what language or anything about your project, but if
youâre using a GC language, make sure you disable GC when
running with valgrind (a common mistake). Youâll see a ton of
false positives that the GC would normally clean up for you, but
some of those wonât be false positives.
Sesse__ wrote 3 hours 53 min ago:
It will, but they will be abbreviated (only total amount shown,
not the individual stack traces) unless you ask to show them in
full.
oblio wrote 4 hours 48 min ago:
Ghostty is written in Zig.
favflam wrote 8 hours 50 min ago:
btw, is it me or is there any justification for anyone including a
developer to run more than 8GB of RAM for a laptop? I don't see
functionality as having changed in the last 15 years.
For me, only Rust compilation necessitates more RAM. But, I assume
devs just do RAM heavy dev work on a server over ssh.
nkrisc wrote 1 hour 21 min ago:
You asked if there is a justification and then in the same post
justified why you need it.
samus wrote 2 hours 40 min ago:
Browsers can get quite bloated, especially if one is not in the
habit of closing tabs or restarting it from time to time. IDEs,
other development tools, and most Electron abominations are also
not shy about guzzling memory.
stackghost wrote 4 hours 24 min ago:
With 32 GB I can run two whole Electron applications! Discord
and Slack!
It's a life of luxury, I tell you.
afiori wrote 8 hours 18 min ago:
Browser + 2 vscode + 4 docker container + MS Teams + postman +
MongoDB Compass
Sure it is bloated, but it is the stack we have for local
development
pdpi wrote 8 hours 30 min ago:
There's all the usual "$APPLICATION is a memory hog" complaints,
for one.
In the SWE world, dev servers are a luxury that you don't get in
most companies, and most people use their laptops as
workstations. Depending on your workflow, you might well have a
bunch of VMs/containers running.
Even outside of SWE world, people have plenty of use for more
than 8GiB of RAM. Large Photoshop documents with loads of layers,
a DAW with a bazillion plugins and samples, anything involving 4k
video are all workloads that would struggle running on such a
small RAM allowance.
gizmo686 wrote 8 hours 16 min ago:
This depends on industry. Around here, working locally on
laptop is a luxury, and most devs are required to treat their
laptop like a thin client.
Of course, being developer laptops, they all come with 16 gigs
of RAM. In contrast, the remote VMs where we do all of the
actual work are limited to 4GiB unless we get manager and IT
approval for more.
user34283 wrote 4 hours 15 min ago:
Yes, zero latency typing in your local IDE on a laptop sounds
like the dream.
In enterprise, we get shared servers with constant connection
issues, performance problems, and full disks.
Alternatively we can use Windows VMs in Azure, with network
attached storage where "git log" can take a full minute. And
that's apparently the strategic solution.
Not to mention that in Azure 8 CPUs gets you four physical
cores of a previous gen server CPU. To anyone working with 4
CPUs or 2 physical cores: good luck.
sumanthvepa wrote 4 hours 25 min ago:
Interesting. I required all my devs to use local VMs for
development. We've saved a fair bit on cloud costs.
layer8 wrote 39 min ago:
For many companies, IP isnât allowed to leave
environments controlled by the company, which employee
laptops are not.
wongarsu wrote 52 min ago:
> We've saved a fair bit on cloud costs
our company just went with the "server in the basement"
approach, with every employee having a user account (no VM
or docker separation, just normal file permissions). Sure,
sounds like the 80s, but it works rearly well. Remote
access with wireguard, uptime similar or better than cloud,
sharing the same beefy CPUs works well and gives good
utilization. Running jobs that need hundreds of GB of RAM
isn't an issue as long as you respect other's needs too
dont hog the RAM all day. And in amortized costs per
employee its dirt cheap. I only wish we had more GPUs.
mr_toad wrote 1 hour 17 min ago:
> Interesting. I required all my devs to use local VMs for
development.
It doesnât work when youâre developing on a large
database, since it wonât fit. Database (and data
warehouse) development has been held back from modern
practices just for this reason.
happymellon wrote 3 hours 36 min ago:
Current job used to let us run containers locally, but they
decided to wrap initially docker, and then podman with
"helper" scripts. These broke regularly, and became too
much overhead to maintain so we are mandated to do local
dev but access a dev k8 cluster to perform any level of
testing that is more than unit and requires a db.
A really shame as running local docker/podman for postges
was fine when you just ran the commands.
cdogl wrote 2 hours 28 min ago:
I find this quite surprising! What benefit does your org
accrue by mandating that the db instance used for testing
is centralised? Where I am, the tests simply assume that
thereâs a database available on a certain port.
docker-compose.yml makes it easy to spin this up for
those so inclined. At that stage itâs immaterial
whether itâs running natively, or in docker, or
forwarded from somewhere else. Our tests stump up all the
data they need and tear down the db afterwards. In
contrast, I imagine that a dev k8s cluster requires some
management and would be a single point of failure.
tynorf wrote 8 hours 44 min ago:
Chrome on my work laptop sits around 20-30GB all day every day.
viraptor wrote 5 hours 15 min ago:
~10 projects in Cursor is 25GB on it's own.
gizmo686 wrote 8 hours 12 min ago:
How much would it take up if there was less RAM available. A
web browser with a bunch of tabs open but not active seems like
the type of system that can increase RAM usage by caching, and
decrease it by swapping (either logically at the application
level, or letting the OS actually swap)
typeofhuman wrote 8 hours 39 min ago:
I wonder if having less RAM would compel you to read, commit to
long term memory, and then close those 80 tabs you have open.
magicalhippo wrote 5 hours 36 min ago:
The issue for me is that bookmarks suck. They don't store the
state (where I was reading) and they reload the webpage so I
might get something else entirely when I come back. They also
kinda just disappear from sight.
If instead bookmarks worked like tab saving does, I would be
happy to get rid of a few hundred tabs. Have them save the
page and state like the tab saving mechanism does. Have some
way to remind me of them after a week or month or so.
Combine that with a search function that can search in
contents as well as the title, and I'm changing habbits ASAP.
bananadonkey wrote 4 hours 45 min ago:
Regarding wanting to preserve the current version of a
page: I use Karakeep to archive those pages. I am sure
there are other similar solutions such as downloading an
offline version, but this works well for me.
I do this mostly for blog posts etc I might not get around
to reading for weeks or months from now, and don't want
them to disappear in the meantime.
Everything else is either a pinned tab (<5) or a bookmark
(themselves shared when necessary on e.g a Slack canvas so
the whole team has easy access, not just me).
While browsing the rest of my tabs are transient and don't
really grow. I even mostly use private browsing for
research, and only bookmark (or otherwise save) pages I
deem to be of high quality. I might have a private window
with multiple tabs for a given task, but it is quickly
reduced to the minimum necessary pages and the the whole
private window is thrown away once the initial source
material gathering is done. This lets me turn off address
bar search engines and instead search only saved history
and bookmarks.
I often see colleagues with the same many browser windows
of many tabs each open struggling to find what they need,
and ponder their methods.
magicalhippo wrote 3 hours 34 min ago:
I've started using Karakeep as well, however I don't find
its built-in viewer as seamless as a plain browser page.
It's also runs afoul of pages which combats bots due to
its headless chrome.
Anyway, just strikes me as odd that the browsers have the
functionality right there, it's just not used to its full
potential.
pdpi wrote 8 hours 24 min ago:
If I'm doing work than involves three different libraries,
I'm not reading and committing to memory the whole
documentation for each of those libraries. I might well have
a few tabs with some of those libraries' source files too. I
can easily end up with tens of tabs open as a form of
breadcrumb trail for an issue I'm tracking down.
Then there's all the basic stuff â email and calendar are
tabs in my browser, not standalone applications. Ditto the
the ticket I'm working on.
I think the real issue is that browsers need to some
lightweight "sleep" mechanism that sits somewhere between a
live tab and just keeping the source in cache.
transcriptase wrote 8 hours 30 min ago:
I wonder if a good public flogging would compel chrome and
web devs to have 80 tabs take up far less than a gigabyte of
memory like they should in a world where optimization
wasnât wholesale abandoned under the assumption that
hardware improvements would compensate for their laziness and
incompetence.
m-schuetz wrote 51 min ago:
The high memory usage is due to the optimization.
Responsiveness, robustness and performance was improved by
making each tab independent processes. And that's good.
Nobody needs 80 tabs, that's what bookmarks are for.
abenga wrote 3 hours 13 min ago:
Is there a straightforward way to have one-process-per tab
in browsers without using significant amounts (O(n_tabs))
of memory?
samus wrote 2 hours 34 min ago:
There is no justification for that IMHO. The program text
only needs to be in memory once. However, each process
probably has its own instance of the JS engine, together
with the website's heap data and the JIT-compiled code
objects. That adds up.
abenga wrote 1 hour 52 min ago:
I'd very much like a crash in one tab not to kill other
tabs. And having per tab sandboxing would be more
secure, no?
refulgentis wrote 7 hours 51 min ago:
They do this stuff.
Iâm honestly amazed OP is managing 30 GB regularly. Iâd
wager itâs a tall tale. Itâs sort of perfect troll bait
on a forum because you end up with people sounding nuts,
defending web browser ram usage, against the common
position, that browsers are RAM hogs.
mi_lk wrote 9 hours 1 min ago:
Iâm sure they would appreciate a report as it doesnât seem that
it can be reproduced yet
keyle wrote 9 hours 56 min ago:
Issues simply don't scale. Using discussions as a filter is a good
idea.
If you spend more time closing issues than creating them manually from
discussions, the math adds up.
cookiengineer wrote 8 hours 59 min ago:
> If you spend more time closing issues than creating them manually
from discussions, the math adds up.
The math is even better if you just ignore all issues and close them
after two weeks for being stale!
Wish this was /s but it isn't.
keyle wrote 8 hours 33 min ago:
As long as it does not affect the metrics of your resume! /s
nh2 wrote 9 hours 5 min ago:
What is the actual difference?
As a maintainers, if you want to be be able to tell real issues from
non-issue discussions, you still gave to read them (triage). That's
what's taking time.
I don't see how transforming a discussion into an issue is less
effort than the other way around. Both are a click.
Github's issues and discussions seem the same feature to me (almost
identical UI with different naming).
The only potential benefit I can see is that discussions have a
top-level upvote count.
doctorpangloss wrote 8 hours 40 min ago:
> able to tell real issues from non-issue discussions
imo almost all issues are real, including "non-issue" - i think you
mean non-bug - "discussions." for example it is meaningful that
discussions show a potential documentation feature, and products
like "a terminal" are complete when their features are authored and
also fully documented or discoverable (so intuitive as to not
require documentation).
99% of the audience of github projects are other developers, not
non-programmer end users. it is almost always wrong to think of
issues as not real, every open source maintainer who gets hung up
on wanting a category of issues narrower than the ones needed to
make their product succeed winds up delegating their product
development to a team of professionals and loses control (for an
example that I know well: ComfyUI).
oofbey wrote 8 hours 58 min ago:
If discussions had a more modern UI with threads or something then
the difference might be real. But AFAICT itâs the same set of
functionality, so itâs effectively equivalent to a tag.
just-ok wrote 7 hours 34 min ago:
They sorta do: each comment on a discussion starts a thread you
can reply to, unlike on issues where you have to keep quoting
each other to track a topic if thereâs more than one. It still
sucks, especially since long threads are collapsed and thus
harder to ctrl-f or link a reply, but itâs something.
sammy2255 wrote 9 hours 14 min ago:
Why do you say that? Curl (arguably one of the most used open source
software in the world) currently has 5 open issues
HTML [1]: https://github.com/curl/curl/issues
mi_lk wrote 9 hours 4 min ago:
Not sure curl is a good example since itâs already very mature
and boring (in a good way)
xpe wrote 11 hours 33 min ago:
Personally, I dig it! Selected parts from linked page:
"""Unlike some other projects, Ghostty does not use the issue tracker
for discussion or feature requests. Instead, we use GitHub discussions
for that. Once a discussion reaches a point where a well-understood,
actionable item is identified, it is moved to the issue tracker. This
pattern makes it easier for maintainers or contributors to find issues
to work on since every issue is ready to be worked on.
This approach is based on years of experience maintaining open source
projects and observing that 80-90% of what users think are bugs are
either misunderstandings, environmental problems, or configuration
errors by the users themselves.[...]"""
kanzure wrote 9 hours 49 min ago:
I proposed something similar for bitcoin:
HTML [1]: https://gnusha.org/pi/bitcoindev/CABaSBax-meEsC2013zKYJnC3ph...
CharlieDigital wrote 10 hours 20 min ago:
Kind of an unstructured Basecamp ShapeUp where the "ask" has been
shaped already through requirements gathering and bets made.
DIR <- back to front page