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.

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.

> 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.

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.

> 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).

I don't agree, and I cannot understand what train of thought would lead to conclude that each individual feature that's a crucial part of any developer's workflow should be broken down to external companies without any good reason at all.

Any developer's workflow consists of a) ticketing, b) revision control, c) auditing code and change history, d) CICD. Obviously a) b) and c) are tightly coupled and you cannot have one without the other, whereas d) invariably leads to a) b) and c) in any incident response scenario. There is no argument that justifies any alternative to a unified developer experience.

Sorry if this was not clear, but I am not making a normative statement that each feature should be broken out into its own tool. I'm saying that the revenue ramp on each these products is, empirically, good enough to be on track to IPO. So GitHub is apparently doing a bad enough job in each of those areas that three separate companies were able to break a feature out into a dedicated product, sell it on its own, and ramp revenue fast enough to support a venture class business. Absolutely wild stuff.

Well, if they wanted to implement keeping track of work to be done, they'd have long ago implemented subissues, sub-subissues, and sub^n-issues, because obviously work does not break down into a list, or a one-level-deep tree - the natural data structure for breaking down work is a directed graph (and if you really must do an 80/20 on it, then a tree).

Sadly, to this day, out of popular software packages used in software companies, only Microsoft Project and maybe Jira get this right. Unfortunately, they have plethora of unrelated issues that are big enough that they drive the industry towards silliness of managing work in tools like Trello or Github/Gitlab issues.

EDIT: I sometimes wonder how much of how Agile implementations look is a consequence of simplistic tooling. When your team's work planner is fundamentally unable to represent the basic idea that tasks can depend on other tasks, you can't really plan ahead much further than a sprint. So is the Agile cadence really about avoiding the Folly of the Waterfall, or is it just shitty tooling that makes it exponentially hard to think ahead for more than two weeks? Did we invent "epics" because we can't link together multiple tasks on a Kanban board?

And then, how many companies SCRUM the living hell out of their developers, while PMs secretly plan the whole thing ahead in MS Project to keep the project on track towards some goal, and then pray no one on the dev team spots a Gantt chart open on their screen?

(Personally, I worked under one once; they begrudgingly admitted to managing everything in MS Project once I started asking if I can get a license, because even Emacs Org Mode sucks at the job if the job is to break down month's worth of work on entire deliverable.)

EDIT2:

> Keeping track of the work to be done doesn't require a ticketing system, anyone remember using Story Cards? A whiteboard?

Anyone remembers a project plan? Work breakdown structure? I know PERT looks to people like a Borg Cube, but then the status quo in software dev looks like Pakled technology. "We are devs. We scrum. Trello make us go!"

I wouldn’t say Jira gets it right.

I find its subtasks a little half baked and I feel like portions of Jira weren’t designed with sub-tasks in mind. We actually avoid them completely at my current work.

It’s understandable why a lot of systems don’t support sub-tasks. Hierarchical data structures are not the easiest to deal with and come with a litany of edge cases. It can also be quite overwhelming UX wise.

> I feel like portions of Jira weren’t designed with sub-tasks in mind

That's true, and I can see why you avoid them. Last time I touched Jira, I quickly learned that subtasks are annoying.

Dependency releationships between tasks are more general and better overall. Unfortunately,

> Hierarchical data structures are not the easiest to deal with and come with a litany of edge cases. It can also be quite overwhelming UX wise.

Don't know of any software that fully figured it out. Even MS Project, which does the relationship and scheduling parts a-ok, is a PITA to use in general, and has some pretty annoying bugs that made me stop using it. Being able to irrecoverably brick the auto-scheduler and have it suddenly crash on opening the project file is a kind of show-stopper.

Another tricky challenge here is scope. Planning, scheduling and doing are three different mindsets, and it's tough to balance them all in a single tool. Someone who figures out how to do it well stands to make a lot of money.

> I sometimes wonder how much of how Agile implementations look is a consequence of simplistic tooling. When your team's work planner is fundamentally unable to represent the basic idea that tasks can depend on other tasks

In the agile world it's accepted that a task that today looks like it depends on another task may not have that dependency next week. Planning involves scheduling what the stakeholders prioritize now that can be done, and whatever lands in the "we can't do that until we do other thing" doesn't even get scheduled.

> Planning involves scheduling what the stakeholders prioritize now that can be done, and whatever lands in the "we can't do that until we do other thing" doesn't even get scheduled.

Planning and scheduling/prioritizing are two distinct processes people often confuse. Planning is about identifying what needs to be done, and breaking it down into a network of tasks joined by dependencies. Scheduling is figuring out who's going to do what and when they're going to do it.

Planning is figuring out your service needs e-mail verification, password reset, and some transactional messages, to stuff like "design e-mail templates" "write templates for {verification, reset, account confirmation} e-mails", "set up infra for sending e-mails", "add {verification, reset} URL flows", "make it send {verification, reset, confirmation} e-mail on {{relevant action}}", etc. Scheduling is me assigning "design e-mail templates" to Joe in graphics dept. and giving him 3 days for it, assigning you the "set up infra" task and giving you a week, and knowing the "make it send ..." tasks won't start until next sprint, at which point we'll find someone to do them, etc.

In naive Agile reality, while <<whatever lands in the "we can't do that until we do other thing" doesn't even get scheduled>>, it gets recorded somewhere (e.g. product backlog), but it won't have its dependency relationship encoded. So every sprint, someone goes over a heap of such tasks, and has to manually reconstruct those relationships, to the degree it lets them plan out the next sprint or two. This both adds work and limits the ability to plan forward (you ain't going to be even thinking about stuff that's obviously beyond the horizon).

While it's true that stakeholder priorities change (as they should), and this affects scheduling, it affects planning much less, as the dependencies aren't about order in time, they're about order in execution. Dependencies aren't volatile - no matter what the stakeholders think this week, you won't be able to work on "make it send emails" until you can send e-mails (infra task) and have e-mails to send (design/write) and have them be useful (endpoints/routes for links). This is useful information to have encoded, particularly with more interdependent features - not only the system will help you do the scheduling correctly, it'll also let you quickly tell that unscheduling work on X now will delay work on Y down the line, etc.

Planning and scheduling/prioritizing are split into separate things by people who think less about shipping working code and more about counting beans.

Shipping working code is a means to an end, not end unto itself. Planning and scheduling/prioritizing are split into separate things by people who think about and then tell the people shipping working code what they should be writing and shipping.

I hate bureaucracy and will actively question the necessity of any imposition of bureaucracy, and resist its imposition if it doesn't seem justified.

Nonetheless, there is use to more than just sticky notes. It tends to come with scale, and trying to coordinate and align teams of teams of teams of teams, etc.

Additionally, sticky notes are impractical for remote teams (would there be some always-on webcam pointed at them?)

Don’t forget code review. I created CodeApprove, but there are so many other good alternatives that could have been GitHub features (Graphite, CodePeer, Reviewable, etc).

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.

> 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

That's a wrong framework to use. Parent/child relationship is a special case of dependencies between tasks, which can be more generally modeled as start/finish relationships, i.e. one of: Start-to-Start, Start-to-Finish, Finish-to-Start and Finish-to-Finish; parent-child relationship is Finish-to-Finish here. This distinction starts to matter if you want to plan out more work items than you can quickly eyeball on a Kanban board, and it's all well-trodden ground with nearly century worth of prior art, to which our entire industry is entirely oblivious.

Useful search terms: PERT, Gantt charts, critical path, PMBOK.

Popular software occasionally spotted in use in our industry (usually by PMs, in secret) that supports it: MS Project, maybe Jira, ... is there anything else?

Once you have sizing, the ability to make an issue dependent, estimated start / end, don’t you have everything needed to generate a PERT / Gantt chart?

You also need the proper dependency types[0] I mentioned, though I'd say you can get away with FS for dependencies and FF for subtasks.

Beyond merely generating a Gantt chart, when you have dependencies and estimated duration you can start estimating how long things will take and which ones can take longer or be delayed without impacting overall project time; add the ability to provide constraints on start and end time, and you can automatically schedule work (and re-schedule at it happens).

Most of these things are in every system in some form or other, but dependencies seem to be missing almost everywhere - and dependencies are the one key component that enable major benefits and turn the system into a proper project planning tool.

--

[0] - https://en.wikipedia.org/wiki/Dependency_(project_management...

Sorry, the goal here is not to trivialize GitHub, or suggest they suck at engineering, or even to say this is easy. I am just saying my own perspective, which is that I wish the core properties (pull requests, issues) had improved a long time ago. I have been a maintainer of a top 0.01% project, and I have seen it get in the way where other tools would have been tolerable. It hasn't always been easy to be a fan.

GitHub is a hugely successful company. They make a shit load of money. Your idea of success is not in congruence with actual success.

Ok, let's try from another angle. Close your eyes and picture the ideal, best, most successful product in this space, for whatever definitions those words mean to you.

Everyone is different, but I think most people would not picture a source control product where search, issues, and on-prem are each so terrible, the default solution for that feature is to use a completely different product from a totally different company, which solves that specific issue (Sourcegraph, Linear, GitLab, respectively).

> I started programming right when they got started.

Then let me tell you about SourceForge. SourceForge, around the time that GitHub started, had a lot of these features (or at least, the ones that were standard practice at the time). It was the de facto home of open source software development at the time, but it was also a megalith that tried to do everything.

GitHub was a breath of fresh air precisely because it had just the right balance of minimalism and features. There were plenty of truly minimalist hosts out there, so we didn't need any more of those. But we also had lots of bloated and slow code hosts. And it deserves to be stressed that the bloated ones were just as unusable as the minimalist ones, even while being (again, for the time) as feature-complete as they come.

Bloated products can't pivot. New features often don't integrate well with existing ones, and they take a long time to develop. We're seeing this with GitHub too, as feature velocity has dropped. But the difference is that GitHub's feature set, particularly their core initial feature set, was exceptionally well designed. They've lost a bit of this edge over time, but overall I think they've done a well enough job of balancing the thoughtfulness of their build-out with doing things at a reasonable speed.

I just want to emphasize this point because I think it gets lost, especially if you're not familiar with what the competition of the time looked like. GitHub absolutely would not have made it to where it is today if they had rushed to add features. For a comparison of what it looks like to build features first and put design on the back burner, see GitLab. There's a reason why I still find their product difficult to navigate despite it being one of the main tools I use in my day-to-day work. And I fear that if anything, GitHub is succumbing to the lure of feature count and becoming its own bloated monolith over time, even with their slow pace.