I just wish they'd improve the markdown autocomplete for issues and pull requests ... I'm not sure why it's so bad but even if i know two or three words in the issue title i almost never get the right issue to choose in the autocomplete list while typing in a markdown comment ...
GitHub introduces sub-issues, issue types and advanced search
161–170 of 213 posts
Re: GitHub introduces sub-issues, issue types and advanced search
#162I 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…
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.
Re: GitHub introduces sub-issues, issue types and advanced search
#163Corporate customers do pay the bills i suppose.
Re: GitHub introduces sub-issues, issue types and advanced search
#164I 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…
> 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).
I don't agree, and I cannot understand what train of thought would lead to conclude that each individual feature that's a crucial part of any developer's workflow should be broken down to external companies without any good reason at all.
Any developer's workflow consists of a) ticketing, b) revision control, c) auditing code and change history, d) CICD. Obviously a) b) and c) are tightly coupled and you cannot have one without the other, whereas d) invariably leads to a) b) and c) in any incident response scenario. There is no argument that justifies any alternative to a unified developer experience.
Re: GitHub introduces sub-issues, issue types and advanced search
#165The enjirafication of github continues.
Re: GitHub introduces sub-issues, issue types and advanced search
#166I 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…
> 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). I don't agree, and I cannot understand what train of thought would lead to conclude that each individual feature that's a crucial part of any developer's workflow should be broken down to external companies without any good reason at a…
I feel like ticketing is something that has been pasted on for corporate reasons.
Keeping track of the work to be done doesn't require a ticketing system,
anyone remember using Story Cards? A whiteboard?
Re: GitHub introduces sub-issues, issue types and advanced search
#167I 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…
> 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). I don't agree, and I cannot understand what train of thought would lead to conclude that each individual feature that's a crucial part of any developer's workflow should be broken down to external companies without any good reason at a…
Sorry if this was not clear, but I am not making a normative statement that each feature should be broken out into its own tool. I'm saying that the revenue ramp on each these products is, empirically, good enough to be on track to IPO. So GitHub is apparently doing a bad enough job in each of those areas that three separate companies were able to break a feature out into a dedicated product, sell it on its own, and ramp revenue fast enough to support a venture class business. Absolutely wild stuff.
Re: GitHub introduces sub-issues, issue types and advanced search
#168Earlier quoted context omitted.
> 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). I don't agree, and I cannot understand what train of thought would lead to conclude that each individual feature that's a crucial part of any developer's workflow should be broken down to external companies without any good reason at a…
I feel like ticketing is something that has been pasted on for corporate reasons. Keeping track of the work to be done doesn't require a ticketing system, anyone remember using Story Cards? A whiteboard?
I hate bureaucracy and will actively question the necessity of any imposition of bureaucracy, and resist its imposition if it doesn't seem justified.
Nonetheless, there is use to more than just sticky notes. It tends to come with scale, and trying to coordinate and align teams of teams of teams of teams, etc.
Additionally, sticky notes are impractical for remote teams (would there be some always-on webcam pointed at them?)
Re: GitHub introduces sub-issues, issue types and advanced search
#169Earlier quoted context omitted.
That's not how it works. It is going the way of Jira. What you mean is if it keeps going that way it will be Jira. Until we get to the point we can decide things are finished and move on to other problems, everything will turn into Jira eventually. It's like entropy. We have the power to stop it, but it wouldn't guarantee those sweet, sweet growth targets.
The problem is Microsoft has two products in this space but everyone hates Azure DevOps which is supposed to be a JIRA competitor and GitHub is where all the momentum is. They'd love to ditch having to maintain ADO and GitHub long term but that means crapifying GitHub so they can migrate their ADO customers. At the same time they're hoping to pull Atlassian customers that use JIRA and GitHub to ditch the latter and j…
ADO almost made me want to use Jira instead.
Turned out that,
while the product it not great,
the pain I experienced using it had more to do with corporate processes than the software itself.
Re: GitHub introduces sub-issues, issue types and advanced search
#170Earlier quoted context omitted.
> 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). I don't agree, and I cannot understand what train of thought would lead to conclude that each individual feature that's a crucial part of any developer's workflow should be broken down to external companies without any good reason at a…
I feel like ticketing is something that has been pasted on for corporate reasons. Keeping track of the work to be done doesn't require a ticketing system, anyone remember using Story Cards? A whiteboard?
Well, if they wanted to implement keeping track of work to be done, they'd have long ago implemented subissues, sub-subissues, and sub^n-issues, because obviously work does not break down into a list, or a one-level-deep tree - the natural data structure for breaking down work is a directed graph (and if you really must do an 80/20 on it, then a tree).
Sadly, to this day, out of popular software packages used in software companies, only Microsoft Project and maybe Jira get this right. Unfortunately, they have plethora of unrelated issues that are big enough that they drive the industry towards silliness of managing work in tools like Trello or Github/Gitlab issues.
EDIT: I sometimes wonder how much of how Agile implementations look is a consequence of simplistic tooling. When your team's work planner is fundamentally unable to represent the basic idea that tasks can depend on other tasks, you can't really plan ahead much further than a sprint. So is the Agile cadence really about avoiding the Folly of the Waterfall, or is it just shitty tooling that makes it exponentially hard to think ahead for more than two weeks? Did we invent "epics" because we can't link together multiple tasks on a Kanban board?
And then, how many companies SCRUM the living hell out of their developers, while PMs secretly plan the whole thing ahead in MS Project to keep the project on track towards some goal, and then pray no one on the dev team spots a Gantt chart open on their screen?
(Personally, I worked under one once; they begrudgingly admitted to managing everything in MS Project once I started asking if I can get a license, because even Emacs Org Mode sucks at the job if the job is to break down month's worth of work on entire deliverable.)
EDIT2:
> Keeping track of the work to be done doesn't require a ticketing system, anyone remember using Story Cards? A whiteboard?
Anyone remembers a project plan? Work breakdown structure? I know PERT looks to people like a Borg Cube, but then the status quo in software dev looks like Pakled technology. "We are devs. We scrum. Trello make us go!"