-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
[docs-infra] Adjust the links to search for issues #11995
[docs-infra] Adjust the links to search for issues #11995
Conversation
Deploy preview: https://deploy-preview-11995--material-ui-x.netlify.app/ Updated pages: |
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.
To apply this MUI' wide 👍
I really wonder if we shouldn't create a new label for all of this type of work. Like a [devex-infra] label, or [support-infra], [product-infra]. For now, [core] is ok, but it's not [code-infra] or [docs-infra]. Otherwise, how about this: We introduce abroad [infra] level, it's like [core] but shared across repositories, and it's a catch-all until there is a clear pattern to specialize [code-infra] and [docs-infra] are specialization examples). https://www.notion.so/mui-org/scope-infra-c446897d1449403ea7ffe076ddedc00a |
On another note: we could probably add org templates instead, if we would be willing to give up the custom names. I was reading about this today and it might be a good way of reducing maintenance work! |
@michelengelen agree, we should explore this. The related issues: https://github.com/mui/mui-private/issues/386, https://github.com/mui/mui-private/issues/360. |
.github/ISSUE_TEMPLATE/1.bug.yml
Outdated
@@ -9,7 +9,7 @@ body: | |||
attributes: | |||
label: Search keywords | |||
description: | | |||
Your issue may have already been reported! First search for duplicates among the [existing issues](https://github.com/mui/mui-x/issues). | |||
Your issue may have already been reported! First search for duplicates among the [existing issues](https://github.com/mui/mui-x/issues?q=is%3Aopen+is%3Aclosed). |
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.
I think that we are missing the extra is:issue
argument in all of these instances.
By going to /issues
both is:issue
and is:open
filters are applied.
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 bit of a generalistic question.
- PRs on github are also issues and
is:issue
would exclude them: Do we want to include PRs in this search or not? 🤷🏼 is:open
will not show any closed issues, but since the issue might be already asked/solved we absolutely want to have them in this list.
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.
But PRs generally target resolving an issue.
I'm not sure we should be polluting the list of searchable entries by including PRs. 🤷
I just raised the point, that this technically causes a "regression" as compared to the existing approach.
If we actually want to include PRs as well, then sure, all is good, but I didn't see anything mentioned about this in the description, hence the flagging. 😉
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.
I have no strong opinion on incuding PRs or not ... Most of the time the search should be accompanied by a search term to limit the results anyways, so the PRs might not be as prominent.
On the other hand you are right about the purpose of PRs in general. There might be additional information in them that could sometimes lead the user to a solution they are looking for, but there are too many ifs and buts in this.
I will add the is:issue
parameter
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.
Or rather: I will change this to https://github.com/mui/mui-x/issues?q=is%3Aissue
This will naturally include all issue states! 👍🏼
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.
Nice, that seems to be the most correct. 👍
I double-checked, that adding both is:open
and is:closed
filters seems to work incorrectly. 🙈
The only way to achieve identical results is by applying the following filter:
is:issue is:open|is:closed
I noticed that the link in the issues templates leads to the default issue search, which looks for
is:issue
andis:open
. Since the solution could also be in a closed issue this should be adjusted.One question remains: should we mention in the text that there could also be a closed issue with a solution as well? 🤔