In other words, GitHub introduces "endless discussions if we're going to use subtasks or sub-issues in our WoW"
GitHub introduces sub-issues, issue types and advanced search
31–40 of 213 posts
Re: GitHub introduces sub-issues, issue types and advanced search
#32Earlier quoted context omitted.
I can handle these 3 changes but if they take it any further it's going the way of jira..
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 just entirely be on GitHub.
What well end up with is a service that sucks to use for all cases.
Re: GitHub introduces sub-issues, issue types and advanced search
#33In other words, GitHub introduces "endless discussions if we're going to use subtasks or sub-issues in our WoW"
That's a leadership issue
Re: GitHub introduces sub-issues, issue types and advanced search
#34Re: GitHub introduces sub-issues, issue types and advanced search
#35I've been waiting so long for this. Finally, we can have Epics that are not a pain in the ass!
Re: GitHub introduces sub-issues, issue types and advanced search
#36Earlier quoted context omitted.
same here. I guess it's Microsoft slowly making it cater to their enterprise clients
Microsoft is getting ready to replace Azure DevOps with GitHub.
This is fiction considering Microsoft is extensively using Azure DevOps internally and is still developing it. Moving projects away from it and to GitHub is impossible because they're incredibly far from having feature parity.
Re: GitHub introduces sub-issues, issue types and advanced search
#37Great, 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.
> 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 management with the tool it needs to track and plan its work. Now issues need to be phrased in a way so that they aren't causing outsiders to worry. Maybe don't say "problem" or "bug" so often. Use an euphemism. Can't we word it in a less concerning way?
If upper management has a dashboard of all departments' boards, you get nested Potemkin villages where the jira tasks are performative for both middle management, who in turn try to dress things up even more for upper management. 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.
Re: GitHub introduces sub-issues, issue types and advanced search
#38Earlier 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…
[deleted]
Re: GitHub introduces sub-issues, issue types and advanced search
#39So that's why they broke loading issue comments without JS. As if the (post-M$) UI hadn't been sluggish enough before...
Re: GitHub introduces sub-issues, issue types and advanced search
#40Earlier quoted context omitted.
I can handle these 3 changes but if they take it any further it's going the way of jira..
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.
Lots of ideas above, rather speculative.
Overall, the claim above, as written, is a rather generalized prediction, not an inevitability.
Enterprise buying power and expectations create various pressures, sure. But there are other pressures and factors that need to be accounted for such as demands from other types of customers and the company’s expertise with what has worked well so far (simpler is better, compared to Jira).
Entropy is a law of physics, sure, but the ways and degrees to which it manifests in software is far from obvious or inevitable.
We live in a world of possible future scenarios, not of narrative-based certainties.
I predict GitHub Issues will remain considerably simpler than Jira for the next five years at least. As code analysis tools improve (traditional static analysis as well as LLM-based), I think we will see a lot of experimentation in this space.