Improve interface to report errors

[ccordoba12]

It seems browsers only accept a limited number of characters in the status bar, and so there are several issues reported by our users that end up being incomplete.

So, instead of that, we should use the Github API to create new issues:

https://developer.github.com/v3/issues/#create-an-issue

@rlaverde, please take care of this one.

[goanpeca]

@ccordoba12 this is a bad, idea. We will flood by repetitive issues, something similar happened with Navigator. We need to provide the user with the error to report, but the act of reporting should come form the user.

[rlaverde]

his is a bad, idea. We will flood by repetitive issues, something similar happened with Navigator

Maybe we could search the issue tracker, before creating a new issue, although I'll be difficult to implement

[goanpeca]

Maybe we could search the issue tracker, before creating a new issue, although I'll be difficult to implement

Bad idea, please don't do this, I tried and I had to disable it.

[ccordoba12]

We're still flood with repetitive issues, but some don't have the full error. So I don't understand what you mean.

Our current mechanism simply is not working as expected, so we need a better approach. What do you suggest then?

[goanpeca]

We're still flood with repetitive issues, but some don't have the full error. So I don't understand what you mean.

Although it sounded like a good idea, having a dialog with a report button for every error that happens is a bad idea. Github is not meant to be used like that, that kind of usage is for an online logging system. So by giving the report button we are really putting ourselves into trouble cause we will get repetitive errors and we will end up doing a bot that automatically closes issues (like I had to do)

Our current mechanism simply is not working as expected, so we need a better approach. What do you suggest then?

Remove the report button. Give a message saying `you can report this error (maybe add a copy error button) in this address (a label with the spyder-ide repo) and also a message saying check if the error has not been reported. By doing this we are putting a bigger barrier so users dont simply make two clicks, but they have to type a URL and do more "manual work", paste an error etc. Only users that use github will be inclined to do so. We should not encourage every spyder user in the world to register on github for every meaningless problem/error they have, if the are not already github users.

[rlaverde]

Although it sounded like a good idea, having a dialog with a report button for every error that happens is a bad idea. Github is not meant to be used like that, that kind of usage is for an online logging system

Maybe we could use a report tool, like sentry, https://sentry.io and manually extract issues and submit them to github. (I don't know how much issues we could expect, and how much we could pay for it https://sentry.io/pricing/)

Also It allows to attach some context information (dependencies installed, the user config...)

Configuring it will add a new dependency to the project, https://github.com/getsentry/raven-python

[ccordoba12]

I still think the dialog is useful, and we haven't received so many errors to cancel it yet.

What we can do (besides using the Github API) is to force people to give a proper description of problem before submitting the error. In other words, that they fill the part about describing the circumstances which generated the problem they are seeing. Almost nobody does that, and that's critical information!

[rlaverde]

to force people to give a proper description of problem before submitting the error

How we can do that?

[ccordoba12]

By opening a new dialog with an instance of CodeEditor, so that people can fill the description of the bug. Then we'd verify that description contains a minimal amount of text (e.g. 100 characters) before activating the Submit button in the dialog.

[rlaverde]

By opening a new dialog with an instance of CodeEditor, so that people can fill the description of the bug.

That will make the url even longer

[ccordoba12]

That's why we need to use the Github API, to send a complete bug report using an HTML request to its server.

[rlaverde]

but we also will need to authenticate users: request login password, or token when they'reuseng 2-factor autentification

[ccordoba12]

What if we use our spyder-bot for this?

https://github.com/orgs/spyder-ide/people/spyder-bot

[rlaverde]

What if we use our spyder-bot for this?

That will be to give access to that account to everybody, even if we restrict the permissions doesn't look like a good solution. Somebody could flood the issue tracker and we won't have a solution for that (banning the bot, or changing the token, and that will break the automated report bug)

[rlaverde]

I think the the problem is only with IE explorer users (another reason for hate it 🙈 ), internet explorer doesn't support urls longer that 2k characters https://stackoverflow.com/a/417184/1335555

Maybe we could try to ensure that the url is shorter than 2k characters, and if its longer advice deactivate the report button, and instead tell users to copy and paste. Although I doesn't like this solution, It'll bother all users (We don't have a way to know which is the default web browser), and almost every report is longer than 2000 characters, so it's practically the same as deactivating the button

I insist in using a report service, github isn't designed for end users, neither for automated reporting

[goanpeca]

@ccordoba12 and @rlaverde you are missing the point. Navigator did a similar thing and has a deluge of issues that I have to close with a bot, because its always the same issue that gets reported. We should not use github if we want to pursue the automation. @rlaverde Sentry is not a good option either because it is not really a logging system. We should not automatically do anything using the github api, because we cannot reliable have safe usarge rates plus we would need to add a token to spyder, even if only issue access it a s huge security problem.

We either make it less easy to report a problem where users need to do manual work (and even then if we have too many users this will blow up on us), or we use a system meant for logging errors, logly,, sumo logic etc....

[ccordoba12]

Github is a good place to have this (instead of an automated system) because we usually need to ask for further information. Without users context, what we receive is usually useless.

@rlaverde, now that you've discovered that the issue comes from IE, let's use the webbrowser module to send the URL to Chrome first, then to Firefox (if Chrome is not installed) and finally raise a further message saying that any other browser is not supported. All of this, only for Windows (other OSes seem fine).

@goanpeca, I've seen the Navigator debacle but we activated our dialog almost at the same time and have not received as many issues as Navigator.

[goanpeca]

Github is a good place to have this (instead of an automated system) because we usually need to ask for further information. Without users context, what we receive is usually useless.

We can ask for that information when sending the report to another place, and most of the system info can be queried automatically.

@goanpeca, I've seen the Navigator debacle but we activated our dialog almost at the same time and have not received as many issues as Navigator.

That is only a matter of usage, Navigator has way more users than Spyder, so it is just a matter of time before we run into the same issues.

[rlaverde]

now that you've discovered that the issue comes from IE, let's use the webbrowser module to send the URL to Chrome first, then to Firefox (if Chrome is not installed)

I tried but webbrowser doesn't work with windows virtual machine, neither webbrowser.get('firefox'), or webbrowser.get('chrome') works (I tried the different names in https://docs.python.org/3.6/library/webbrowser.html but they didn't work)

I could write a PR with that change but I'll need help testing that change works as excepted

[rlaverde]

I agree with @goanpeca, if we are going to automatize the issue reporting, you should query more information, we are not only getting duplicated issue but also issue with scarce information (that we could not reproduce).

I think we could query things like: last focused plugin, plugins activated, layout, number of files open, and with user permission other things like: history of the console, project tree, even screenshots

Although I don't know if it's the right think to do, automated issue reports are adding a maintenance burden.

[goanpeca]

Although I don't know if it's the right think to do, automated issue reports are adding a maintenance burden.

Precisely why another service needs to be used. Github is not meant to be used to report 10/100/1000 "identical" error reports, the idea is for people to use the issue tracker manually.

[ccordoba12]

Navigator has way more users than Spyder

Almost all repeated issues came from users trying to start Spyder with Navigator only in macOS ;-p

---

Look, we need a fix to our current problem right away. We can't keep discussing about something that we really don't know how to implement, and that it could take us a significant amount of time to do.

Right now, we need to avoid users to send the report through IE, and also avoid empty reports (i.e. without a description of the problem).

@rlaverde, please open a PR with a new dialog asking for a description of the problem. This dialog needs to be shown after users press the Submit button and it needs to contain a CodeEditor with the Markdown mode on. Finally, please verify that the dialog has at least 20 words or something before activating the Send button in that dialog.

Then, we can open a new PR with the IE issue.