GitHub introduces sub-issues, issue types and advanced search
1–10 of 213 posts
Re: GitHub introduces sub-issues, issue types and advanced search
#2Nice additions - Buganizer has had these for years.
Good that issue types can be user defined.
Re: GitHub introduces sub-issues, issue types and advanced search
#3The sub-issue structure seems much better than Jira's approach where everything has to fit into a hierarchy. Then it becomes hard to align on the definition of a certain level in the hierarchy.
This create-a-subissue-when-needed way is more sensible.
Re: GitHub introduces sub-issues, issue types and advanced search
#4The sub-issue structure seems much better than Jira's approach where everything has to fit into a hierarchy. Then it becomes hard to align on the definition of a certain level in the hierarchy. This create-a-subissue-when-needed way is more sensible.
It's also not that different from what people have been using Task Lists for today: https://docs.github.com/en/get-started/writing-on-github/wor...
I think that's maybe my biggest question is what the interop looks like between Task Lists and Sub-Issues. Is there a "one-click upgrade" yet? What if I want to copy a list of Sub-Issues as Markdown Task List to copy into a Discussion or a Wiki somewhere?
Re: GitHub introduces sub-issues, issue types and advanced search
#5Great, but I would've been happier if I'd had some dead simple dependency tracking 10 years ago.
Just enough to create metabug functionality with. Like Bugzilla, Trac, Mantis etc have sported for at least two deades. I've always wondered why Github didn't have such basic functionality. (No, just the ability to reference other issues is not enough; I want to get an email for the metabug when all blocking issues are resolved).
Re: GitHub introduces sub-issues, issue types and advanced search
#6GitHub was better before MSFT took over. MSFT introduces bureaucratic fluff, hierarchies and loads of unnecessary complexities. How about adding a registry?
Re: GitHub introduces sub-issues, issue types and advanced search
#7The sub-issue structure seems much better than Jira's approach where everything has to fit into a hierarchy. Then it becomes hard to align on the definition of a certain level in the hierarchy. This create-a-subissue-when-needed way is more sensible.
You can use a single type of issue in Jira and just rely on linking them together
Re: GitHub introduces sub-issues, issue types and advanced search
#8also let people sort repositories by the ratio of open requests to closed requests, average amount of time to respond on an issue
Re: GitHub introduces sub-issues, issue types and advanced search
#9Great, 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
#10Great, 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.
> Maybe priority/severity or status/resolution?
That's already possible with the tag system. At least, that's the most common use I see for repos that decide to use tags.
How do you envision this differing?