Live data from Hacker News

New GitHub Issues Beta

github.com

151–160 of 223 posts

Re: New GitHub Issues Beta

#151

Earlier quoted context omitted.

Neither, you should have a third conceptual tool to encapsulate the overall product, then once you have a feature spec, you cut tickets for the subcomponents. Depending on the API complexity, I personally would either define the spec as a PR to our API doc repo, or define it as part of the backend task.

If I have a third tool, I might as well use that tool for all my issues anyways then? Especially when a tool like Linear can integrate with GH anyways.

I've actually been experimenting with something similar to what adrianpike describes. Basecamp is home to all higher level product/business stuff. In part, that's because everyone in the business has access to Basecamp and uses it on a daily basis.

Concrete development work gets put into GitHub Issues. Most people on the business side don't have access to GitHub and wouldn't be comfortable with it. Smaller stuff may not get a GitHub Issue. It may just live in Basecamp. Technical stuff that the business will never care to see may only live in GitHub.

It's a new process I'm experimenting with. We'll see if it ends up being too disjointed.

Re: New GitHub Issues Beta

#152
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.

I bet they aren't too worried.

This seems like a product area where hitting all the features on a purchasing manager's feature list is more important than being good. Atlassian seems optimized for that.

Re: New GitHub Issues Beta

#154
post #61

Earlier quoted context omitted.

What I need: 1. Issues that can be linked to other issues (regardless of repo), i.e. local issue blocked by remote issue 2. Projects that can contain issues from multiple repos, even a mix of public and private repos Please say this is now possible, otherwise we too are looking at Linear, Jira, etc when we'd like to be looking at Github.

It is indeed now possible. Give it a try and let us know what you think.

Can projects now contain issues from multiple _orgs_? I've had worked on things that spanned orgs before, and as far as I know projects couldn't handle that.

I'm really glad subtasks is now a thing!

Re: New GitHub Issues Beta

#155
post #95

Earlier quoted context omitted.

This is super common, and it's one reason why I have always volunteered (even though it sucks) to be the Jira Person. I'm experienced with it and have a good handle on how not to make it a big giant workflow mess, and I can then make sure that, by not being shy about who's running it and managing it, that feedback goes somewhere actionable.

JIRA workflow is managed by another department. Our IT department is like 50k+ employees. I think there are 100k in IT and Ops.

Absolutely common. And I'll happily consult for companies in that boat but I would do a lot to avoid working for one.

Re: New GitHub Issues Beta

#156
post #127
post #23

I am longing for the day they deprecate Azure Devops and merge it into GitHub Enterprise. This is the only way I’ll ever get the ability to work with GitHub in my company, which has a much superior UI/UX imo.

Azure DevOps is quite a bit more advanced than GitHub. Is there a feature that GitHub has that is missing from Azure DevOps? UX is very subjective and while DevOps is not perfect, I don't find it straight up horrible. It has way more features that need a place in the UI. Plus it's lightning fast compared to JIRA.

It's extremely confusing the way the repos work in Azure DevOps as compared to GitHub, the only way you can see which one you are working on is through the little tab on the top. Since this also controls what PRs show up, about once every day or two I'll click on "pull requests" and be super confused as to why there's no PRs present until I realize "oh! I was browsing the other repo earlier that's why." Especially when issues and everything else are not connected to repos in any way, this is a weird UX decision. At least put the name of the repo next to the pull requests button like in GitHub, so I see where I am before I click.

Re: New GitHub Issues Beta

#157

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.

GitHub issues should not be used by non-technical contributors though (imo)

I love having our less-technical team members on GitHub. We post loads of screengrabs in issues and PRs, discuss changes and wording and it keeps everyone in the loop.

I really wouldn't want to go back to using a separate to like Jira or Trello.

Re: New GitHub Issues Beta

#160
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.

For day-to-day, Jira is completely fine. I get frustrated with it when I need to dive into basic admin tasks - like spinning up a new project or board. Their admin and setting panels are completely incomprehensible. Also, Jira doesn't have a story for archiving tickets. Only a straight, permanent, hard delete with no recovery. I got reminded of this the hard way. ----- We're currently switching to Clubhouse (though a…

Same. My personal pet peeve is "workflows", aka, you moved something from To Do to In Progress, and now it's impossible to move back because its not part of one of the allowable paths for a ticket. It's just like... why. PMs spend all this time designing the workflows only to make more work for themselves when everyone needs them to manually move things.
Post reply on HN