-
Notifications
You must be signed in to change notification settings - Fork 16
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
[RFC] Have different comments for each closing scenario #183
Comments
I don't see how the automatic message could contain the duplicated issue number. From my perspective duplicates are a bit more complex:
But a more mature product like the grid might have different usages |
For the duplicated issue, can we rephrase to:
The main reason is that the original issue may still be opened (not resolved). |
I get what you mean ... this is not about closing it with the label all the time. You can still do that, but when applying the label we are 100% sure this is a duplicate. We can still ask the author for confirmation that this is a duplicate of #[?] and depending on the answer we can add the label or just handle it as a separate issue. |
Love this proposal! It would be really nice to differentiate between "not planned" and "duplicate" for sure. How about a tag for (admittedly rare) spam posts? (e.g., mui/material-ui#42900) I see something like this every couple months and it would be nice to have an automated message that says something to the effect of "Thanks for your interest in contributing, but we do not feel that this is a meaningful change. Please feel free to contact our DevEx team at [email protected] if you need help finding an issue to work on to improve your chances of getting your PR merged next time." Not a huge need but something to consider. |
@mui/company objections of turning this into an issue to implement it? |
@michelengelen It's great that we are working on a normalization of this 👍. On the different cases:
Maybe? **This issue has been closed**.
+We believe the problem is solved.
If you have a similar problem but not exactly the same, please open a [new issue](https://github.com/mui/mui-x/issues/new/choose).
Is the idea to have this message automatically applied after we do? https://www.notion.so/mui-org/GitHub-issues-Product-backlog-c1d7072e0c2545b0beb43b115f6030f6?pvs=4#d138cdf4990c45dabd3cd7069deb3504
To add as a macro in https://www.notion.so/mui-org/Technical-Support-80c9c7e0af614af68c1abb7120f634c8?pvs=4#d0ea7801bb9c45d19f6f58e16af6501d?
Please no mention of Discord. If we add this label, it's because we believe it's a Q&A, it doesn't fit: https://mui.com/material-ui/getting-started/support/#discord. I personally see no issues with https://github.com/mui/material-ui/blob/9063a9d507d6947e2e4a096c81f356d17b1379f2/.github/workflows/support-stackoverflow.yml#L25-L33. It seems great.
As far as I know, it's not possible to open an issue once closed by a maintainer. Instead, I would see: This issue has been inactive for 7 days and has been automatically closed.
-Please reopen it if you need further assistance.
+If you have new information, you can leave a comment, it will automatically reopen this issue. It looks like this will work: https://github.com/MBilalShafi/no-response-add-label/blob/8336c12292902f27b931154c34ba4670cb9899a2/src/no-response.ts#L137. |
What's the problem?
The comment from @mnajdova got me thinking about streamlining our communication on closing issues due to the different reasons.
Today, we close issues with one of those cases:
In MUI X we do not do 4. since we have paid users and are kind of obliged to also answer these questions as the community won't. We should probably refer open-source users to Stack Overflow sometimes anyway.
Right now the only case where we do not add a closing message in MUI X is 5. A bit different from the material-ui repo: mui/material-ui#43450 (comment)
What are the requirements?
Proposed solution
We can use the
state_reason
field to close issues via a workflow. When manually closing you get the choice of "completed" or "not planned" which will also be written into that field, so we can easily determine this based on that field when using it in a workflow.Considering this we can improve our communication with a refined message for each case:
This issue has been closed. If you have a similar problem but not exactly the same, please open a new issue.
Now, if you have additional information related to this issue or things that could help future readers, feel free to leave a comment.
(appendix for authors outside of the org)
Note
We value your feedback @${issue.data.user.login}! How was your experience with our support team?
If you could spare a moment, we'd love to hear your thoughts in this brief Support Satisfaction survey. Your insights help us improve!
Thank you for reporting this issue. However, it seems that we've already addressed this in issue #[issue number]. Please feel free to add any additional details or questions to that thread.Thank you for reporting this issue. However, it seems to be about the same problem as described in issue #[issue number]. Please feel free to add any additional details or questions to that thread.
Thank you for your feedback. While we understand the value of this feature, it's not currently on our roadmap. We'll keep it in mind for future development.
Thanks for reaching out!
We primarily use GitHub issues to track bugs and feature requests. This appears to be an implementation question related to [product].
Here are some resources that might be helpful:
If your question evolves into a confirmed bug and follows our issue template, we can reopen this issue.
Happy coding!
This issue has been inactive for 7 days and has been automatically closed. Please reopen it if you need further assistance.
The text was updated successfully, but these errors were encountered: