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

121–130 of 320 posts

Re: Why users cannot create Issues directly

#121

Post by ncruces »

Mawr wrote: post #99
Etheryte wrote: post #77

Earlier quoted context omitted.

[flagged]

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.

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.

Re: Why users cannot create Issues directly

#122

Post by samus »

abenga wrote: post #110
transcriptase wrote: post #31

Earlier quoted context omitted.

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.

Is there a straightforward way to have one-process-per tab in browsers without using significant amounts (O(n_tabs)) of memory?

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.

Re: Why users cannot create Issues directly

#124

Post by codeflo »

throwaway81523 wrote: post #104
ok123456 wrote: post #29

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.

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.

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

Re: Why users cannot create Issues directly

#125

Post by euroderf »

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.

Re: Why users cannot create Issues directly

#126

Post by cdogl »

happymellon wrote: post #101
sumanthvepa wrote: post #88

Earlier quoted context omitted.

Interesting. I required all my devs to use local VMs for development. We've saved a fair bit on cloud costs.

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

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.

Re: Why users cannot create Issues directly

#127

Post by skywhopper »

cortesoft wrote: post #12

Is this fundamentally different than just using tags on issues to separate ready to work on things from initial user submissions?

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.

Re: Why users cannot create Issues directly

#128

Post by skywhopper »

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.

[flagged]

Re: Why users cannot create Issues directly

#129

Post by skywhopper »

Mawr wrote: post #99
Etheryte wrote: post #77

Earlier quoted context omitted.

[flagged]

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.

How is “submit your issue to this nearly identical discussion tool in the same web app” a burden?

Re: Why users cannot create Issues directly

#130

Post by ChrisMarshallNY »

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.

Post reply on HN