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

151–160 of 320 posts

Re: Why users cannot create Issues directly

#151

Post by m-schuetz »

transcriptase wrote: post #31
typeofhuman wrote: post #27

Earlier quoted context omitted.

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.

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.

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.

Re: Why users cannot create Issues directly

#152

Post by dymk »

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.

How is that different from other bug tracking systems? The devs have to triage submitted tickets there too

Re: Why users cannot create Issues directly

#153

Post by twelvedogs »

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).

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

Re: Why users cannot create Issues directly

#154

Post by g947o »

literatepeople wrote: post #7

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.

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.

Re: Why users cannot create Issues directly

#155

Post by konhi »

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.

Re: Why users cannot create Issues directly

#156

Post by g947o »

sleekest wrote: post #68
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?

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.

Re: Why users cannot create Issues directly

#157

Post by layer8 »

sumanthvepa wrote: post #88
gizmo686 wrote: post #35

Earlier quoted context omitted.

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.

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

For many companies, IP isn’t allowed to leave environments controlled by the company, which employee laptops are not.

Re: Why users cannot create Issues directly

#158

Post by botanical76 »

arccy wrote: post #144
WhyNotHugo wrote: post #132

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

behold the best way to search github issues. Using Google or whatever decent search engine: site:https://github.com/org/repo key words

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.

Re: Why users cannot create Issues directly

#159

Post by layer8 »

spinningarrow wrote: post #133
WhyNotHugo wrote: post #132

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

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)

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.
Post reply on HN