[lostcolony]

Integrate with a ticketing system, force commits to match a pattern, and you can ensure the rationale is tied to your ticketing system (i.e., commits/merges have to be prefaced with FOO-####)

[klardotsh]

This is generally great (and I do it on projects I'm confident won't be moving any time in their useful life), but if you ever switch VCS/ticket systems, it gets messy quick.

Ever moved from Github Issues to Jira/Trello or vice-versa? How about Bitbucket to Github (as I did for my current company)? That's a whole lot of context potentially being lost, either in tickets or PR discussions.

How much of that lost context would have ever been used anyway is up for debate, of course. In my experience the answer tends to be "rarely, but sometimes".

[sedachv]

This is why I discourage Free Software projects from using hosted issue trackers entirely, especially ones that are proprietary (such as GitHub). Mailing lists are the best solution for longevity and meaningful discussion. If you really need to, you can organize things in a file that is in the repository alongside the source code (Org mode is great for this), which has many significant advantages (and downsides, like not being point-click for PMs, but if your Free Software project has PMs, you have bigger problems that software cannot solve).

[james_s_tayler]

Often that sometimes is a life saver though...

[pcnix]

This happens on github/gitlab too, with pretty much all open source projects. It's definitely a cause for concern eventually, because the context for the problem and the rationale for decisions is now something that you have to maintain apart from just maintaining the codebase. Right now github etc do a good job of managing that for you, but the long term handling of this context definitely has scope to improve.

[maxxxxx]

Obviously this system will be obsolete in a few years too and nobody will know how to find stuff int it :-)