[SOLAR_FIELDS]

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.

[TeMPOraL]

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

[ec109685]

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?

[TeMPOraL]

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

[antics]

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.