Closed nvaccessAuto closed 2 years ago
nvaccessAuto
commented
10 years ago Comment 1 by zahari_bgr on 2014-03-28 00:09 The issue is that some people, including me, sometimes are lazy, sometimes we postpone the report and then forget about it, etc. So I think that Reporting a bug with a few clicks will greatly increase and improve the user feedback. Also, many users don't know where and how to report bugs.
nvaccessAuto
commented
10 years ago Comment 3 by nvdakor on 2014-03-28 00:41 Hi, A few concerns:
bhavyashah
commented
7 years ago In terms of trying to ensure quality of the report, we already have a fairly comprehensive set of standard questions present in the Github template for filing new tickets. Apart from that, this seems like an great proposal to bridge the gap between users and developers even further. One concern that remains is users accidentally or deliberately spamming this channel of reporting issues. To regulate this, I suggest having a mechanism where NV Access (and potentially a few credible contributors) would first approve the sent report before it gets listed as a new issue on our tracker.
LeonarddeR
commented
7 years ago Also note that the current platform used (Github) is much more mainstream than the old Trac system.
Brian1Gaff
commented
7 years ago You may well believe this, but from what I observe in the main user list there is confusion. the unfortunate part of Github is that its everything to everyone and even I find myself lost in its many options which are really aimed at developers not users. The idea of being able to report errors with a bundled log seems good for major issues that crash nvda, but I'd also like to offer people an uncluttered online interface that front ends github with just the important links, much as Trac had.
LeonarddeR
commented
7 years ago @Brian1Gaff commented on 28 aug. 2017 11:37 CEST:
You may well believe this, but from what I observe in the main user list there is confusion.
I think there's nothing wrong with users reporting their problems on the users list, as long as someone feels responsible for filing them on github. @Qchristensen, thoughts?
Qchristensen
commented
7 years ago Things which cause NVDA itself to crash are certainly very important for us to find out. In the context of users wanting to report things however, they are relatively rare compared to "feature XYZ in Program ABC isn't working or causes a problem in Program ABC". A way of reporting a problem (or requesting a feature) directly from NVDA is arguably useful.
I think we'd need to be careful with a system which automatically created GitHub issues from several points: Firstly, if there was something that caused a major problem, we want to know about it, but we don't want 1,000 issues suddenly popping up on GitHub all for the same thing. Secondly, we need a way of keeping contact open with the person reporting the issue so that when we get reports saying things like "not working in Chrome", we can follow up and find out exactly what isn't working. This would either require the user creating or logging into a GitHub account, or probably easier, automatically pasting the report into your default e-mail client to send to a specified address.
Re reporting issues on the Users list, often people do this either because they aren't familiar or comfortable with GitHub, or to try and get corroboration from others to help submit a useful issue in the first place. Speaking for myself, when I see something on the user list, I will often look and see if there is an open GitHub issue and if not, either suggest the user create one (or ask for help creating one) or if it's something I can readily replicate, I might just create it and note that when I reply.
I can see the potential in a reporting mechanism within NVDA itself, particular given that when people e-mail me with a problem, often the first thing I have to ask is either "What version of Windows, NVDA or the relevant program are you running?" or "Can you send me a log please?"
Adriani90
commented
5 years ago In my opinion we have lots of issues which actually are not really issues or at least not directly NVDA related. If people get such an easy way to report issues without having to elaborate on more detail about them, we will have thousants of issues on Github and will be overwelmed by that. I think, after getting more experience during last years in this community, the community works very well. People are active on users mail lists, twitter, facebook and other channels like github. There are so many ways to report issues, every country has its own mail lists and some countries even own support channels. I think this function would only overfill github and also NV Access with issues which actually could be solved very easily in the mail list or so. Don't forget that on Github there are many people commenting on issues. Not only NV Access. But if through such a function crash errors go directly to NV Access, this is also not a guarantee that you will get a quick response. The guys are really busy and that's user lists and github are such good channels for reporting issues. And additionally, being active on mail lists and other channels motivate people to learn more about this project. And all people feel good if they can help someone to solve an issue. As I can see, NV Access is very responsive on every channel as well. So why not using these channels?
Qchristensen
commented
5 years ago Ok I think there are two parts to this we can consider: 1) Is there a way to automate sending of crash report data, and perhaps limit the scope for now to NVDA crashes? My thought is to have this sent on next NVDA startup. We already have a setting for users to opt-in to sending usage statistics, and at least at first, my thought would be to honour this setting and automatically send crash data without needing further user input if the user already allows usage statistics to be gathered.
2) The other part is having a way to more easily allow users to submit more general feedback or issues - either by a link to GitHub or to the user e-mail list from within the help menu. There have been a couple of issues raised for that - particularly #8685 so I'd be happy to leave THIS issue open to look at the merits and feasibility of sending automatic crash data, and encourage further comments on submitting general feedback to #8685.
josephsl
commented
5 years ago CC @DerekRiemer, if you don’t mind commenting about Crash Hero. Thanks.
derekriemer
commented
5 years ago NVDA Developers and bug smashers! ATTENTION! This is an important announcement from the department of release stability management. Recently, a new member joined the NVDA community. Her name will remain anonymous, but you may refer to her as the crash hero. In fact, she is the first NVDA superhero. She exhibits her superpower in the form of an NVDA Add-on that can save all your crash dumps in a folder of your choosing on your computer and she does this automatically when NVDA reboots after a crash. She even asks you what you were doing before the crash, and logs it in a messages file. With her completely accurate perception of time and date, you will always know when crashes happened, because she names each crash as a timestamped folder inside your crashes directory. Let the crash hero save you from having to remember where to find the crash dump and keep track of what exactly you were doing before a crash occurred. Now that I’ve introduced the crash hero, on behalf of the crash hero, I would like to invite you to experience the thrill of never having to open your temp directory and frantically save the crash somewhere when a crash happens in the middle of a homework assignment or business meeting. The crash hero will save crashes in your user folder by default, but by selecting the crash settings item in your NVDA preferences menu, you can pick a custom folder to log all of your crashes in! The crash hero is here, and the crash hero is ready to help you if you are someone who regularly runs snapshots of NVDA so that you or other developers can catch bugs before they sting the general masses. Download: https://derekriemer.com/2017/02/06/crash-hero/
Note: can someone update the NVDA addons site with the proper blog post?
Adriani90
commented
5 years ago cc: @nvdaes
Adriani90
commented
5 years ago cc: @josephsl
josephsl
commented
5 years ago Hi, actually, I recommend copying Derek and Mick on this one.
----- Original Message ----- From: Adriani90 <notifications@github.com To: nvaccess/nvda <nvda@noreply.github.com Date sent: Sat, 04 May 2019 09:00:43 -0700 Subject: Re: [nvaccess/nvda] Simplified error reporting (#4033)
cc: @josephsl
-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/nvaccess/nvda/issues/4033#issuecomment-4893396 09
Adriani90
commented
5 years ago Hey, Derek is already on there. He posted a description for the crash hero two comments above which should be updated on the addons website but I don’t have rights for doing this and I also don’t know how to do it yet. I thought maybe you could do it. Thanks.
Adriani90
commented
4 years ago @josephsl could you update the description of Crash hero as proposed by Derek above?
josephsl
commented
4 years ago Hi, I think that’s really up to @DerekRiemer to do so. Thanks for reminding me about it.
bhavyashah
commented
2 years ago I second the narrower feature of enabling users to automatically report crashes. My sense is that crashes usually happen unexpectedly rather than in consistent, predictable patterns. This means that a user might not be in a position, in that moment, to save the crash dump or old log and file a GitHub ticket or post on the email list. Whether the cause is laziness (which is not an unreasonable cause), busyness (that the user is engaged in other, more pressing activity), or ignorance (many NVDA users neither have a GitHub account nor are on mailing lists), I think there are enough cases where crashes unfortunately don’t get reported. I think there is precedent in NVDA development that significantly prioritizes crashes over other bug reports and feature requests – please correct me if I am wrong. Therefore, crashes merit diagnosis and that is only possible if we know of them. P.S. The goal of this comment was to argue for the importance of this feature request. If NVDA is crashing for users without our knowledge, I think that is a big problem.
bhavyashah
commented
2 years ago I don’t think the crash reports should automatically generate GitHub tickets. Instead, I think they should directly go to NV Access who can review them, and in case they manage to independently replicate it, they can file a GitHub ticket for it themselves. Security: Even if we are transparent about it, I think users may have privacy concerns about public release of their NVDA log. This discomfort will likely be lesser if the session data is only going to a few trusted folks at NV Access. Other than how folks might feel, I think there are genuine risks of confidential information coming out in the public domain. Feasibility: There are roughly 35,000 NVDA users who have enabled sharing of usage statistics. Presumably, a comparable amount will have enabled crash reporting. Even if each user experiences one NVDA crash a year, this would still generate about a hundred crash reports each day. How NV Access will distribute resources to monitor even a randomly sampled subset of these crash reports – I don’t know. What is clear though is that hundreds of new tickets on GitHub daily would probably be unmanageable.
seanbudd
commented
2 years ago Closing in favour of the newer issue, with a clearer summary: #13703
Reported by zahari_bgr on 2014-03-28 00:05 I suggest more automatic error reporting, so more users could partisipate with reporting bugs. For example, when crash accour, there could be a dialog, which asks the user whether he/she wants to report the issue or not, and if yes, it could open another dialog, or a webpage, with automatically attached log and crash dump, where he/she could provide more details and submit the report. There could be also a menu entry for reporting a bug, may be in the Help submenu of NVDA menu. There could be an option for editing the log file before submitting - in case of user sensetive data. A set of standard questions about the issue can improve the quality of the reports.