It's not so much "not JIRA", it's that managing code bases <i>outside</i> of the code base is hard and awkward. And due respect to fossil-scm, I don't know if any way to do it otherwise.<p>The goal here is to look at something that tells an organisation <i>why</i> chnages to a codebase occurred. Each individual commit can have a nice explanation (in a given human language) of why that specific change occurred. But how does one link other commits, dozens or hundreds or orders of magnitude more.<p>Can they be accounted for to investors, auditors, regulators?<p>But equally demanding that commits link to <i>something</i> that links to <i>why</i>, it demands that the rest of the business also link to that something (ie JIRA) so they can explain why they expended time and effort<p>JIRA or whatever ticketing system, will slowly become the central repository of <i>justification</i> for expense - a great position sure, but also dangerous.<p>Following on, having some repository of why - of cost drivers - forces not just the software developers but the whole business to justify its activity against the repository. This seems hugely similar to lawyers billing by the 15 minute increment, and indeed a git repo will provide good billing like data too !<p>But the issue still exists - if I say my activity links to ticket number 1234, then we have a hierarchy (?) of what 1234 links to. The smacks of stories and epics and the whole agile package, but is also a common accounting process<p>my issue is that this is a neat, backwards looking explanation for what was done. It's not a good way to manage forwards.<p>And often I find the problem is people wanting to use JIRAs tickets to manage what will be done, not account for what has been done