I've used plenty of proprietary issue tracking systems and GitHub is missing several features that I now consider quite important though certainly not essential:
* The ability to write an issue summary separate from comments. When you are debugging some hairy bug, some manager doesn't really want to wade through all the comments to get an idea; an editable summary at the very top of the page communicates high-level points to stakeholders while others continue to comment on details. People work around this by editing the initial comment of the issue but it's better if there's something more dedicated.
* Sophisticated access control. More than once when someone writes a bug report they are referring to a bug experienced by a single user. For user privacy reasons there needs to be a per-issue permission system to restrict access beyond the permission implied by the repo.
* The ability to add personal notes to an issue without publishing it. Whether it's a draft form of a comment or something else, it gets rid of the need to maintain your own notes.
Every experienced dev knows what happens when they are subjected to issue trackers with loads of features: some managers require all those features to be used (cause that's what they paid for!). So instead of spending your time debugging you have to ensure the bug is properly tagged, categorized, has the right version number(s) for affected software, has the right assignee, yadda, yadda. Then some busy beaver will send you email reminding you that you haven't filled in all the drop-downs and check boxes correctly....
It wouldn’t be too hard to add that with a 3rd party plugin. You could set an event hook to run through the comments, and add it to the top comment.
For bonus points, you could use an LLM to summarise. Every company loves a bit of AI these days, so your manager can gloat with his manager buddies that you now have AI-powered issue tracking.
2. That sounds like an anti-pattern to me. There shouldn’t be PII in your dev issue tracking system.
There problem here isn’t RBAC, it’s the workflow. If you’re in a situation where you need to make notes of sensitive information then you should store that in the same data store as the source information (eg Salesforce, et al). And I say this as someone who hates Salesforce.
3. I’ve not seen this feature in any issue tracker. Sounds like a nice feature but I wouldn’t have thought it as essential.
> That sounds like an anti-pattern to me. There shouldn’t be PII in your dev issue tracking system.
Then how do you track such issues? I'll give you a real example I've experienced: a high-value customer writes to support and complains that his UI is broken. None of the other people's UIs are broken. Do you not use the issue tracking system just because you need to get that customer's private settings and PII in order to debug the bug?
It's common to require PII to be stored elsewhere, but people will still make mistakes and copy paste PII for convenience. In the end isn't it better for your issue tracking system to be flexible enough to store PII?
You can say user ID is broken and define how it’s broken. You don’t have include any of their PII outside of the user ID.
> It's common to require PII to be stored elsewhere, but people will still make mistakes and copy paste PII for convenience.
That’s a training problem.
And It’s also common for people to fuck up RBAC. The latter is a harder problem to fix with training than teaching them to keep PII out of issue tracking systems.
> In the end isn't it better for your issue tracking system to be flexible enough to store PII?
I’ve worked in some very sensitive domains. They managed just fine keeping customer data out of the issue tracking systems.
The user ID is a piece of email. It is PII. To define how it's broken is to describe a list of specific actions the user did to the private information in their account causing the UI to be broken.
If training is such a problem, I don't understand why we solve the problem by obviating such training and make the issue tracking system an acceptable storage medium for PII?
3. ServiceNow incident tracking has something close called “work notes”. Work notes are for internal team members with a certain role, where comments are public and meant to communicate to the issue reporter.
llm \
-f issue:https://github.com/simonw/sqlite-chronicle/issues/7 \
-m openai/o4-mini \
-o reasoning_effort high \
-s 'Output markdown explaining this issue and the proposed resolution succinctly and clearly'
That reminds me: GitHub has a bad habit of hiding comments in a long issue. It displays the first few and the last few comments. So you can't expect an extension to grab the entire context without it specifically being designed for GitHub. In fact even the browser's built-in Find In Page won't find everything.
* The ability to write an issue summary separate from comments. When you are debugging some hairy bug, some manager doesn't really want to wade through all the comments to get an idea; an editable summary at the very top of the page communicates high-level points to stakeholders while others continue to comment on details. People work around this by editing the initial comment of the issue but it's better if there's something more dedicated.
* Sophisticated access control. More than once when someone writes a bug report they are referring to a bug experienced by a single user. For user privacy reasons there needs to be a per-issue permission system to restrict access beyond the permission implied by the repo.
* The ability to add personal notes to an issue without publishing it. Whether it's a draft form of a comment or something else, it gets rid of the need to maintain your own notes.