3 ms·

Totally agree. GitHub issues is probably the best bug tracker/ticketing system you can imagine. Intuitive interface, simple, clean, and fast. Just waiting for a

Totally agree. GitHub issues is probably the best bug tracker/ticketing system you can imagine. Intuitive interface, simple, clean, and fast. Just waiting for a Microsoft redesign to completely fuck it up. :P

kccqzy 1y ago
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.
- 9dev 1y ago
  > an editable summary at the very top of the page communicates high-level points to stakeholders I would hope this will soon be written by AI automatically; summing up high-level points in an issue discussion seems like a perfect task for an LLM.
  - simonw 1y ago
    I've been rolling my own version of that recently via my https://github.com/simonw/llm-fragments-github https://github.com/simonw/llm-fragments-github plugin. Here's an example where I condensed 50+ comments (accumulated over a year and a half!) into a summary comment and added it to the thread: https://github.com/simonw/sqlite-chronicle/issues/7#issuecomment-2833108867 https://github.com/simonw/sqlite-chronicle/issues/7#issuecom... I created the summary like this: 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'
- hnlmorg 1y ago
  1. Summary 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.
  - billylb42 1y ago
    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.
  - kccqzy 1y ago
    > 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?
    - hnlmorg 1y ago
      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.
- bjourne 1y ago
  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....
- pacifika 1y ago
  Run the Orbit extension on the page. That should give you a summary
  - kccqzy 1y ago
    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.
    - simonw 1y ago
      Yeah, I'm annoyed by that too. Thankfully it doesn't affect the API.
soraminazuki 1y ago
It's already locked up behind a login wall. You can only search for a handful of issues before being quickly rate limited.
hugh-avherald 1y ago
Isn't the entire purpose of Azure DevOps to be a sort of Jovian gravity well into which Microsoft marketing principles can be sucked into before they hit GitHub?
- WorldMaker 1y ago
  Hard for it to stay that way when Microsoft's own teams start dogfooding it. Evidence points to even the Windows Team using GitHub Issues as their primary PM tool today. The saving grace for now seems to be that Microsoft sees the "Advanced" PM tools in GitHub as value adds and is either rolling them out slowly to charge "Preview Customers" for as long as possible for that for that feature before making it public and/or putting them into GitHub pricing tiers such as "If you have to ask how much it costs, you can't afford it" and "Offer you cannot afford to refuse".

kccqzy 1y ago

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.

9dev 1y ago
> an editable summary at the very top of the page communicates high-level points to stakeholders I would hope this will soon be written by AI automatically; summing up high-level points in an issue discussion seems like a perfect task for an LLM.
- simonw 1y ago
  I've been rolling my own version of that recently via my https://github.com/simonw/llm-fragments-github https://github.com/simonw/llm-fragments-github plugin. Here's an example where I condensed 50+ comments (accumulated over a year and a half!) into a summary comment and added it to the thread: https://github.com/simonw/sqlite-chronicle/issues/7#issuecomment-2833108867 https://github.com/simonw/sqlite-chronicle/issues/7#issuecom... I created the summary like this: 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'
hnlmorg 1y ago
1. Summary 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.
- billylb42 1y ago
  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.
- kccqzy 1y ago
  > 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?
  - hnlmorg 1y ago
    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.
bjourne 1y ago
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....
pacifika 1y ago
Run the Orbit extension on the page. That should give you a summary
- kccqzy 1y ago
  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.
  - simonw 1y ago
    Yeah, I'm annoyed by that too. Thankfully it doesn't affect the API.

soraminazuki 1y ago

It's already locked up behind a login wall. You can only search for a handful of issues before being quickly rate limited.

hugh-avherald 1y ago

Isn't the entire purpose of Azure DevOps to be a sort of Jovian gravity well into which Microsoft marketing principles can be sucked into before they hit GitHub?

WorldMaker 1y ago
Hard for it to stay that way when Microsoft's own teams start dogfooding it. Evidence points to even the Windows Team using GitHub Issues as their primary PM tool today. The saving grace for now seems to be that Microsoft sees the "Advanced" PM tools in GitHub as value adds and is either rolling them out slowly to charge "Preview Customers" for as long as possible for that for that feature before making it public and/or putting them into GitHub pricing tiers such as "If you have to ask how much it costs, you can't afford it" and "Offer you cannot afford to refuse".