Hacker News Reader

Comment by jtvjan | Hacker News Reader

I've recently tried Jami to chat with a friend using the new(?) Qt client, and it wasn't a very good experience. Scrolling feels terrible. When I scroll up, it keeps going for a moment even though I let go of the scroll wheel. When I scroll down, the view jumps around as images load in.

After we filled up the chat a bit, opening it again takes about six seconds. And sometimes, it starts using 60% CPU doing apparently nothing.

There is a "reply to message" function, but it's useless on images because it only shows the first part of the path to the image (you just see "/home/me/.local/share/jami/8fd7...") and clicking it doesn't bring you to the message in question.

I also tried the Android client, which was usable enough, but it could only receive messages if I had the desktop client too. But that might be because of my NAT.

View on HN

Thanks a lot for the feedback, and sorry about the issues. Would you please report them on the Jami bug trackers per https://docs.jami.net/user/bug-report-guide.html if not already? This would help the team keep track, look further into them, and hopefully fix them.

This isn’t really a helpful response. It’s the project owner’s responsibility to maintain the project, not their users.

While it’s certainly nice if the user does this and removes burden from you, it’s a better practice (and engenders more good will from your users) to just ingest this into the bug tracker on the user’s behalf (and dedupe as needed / do a search and give them the link to existing bugs if it describes their issue).

Yes, the creators should be testing their app. But making bug reports is also a fundamental useful thing. Should I not report bugs in mac os or chrome or python3 because the project owner should have figured it out? No.

He's saying, and I agree, that a casual first time user making a low friction complaint somewhere like here should simply be digested immediately by a team member and ammended onto a perviously created bug in their system. Or a new bug should be created by a team member.

I do this at my job all the time because our Jira setup is fucking balls and I have all kinds of greesemonkey to make it usable and quick for me. Any casual user is going to bounce the fuck off our jira setup. Secondly I know if there is already a bug in our system covering this issue or not, less time for my team to do de-duping etc.

Yup. About the only two complaints that might reasonably warrant asking the user to create a ticket themselves is the NAT one and the CPU spike doing nothing. For both of those though, rather than having the user create a bug report just to go back and forth over it asynchronously over months until the end user gets discouraged and drops it, a better situation works be diagnostic tools that could monitor and collect data that the devs could then analyze, ideally baked into the code where you just click a button to submit feedback and your code can code to open a bug report or just ingest metrics or something.

Reporting bugs is more then leaving 1 short sentence on random place.

Reply on news.ycombinator.com