Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New GitHub Issues Beta

github.com

Post reply on HN
Print view View original

191–200 of 223 posts

Re: New GitHub Issues Beta

#191

Post by kungito »

jayd16 wrote: post #184
coffeemug wrote: post #147

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…

Yeah, often I get into a problem where I wanted to have a hierarchical tree to organize my things and then later I wanted to somehow connect nodes from different branches in some way. I guess you could always have `ui::app::android ui app android` if needed

Re: New GitHub Issues Beta

#192

Post by SilverRed »

telaandrews wrote: post #44
dragosmocrii wrote: post #37

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?

For me in Gitlab, you would create an epic (if its a large feature) and then put all of the tasks as their own issues in the respective repos.

Re: New GitHub Issues Beta

#193

Post by SilverRed »

rawfan wrote: 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 have not seen such a move in any of the projects I have looked at. Repo maintainers have either just allowed feature requests and ignore them but leave them there for either someone else to chip in on or just to show that it has already been requested. Or they will just close feature requests.

Re: New GitHub Issues Beta

#194

Post by SilverRed »

mariorod wrote: post #89
gnachman wrote: post #50

If anyone from Github is here, can you please allow attachments of unrecognized file types? You won't let users attach their binary .plist prefs files and this makes Github issues unusable for my project.

As you can guess there is a lot we do when it comes to attachments to keep the platform safe, which includes having an allow list of them. Now, I agree there is room for improvement and are looking into an attachment API that will address this.

Can't you already attach arbitrary files as part of a tagged release? You can also direct link to any file you want which works the same as if it was uploaded. I'm not sure the file whitelist is adding any security here.

Re: New GitHub Issues Beta

#195

Post by SilverRed »

munchkinship wrote: post #46

So for a non-developer that wishes to collaborate, they now need a GitHub license? That's a deal-breaker right there for any org that is composed of more than developers.

At my org we just have one user with reporter permissions on gitlab which is shared by a bunch of people who just write their name at the end of tickets or comments. For more involved people who need to be assigned to things or pinged, they pay the full license.

Re: New GitHub Issues Beta

#196

Post by danielfranz »

Groxx wrote: post #30

"it's just a spreadsheet, and [view X] is a filter on that sheet" is a nice mental model. I've had lots of managers organize stuff in google sheets and then copy to [task manager X] simply because it's easier to think about - they'd probably love this. I certainly would, vs Jira's massive "everything is custom UI / a unique concept" mess.

Agree. Then again if you use JXL in your Jira you have a more agnostic spreadsheet view of your issues as well. Pretty neat. https://jxl.app

Re: New GitHub Issues Beta

#197

Post by SilverRed »

dreamcompiler wrote: post #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?

The GDPR mandates that all web services allow you to export your data which github supports. Alternatives like gitlab allow you to import all of that "proprietary" data direct from github so its not a very strong lock in.

Re: New GitHub Issues Beta

#198

Post by danielfranz »

justinjlynn wrote: post #55
denimnerd42 wrote: post #51

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 so close to reality it really hurts - like a good The Onion article... excellent satire. Powerful tools are flexible enough to be used correctly by knowledgeable people and help people become knowledgeable. Badly designed tools are tools which don't help people become knowledgeable and don't prevent unknowledgeable people from harming themselves or others using them. Atlassian tools, like JIRA, are almost alw…

Imho the power and customisability of Jira is great. The problem is just its UI and performance. There are solutions to that though. You can always JXL your Jira (https://jxl.app).

Re: New GitHub Issues Beta

#199

Post by [deleted] »

robinhood wrote: post #19
ErrantX wrote: post #16

Earlier quoted context omitted.

So, yeh I partly agree. However those orgs often have a Very Big License for GitHub Enterprise, and therefore with some enterprise porting tools it's not that high friction a switch (supplier managers will be all in favour; one less contract to manage!)

They mostly don't. Once you have Jira, you have Confluence, then Bitbucket. That many less contracts to manage.

[deleted]

Re: New GitHub Issues Beta

#200

Post by ErrantX »

robinhood wrote: post #19
ErrantX wrote: post #16

Earlier quoted context omitted.

So, yeh I partly agree. However those orgs often have a Very Big License for GitHub Enterprise, and therefore with some enterprise porting tools it's not that high friction a switch (supplier managers will be all in favour; one less contract to manage!)

They mostly don't. Once you have Jira, you have Confluence, then Bitbucket. That many less contracts to manage.

Hard to be sure either way, but most of the sources I could find indicate this isn't true.

E.g. https://www.slintel.com/tech/source-code-management/github-v...

Post reply on HN