This seems like it repeats the same problem I generally have with most methodologies: it treats planning as being separate from development. Plans go into (Jes

This seems like it repeats the same problem I generally have with most methodologies: it treats planning as being separate from development. Plans go into (Jesus make the hurting stop) Jira while development goes into Git. And, okay, all of this requires new tooling, that figures out what your "issues" are based on the state of your source repos. But... Suppose you were doing (Something Like) TDD and your "planning" was to write a bunch of tests that broke. Or you're even not doing TDD but you can detect stubbed out code and draw issues from that, possibly by reading related documentation. And your working set of issues, then, are all the tests / stubs detected in active branches. (And this needs some logic to clean up the duplicates, and needs to be smart enough to notify people when things finish. And you want smart tests like TestNG that can identify dependencies.) And it needs to serve aspects outside development; let's say functions that touch the UX must be certified by a designer / tester. That person should be able to digitally sign code (maybe even just a handle and date is enough) and then those changes are known good. The reason I bring this up is because of a big deficiency in the issue trackers: identifying a new issue is cognitively/technically/procedurally expensive. One of the big things language designers try to do is make elements lightweight. Python added inline assignment because they saw people would repeat code just to avoid creating a new variable name. And when we're doing issues, planning out a new issue means setting up a meeting or opening a ticket in Jira and filling out a ton of paperwork, etc. It seems like it ought to be as light-weight as defining a new test, or writing out a stub function.