-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move community support to email #5651
Move community support to email #5651
Conversation
With the aim of keeping the issue tracker related to code issues, and have a more control over specific request. We are moving admin-only actionable request to email.
There is also our build error warning that automatically opens an issue on GitHub. Do you think we want to change that as well? |
@agjohnson I don't think that's convenient for the users or us. Why? If keeps the knowledge of how to fix x public or current problems. Also, we will have emails of the same error, when maybe there is an issue where users can search for the solution. Or when we break the builders, we will get a lot of emails, in an issue a user can just report the problem in the same thread. |
I'm talking about the generic failure case, which should only be for unknown errors that are raised in the build process. It's almost always going to be a support request that involves us looking up information and the user can't really self remedy these errors. For example, the error that lists the build id and we have to go into Sentry to fish out the actual cause. |
Personally I think that half of those generic errors are because something is wrong from our side (like #5653 (comment)), and those should go in the issue tracker. We have some other issues related to memory consumption that can lead to the same problem (the other half). |
They should end up as proper issues if there is something we want to fix, yeah. But that doesn't necessarily mean that the support request needs to be an issue itself -- the issue you linked would be hard for anyone else to find or get value out of, and it effectively separates that request from the rest of our support requests. Generic support suggestions like this could go to our support queue, and from there we decide if they are an issue we should be working on improving (open a linked github issue), or if they are not worth our time to develop a fix for (resolve and close the support request). |
I feel like we are going to get flooded if we link from a general failure to email. Most of them are problems in our side, like not catching the appropriate error or raising a different error. We could just test how it goes with the current support and then link from general failures to email. |
I agree with Anthony on this: pointing the generic error to the issue tracker gives nothing useful to the next person with "the same problem". Those issues are usually on our side and they need to check sentry, logs, etc to debug a little --the user can take no action on these ones. Then, if it's something that needs to be fixed, we (the Core Team) can open an issue here. I'd change that link to become a Besides, I think we can modify the GitHub issue template mentioning that support requests are managed by email. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a good change. We can address the other additions later, but let's ship this since it's done 👍
With the aim of keeping the issue tracker related to code issues,
and have a more control over specific request.
We are moving admin-only actionable request to email.
I found these places only, not sure if anything else is missing or if we are pointing to the correct email :)