31–40 of 223 posts
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.
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.
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.
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.
Then we switched to BitBucket Server because it integrates better and cost a lot less, plus GH Enterprise was a weird black box VM back then that we had to hack into to make work for whatever reason.
I couldn't point you to anyone who likes BitBucket Server, but as long as you're on the CLI and don't have to use the terrible web UI too much, it sort of works.
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 hate JIRA but there is very little else serving these customers.
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.
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.
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.
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.
Where did you end up?
"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.
Our primary interface at Streak is a spreadsheet. It looks simple to build but we've invested (and continue to invest) a ton of engineering time to making it great. Users love the interaction model like you said.