37 ms·

GitHub introduces sub-issues, issue types and advanced search

368 points by julius-fx 2y ago

grajaganDev 2y ago
Nice additions - Buganizer has had these for years. Good that issue types can be user defined.
kkaatii 2y ago
The sub-issue structure seems much better than Jira's approach where everything has to fit into a hierarchy. Then it becomes hard to align on the definition of a certain level in the hierarchy. This create-a-subissue-when-needed way is more sensible.
- WorldMaker 2y ago
  It's also not that different from what people have been using Task Lists for today: https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/about-task-lists https://docs.github.com/en/get-started/writing-on-github/wor... I think that's maybe my biggest question is what the interop looks like between Task Lists and Sub-Issues. Is there a "one-click upgrade" yet? What if I want to copy a list of Sub-Issues as Markdown Task List to copy into a Discussion or a Wiki somewhere?
- trallnag 2y ago
  You can use a single type of issue in Jira and just rely on linking them together
  - kkaatii 2y ago
    Wow i didn't know that.
  - IshKebab 2y ago
    Yeah we ended up doing this. You should basically never use Epics or Subtasks in Jira because they have weird unnecessary restrictions that don't apply to normal tasks, especially around putting them in sprints.
Wicher 2y ago
Great, but I would've been happier if I'd had some dead simple dependency tracking 10 years ago. Just enough to create metabug functionality with. Like Bugzilla, Trac, Mantis etc have sported for at least two deades. I've always wondered why Github didn't have such basic functionality. (No, just the ability to reference other issues is not enough; I want to get an email for the metabug when all blocking issues are resolved).
tw12312831 2y ago
GitHub was better before MSFT took over. MSFT introduces bureaucratic fluff, hierarchies and loads of unnecessary complexities. How about adding a registry?
- shamiln 2y ago
  What type of registry? GitHub packages?
  - yallpendantools 2y ago
    I would hazard a guess, more in the vein of the much-maligned "Windows Registry". https://en.wikipedia.org/wiki/Windows_Registry https://en.wikipedia.org/wiki/Windows_Registry
vivzkestrel 2y ago
also let people sort repositories by the ratio of open requests to closed requests, average amount of time to respond on an issue
Calzifer 2y ago
Great, a few more decades and it might become a usable bugtracker. What's next on the list? Maybe priority/severity or status/resolution? I helped on a quite large open source project for some time and loved working with Bugzilla. The announced switch to Github for that project was one reason I lost interest. I even prefer to work with a well administrated(!) Jira over Github issues.
- StableAlkyne 2y ago
  > Maybe priority/severity or status/resolution? That's already possible with the tag system. At least, that's the most common use I see for repos that decide to use tags. How do you envision this differing?
  - smarx007 2y ago
    Sorting by priority?
  - akoboldfrying 2y ago
    Are you thinking of labels? I only know GitHub "tags" to be the raw git branch-that-never-moves kind.
    - ffsm8 2y ago
      Totally off topic, but Tags can be moved too. ;) It's mostly a convention that we use annotated tags (a tag that also creates a commit) and don't move them
- chrisandchris 2y ago
  Transitioned from Jira to Gitlab. Jira has workflows/resolution states. Gitlab only has tags. It's a different mindset and a different way to work. I'm not sure I'm happy with only-tags because it puts the work to the end-user (i regularly need to add tags because someone forgot to add it - could not happen with workflows and proper transitions).
- IshKebab 2y ago
bnewman85 2y ago
Let us comment on the commit messages and create a better UI for editing messages for teams that take git history seriously, please. Are there no linux kernel devs at msft who can make this happen?
- atq2119 2y ago
  In the same vein, better reviewability of series of commits. It's absolutely baffling to me that GitHub still doesn't support the original workflow for Git.
decide1000 2y ago
I am not sure if I am going to like this feature. I miss the simplicity. Guess those times re over.
- captn3m0 2y ago
  I'm remembering the Redmine slide from Zach Holman's talk, where he makes fun of the overly complicated Redmine issue creation screen, compared to what the GitHub screen looked like (back in 2011). Slides 56 and 57 at https://speakerdeck.com/holman/how-github-uses-github-to-build-github?slide=56 https://speakerdeck.com/holman/how-github-uses-github-to-bui...
- dacryn 2y ago
  same here. I guess it's Microsoft slowly making it cater to their enterprise clients
  - foepys 2y ago
    Microsoft is getting ready to replace Azure DevOps with GitHub.
    - alternatex 2y ago
      This is fiction considering Microsoft is extensively using Azure DevOps internally and is still developing it. Moving projects away from it and to GitHub is impossible because they're incredibly far from having feature parity.
      - ciberado 2y ago
        Feature parity is probably not required as long as the different teams are able to adapt their workflow to GitHub's approach. Anecdotally, every employee from Microsoft I've talk to about this point during the last two years keep telling me that ADO is over.
        stackskipton 2y ago
whataguy 2y ago
They also changed the design of issue comments, but seemingly reverted it back to the old design in production? (If you check the first video on the blog you can see e.g. the profile picture inside of the comment, while the old and current version has it on the outside.)
politelemon 2y ago
The issue types are similar to labels. I wonder why they didn't build on that.
eviks 2y ago
> This means there are no new UI patterns to slow you down, Sure there are, it's a common UI design mistake - you can't do advanced without breaking the basics: previously you could filter your issues with a drop-down filter in 2 clicks. The PR tab still has this (inconsistency) while the new issue requires a worse and longer path that uses a typed field, bringing up you phone keyboard as a downside
- maeil 2y ago
  Longer paths, especially ones like these that require keyboard input, are especially painful from an accessibility perspective, where for most cases such typed fields make things take exponentially longer than if it can be achieved by just clicks/tabs/arrows.
prymitive 2y ago
There is a huge wall of placeholder being replaced with issues when the issues tab loads, which is pretty annoying when you got used to the old UI. But it’s nice to see M$ can still deliver features without Autocomplete Integration forced in it.
Springtime 2y ago
It's neat there are more options for filtering though ime the new issues UI is less responsive, showing placeholder skeletons more frequently than I'd like. Perhaps less noticeable when a fast connection is always available but even just showing the total Open/Closed ticket counters can take a few seconds when it used to be instant.
stock_toaster 2y ago
From Copilot integration that you can’t disable if you accidentally clicked something once (you can only now as of a few days ago hide the UI, but you are still not able to disable it in settings), to this issues UI aglomeration. The Microsoftization/enshittification of Github continues apace.
paradox460 2y ago
Not bad, but I still have to say that zenhub does it better Used that at an old job and it was the only project management software I didn't grow to hate. Fast, "built into" GitHub, and adds other value across the site, I miss it now at my current jira gig
- hamandcheese 2y ago
  Big +1, I used zenhub at one of my first jobs and I miss it to this day.
  - paradox460 2y ago
    Its one of those things that I will forever evangelize for, because the one time I was able to use it, I had my most productive year ever. My github activity graph for the 18 months I got to use zenhub looked like a beautiful green meadow. I've tried most other project management software. They all stink in one way or another. JIRA is a known problem, ClickUp, Monday, and friends aren't much better. I never liked pivotal, and its dead now, so doesn't really matter. And Github's projects feature is just too spartan to be useful
isodev 2y ago
In other words, GitHub introduces "endless discussions if we're going to use subtasks or sub-issues in our WoW"
- celdon25 2y ago
  That's a leadership issue
  - Y-bar 2y ago
    And even then it affects us all and distracts us from the work we actually want to do.
polycaster 2y ago
I've been waiting so long for this. Finally, we can have Epics that are not a pain in the ass!
shiomiru 2y ago
So that's why they broke loading issue comments without JS. As if the (post-M$) UI hadn't been sluggish enough before...
weinzierl 2y ago
I, for my part, would be happy if they could make basic search work for a start. Will the advanced search finally allow us to find the most basic things reliably?
- edflsafoiewq 2y ago
  What doesn't work?
  - weinzierl 2y ago
    If you search code for a string you know is there it is completely git or miss if it is found. Always has been like that. Also see https://news.ycombinator.com/item?id=35144250 https://news.ycombinator.com/item?id=35144250
    - edflsafoiewq 2y ago
      I assumed you were talking about issue search, since that's what the thread is about.
    - idunnoman1222 2y ago
      Oh yeah, where on the Internet does this work reliably?please don’t say gitlab
      - maeil 2y ago
        Sourcegraph.
      - trollbridge 2y ago
        grep -rli search_this some-repo # (or use rg if you prefer)
        idunnoman1222 2y ago
        Holy shit what a good idea why doesn’t GitHub just let you use ripgrep?!?!?
hamandcheese 2y ago
A GitHub feature I think would be really handy is suggesting duplicate issues when writing up a new issues. Many projects ask that you search for already reported tickets, but GitHub's current search isn't great if you aren't sure what you are looking for.
- deleted 2y ago
  [deleted]
- hnlmorg 2y ago
  Completely agree with this suggestion. Ive often wondered why GitHub hasn’t introduced this feature because it feels like a really obvious thing to introduce and something that would add an immense amount of value to a lot of projects.
  - sethops1 2y ago
    Cynical answer: because having users writeup duplicate issues and then having maintainers close them is more engagement than warding off unnecessary toil. Gotta keep those metrics going up and to the right.
    - rafram 2y ago
      GitHub doesn’t have ads and makes its money off of enterprise subscriptions (and Copilot), so I don’t think “engagement” is a very important metric for them.
      - ysavir 2y ago
        To the company, no. But to people trying to get a promotion/bigger budgets by proving the features they work on are getting a lot of usage, plausible.
        drdaeman 2y ago
        > To the company, no. Why not? Companies love to boast about MAUs and similar metrics (even if completely bogus), it has good effect on stock prices.
joshSzep 2y ago
this happens after I've moved everything to height. downside is it was a lot of work. upside is height is amazing and I'm pleased with the choice. anyone else using it?
- mg74 2y ago
  what is height?
  - matt_kantor 2y ago
    Maybe this? https://height.app/ https://height.app/
- quesera 2y ago
  > anyone else using it? We're looking for a new home, with Pivotal Tracker shutting down on April 30th (101 days left!). I had not heard of Height before. On first glance, it looks like a genuinely modern project management service -- which is both interesting and unsettling.
  - joshSzep 2y ago
    We are loving it and we aren't even using it fully to its ability. For example we do almost no communication in the 'chat' that exists for each issue (in place of comments) since we are a very small team and still are talking mostly in slack about the issues, but I predict as we grow this will become a useful feature for us. In the meantime we are loving the 'every issue can have sub-issues' and have customized the fields to our liking. This is a tool with a lot of power. I can see a well-intentioned PM going crazy with it, but for our needs I was startled with how great it is.
zb3 2y ago
Bring back sorting code search results by date! https://github.com/orgs/community/discussions/52932 https://github.com/orgs/community/discussions/52932
shpx 2y ago
Instead of these features I want them to stop spam issues on my repos. All the issues I've gotten in the last year on my project are completely nonsensical. It's not even spam it's just like random URLs or complete nonsense from freshly created accounts that aren't trying to sell anything or just the issue template. And every time it costs me 2 clicks to click on "report" then I have to type "spam", click the spam category, then I have to type "it's spammmmmmmmmmmmmmmmmmmmmm" to hit the 15 character report description requirement, then I have to solve a captcha. All this despite the fact that I've had a GitHub account for like a decade and I've filed like 30+ spam reports, none of which were frivolous. I opened GitHub after typing this comment and there it was, a notification from an obvious bot account opening an issues that's just 5 meaningless Korean letters with no description.
- bsmth 2y ago
  It might be worth trying the moderation tools that prevent interactions from accounts less than 24 hours old. Docs here https://docs.github.com/en/communities/moderating-comments-and-conversations/limiting-interactions-in-your-repository https://docs.github.com/en/communities/moderating-comments-a... I share your frustration with this, and in my experience a lot of noise comes from these types of accounts.
javier2 2y ago
I would like it if Github could fix all the bugs with back button (broken browser history) first
riidom 2y ago
Ah this really feels like they could have tackled https://github.com/orgs/community/discussions/4993 https://github.com/orgs/community/discussions/4993 too, what a missed opportunity, I'd love to be notified about some repositories again, which I had to unwatch now because of daily autobuild spam.
akimbostrawman 2y ago
>This means there are no new UI patterns to slow you down, requiring JS to simply view issues begs to differ....
- FridgeSeal 2y ago
  I look forward to GitHub getting even slower and buggier than it is now.
donatj 2y ago
This seems... unneeded bloat? I guess there are some obsessive organizers out there, but a markdown checklist of steps - potentially with links to other tickets seems like all you need. If you're going to improve something improve code review! Let me comment on and suggest diffs to lines the author did not touch. Like half the time I am reviewing code it is "Hey, you refactored this but you missed a usage in this other file" and right now I have to manually give them file and line number manually and hope for the best.
- replete 2y ago
  A lot of this will seem trivial if you haven't used Github for an organization's management of issues. This also lets you start off with a markdown checklist, and convert items to sub-issues.
  - paulryanrogers 2y ago
    > This also lets you start off with a markdown checklist, and convert items to sub-issues. Wasn't that already possible with Tasklists? We did it using "- [ ] description", then clicking the covert-to-issue hover option.
  - donatj 2y ago
    See, but I do. For almost a decade, we have used it as-is for tickets and bug tracking, and it's never been a problem. I just don't see the use case for sub issues.
mikeocool 2y ago
Maybe they’ll add “Closed - won’t fix” and “Closed - stale” statuses next!
- edflsafoiewq 2y ago
  They already have "Closed as not planned (won't fix, can't repro, stale)". You can use labels for finer granularity if you want.
- paulryanrogers 2y ago
  There is already close as unplanned, which can serve both if you're flexible
jerrygoyal 2y ago
I've almost stopped using GitHub as I switched over to vscode Github Pull Request Extension.
ttoinou 2y ago
Looks very good. I might switch from Gitlab Issues if I find a tool to convert issues
jxi 2y ago
Strange that issue types is only available if your repository is part of an organization. Why is this not configurable at the repository level?
- paulryanrogers 2y ago
  To upsell? To maintain consistency among repos? To facilitate use among GH Projects?
sangeeth96 2y ago
I'm curious if there are folks here who work at for-profit orgs who use GitHub projects as their sole issue tracker for the entire org. How do you do it and what are the common pain points? Do you couple it with other issue trackers/project management tools like Jira? If so—why? I still feel GH Projects is solely aimed at OSS or dev-centric or dev-only orgs and doesn't cater to teams with non-devs, which is how I think most orgs function. I'm not sure if it'll ever try to be something more than that but I really wish it did.
- jjayj 2y ago
  It would be a tough sell for my org to triple our license spend on GHEC just so we can teach a bunch of folks new software.
  - sangeeth96 2y ago
    Absolutely. They definitely can't expect to sell this to teams/orgs with non-devs without introducing separate pricing for folks who just want to read/write to projects but maybe read-only for some aspects of a repo.
  - eclipticplane 2y ago
    A FOSS plugin to mimic Service Desk on top of Github issues would be great. You'd miss the infinite complexity of Jira workflow configuration, but that might be a good thing.
    - jt_b 2y ago
      Not FOSS, but this is kind of what Zenhub was/is, right?
- acjohnson55 2y ago
  We did at my previous employer (https://www.ourbranch.com/ https://www.ourbranch.com/) in our data org. I can't totally remember, I'm pretty sure the engineering org did, too. It definitely is lacking in some of the advanced features you get with a Jira, but it was fine. I was surprised by how powerful GitHub Projects is. We also built out extra reporting for it in our data warehouse, using Fivetran for ELT.
the_duke 2y ago
Slowly inching towards something usable for companies / large projects... One big thing missing is resolution status for issues, like "cancelled", "complete", ...
- paulryanrogers 2y ago
  You can close as complete (default) or unplanned today. It's called the 'reason'.
landsman 2y ago
I am looking forward to project management without Jira!
cloverich 2y ago
I was excited to see this feature pop up in beta, specifically sub issues. VS code organizes their work with parent sprint issues ("iteration plan", see [1]). I started using this pattern on my own project and once i adapted, now prefer it. Now rather than using markdown bullet points, i can use first class sub issues which are slightly less awkward. Ultimately a minor feature addition, but if it pushes more people to use then pattern, i think it would be nice. Lighter weight than proper tools, and imho all you need for moderately complex projects if the suits dont have too many needs / influence. [1]: https://github.com/microsoft/vscode/issues/237297 https://github.com/microsoft/vscode/issues/237297
localghost3000 2y ago
A few jobs back I got “promoted” (honestly I didn’t want it but I digress) to an EM. First thing I did was ditch Jira for GH issues. I was hailed as a hero for it. Unfortunately it ended up being a disaster and we had to switch back a year or so later. These were some of the missing features so pretty exciting.
- aklemm 2y ago
  You should write Cliff's notes for the Odyssey. What an epic summary.
JensRantil 2y ago
Jens's law: Every ticketing system will eventually become Jira. This is also what is happening with GH issues.
- dmd 2y ago
  It's worse than that. Every ticketing system will eventually become ServiceNow. Compared to SN, Jira is a breath of fresh air.
  - redserk 2y ago
    One more field will solve it!
    - JensRantil 2y ago
      LOL.
maxcruer 2y ago
Behold: GitHub is becoming Jira!
nmstoker 2y ago
I wish they would build features to defend against those near-spam type comments where someone is lazy and appends their clearly unrelated issue onto an existing one that maybe shares a few keywords but nothing substantive. It's not quite spam: there's often a real person behind it with a real issue but they need a (metaphorical) slap before they muddy the waters and disturb countless people already in the conversation.
- nmstoker 2y ago
  This would be worthwhile for the individuals too - you often find a recurring pattern with all / most of their raised issues and with basic guidance they might up their game (or give up)
andy_ppp 2y ago
When you have issues in different repos but in the same board it seems very confusing that you can create them and then have to assign them to a repo for them to move out of being a Draft issue (well maybe it is not an issue yet rather a task). Maybe I'm using it wrong but I found this pretty strange. Most projects will have a backend and frontend repo certainly when building an app so I think not being able to manage issues against both projects made things a bit strange. Maybe I should use a different blank mono repo just for issues but then I imaging the integration with PRs and commit messages breaks. Additionally I want to be able to have #PROJ-0002 style IDs for tasks, so for example I can add messages for tasks that affect both repos (e.g. "Imported types from GraphQL API into app (#BACKEND-1234, #FRONTEND-1234)") just having numbers is very limited and slightly confusing.
antics 2y ago
I think of GitHub as a sad story. There are probably going to be at least 3 public companies that should have "just" been GitHub features: GitLab (GitHub Enterprise), Sourcegraph (search), and Linear (GitHub Issues). There are dozens of upstarts "unbundling" features of GitHub that are genuinely useful, but which are under-loved and under-invested in, and surely some of those will become successful too. It feels like GitHub continuously invents the future, and then waits for someone else to make it truly great. It is so painful to watch because I love GitHub so much. I graduated college in 2013, which means I started programming right when they got started. I read their dev blog every single day, eagerly waiting for new features (which were released every couple days). I watched their team page grow, I looked carefully at what they did to deserve a spot at such a cool company. I scoured the projects they contributed back to for hints about what good code looked like (my favorite was Vicent Martí's contributions to libgit2). I eagerly taught my friends how to use git because university taught subversion. I wrote my own Rails tutorials as a way to learn the magic. But it's been years now, and it's not an easy love. It's work! It's so painful to watch it get continuously lapped by upstarts. I always just thought the core offerings (Pull Requests and Issues) would get better eventually. And now, 14 years later, they finally are. But very slowly. I really want to believe, but after 16 years, it is starting to sink in that GitHub might just be a place to store files. The magic is still in there. I think there are lots of people like me, who want to believe. But it will take real agency to do it, and that's really hard to muster at this stage in a company's life.
- SOLAR_FIELDS 2y ago
  FWIW, this specific feature - what they are now calling sub-issues - is actually better described as a framework for modeling proper parent-child relationships in their system, which is something quite hard to get right, mainly because it has to work somehow with the existing issues feature set. People building this feature from scratch (e.g. Linear) have it trivial to solve, because they didn't have any backwards compatibility issue to worry about. This is, of course, absolutely Github's fault for not designing it to accomodate such a thing easily in the first place, but the people who built this feature are probably not the same people who made that original decision. They've been working on some version of this feature for several years now in various iterations. I believe this is either their third or fourth attempt to get it right - I was trialing a beta of some previous iteration of it a few years ago and it was incomplete/not fully well thought out which must be why they dropped it. I'd trust the feature here at least to be decent now, because of how many attempts they've had at it. But yeah if I was a company like Zenhub I would be probably a bit worried at this announcement since it is almost inevitable that this specific feature is going to be enough for people to no longer need third party management of issues. I know in a previous company I worked for that specific feature (proper parent-child relationships) was the reason they used Zenhub, and same for my current company using Linear.
ozim 2y ago
Next thing you know they just reimplement JIRA and everyone starts writing posts how much they hate it.
breatheoften 2y ago
I just wish they'd improve the markdown autocomplete for issues and pull requests ... I'm not sure why it's so bad but even if i know two or three words in the issue title i almost never get the right issue to choose in the autocomplete list while typing in a markdown comment ...
liontwist 2y ago
Corporate customers do pay the bills i suppose.
cratermoon 2y ago
The enjirafication of github continues.
sensanaty 2y ago
Day 50 trillion of begging Github for a functional notification system so I can stop receiving infinite numbers of emails from all the bots and similar things commenting on PRs. Also being designated a codeowner in a large repo, the number of notifications I get daily from the number of PRs is fucking absurd, with no way of turning them off. Drives me up the wall daily. If a colleague doesn't straight up send me a PR in a DM, I'll basically never see it because I've given up on the notification screen a looooong time ago.
- christophilus 2y ago
  It’s fine for small projects. I clear mine daily, and it’s the sole place I do any communication management.
- adsteel_ 2y ago
  Have you been able to try trailer.app?
- deckar01 2y ago
  Doesn’t unwatching a repo limit notifications to mentions and participated threads?
  - deleted 2y ago
    [deleted]
  - ricardobeat 2y ago
    Codeowners are added as a reviewer to every PR that touches a file under their (team) ownership. In a large codebase it can easily happen that a large % of PRs changes something you're a codeowner for.
- blharr 2y ago
  It's a workaround, but why not use email filters for this?
  - sensanaty 2y ago
xyst 2y ago
They have time to work on this micromanagement feature yet can't fix the broken conversation workflow when reviewing PRs. Smh.
carwyn 2y ago
The sub-issues are good, with more relationship types coming (dependencies, not just parent-child). The better search is welcome. However there are some questions for me in relation to the overall semantics of labels, issue types and project fields. Labels are repo only and multi valued. Issue types are organisation wide and single valued, project fields are the richest, but no multi-valued option, and they end up in a disjointed place in the API (you can't get at them easily when what you have is the issue, you have to go in via the project). An example of this disjointed feeling it that there are no "issue type"s for a PR. This means that if you want to share metadata between PR and Issues, you have to use labels anyway. I do wonder if types could have been better implemented as namespaces for labels. This combined with being able to have organisation or repo context label namespaces would have allowed for far more flexibility. The other thing that vanished from the public roadmap amongst all this was support for better workflows. Currently there's no easy way to create allowed state transitions between metadata state (e.g in a project stop issues being able to skip the QA status). The attention this area is getting is welcome, and there are many good things in there, but it does feel a bit disjointed. A more unified metadata model would be welcome.
tehbeard 2y ago
Ah, thought something had changed. Been rather use to the key combo for inverting filtering on issues (E.g. show all issues without a particular label)... That seems to have been nuked.

368 points by julius-fx 2y ago

Nice additions - Buganizer has had these for years. Good that issue types can be user defined.

The sub-issue structure seems much better than Jira's approach where everything has to fit into a hierarchy. Then it becomes hard to align on the definition of a certain level in the hierarchy. This create-a-subissue-when-needed way is more sensible.

WorldMaker 2y ago
It's also not that different from what people have been using Task Lists for today: https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/about-task-lists https://docs.github.com/en/get-started/writing-on-github/wor... I think that's maybe my biggest question is what the interop looks like between Task Lists and Sub-Issues. Is there a "one-click upgrade" yet? What if I want to copy a list of Sub-Issues as Markdown Task List to copy into a Discussion or a Wiki somewhere?
trallnag 2y ago
You can use a single type of issue in Jira and just rely on linking them together
- kkaatii 2y ago
  Wow i didn't know that.
- IshKebab 2y ago
  Yeah we ended up doing this. You should basically never use Epics or Subtasks in Jira because they have weird unnecessary restrictions that don't apply to normal tasks, especially around putting them in sprints.

Wicher 2y ago

Great, but I would've been happier if I'd had some dead simple dependency tracking 10 years ago. Just enough to create metabug functionality with. Like Bugzilla, Trac, Mantis etc have sported for at least two deades. I've always wondered why Github didn't have such basic functionality. (No, just the ability to reference other issues is not enough; I want to get an email for the metabug when all blocking issues are resolved).

tw12312831 2y ago

GitHub was better before MSFT took over. MSFT introduces bureaucratic fluff, hierarchies and loads of unnecessary complexities. How about adding a registry?

shamiln 2y ago
What type of registry? GitHub packages?
- yallpendantools 2y ago
  I would hazard a guess, more in the vein of the much-maligned "Windows Registry". https://en.wikipedia.org/wiki/Windows_Registry https://en.wikipedia.org/wiki/Windows_Registry

vivzkestrel 2y ago

also let people sort repositories by the ratio of open requests to closed requests, average amount of time to respond on an issue

Calzifer 2y ago

Great, a few more decades and it might become a usable bugtracker. What's next on the list? Maybe priority/severity or status/resolution? I helped on a quite large open source project for some time and loved working with Bugzilla. The announced switch to Github for that project was one reason I lost interest. I even prefer to work with a well administrated(!) Jira over Github issues.

StableAlkyne 2y ago
> Maybe priority/severity or status/resolution? That's already possible with the tag system. At least, that's the most common use I see for repos that decide to use tags. How do you envision this differing?
- smarx007 2y ago
  Sorting by priority?
- akoboldfrying 2y ago
  Are you thinking of labels? I only know GitHub "tags" to be the raw git branch-that-never-moves kind.
  - ffsm8 2y ago
    Totally off topic, but Tags can be moved too. ;) It's mostly a convention that we use annotated tags (a tag that also creates a commit) and don't move them
chrisandchris 2y ago
Transitioned from Jira to Gitlab. Jira has workflows/resolution states. Gitlab only has tags. It's a different mindset and a different way to work. I'm not sure I'm happy with only-tags because it puts the work to the end-user (i regularly need to add tags because someone forgot to add it - could not happen with workflows and proper transitions).
IshKebab 2y ago

bnewman85 2y ago

Let us comment on the commit messages and create a better UI for editing messages for teams that take git history seriously, please. Are there no linux kernel devs at msft who can make this happen?

atq2119 2y ago
In the same vein, better reviewability of series of commits. It's absolutely baffling to me that GitHub still doesn't support the original workflow for Git.

decide1000 2y ago

I am not sure if I am going to like this feature. I miss the simplicity. Guess those times re over.

captn3m0 2y ago
I'm remembering the Redmine slide from Zach Holman's talk, where he makes fun of the overly complicated Redmine issue creation screen, compared to what the GitHub screen looked like (back in 2011). Slides 56 and 57 at https://speakerdeck.com/holman/how-github-uses-github-to-build-github?slide=56 https://speakerdeck.com/holman/how-github-uses-github-to-bui...
dacryn 2y ago
same here. I guess it's Microsoft slowly making it cater to their enterprise clients
- foepys 2y ago
  Microsoft is getting ready to replace Azure DevOps with GitHub.
  - alternatex 2y ago
    This is fiction considering Microsoft is extensively using Azure DevOps internally and is still developing it. Moving projects away from it and to GitHub is impossible because they're incredibly far from having feature parity.
    - ciberado 2y ago
      Feature parity is probably not required as long as the different teams are able to adapt their workflow to GitHub's approach. Anecdotally, every employee from Microsoft I've talk to about this point during the last two years keep telling me that ADO is over.
      - stackskipton 2y ago

whataguy 2y ago

They also changed the design of issue comments, but seemingly reverted it back to the old design in production? (If you check the first video on the blog you can see e.g. the profile picture inside of the comment, while the old and current version has it on the outside.)

politelemon 2y ago

The issue types are similar to labels. I wonder why they didn't build on that.

eviks 2y ago

> This means there are no new UI patterns to slow you down, Sure there are, it's a common UI design mistake - you can't do advanced without breaking the basics: previously you could filter your issues with a drop-down filter in 2 clicks. The PR tab still has this (inconsistency) while the new issue requires a worse and longer path that uses a typed field, bringing up you phone keyboard as a downside

maeil 2y ago
Longer paths, especially ones like these that require keyboard input, are especially painful from an accessibility perspective, where for most cases such typed fields make things take exponentially longer than if it can be achieved by just clicks/tabs/arrows.

prymitive 2y ago

There is a huge wall of placeholder being replaced with issues when the issues tab loads, which is pretty annoying when you got used to the old UI. But it’s nice to see M$ can still deliver features without Autocomplete Integration forced in it.

Springtime 2y ago

It's neat there are more options for filtering though ime the new issues UI is less responsive, showing placeholder skeletons more frequently than I'd like. Perhaps less noticeable when a fast connection is always available but even just showing the total Open/Closed ticket counters can take a few seconds when it used to be instant.

stock_toaster 2y ago

From Copilot integration that you can’t disable if you accidentally clicked something once (you can only now as of a few days ago hide the UI, but you are still not able to disable it in settings), to this issues UI aglomeration. The Microsoftization/enshittification of Github continues apace.

paradox460 2y ago

Not bad, but I still have to say that zenhub does it better Used that at an old job and it was the only project management software I didn't grow to hate. Fast, "built into" GitHub, and adds other value across the site, I miss it now at my current jira gig

hamandcheese 2y ago
Big +1, I used zenhub at one of my first jobs and I miss it to this day.
- paradox460 2y ago
  Its one of those things that I will forever evangelize for, because the one time I was able to use it, I had my most productive year ever. My github activity graph for the 18 months I got to use zenhub looked like a beautiful green meadow. I've tried most other project management software. They all stink in one way or another. JIRA is a known problem, ClickUp, Monday, and friends aren't much better. I never liked pivotal, and its dead now, so doesn't really matter. And Github's projects feature is just too spartan to be useful

isodev 2y ago

In other words, GitHub introduces "endless discussions if we're going to use subtasks or sub-issues in our WoW"

celdon25 2y ago
That's a leadership issue
- Y-bar 2y ago
  And even then it affects us all and distracts us from the work we actually want to do.

polycaster 2y ago

I've been waiting so long for this. Finally, we can have Epics that are not a pain in the ass!

shiomiru 2y ago

So that's why they broke loading issue comments without JS. As if the (post-M$) UI hadn't been sluggish enough before...

weinzierl 2y ago

I, for my part, would be happy if they could make basic search work for a start. Will the advanced search finally allow us to find the most basic things reliably?

edflsafoiewq 2y ago
What doesn't work?
- weinzierl 2y ago
  If you search code for a string you know is there it is completely git or miss if it is found. Always has been like that. Also see https://news.ycombinator.com/item?id=35144250 https://news.ycombinator.com/item?id=35144250
  - edflsafoiewq 2y ago
    I assumed you were talking about issue search, since that's what the thread is about.
  - idunnoman1222 2y ago
    Oh yeah, where on the Internet does this work reliably?please don’t say gitlab
    - maeil 2y ago
      Sourcegraph.
    - trollbridge 2y ago
      grep -rli search_this some-repo # (or use rg if you prefer)
      - idunnoman1222 2y ago
        Holy shit what a good idea why doesn’t GitHub just let you use ripgrep?!?!?

hamandcheese 2y ago

A GitHub feature I think would be really handy is suggesting duplicate issues when writing up a new issues. Many projects ask that you search for already reported tickets, but GitHub's current search isn't great if you aren't sure what you are looking for.

deleted 2y ago
[deleted]
hnlmorg 2y ago
Completely agree with this suggestion. Ive often wondered why GitHub hasn’t introduced this feature because it feels like a really obvious thing to introduce and something that would add an immense amount of value to a lot of projects.
- sethops1 2y ago
  Cynical answer: because having users writeup duplicate issues and then having maintainers close them is more engagement than warding off unnecessary toil. Gotta keep those metrics going up and to the right.
  - rafram 2y ago
    GitHub doesn’t have ads and makes its money off of enterprise subscriptions (and Copilot), so I don’t think “engagement” is a very important metric for them.
    - ysavir 2y ago
      To the company, no. But to people trying to get a promotion/bigger budgets by proving the features they work on are getting a lot of usage, plausible.
      - drdaeman 2y ago
        > To the company, no. Why not? Companies love to boast about MAUs and similar metrics (even if completely bogus), it has good effect on stock prices.

joshSzep 2y ago

this happens after I've moved everything to height. downside is it was a lot of work. upside is height is amazing and I'm pleased with the choice. anyone else using it?

mg74 2y ago
what is height?
- matt_kantor 2y ago
  Maybe this? https://height.app/ https://height.app/
quesera 2y ago
> anyone else using it? We're looking for a new home, with Pivotal Tracker shutting down on April 30th (101 days left!). I had not heard of Height before. On first glance, it looks like a genuinely modern project management service -- which is both interesting and unsettling.
- joshSzep 2y ago
  We are loving it and we aren't even using it fully to its ability. For example we do almost no communication in the 'chat' that exists for each issue (in place of comments) since we are a very small team and still are talking mostly in slack about the issues, but I predict as we grow this will become a useful feature for us. In the meantime we are loving the 'every issue can have sub-issues' and have customized the fields to our liking. This is a tool with a lot of power. I can see a well-intentioned PM going crazy with it, but for our needs I was startled with how great it is.

zb3 2y ago

Bring back sorting code search results by date! https://github.com/orgs/community/discussions/52932 https://github.com/orgs/community/discussions/52932

shpx 2y ago

Instead of these features I want them to stop spam issues on my repos. All the issues I've gotten in the last year on my project are completely nonsensical. It's not even spam it's just like random URLs or complete nonsense from freshly created accounts that aren't trying to sell anything or just the issue template. And every time it costs me 2 clicks to click on "report" then I have to type "spam", click the spam category, then I have to type "it's spammmmmmmmmmmmmmmmmmmmmm" to hit the 15 character report description requirement, then I have to solve a captcha. All this despite the fact that I've had a GitHub account for like a decade and I've filed like 30+ spam reports, none of which were frivolous. I opened GitHub after typing this comment and there it was, a notification from an obvious bot account opening an issues that's just 5 meaningless Korean letters with no description.

bsmth 2y ago
It might be worth trying the moderation tools that prevent interactions from accounts less than 24 hours old. Docs here https://docs.github.com/en/communities/moderating-comments-and-conversations/limiting-interactions-in-your-repository https://docs.github.com/en/communities/moderating-comments-a... I share your frustration with this, and in my experience a lot of noise comes from these types of accounts.

javier2 2y ago

I would like it if Github could fix all the bugs with back button (broken browser history) first

riidom 2y ago

Ah this really feels like they could have tackled https://github.com/orgs/community/discussions/4993 https://github.com/orgs/community/discussions/4993 too, what a missed opportunity, I'd love to be notified about some repositories again, which I had to unwatch now because of daily autobuild spam.

akimbostrawman 2y ago

>This means there are no new UI patterns to slow you down, requiring JS to simply view issues begs to differ....

FridgeSeal 2y ago
I look forward to GitHub getting even slower and buggier than it is now.

donatj 2y ago

This seems... unneeded bloat? I guess there are some obsessive organizers out there, but a markdown checklist of steps - potentially with links to other tickets seems like all you need. If you're going to improve something improve code review! Let me comment on and suggest diffs to lines the author did not touch. Like half the time I am reviewing code it is "Hey, you refactored this but you missed a usage in this other file" and right now I have to manually give them file and line number manually and hope for the best.

replete 2y ago
A lot of this will seem trivial if you haven't used Github for an organization's management of issues. This also lets you start off with a markdown checklist, and convert items to sub-issues.
- paulryanrogers 2y ago
  > This also lets you start off with a markdown checklist, and convert items to sub-issues. Wasn't that already possible with Tasklists? We did it using "- [ ] description", then clicking the covert-to-issue hover option.
- donatj 2y ago
  See, but I do. For almost a decade, we have used it as-is for tickets and bug tracking, and it's never been a problem. I just don't see the use case for sub issues.

mikeocool 2y ago

Maybe they’ll add “Closed - won’t fix” and “Closed - stale” statuses next!

edflsafoiewq 2y ago
They already have "Closed as not planned (won't fix, can't repro, stale)". You can use labels for finer granularity if you want.
paulryanrogers 2y ago
There is already close as unplanned, which can serve both if you're flexible

jerrygoyal 2y ago

I've almost stopped using GitHub as I switched over to vscode Github Pull Request Extension.

ttoinou 2y ago

Looks very good. I might switch from Gitlab Issues if I find a tool to convert issues

jxi 2y ago

Strange that issue types is only available if your repository is part of an organization. Why is this not configurable at the repository level?

paulryanrogers 2y ago
To upsell? To maintain consistency among repos? To facilitate use among GH Projects?

sangeeth96 2y ago

I'm curious if there are folks here who work at for-profit orgs who use GitHub projects as their sole issue tracker for the entire org. How do you do it and what are the common pain points? Do you couple it with other issue trackers/project management tools like Jira? If so—why? I still feel GH Projects is solely aimed at OSS or dev-centric or dev-only orgs and doesn't cater to teams with non-devs, which is how I think most orgs function. I'm not sure if it'll ever try to be something more than that but I really wish it did.

jjayj 2y ago
It would be a tough sell for my org to triple our license spend on GHEC just so we can teach a bunch of folks new software.
- sangeeth96 2y ago
  Absolutely. They definitely can't expect to sell this to teams/orgs with non-devs without introducing separate pricing for folks who just want to read/write to projects but maybe read-only for some aspects of a repo.
- eclipticplane 2y ago
  A FOSS plugin to mimic Service Desk on top of Github issues would be great. You'd miss the infinite complexity of Jira workflow configuration, but that might be a good thing.
  - jt_b 2y ago
    Not FOSS, but this is kind of what Zenhub was/is, right?
acjohnson55 2y ago
We did at my previous employer (https://www.ourbranch.com/ https://www.ourbranch.com/) in our data org. I can't totally remember, I'm pretty sure the engineering org did, too. It definitely is lacking in some of the advanced features you get with a Jira, but it was fine. I was surprised by how powerful GitHub Projects is. We also built out extra reporting for it in our data warehouse, using Fivetran for ELT.

the_duke 2y ago

Slowly inching towards something usable for companies / large projects... One big thing missing is resolution status for issues, like "cancelled", "complete", ...

paulryanrogers 2y ago
You can close as complete (default) or unplanned today. It's called the 'reason'.

landsman 2y ago

I am looking forward to project management without Jira!

cloverich 2y ago

I was excited to see this feature pop up in beta, specifically sub issues. VS code organizes their work with parent sprint issues ("iteration plan", see [1]). I started using this pattern on my own project and once i adapted, now prefer it. Now rather than using markdown bullet points, i can use first class sub issues which are slightly less awkward. Ultimately a minor feature addition, but if it pushes more people to use then pattern, i think it would be nice. Lighter weight than proper tools, and imho all you need for moderately complex projects if the suits dont have too many needs / influence. [1]: https://github.com/microsoft/vscode/issues/237297 https://github.com/microsoft/vscode/issues/237297

localghost3000 2y ago

A few jobs back I got “promoted” (honestly I didn’t want it but I digress) to an EM. First thing I did was ditch Jira for GH issues. I was hailed as a hero for it. Unfortunately it ended up being a disaster and we had to switch back a year or so later. These were some of the missing features so pretty exciting.

aklemm 2y ago
You should write Cliff's notes for the Odyssey. What an epic summary.

JensRantil 2y ago

Jens's law: Every ticketing system will eventually become Jira. This is also what is happening with GH issues.

dmd 2y ago
It's worse than that. Every ticketing system will eventually become ServiceNow. Compared to SN, Jira is a breath of fresh air.
- redserk 2y ago
  One more field will solve it!
  - JensRantil 2y ago
    LOL.

maxcruer 2y ago

Behold: GitHub is becoming Jira!

nmstoker 2y ago

I wish they would build features to defend against those near-spam type comments where someone is lazy and appends their clearly unrelated issue onto an existing one that maybe shares a few keywords but nothing substantive. It's not quite spam: there's often a real person behind it with a real issue but they need a (metaphorical) slap before they muddy the waters and disturb countless people already in the conversation.

nmstoker 2y ago
This would be worthwhile for the individuals too - you often find a recurring pattern with all / most of their raised issues and with basic guidance they might up their game (or give up)

andy_ppp 2y ago

When you have issues in different repos but in the same board it seems very confusing that you can create them and then have to assign them to a repo for them to move out of being a Draft issue (well maybe it is not an issue yet rather a task). Maybe I'm using it wrong but I found this pretty strange. Most projects will have a backend and frontend repo certainly when building an app so I think not being able to manage issues against both projects made things a bit strange. Maybe I should use a different blank mono repo just for issues but then I imaging the integration with PRs and commit messages breaks. Additionally I want to be able to have #PROJ-0002 style IDs for tasks, so for example I can add messages for tasks that affect both repos (e.g. "Imported types from GraphQL API into app (#BACKEND-1234, #FRONTEND-1234)") just having numbers is very limited and slightly confusing.

antics 2y ago

I think of GitHub as a sad story. There are probably going to be at least 3 public companies that should have "just" been GitHub features: GitLab (GitHub Enterprise), Sourcegraph (search), and Linear (GitHub Issues). There are dozens of upstarts "unbundling" features of GitHub that are genuinely useful, but which are under-loved and under-invested in, and surely some of those will become successful too. It feels like GitHub continuously invents the future, and then waits for someone else to make it truly great. It is so painful to watch because I love GitHub so much. I graduated college in 2013, which means I started programming right when they got started. I read their dev blog every single day, eagerly waiting for new features (which were released every couple days). I watched their team page grow, I looked carefully at what they did to deserve a spot at such a cool company. I scoured the projects they contributed back to for hints about what good code looked like (my favorite was Vicent Martí's contributions to libgit2). I eagerly taught my friends how to use git because university taught subversion. I wrote my own Rails tutorials as a way to learn the magic. But it's been years now, and it's not an easy love. It's work! It's so painful to watch it get continuously lapped by upstarts. I always just thought the core offerings (Pull Requests and Issues) would get better eventually. And now, 14 years later, they finally are. But very slowly. I really want to believe, but after 16 years, it is starting to sink in that GitHub might just be a place to store files. The magic is still in there. I think there are lots of people like me, who want to believe. But it will take real agency to do it, and that's really hard to muster at this stage in a company's life.

SOLAR_FIELDS 2y ago
FWIW, this specific feature - what they are now calling sub-issues - is actually better described as a framework for modeling proper parent-child relationships in their system, which is something quite hard to get right, mainly because it has to work somehow with the existing issues feature set. People building this feature from scratch (e.g. Linear) have it trivial to solve, because they didn't have any backwards compatibility issue to worry about. This is, of course, absolutely Github's fault for not designing it to accomodate such a thing easily in the first place, but the people who built this feature are probably not the same people who made that original decision. They've been working on some version of this feature for several years now in various iterations. I believe this is either their third or fourth attempt to get it right - I was trialing a beta of some previous iteration of it a few years ago and it was incomplete/not fully well thought out which must be why they dropped it. I'd trust the feature here at least to be decent now, because of how many attempts they've had at it. But yeah if I was a company like Zenhub I would be probably a bit worried at this announcement since it is almost inevitable that this specific feature is going to be enough for people to no longer need third party management of issues. I know in a previous company I worked for that specific feature (proper parent-child relationships) was the reason they used Zenhub, and same for my current company using Linear.

ozim 2y ago

Next thing you know they just reimplement JIRA and everyone starts writing posts how much they hate it.

breatheoften 2y ago

I just wish they'd improve the markdown autocomplete for issues and pull requests ... I'm not sure why it's so bad but even if i know two or three words in the issue title i almost never get the right issue to choose in the autocomplete list while typing in a markdown comment ...

liontwist 2y ago

Corporate customers do pay the bills i suppose.

cratermoon 2y ago

The enjirafication of github continues.

sensanaty 2y ago

Day 50 trillion of begging Github for a functional notification system so I can stop receiving infinite numbers of emails from all the bots and similar things commenting on PRs. Also being designated a codeowner in a large repo, the number of notifications I get daily from the number of PRs is fucking absurd, with no way of turning them off. Drives me up the wall daily. If a colleague doesn't straight up send me a PR in a DM, I'll basically never see it because I've given up on the notification screen a looooong time ago.

christophilus 2y ago
It’s fine for small projects. I clear mine daily, and it’s the sole place I do any communication management.
adsteel_ 2y ago
Have you been able to try trailer.app?
deckar01 2y ago
Doesn’t unwatching a repo limit notifications to mentions and participated threads?
- deleted 2y ago
  [deleted]
- ricardobeat 2y ago
  Codeowners are added as a reviewer to every PR that touches a file under their (team) ownership. In a large codebase it can easily happen that a large % of PRs changes something you're a codeowner for.
blharr 2y ago
It's a workaround, but why not use email filters for this?
- sensanaty 2y ago

xyst 2y ago

They have time to work on this micromanagement feature yet can't fix the broken conversation workflow when reviewing PRs. Smh.

carwyn 2y ago

The sub-issues are good, with more relationship types coming (dependencies, not just parent-child). The better search is welcome. However there are some questions for me in relation to the overall semantics of labels, issue types and project fields. Labels are repo only and multi valued. Issue types are organisation wide and single valued, project fields are the richest, but no multi-valued option, and they end up in a disjointed place in the API (you can't get at them easily when what you have is the issue, you have to go in via the project). An example of this disjointed feeling it that there are no "issue type"s for a PR. This means that if you want to share metadata between PR and Issues, you have to use labels anyway. I do wonder if types could have been better implemented as namespaces for labels. This combined with being able to have organisation or repo context label namespaces would have allowed for far more flexibility. The other thing that vanished from the public roadmap amongst all this was support for better workflows. Currently there's no easy way to create allowed state transitions between metadata state (e.g in a project stop issues being able to skip the QA status). The attention this area is getting is welcome, and there are many good things in there, but it does feel a bit disjointed. A more unified metadata model would be welcome.

tehbeard 2y ago

Ah, thought something had changed. Been rather use to the key combo for inverting filtering on issues (E.g. show all issues without a particular label)... That seems to have been nuked.