Live data from Hacker News

New GitHub Issues Beta

github.com

101–110 of 223 posts

Re: New GitHub Issues Beta

#101
post #9

I wonder how tense things are over at Atlassian right now. Jira seems so universally hated that it feels like any competition that ticks a few basic needs could start hurting them.

first step of any agile transformation is to get yourself neck deep into atlassian products. 2nd step is to setup complex JIRA workflows and reporting and use it to break all agile principles. third step is for your devs to take none of this seriously and put fake data into JIRA which your middle managers never catch onto. then your engineers who actually want to get shit done leave and you're left only with people w…

This is gold. I’m one of those engineers who left. But I didn’t leave before creating this tool for others who were staying behind. It automatically reassigns your JIRA tickets to someone else. Very handy right before stand ups and scrum of scrums where they look at who has the most open tickets.

The goodbye email where I linked to this was the highlight of my career.

https://github.com/jmathai/all-hands-on-deck

Re: New GitHub Issues Beta

#102

Earlier quoted context omitted.

first step of any agile transformation is to get yourself neck deep into atlassian products. 2nd step is to setup complex JIRA workflows and reporting and use it to break all agile principles. third step is for your devs to take none of this seriously and put fake data into JIRA which your middle managers never catch onto. then your engineers who actually want to get shit done leave and you're left only with people w…

This is gold. I’m one of those engineers who left. But I didn’t leave before creating this tool for others who were staying behind. It automatically reassigns your JIRA tickets to someone else. Very handy right before stand ups and scrum of scrums where they look at who has the most open tickets. The goodbye email where I linked to this was the highlight of my career. https://github.com/jmathai/all-hands-on-deck

[deleted]

Re: New GitHub Issues Beta

#103
There is currently a move to disable issues (in opensource projects) and the driving factor behind this, is that other people can basically put stuff on your todo-list.

What would be better:

- make issues read-only for non-members

- track problems in discussions. often they're not really bugs and other people can directly help. If not, I'll convert the discussion to an issue when appropriate.

Benefit: bugs as discussions can be upvoted or downvoted so the community helps prioritizing.

Re: New GitHub Issues Beta

#104

if someone from github is looking at this, can u please include Gitlab's "Scoped Labels" in this - https://docs.gitlab.com/ee/user/project/labels.html#scoped-l... it seems that the new issues are going to operate on the basis of labels (as it should). Scoped/Nested labels are a godsend. For example, I can tag an issue with a label "UI::App::Android" and i should be able to filter on the basis of "UI::App" and get all…

This seems to be covered by the new ability to extend issues with custom fields.

Re: New GitHub Issues Beta

#105

if someone from github is looking at this, can u please include Gitlab's "Scoped Labels" in this - https://docs.gitlab.com/ee/user/project/labels.html#scoped-l... it seems that the new issues are going to operate on the basis of labels (as it should). Scoped/Nested labels are a godsend. For example, I can tag an issue with a label "UI::App::Android" and i should be able to filter on the basis of "UI::App" and get all…

This seems to be covered by the new ability to extend issues with custom fields.

not really - u can have multiple labels for an issue. but one value for a custom field.

that's why the scoped/hierarchical stuff start becoming powerful for issues.

Gitlab had the right insight here.

Re: New GitHub Issues Beta

#106
post #103

There is currently a move to disable issues (in opensource projects) and the driving factor behind this, is that other people can basically put stuff on your todo-list. What would be better: - make issues read-only for non-members - track problems in discussions. often they're not really bugs and other people can directly help. If not, I'll convert the discussion to an issue when appropriate. Benefit: bugs as discuss…

I haven't used Discussions, but why doesn't Issues already do what you're asking for? You don't have to consider every open issue as your TODO list; use one or more "Triaged" labels for that. And voting on issues already exists.

Re: New GitHub Issues Beta

#107
post #73

Question: how does the Table view headings reconcile to the Board view? On the Table view, there is a heading for: "Prototype", "Beta" and "Launch" https://github.githubassets.com/images/modules/site/planning... But when you look at the Board view, I don't see "Prototype", "Beta" or "Launch" denoted anywhere on the card. https://github.githubassets.com/images/modules/site/planning...

By looks of it, they're milestones :)

But how do the milestones get surfaced on the Board view?

Re: New GitHub Issues Beta

#108
I don't use GitHub Issues [much] because I was under the impression that issues are not themselves stored as a git repo, but rather they are some kind of proprietary database GitHub maintains. Thus they create lockin for GitHub.

Am I wrong about this?

Re: New GitHub Issues Beta

#109

Earlier quoted context omitted.

This seems to be covered by the new ability to extend issues with custom fields.

not really - u can have multiple labels for an issue. but one value for a custom field. that's why the scoped/hierarchical stuff start becoming powerful for issues. Gitlab had the right insight here.

[deleted]
Post reply on HN