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

291–300 of 320 posts

Re: Why users cannot create Issues directly

#291

Post by latexr »

johnfn wrote: post #250
Etheryte wrote: post #77

Earlier quoted context omitted.

[flagged]

This is like being forced to pay 50 bucks to your apartment because someone else broke the door. Then when you complain about it people tell you you’re entitled!

But it’s not your apartment (project/repo), it’s someone else’s. If it were yours, the rules wouldn’t apply.

You can clone the other person’s apartment for free and do whatever you like, though. Just don’t barge in to someone else’s apartment and demand they treat you, a stranger, like if it were yours.

Re: Why users cannot create Issues directly

#292

Post by touisteur »

pixl97 wrote: post #276
Sohcahtoa82 wrote: post #265

Earlier quoted context omitted.

There are people that when using a computer, if anything goes remotely wrong, they completely lose all notions of language comprehension. You can make messages as non-technical as possible and provide troubleshooting steps, and they just throw their hands up and say "I'm not a computer person! I don't know what it's telling me!" 20 years ago, I worked the self-checkout registers in retail. I'd have people scan an ite…

>completely lose all notions of language comprehension I see this pretty often. These aren't even what should be called typical users in theory. They are people doing a technical job and were hired with technical requirements, an application will spit out a well written error message in the domain they should be professionals in and their brain turns off. And ya, it ends up in a call to me where I state the same thin…

I think it's something to do with the expectations of automation. We seem to be wired or trained to trust the machines fully, and enter a state of helplessness when we think we are driven by a machine.

I've seen this with gnss-assisted driving, or with automated driving, or with aircraft autopilot. Something disengages, gives unwarranted trust, we lose context, training fades ; and when thrown back in control, the avalanche of context and responsibility is overwhelming, compounded by the lack of context about the previous intermediate steps.

One of the most worrying dangers of automation, is this trust (even by supposed knowledgeable technicians) and the transition out of the 'the machine is perfect' and when it hands you back the helm on a failure, an inability to trust the machine again.

The way to avoid entering this state, seems to stay deeply engaged in the inputs and decisions of the system (read 'automation should be like iron man, not like ultron') and have a deep understanding of the moving parts, critical design decisions of the system, and traces/visualization/checklist of the intermediate steps.

I don't know where the corpus of research about this is (probably in safety engineering research tomes), but it crystallized for me when comparing the crew reactions and behaviour of the Rio-Paris Air France crash, and the Quantas A380 accident in Singapour.

For the first one, amongst many, many other errors (be it crew management, taking account of the weather...) and problematic sensor behaviour, the transcript tells a harrowing story of a crew not trusting their aircraft anymore after recovering from a sensor failure (that failure ejecting them from autopilot and giving them back mostly full control), ignoring their training, and many of the actual alarms the aircraft was rightly giving, blaring at them.

In the second case, a crew that tries to piece out what capabilities they still have after a massive engine failure (explosion), wrecking most of the other systems with shrapnel. And keeping enough in the loop to decide when the overwhelmed system is giving wrong sensor instructions (transfering fuel from the unaffected reservoirs to actually destroyed, leaky ones).

Human factor studies are often fascinating.

Re: Why users cannot create Issues directly

#293

Post by favflam »

tynorf wrote: post #25
favflam wrote: post #24

Earlier quoted context omitted.

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.

Chrome on my work laptop sits around 20-30GB all day every day.

I do work off of a Chromebook with 8GB of RAM total, but I do keep an eye on how many tabs I have open.

Re: Why users cannot create Issues directly

#294

Post by favflam »

nkrisc wrote: post #142
favflam wrote: post #24

Earlier quoted context omitted.

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.

You asked if there is a justification and then in the same post justified why you need it.

My post was about laptop RAM. I counted server-side RAM as a separate thing.

Re: Why users cannot create Issues directly

#295

Post by xpe »

lawgimenez wrote: post #19

How about using issue types? https://docs.github.com/en/issues/tracking-your-work-with-is...

For those interested in social science research, there are many ways to explore this empirically. You could mix and match some of the following approaches:

1. Ask a high-quality LLM in research mode to gather empirical statistics on how different GitHub projects are setup.

2. Put human eyes on the data you find, look for patterns, see what is interesting. (I recommend reading on approaches that promote transparency about the order in which you collect data, form hypotheses, etc.)

3. Put on your anthropologist hat and do open-ended interviews with project maintainers.

And so on.

Re: Why users cannot create Issues directly

#296

Post by xpe »

paxys wrote: post #16

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.

Yet another great suggestion to consider! Thanks. Mind sharing some Github repos that use projects in this way?... that you think are good exemplars?

Re: Why users cannot create Issues directly

#297

Post by wpietri »

lokar wrote: post #227
wpietri wrote: post #182

Earlier quoted context omitted.

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

Some people see "bug tracker" and think "a vetted report of a problem that needs fixing", others see "bug tracker" and think "a task/todo list of stuff ready for an engineer to work on" Both are valid, and it makes sense to be clear about what the teams view is

Agreed. Honestly, I think of those as two very different needs that should have very different systems. To me a bug tracker is about collecting user reports of problems and finding commonalities. But most work should be driven by other information.

I think the confusion of bug tracking with work tracking comes out of the bad old days where we didn't write tests and we shipped large globs of changes all at once. In that world, people spent months putting bugs in, so it makes sense they'd need a database to track them all after the release. Bugs were the majority of the work.

But I think a team with good practices that ships early and often can spend a lot more time on adding value. In which case, jamming everything into a jumped-up bug tracker is the wrong approach.

Re: Why users cannot create Issues directly

#298

Post by yencabulator »

icepush wrote: post #287
Sohcahtoa82 wrote: post #232

Earlier quoted context omitted.

> people who don't read error messages One of my pet peeves that I will never understand. I do not expect users to understand what an error means, but I absolutely expect them to tell me what the error says . I try to understand things from the perspective of a non-technical user, but I cannot fathom why even a non-technical user would think that they don't need to include the contents of an error message when seekin…

Joel Spolsky solved this over 25 years ago https://www.joelonsoftware.com/2000/04/26/designing-for-peop...

That solves nothing, just describes the problem.

Re: Why users cannot create Issues directly

#299

Post by alexsmirnov »

traceroute66 wrote: post #248
Sohcahtoa82 wrote: post #232

Earlier quoted context omitted.

> people who don't read error messages One of my pet peeves that I will never understand. I do not expect users to understand what an error means, but I absolutely expect them to tell me what the error says . I try to understand things from the perspective of a non-technical user, but I cannot fathom why even a non-technical user would think that they don't need to include the contents of an error message when seekin…

> I do not expect users to understand what an error means I'm not sure I agree. Reason ? The old adage "handle errors gracefully". The "gracefully" part, by definition means taking into account the UX. Ergo "gracefully" does not mean spitting out either (a) a meaningless generic message or (b) A bunch of incomprehensible tech-speak. Your error should provide (a) a user-friendly plain-English description and (b) an er…

This is not about understanding the message, but switching user mental activity. I go myself in the similar situations many times. One example: I tried to pay my bills in online bank application, but got into error. After several attempts, I did read message and it say "Header size exceed..." . It give me clue that app probably put too much history into cookies. Clear browser data, log in again, and all got works.

Even when error message was clearly understandable for my expertise, it took surprisingly long tome to switch from one mental activity - "Pay bills", to another - "Investigate technical problem". And you have to throw away all short memory to switch into another task. So all rumors about "stupid" users is direct consequence from how human mind works.

Post reply on HN