Live data from Hacker News

GitHub introduces sub-issues, issue types and advanced search

github.blog

171–180 of 213 posts

Re: GitHub introduces sub-issues, issue types and advanced search

#171
post #159
post #158

Earlier quoted context omitted.

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,…

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 p…

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

Re: GitHub introduces sub-issues, issue types and advanced search

#172
post #155

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…

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

Re: GitHub introduces sub-issues, issue types and advanced search

#173
post #155

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 is a hugely successful company. They make a shit load of money. Your idea of success is not in congruence with actual success.

Re: GitHub introduces sub-issues, issue types and advanced search

#174
post #160

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

It's worse than that. Every ticketing system will eventually become ServiceNow. Compared to SN, Jira is a breath of fresh air.

One more field will solve it!

Re: GitHub introduces sub-issues, issue types and advanced search

#175

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?

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

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.

Re: GitHub introduces sub-issues, issue types and advanced search

#176
post #171
post #159

Earlier quoted context omitted.

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 p…

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

Re: GitHub introduces sub-issues, issue types and advanced search

#177
post #155

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…

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 co…

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

Re: GitHub introduces sub-issues, issue types and advanced search

#178

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.

If we're talking issues (i.e. reports from external parties, like OSS users, and not internally defined tasks), then care is needed to avoid it working out like the Stack Overflow experience. What is it, you ask?

[Closed; Locked: not constructive; Duplicate of: #1701, #74656]

Users will fight such things for a simple reason: every larger OSS project has tons of open[0] issues that look like duplicates, and perhaps even are duplicates, but no one can tell because they're all ~forever old and unresolved, so new people keep adding them again to bring attention to them.

Perhaps Github should start sorting issues by "Last updated" instead of the issue number - then some of the duplicate reports would just turn into "+1"s and "bump!"s on the existing issues.

--

[0] - Or closed by stale bot, which is effectively still open, but with an insult on top.

Re: GitHub introduces sub-issues, issue types and advanced search

#180
post #9

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.

IDK, but maybe, for the sake of people working in projects that are managed using Github/Gitlab issues, they'll spin off a separate "Tasks" features and allow to set dependencies on them.
Post reply on HN