Let us comment on the commit messages and create a better UI for editing messages for teams that take git history seriously, please. Are there no linux kernel devs at msft who can make this happen?
GitHub introduces sub-issues, issue types and advanced search
11–20 of 213 posts
Re: GitHub introduces sub-issues, issue types and advanced search
#12I am not sure if I am going to like this feature. I miss the simplicity. Guess those times re over.
Re: GitHub introduces sub-issues, issue types and advanced search
#13The 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
Wow i didn't know that.
Re: GitHub introduces sub-issues, issue types and advanced search
#14They also changed the design of issue comments, but seemingly reverted it back to the old design in production? (If you check the first video on the blog you can see e.g. the profile picture inside of the comment, while the old and current version has it on the outside.)
Re: GitHub introduces sub-issues, issue types and advanced search
#15I am not sure if I am going to like this feature. I miss the simplicity. Guess those times re over.
I'm remembering the Redmine slide from Zach Holman's talk, where he makes fun of the overly complicated Redmine issue creation screen, compared to what the GitHub screen looked like (back in 2011).
Slides 56 and 57 at https://speakerdeck.com/holman/how-github-uses-github-to-bui...
Re: GitHub introduces sub-issues, issue types and advanced search
#16Great, 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.
Transitioned from Jira to Gitlab. Jira has workflows/resolution states. Gitlab only has tags.
It's a different mindset and a different way to work. I'm not sure I'm happy with only-tags because it puts the work to the end-user (i regularly need to add tags because someone forgot to add it - could not happen with workflows and proper transitions).
Re: GitHub introduces sub-issues, issue types and advanced search
#17> This means there are no new UI patterns to slow you down,
Sure there are, it's a common UI design mistake - you can't do advanced without breaking the basics: previously you could filter your issues with a drop-down filter in 2 clicks. The PR tab still has this (inconsistency) while the new issue requires a worse and longer path that uses a typed field, bringing up you phone keyboard as a downside
Re: GitHub introduces sub-issues, issue types and advanced search
#18Great, 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.
Re: GitHub introduces sub-issues, issue types and advanced search
#19There is a huge wall of placeholder being replaced with issues when the issues tab loads, which is pretty annoying when you got used to the old UI.
But it’s nice to see M$ can still deliver features without Autocomplete Integration forced in it.
Re: GitHub introduces sub-issues, issue types and advanced search
#20The 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
Yeah we ended up doing this. You should basically never use Epics or Subtasks in Jira because they have weird unnecessary restrictions that don't apply to normal tasks, especially around putting them in sprints.