Having worked in a shop that used GitLab issues for project management, I've come to realize GitHub-style issue trackers work if all your project management boils down to creating and tracking bite-sized blobs of work. It stops being sufficient when you need to actually plan ahead. FWIW, so does Trello. Couple reasons why:
- Issues are flat. Work breaks down into a tree. And no, "epic / ticket / checkboxes in task" is not enough, that's barely two and a half levels. Compare with https://en.wikipedia.org/wiki/Work_breakdown_structure [0].
- Issues are independent. Properly broken down, work in a project has dependencies. That turns a tree of tasks into a directed acyclic graph of tasks - work items depend on other items, often items from different areas in the WBS.
- Issues don't schedule well. Most issue trackers I've seen don't support simultaneously entering planned start/end dates, actual start/end dates, and actual work being done. This means they can't be effectively used to estimate the length of the project, and update that estimate as the project progresses. Forget about any auto-scheduling.
There's a reason why old-school PMs love their Gantt charts so much - they properly reflect the graph-like nature of work, and they let you see the information crucial for planning at a glance.
In my opinion, any system that doesn't support entering DAGs of tasks with planned manual and automatic dates (e.g. "this task will take ~5 days, and starts when that other task ends"), and doesn't allow you to compute the critical path, is not a project management tool, but a glorified TODO list. A good PM tool does what I've outlined above, plus it lets you easily run what-if analysis - that is, play around with estimates, resource availability, task ordering, to explore the space of possible project plans and possible failure modes.
So, in my opinion, neither GitHub/GitLab issues, nor Trello or other Kanban boards, are useful for PM work. I've heard that properly configured Jira just might be. MS Project is a good one, if you ignore its clunky UI and propensity to randomly lock up for no reason.
--
[0] - Even where the Wiki says "For most projects a hierarchy of two to four levels will suffice.", this is in context of "lowest level of detail of the WBS should be longer than a single reporting period", which would be typically a month or more. Tickets in the issue tracker are thus a level below that. So, to properly break a project down, you need ~2-4 levels of structure above your tickets.