[btown]

I like GitHub precisely because it didn't try to capture the entire market of issue trackers and code search too aggressively.

If GitHub sub-issues had existed even in an inferior form back in 2019, developer-targeted trackers like Linear and Shortcut would have had a hard time existing, and all of their ideas (some of which have advised the UX of today's GitHub sub-issues release!) would have been lost to time.

Now, perhaps this was not value-maximizing to Microsoft, or value-maximizing to companies who now need an extra license for Linear - but I would argue that for actual developer experience, GitHub fostering a spirit of innovation through its own stagnation has created a vibrant ecosystem better than anything any company could do themselves.

[antics]

Yes this is one of the reasons this discussion is so tricky. I just believe that if I maintain a popular project on GitHub I should not be automatically consigned to worst-in-class experiences for Issues and code review. I understand this is mildly controversial but I have had maintainer status on a few top 0.01% GitHub repositories and I have seen tools that do not suck, and so my opinion is that a better world is possible.

Again, I say all of this entirely with love. I love GitHub. I have used GitHub since I started programming. I want them to win.

[habosa]

> automatically consigned to worst-in-class experiences

You said it perfectly. This is why there are a lot of people willing to create better experiences on top of GitHub’s API.

I created CodeApprove (https://codeapprove.com) to improve GitHub’s code review and there’s also Graphite, CodePeer, Reviewable, and others doing a great job.

[TeMPOraL]

Any of them support dependencies between issues? Without it, it's still all worst-in-class experience for the purpose of managing work. Yes, this is distinct from issue tracking, which is an input, and usually external, but people seem to have this weird habit of trying to manage software projects using GitHub or GitLab issues.