You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
'Reporting abuse or spam' docs seem to be outdated/misleading, as many ways suggested don't seem possible #40496
Technically yes, this is stated at the top of the docs page:
Who can use this feature?
Owners, collaborators, prior contributors, and people with write access can report issues, pull requests, discussions, and comments on issues, pull requests, discussions, and commits. Anyone can report apps in GitHub Marketplace.
But when I am looking for a quick answer to something, I am usually going to jump straight to the section of interest; in which case I don't get shown that:
So it would probably be better to explicitly include that a normal user isn't going to be able to see those options in those subsections; if that is truly the case.
Though it's also confusing to me (except that past related issues mention it) that this feature would be restricted; as it adds more friction that will lead to less people 'raising the appropriate alarm'; as they may not know (or want to spend the time) to click through to the user profile and report from there.
It's also kind of confusing to me because in the iOS app, I do see a 'report' option in the ... menu for issues/comments/etc seemingly always; but on web that menu option isn't present.
But when I am looking for a quick answer to something, I am usually going to jump straight to the section of interest; in which case I don't get shown that:
It looks like there was even a PR that attempted to add this 'in-place' guidance way back in 2022:
@0xdevalias The PR you linked was closed because the issue was addressed here, not because the solution proposed in the comment was rejected. There's still a "who can use this" box at the top of the article. I suspect that with that box there, the answer is going to be "leave it as it is, the information is there and it's prominent," but I can check to see if opinions have changed in the last few years, if you'd like me to.
The PR you linked was closed because the issue was addressed here, not because the solution proposed in the comment was rejected.
@Sharra-writes I disagree. The user that opened #20202 also created #20204, which was rejected as per #20204 (comment), which is also mentioned with slightly more detail in #20202 (comment); and that last comment was the source for why #23050 was done in the first place.
There's still a "who can use this" box at the top of the article.
@Sharra-writes There is, but that's why I detailed how that is only useful when you enter the page at the top; not when you jump to a specifically relevant/focussed section.
The past issues I linked back to also show how this isn't really discoverable enough/useful enough, as there is a history of people being confused by this; even after the above changes were made:
I also believe there is precedent in the docs already for patterns where even if it is included in a generic box at the top; it is still called out in some way in the more specific sub-sections; as arguably, that is the more important place for that to exist rather than a generic banner at the top that attempts to add rules for various sub-sections (but that don't apply to all).
I suspect that with that box there, the answer is going to be "leave it as it is, the information is there and it's prominent," but I can check to see if opinions have changed in the last few years, if you'd like me to.
@Sharra-writes I would appreciate it; as I feel like with minimal tweaks this could be made a lot more user friendly / usable.
@0xdevalias Fair enough. I can see how getting linked to a particular section would pose a problem, and a page like that does seem like a prime target for linking only to particular sections. I'll point that out and see what the rest of the team thinks.
A stale label has been added to this issue, because it has been open for 30 days with no activity. If you think this issue should remain open, please add a new comment.
@0xdevalias I probably have an answer to that question (not a super helpful one or this would have moved forward already, but I know the team discussed it at least once), but I was sick this week and I'm drowning in notifications, so I'm not going down that rabbit hole right now. Hopefully I can get some Actions and localization stuff cleared up and focus on other things, including this. I removed the inactive tag, at least.
A stale label has been added to this issue, because it has been open for 30 days with no activity. If you think this issue should remain open, please add a new comment.
@0xdevalias Hello, and first of all let me apologise for how long this issue has languished without action.
I can see exactly where this has been frustrating for you, and I appreciate you taking the time to raise an issue about it, so I want to address it in detail. I will start by saying, though, just to set expectations appropriately, that unfortunately there's not going to be anything we can do on this particular occasion.
Ultimately, when you noted this...
Technically yes, this is stated at the top of the docs page:
... you actually pre-empted my answer. I agree this isn't a perfect solution, but it's what we've devised to try to manage situations where options will differ based on readers' levels of access (or indeed which version of GitHub they're using).
I can see that this is particularly frustrating for this particular use case, and I'm sorry this isn't going to be the answer you were looking for. Again, also, I'm sorry it took so long for an answer to be provided. The GitHub docs are complex, and I will say that we're always trying to innovate and improve our content and its usability, and that we do listen to feedback like this. In the end, this really is a feature request for the docs site itself, and that's why I'm unable to take a specific action for it from this repo and promise a specific resolution.
If there's something I've missed, or if you'd like to discuss further, please feel free to leave another comment—but I will aim to close this issue out shortly. Thank you 🙇
@subatoi Thanks for taking the time to look into it and for the detailed response. I appreciate the apology as well, and I understand that this isn't necessarily something you personally, or the team responsible for this repo, can directly fix.
That said, I do want to be clear that I'm pretty unhappy with this as an outcome.
If this is ultimately a feature request for the docs site itself, and therefore can't be actioned from this repo, I don't think the useful end state should be "there's nothing we can do here" followed by presumably closing the issue. GitHub is much better placed than I am to know which team/repo/internal tracker actually owns that functionality. I'd much rather see the issue handed off to the appropriate place; whether that's opening/cross-linking a public issue elsewhere, or filing it internally and leaving some indication here that the feedback has actually gone somewhere.
From my perspective, I already did the work of identifying the problem, reproducing it, providing screenshots, digging through historical related issues/PRs, and explaining the user-facing impact. Having to then also figure out GitHub's internal ownership boundaries and re-file/re-explain the same thing elsewhere feels like an unreasonable amount of burden to put back on the person reporting the problem.
This is also unfortunately not the first time I've recently had essentially this experience in this repo. In #39847, @Sharra-writes made a genuine effort to chase the issue through a few different teams, but ultimately couldn't get a useful answer and that issue was also closed without any particularly useful action coming from it.
I don't say any of that to blame you personally; I appreciate that you're working within whatever ownership/process constraints exist. But from the outside, the distinction between "this team can't act on it" and "GitHub can't/won't carry the feedback any further" doesn't make the customer/contributor experience much better.
At this point I don't really have the energy or capacity to keep chasing these things through GitHub's organisational boundaries, so realistically I don't have much choice other than to accept the issue being closed or whatever the outcome here is going to be. But I don't want that acceptance to be mistaken for being satisfied with the outcome.
Experiences like this make me considerably less inclined to spend the time digging into problems and filing detailed feedback in future. I care about improving these things for everyone, but it's hard to justify putting that effort in when even well-developed reports can seemingly reach the edge of one team's responsibility and then just stop there; and that has sort of been a repeated experience across many of GitHub's repo's/etc in general.
@0xdevalias I appreciate you taking the time to write back to me. On reflection and after discussing it internally, I think that on this occasion, given the particularly sensitive nature of the content you've highlighted, there may be a compromise we can reach. I understand if you've already got to the point where you'd rather not work on it any more, but if not... If you'd be interested in raising a PR to add a few targeted sentences to try to alleviate the pain points you've highlighted, then I'd be happy to review that. I can't guarantee that I'll be able to accept the first iteration of it, but I can guarantee that I'll work with you to reach a compromise if not, if that's something you'd be interested in. Just let me know your thoughts.
Activity
0xdevalias commentedon Sep 21, 2025
Technically yes, this is stated at the top of the docs page:
But when I am looking for a quick answer to something, I am usually going to jump straight to the section of interest; in which case I don't get shown that:
So it would probably be better to explicitly include that a normal user isn't going to be able to see those options in those subsections; if that is truly the case.
Though it's also confusing to me (except that past related issues mention it) that this feature would be restricted; as it adds more friction that will lead to less people 'raising the appropriate alarm'; as they may not know (or want to spend the time) to click through to the user profile and report from there.
It's also kind of confusing to me because in the iOS app, I do see a 'report' option in the
...menu for issues/comments/etc seemingly always; but on web that menu option isn't present.0xdevalias commentedon Sep 21, 2025
It looks like there was even a PR that attempted to add this 'in-place' guidance way back in 2022:
But was rejected:
Sharra-writes commentedon Sep 22, 2025
@0xdevalias The PR you linked was closed because the issue was addressed here, not because the solution proposed in the comment was rejected. There's still a "who can use this" box at the top of the article. I suspect that with that box there, the answer is going to be "leave it as it is, the information is there and it's prominent," but I can check to see if opinions have changed in the last few years, if you'd like me to.
0xdevalias commentedon Sep 23, 2025
@Sharra-writes I disagree. The user that opened #20202 also created #20204, which was rejected as per #20204 (comment), which is also mentioned with slightly more detail in #20202 (comment); and that last comment was the source for why #23050 was done in the first place.
@Sharra-writes There is, but that's why I detailed how that is only useful when you enter the page at the top; not when you jump to a specifically relevant/focussed section.
The past issues I linked back to also show how this isn't really discoverable enough/useful enough, as there is a history of people being confused by this; even after the above changes were made:
I also believe there is precedent in the docs already for patterns where even if it is included in a generic box at the top; it is still called out in some way in the more specific sub-sections; as arguably, that is the more important place for that to exist rather than a generic banner at the top that attempts to add rules for various sub-sections (but that don't apply to all).
@Sharra-writes I would appreciate it; as I feel like with minimal tweaks this could be made a lot more user friendly / usable.
Sharra-writes commentedon Sep 23, 2025
@0xdevalias Fair enough. I can see how getting linked to a particular section would pose a problem, and a page like that does seem like a prime target for linking only to particular sections. I'll point that out and see what the rest of the team thinks.
0xdevalias commentedon Sep 24, 2025
@Sharra-writes Thank You, I appreciate it :)
jonathansevoich8-crypto commentedon Sep 24, 2025
github-actions commentedon Nov 18, 2025
A stale label has been added to this issue, because it has been open for 30 days with no activity. If you think this issue should remain open, please add a new comment.
0xdevalias commentedon Nov 18, 2025
@Sharra-writes Any updates?
(Mostly commenting to remove the 'stale' label)
Sharra-writes commentedon Nov 22, 2025
@0xdevalias I probably have an answer to that question (not a super helpful one or this would have moved forward already, but I know the team discussed it at least once), but I was sick this week and I'm drowning in notifications, so I'm not going down that rabbit hole right now. Hopefully I can get some Actions and localization stuff cleared up and focus on other things, including this. I removed the inactive tag, at least.
github-actions commentedon Jan 6, 2026
A stale label has been added to this issue, because it has been open for 30 days with no activity. If you think this issue should remain open, please add a new comment.
0xdevalias commentedon Jan 6, 2026
(Commenting RE: stale label as I still think this issue is valid)
subatoi commentedon Aug 24, 2026
@0xdevalias Hello, and first of all let me apologise for how long this issue has languished without action.
I can see exactly where this has been frustrating for you, and I appreciate you taking the time to raise an issue about it, so I want to address it in detail. I will start by saying, though, just to set expectations appropriately, that unfortunately there's not going to be anything we can do on this particular occasion.
Ultimately, when you noted this...
... you actually pre-empted my answer. I agree this isn't a perfect solution, but it's what we've devised to try to manage situations where options will differ based on readers' levels of access (or indeed which version of GitHub they're using).
I can see that this is particularly frustrating for this particular use case, and I'm sorry this isn't going to be the answer you were looking for. Again, also, I'm sorry it took so long for an answer to be provided. The GitHub docs are complex, and I will say that we're always trying to innovate and improve our content and its usability, and that we do listen to feedback like this. In the end, this really is a feature request for the docs site itself, and that's why I'm unable to take a specific action for it from this repo and promise a specific resolution.
If there's something I've missed, or if you'd like to discuss further, please feel free to leave another comment—but I will aim to close this issue out shortly. Thank you 🙇
0xdevalias commentedon Aug 24, 2026
@subatoi Thanks for taking the time to look into it and for the detailed response. I appreciate the apology as well, and I understand that this isn't necessarily something you personally, or the team responsible for this repo, can directly fix.
That said, I do want to be clear that I'm pretty unhappy with this as an outcome.
If this is ultimately a feature request for the docs site itself, and therefore can't be actioned from this repo, I don't think the useful end state should be "there's nothing we can do here" followed by presumably closing the issue. GitHub is much better placed than I am to know which team/repo/internal tracker actually owns that functionality. I'd much rather see the issue handed off to the appropriate place; whether that's opening/cross-linking a public issue elsewhere, or filing it internally and leaving some indication here that the feedback has actually gone somewhere.
From my perspective, I already did the work of identifying the problem, reproducing it, providing screenshots, digging through historical related issues/PRs, and explaining the user-facing impact. Having to then also figure out GitHub's internal ownership boundaries and re-file/re-explain the same thing elsewhere feels like an unreasonable amount of burden to put back on the person reporting the problem.
This is also unfortunately not the first time I've recently had essentially this experience in this repo. In #39847, @Sharra-writes made a genuine effort to chase the issue through a few different teams, but ultimately couldn't get a useful answer and that issue was also closed without any particularly useful action coming from it.
I don't say any of that to blame you personally; I appreciate that you're working within whatever ownership/process constraints exist. But from the outside, the distinction between "this team can't act on it" and "GitHub can't/won't carry the feedback any further" doesn't make the customer/contributor experience much better.
At this point I don't really have the energy or capacity to keep chasing these things through GitHub's organisational boundaries, so realistically I don't have much choice other than to accept the issue being closed or whatever the outcome here is going to be. But I don't want that acceptance to be mistaken for being satisfied with the outcome.
Experiences like this make me considerably less inclined to spend the time digging into problems and filing detailed feedback in future. I care about improving these things for everyone, but it's hard to justify putting that effort in when even well-developed reports can seemingly reach the edge of one team's responsibility and then just stop there; and that has sort of been a repeated experience across many of GitHub's repo's/etc in general.
subatoi commentedon Aug 24, 2026
@0xdevalias I appreciate you taking the time to write back to me. On reflection and after discussing it internally, I think that on this occasion, given the particularly sensitive nature of the content you've highlighted, there may be a compromise we can reach. I understand if you've already got to the point where you'd rather not work on it any more, but if not... If you'd be interested in raising a PR to add a few targeted sentences to try to alleviate the pain points you've highlighted, then I'd be happy to review that. I can't guarantee that I'll be able to accept the first iteration of it, but I can guarantee that I'll work with you to reach a compromise if not, if that's something you'd be interested in. Just let me know your thoughts.
subatoi commentedon Sep 1, 2026
I'll go ahead and close this for now, but please feel free to add a new comment in reply to my post above to restart this 🙇