Live data from Hacker News

Pivotal Tracker will shut down

pivotaltracker.com

241–250 of 271 posts

Re: Pivotal Tracker will shut down

#241
post #170

Earlier quoted context omitted.

Obviously I meant 10% of all customers would hypothetically migrate from Pivotal to this new imaginary service, not that 10% of the data from each customer would be migrated... So 100% of the data migrated from 10% of the Pivotal user base, pretty generous assumptions I think.

> Obviously I meant... Respectfully: if it was obvious, I wouldn't have come to the conclusion I did and written up what I wrote. > So 100% of the data migrated from 10% of the Pivotal user base... Yeah, maybe. I don't know how large the slice of the Pivotal Tracker userbase you'd be able to retain even if you had a perfect clone. I bet it would be notably larger than you imagine it would be... it's my understanding…

> Respectfully: if it was obvious, I wouldn't have come to the conclusion I did and written up what I wrote.

I dunno, that felt obvious to me. Both the idea that you’d somehow manage to get all customers to migrate to your new service, as well as that they’d migrate only 10% of their data sound preposterous.

Re: Pivotal Tracker will shut down

#242
post #173

Earlier quoted context omitted.

"Good money" to a company with $13B revenue a year is a lot different than "good money" to a solo developer. If you can pick up six figures a year in revenue and keep things small enough to run solo, it's a good business for you.

If solo developers could make enterprise-grade work management systems we’d sure have a lot more of them around.

I think solo developers don’t make those systems because they don’t have to. Not because they couldn’t.

Re: Pivotal Tracker will shut down

#243
post #138
post #112

Earlier quoted context omitted.

I also loved that it was adamant about having specific, defined states with no customization. The issue is todo, in progress, done, delivered, accepted… that’s it. Custom issue states are a special kind of hell in JIRA.

> Custom issue states are a special kind of hell in JIRA. The nth circle of hell looks like a Jira workflow. https://i.imgur.com/dQE9vWn.png and https://medium.com/@daitcheson/you-can-do-better-than-jira-1...

That first one looks kind of reasonable compared to our ‘simplified’ workflow. The full one?…

Re: Pivotal Tracker will shut down

#245
post #241

Earlier quoted context omitted.

> Obviously I meant... Respectfully: if it was obvious, I wouldn't have come to the conclusion I did and written up what I wrote. > So 100% of the data migrated from 10% of the Pivotal user base... Yeah, maybe. I don't know how large the slice of the Pivotal Tracker userbase you'd be able to retain even if you had a perfect clone. I bet it would be notably larger than you imagine it would be... it's my understanding…

> Respectfully: if it was obvious, I wouldn't have come to the conclusion I did and written up what I wrote. I dunno, that felt obvious to me. Both the idea that you’d somehow manage to get all customers to migrate to your new service, as well as that they’d migrate only 10% of their data sound preposterous.

How about they migrate they easy 98% of data and ignore the hard, large, expensive, etc 2%? Does that sound preposterous?

Re: Pivotal Tracker will shut down

#246

Shortcut ( https://www.shortcut.com/ ) is a solid alternative to Pivotal Tracker. I work as an Engineering Manager there and helped build an importer for Pivotal Tracker data into Shortcut ( https://github.com/useshortcut/api-cookbook/tree/main/pivota... ). Shortcut as a product is team-oriented with solid GitHub/Gitlab/Bitbucket and Slack integrations.

Woah wasn't this called Clubhouse at one point? I'm getting blast from the past! We used Clubhouse at Papa long time ago.

It was, and at that time it suddenly became much harder to do a web search on how to do anything in their UI! Turns out, Shortcut is not the most Google friendly name.

Re: Pivotal Tracker will shut down

#247
post #67

Shortcut ( https://www.shortcut.com/ ) is a solid alternative to Pivotal Tracker. I work as an Engineering Manager there and helped build an importer for Pivotal Tracker data into Shortcut ( https://github.com/useshortcut/api-cookbook/tree/main/pivota... ). Shortcut as a product is team-oriented with solid GitHub/Gitlab/Bitbucket and Slack integrations.

Still feels like too many columns, too many states. Pivotal Tracker - ice box, backlog, or current iteration. I see companies in Trello Hell - well meaning, but often conflated, grey area states. There's like 10-15 columns on their boards. It's a hot mess.

I agree. People who like Pivotal Tracker (like me) for its focus and simplicity would not enjoy Clubhouse.

Re: Pivotal Tracker will shut down

#248
post #241

Earlier quoted context omitted.

> Obviously I meant... Respectfully: if it was obvious, I wouldn't have come to the conclusion I did and written up what I wrote. > So 100% of the data migrated from 10% of the Pivotal user base... Yeah, maybe. I don't know how large the slice of the Pivotal Tracker userbase you'd be able to retain even if you had a perfect clone. I bet it would be notably larger than you imagine it would be... it's my understanding…

> Respectfully: if it was obvious, I wouldn't have come to the conclusion I did and written up what I wrote. I dunno, that felt obvious to me. Both the idea that you’d somehow manage to get all customers to migrate to your new service, as well as that they’d migrate only 10% of their data sound preposterous.

> ...as well as that they’d migrate only 10% of their data sound preposterous.

Ah, I might be unduly affected by some big data (not Big Data, mind you) migrations that I'm currently involved in, where the Powers That Be are telling us that we have to throw away a huge fraction of our historical data. Well, that and the many times we've had to fight beancounters who popped on by to demand we save the company what amounts to pocket change by throwing away tons of historical data.

(It's flabbergasting how beancounters tend to ignore the price of programmer time when making their cost-cutting spreadsheets.)

Re: Pivotal Tracker will shut down

#249
post #238

Earlier quoted context omitted.

> Obviously I meant... Respectfully: if it was obvious, I wouldn't have come to the conclusion I did and written up what I wrote. > So 100% of the data migrated from 10% of the Pivotal user base... Yeah, maybe. I don't know how large the slice of the Pivotal Tracker userbase you'd be able to retain even if you had a perfect clone. I bet it would be notably larger than you imagine it would be... it's my understanding…

> Respectfully: if it was obvious, I wouldn't have come to the conclusion I did and written up what I wrote. Sorry about that, I think I assumed some familiarity with moving data around/migrations, and moving 10% of a customers data around from a legacy service to new service wouldn't make much sense in that context. > I bet it would be notably larger than you imagine it would be I think being able to capture 10% of…

> ...I think I assumed some familiarity with moving data around/migrations...

I am familiar with this sort of thing, yes.

I'm also professionally familiar with people who seem to think that it's totally acceptable to obligate folks to throw away large fractions of their valuable historical data in the name of cost savings. "Surely you can identify the most valuable 10% of your data!" they say.

Given that I don't know you and what you know, and given that I've encountered a shockingly high number of these fools with a fetish for data destruction, I chose to expect the worst from your somewhat-ambiguous statement... which would ensure that at least one of us learned something, regardless of the truth of the situation.

Post reply on HN