4 ms·

> The place for these what/why messages would appear to be in a ticketing system of some kind, referenced by ID in the commit message. No. It's best to assume

> The place for these what/why messages would appear to be in a ticketing system of some kind, referenced by ID in the commit message. No. It's best to assume that all information in your ticketing system will be totally lost. The commit message should have the "what/why" directly in them, because that's where you'll first look when you want to find that out (why add an extra hop), and it would require extreme incompetence (which is not unknown) to lose information stored there.

nazgul17 4y ago
I agree at a gut level with this. Do you have a source that this is more widely believed? I would like to bring this to my tech lead.
- ycombobreaker 4y ago
  Walk through a hypethetical ticketing system migration with your tech lead. Assume all external links are broken, and see how expensive it becomes to answer questions about your own codebase. "why did we add special case X? is it still applicable? It interferes with new feature request Y, can we remove it to reduce total risk/cost of implementing Y?" Integrating with another tool is fine, but not at the expense of your commit history!
- tablespoon 4y ago
  > I agree at a gut level with this. Do you have a source that this is more widely believed? I would like to bring this to my tech lead. This was learned from hard experience. During my tenure, we've migrated corporate wikis/"collaboration systems" four times, and we've used at least as many ticket systems. We also migrated from webex to Teams a few years ago. Each migration resulted in at best a severe partial loss, and in some cases a total loss. The most stable resource is the codebase. Basically, whenever anyone does a migration for you, they will lose things, and they might even think losing them is a "clever" shortcut that will make them more efficient. Our recent documentation system migration only covered documents modified in the last year as a corporate cost-saving measure, and we were on our own for everything else. Weak/understaffed teams did a bad job. They retroactively implemented a retention policy on Webex that wiped out a lot of valuable recordings, and then the coup-de-grace was the migration to MS Teams, which wiped almost everything else (basically everything that the original recorder didn't conscientiously download and save). We recently migrated to MS ADO as our work tracking system, and that was the only time I've seen old stories/bugs migrated at all, and even then we still lost all embedded images. Here's a list of things in order of least to most likely to be lost: 1. Head/tip of your project in source control 2. Source history 3. Documentation stored in a central location as files you can easily copy 4. Documentation stored in some system (like a wiki) 5. Tickets/stories in your work tracking system

nazgul17 4y ago

I agree at a gut level with this. Do you have a source that this is more widely believed? I would like to bring this to my tech lead.

ycombobreaker 4y ago
Walk through a hypethetical ticketing system migration with your tech lead. Assume all external links are broken, and see how expensive it becomes to answer questions about your own codebase. "why did we add special case X? is it still applicable? It interferes with new feature request Y, can we remove it to reduce total risk/cost of implementing Y?" Integrating with another tool is fine, but not at the expense of your commit history!
tablespoon 4y ago
> I agree at a gut level with this. Do you have a source that this is more widely believed? I would like to bring this to my tech lead. This was learned from hard experience. During my tenure, we've migrated corporate wikis/"collaboration systems" four times, and we've used at least as many ticket systems. We also migrated from webex to Teams a few years ago. Each migration resulted in at best a severe partial loss, and in some cases a total loss. The most stable resource is the codebase. Basically, whenever anyone does a migration for you, they will lose things, and they might even think losing them is a "clever" shortcut that will make them more efficient. Our recent documentation system migration only covered documents modified in the last year as a corporate cost-saving measure, and we were on our own for everything else. Weak/understaffed teams did a bad job. They retroactively implemented a retention policy on Webex that wiped out a lot of valuable recordings, and then the coup-de-grace was the migration to MS Teams, which wiped almost everything else (basically everything that the original recorder didn't conscientiously download and save). We recently migrated to MS ADO as our work tracking system, and that was the only time I've seen old stories/bugs migrated at all, and even then we still lost all embedded images. Here's a list of things in order of least to most likely to be lost: 1. Head/tip of your project in source control 2. Source history 3. Documentation stored in a central location as files you can easily copy 4. Documentation stored in some system (like a wiki) 5. Tickets/stories in your work tracking system