Live data from Hacker News

GitHub introduces sub-issues, issue types and advanced search

github.blog

181–190 of 213 posts

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

#181
Day 50 trillion of begging Github for a functional notification system so I can stop receiving infinite numbers of emails from all the bots and similar things commenting on PRs.

Also being designated a codeowner in a large repo, the number of notifications I get daily from the number of PRs is fucking absurd, with no way of turning them off. Drives me up the wall daily. If a colleague doesn't straight up send me a PR in a DM, I'll basically never see it because I've given up on the notification screen a looooong time ago.

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

#182

Earlier quoted context omitted.

> well administrated Jira Based on my experience that doesn't exist. Hell even if it did, Jira is sooooo unbelievably slow I would still take literally anything else. Maybe even Savannah. A colleague joked that we need a "waiting for Jira" Jira task.

I think 99% of the problems with Jira stem from trying to use it for too many things at the same time. If it's used for tracking issues, it's great. If a team just uses it for keeping track of its ongoing work, it ok. If the team also uses it to plan work, it works less well. If management also uses it to keep track of what the team is doing, it works even less well, because now the team needs to put on a show for ma…

> At this point, the team (which still needs to track its issues and ongoing work) likely has a secret second issue tracker via post-it notes on a door somewhere.

This. In my case, it was the whiteboard. It was at a place I worked ~decade ago, where everyone was using Jira for the official work management. That included management, but also included everyone in the electronics production and assembly branch of the company, so it was funny to compare our meticulously described sprint items with co-workers burning through dozens of entries a day, named by just long incrementing numbers.

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

#183
post #78

Earlier quoted context omitted.

To the company, no. But to people trying to get a promotion/bigger budgets by proving the features they work on are getting a lot of usage, plausible.

> To the company, no. Why not? Companies love to boast about MAUs and similar metrics (even if completely bogus), it has good effect on stock prices.

Those are very general stats. They won't drop just because they disincentivize abuse of issues or pull requests.

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

#185
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…

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

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

#186
The sub-issues are good, with more relationship types coming (dependencies, not just parent-child). The better search is welcome. However there are some questions for me in relation to the overall semantics of labels, issue types and project fields.

Labels are repo only and multi valued. Issue types are organisation wide and single valued, project fields are the richest, but no multi-valued option, and they end up in a disjointed place in the API (you can't get at them easily when what you have is the issue, you have to go in via the project).

An example of this disjointed feeling it that there are no "issue type"s for a PR. This means that if you want to share metadata between PR and Issues, you have to use labels anyway.

I do wonder if types could have been better implemented as namespaces for labels. This combined with being able to have organisation or repo context label namespaces would have allowed for far more flexibility.

The other thing that vanished from the public roadmap amongst all this was support for better workflows. Currently there's no easy way to create allowed state transitions between metadata state (e.g in a project stop issues being able to skip the QA status).

The attention this area is getting is welcome, and there are many good things in there, but it does feel a bit disjointed. A more unified metadata model would be welcome.

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

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

Jira is so abominably slow, that it should be laughed/shamed out of the room in any discussion of useful software.

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

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

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

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

#190

Earlier quoted context omitted.

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

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?
Post reply on HN