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.
GitHub introduces sub-issues, issue types and advanced search
181–190 of 213 posts
Re: GitHub introduces sub-issues, issue types and advanced search
#182Earlier 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…
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
#183Earlier 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.
Re: GitHub introduces sub-issues, issue types and advanced search
#184Smh.
Re: GitHub introduces sub-issues, issue types and advanced search
#185I 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…
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
#186Labels 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
#187Great, 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.
Re: GitHub introduces sub-issues, issue types and advanced search
#188>This means there are no new UI patterns to slow you down, requiring JS to simply view issues begs to differ....
Re: GitHub introduces sub-issues, issue types and advanced search
#189I 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.
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
#190Earlier 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-…