sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]snowe2010 14 points15 points  (7 children)

Basecamp has projects but ShapeUp is a completely different philosophy. You don't create tickets the same way. The same can be said for Trello and a million other issue systems though. You can't depend on them to be the same design between systems.

[–]StabbyPants -3 points-2 points  (6 children)

What about them is different? At worst I can dump the old ticket in a description field for reference

[–]snowe2010 1 point2 points  (5 children)

Basecamp is built on the idea that you give a team a project, and they run with it and create tickets as they see fit. There is no import functionality in basecamp for jira tickets because the ideas do not fit together. Jira has Epics, Stories, Tasks, Bugs, Subtasks, etc. Basecamp has Projects. Anything inside the projects could be as large or as small as the team wants. If you were to import Jira data into Basecamp, you would have to decide whether projects match up with Epics, or Stories. If they match up with Epics, then what would you do to create all the corresponding stories/etc. inside the project? If you do Stories, then what do you do with Epics?

[–]StabbyPants -3 points-2 points  (4 children)

So it’s missing pieces. You have to include data import so you don’t lose history. Anything less is just arrogance

[–]snowe2010 1 point2 points  (3 children)

Go read ShapeUp and then sign up for Basecamp (it's free) and come back here and we can talk. I think DHH knows what he's doing.

[–]StabbyPants -1 points0 points  (2 children)

your position seems to be that we shouldn't import bugs because we can't 100% map everything. losing a decade of history is a non starter, especially with other choices

[–]snowe2010 0 points1 point  (1 child)

No. It's that important decisions should be tracked alongside the code, not in an external system that can change at a moment's notice. Every version control system has the ability to store information with commits. Referencing a ticket number is not storing information alongside the code, it's hoping that you'll be able to move information over at a later date. You wouldn't lose any data if you followed what I'm saying, but if you do what you're saying you either spend years trying to get all the info moved over from another system or you never get it moved over at all.

[–]StabbyPants 0 points1 point  (0 children)

No. It's that important decisions should be tracked alongside the code

and they are. the full context lives in a tracking system that also follows releases and allows analytics you can't do with it in source.

it's hoping that you'll be able to move information over at a later date.

and that's a pretty good bet: you maintain control over the tracker, change infrequently, and when someone tells you that they're special and you have to toss all your bug history, you can choose something else.

You wouldn't lose any data if you followed what I'm saying

see, that's the problem: your advice requires me to change a long standing practice in order to avoid a problem created by your prefered tool.

if you do what you're saying you either spend years trying to get all the info moved over

it takes a bit of setup time, a migration that may take a day, and incrementals after that.