Live data from Hacker News

New GitHub Issues Beta

github.com

181–190 of 223 posts

Re: New GitHub Issues Beta

#181

It floors me that they haven't addressed the underlying architecture issues that made Issues unusable: Issues are only for a single repo. Business users don't (and shouldn't) know what repo to add an Issue to. This is why we moved away from Issues and none of these new visualizations make the product usable until they deliver multi-repo issues.

Product team shouldn’t understand the product sounds like a recipe for failure to me. The product team actually should have a good idea of which component does what and be able to identify where the defects and opportunities lie. If they don’t then that’s a communications failure.

Re: New GitHub Issues Beta

#184

Earlier quoted context omitted.

Why not just tag it with separate labels? For that example, tag it with ui, app, and android. Then search with ui and app labels?

For the same reason you ever need hierarchies-- without scoped labels you end up with a confusing soup of labels that's very difficult to make sense of. And the more labels you get, the harder everything becomes.

"UI::App::Android" seems kind of odd to me, or at least its a poor example. Does this mean you can't search for "Android" and get all Android issues? Maybe I'm not understanding how it works?

It seems like it would make sense as a way of name spacing. "Web::UI" and "Android::UI" would ensure an Android dev doesn't need to sort through all UI issues and all UI issues without a platform tag would also show up in a different search. Having the platform last seems strange to me, though.

Re: New GitHub Issues Beta

#185

Earlier quoted context omitted.

Maybe Github Issues is not supposed to work as a support ticketing system? You are allowed to move issues between repos, so in theory you could create a dummy repo where users can add issues, and then those issues can be moved to their appropriate repo.

What if I want to define a new feature that has both backend and frontend tasks, and have separate repos for the FE and BE? Which repo do we create the issue in?

Either one. You'll eventually open an issue on the other repo too and link them.

Re: New GitHub Issues Beta

#186
In case the GitHub Issues team is still looking here, I have a request! Can you put the name of the commenter somewhere besides just the name field in the email from? Currently it's something like, Poster Name , but that means you can't tell who the poster was from the email content itself.

I use Apple Mail and have a contact for GitHub since that provides benefits like an avatar, easier search, etc, but now the contact clobbers the name field and I just see every email from "GitHub" with zero indication who wrote the comment.

Re: New GitHub Issues Beta

#189
post #167
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.

Ex-Atlassian here. Last day was around a month ago. Not tense at all. You'd be surprised at how many people actually like Jira, mainly because of how customizable it is. That in my opinion is it's biggest boon and its greatest curse. Every Jira instance is so different it's hard to compare between them. Stock isn't bad at all and works quite well. There are performance issues for sure, but I've yet to see a competito…

> You'd be surprised at how many people actually like Jira, mainly because of how customizable it is.

Are there any numbers of how many of the users like it, compared to how many users struggle with it? I can't imagine that a majority of Jira users likes it, as that's not my experience. I have met very few people (mainly project managers) so far, which believe that Jira (and other Atlassian products as well) are great products.

Re: New GitHub Issues Beta

#190
post #184

Earlier quoted context omitted.

For the same reason you ever need hierarchies-- without scoped labels you end up with a confusing soup of labels that's very difficult to make sense of. And the more labels you get, the harder everything becomes.

"UI::App::Android" seems kind of odd to me, or at least its a poor example. Does this mean you can't search for "Android" and get all Android issues? Maybe I'm not understanding how it works? It seems like it would make sense as a way of name spacing. "Web::UI" and "Android::UI" would ensure an Android dev doesn't need to sort through all UI issues and all UI issues without a platform tag would also show up in a diff…

my apologies.

Its the hardest thing in computer science - "Naming Things"

Post reply on HN