you are talking about philosophical relativism and using a philosophically progressivist bias to claim legitimacy.
at some point, Alice and Bob's linux will diverge to the point that Charlie will recognize neither as being linux, at which point there needs to be some basis for legitimacy to have a common ground, which in turn 'devolves into asking questions about power' (e.g. authority/legitimacy)
one can certainly be too fixed in ones approach, but the inverse is also true.
if bob, alice and charlie all work for an organization of people delivering 'the same linux' (whether open source/community driven or public company), what will a consumer of this 'linux' recieve when they get it?
which in turn 'devolves into asking questions about power' ..
ultimately we need to be on some same page, even if it is a bunch of post it notes on a desk and not a neatly bound hardcopy, so i wouldn't let the dualism implicit in being relativist create a false dichotomy whereby being organized at all is somehow outside of the realm of possibility.
what does your vision of 'keeping track of being on the same page' look like, if the page doesn't even need to exist to be on it?
or does so-called software 'enlightenment' require dissociating from all fixed concepts altogether? (show me the computer that will work this way and not be a magic spell, quantum included, since we are talking about 'being realistic')
I’m tying this to the notion of Git’s branching model of course, each branch being something of a slightly different perspective or reference code for the same amorphous project of Linux. What consumers receive is just that then, a perspective on the broader project, one particular snapshot with various patches and so forth. In an OOP analogy Linux is a class and they receive an instance of that class, maybe.
But yeah I think I am with you, dissociating from all fixed concepts altogether is probably not a great direction to go with this. You want some project organization and request or issue tracking. I am sorry if I sort of was suggesting that issue-tracking at all was meaningless, I definitely don’t agree with that. But I do think it instead has something to do with recognizing that the code to resolve an issue (if there is code at all, if it's not just getting closed as works-as-intended) leads to that issue having a “status” which needs to be tracked across multiple branches, and that this process is tedious and error-prone when we try to do it by hand.
I think that one of the points that you raise is quite valid - that issue tracking should really be integrated into version control.
I would summarize the problems of various bugtrackers including Jira as being insufficiently “up with the times” therefore. They reflect the old modernist approach to truth. Schedules, deadlines, when was this “done”. But we know in software that really you want your source of truth of your bugtracker to basically be in the same Git repository as your code: one and the same commit needs to simultaneously close a bug as needs to properly change the source code to fix that bug, because the bug may be fixed in your “staging” codebase but that bugfix may not yet be deployed to “prod.” A reversion merged into prod as a hotfix needs to suddenly re-open the bug that we said was fixed-in-prod because now it no longer is. All of that. That's my hazy crackpot vision. :)
Given all that, there is also a great difficulty with people using workflows like GitFlow which have the same “old way of doing things” misunderstandings. It’s not that those workflows aren’t good, they are good—for SVN repositories. You apply them to a Git repository and then you have this strange tension where the workflow and the VCS are working at cross-purposes sometimes. So it's also things like GitLab's CI/CD being a file checked into Git. This sounds great until you realize that nobody is expecting postmodernism to suddenly pop up here. “How did you merge that thing into prod when all of our admins were unreachable? Admins are supposed to have to push the button.” “Well, I was really in a bind, so I did something I would have never normally done: I pushed up my own branch `fix-master`, and in that branch I changed the CI/CD file to trigger deploys to production on pushes to `fix-master` instead of `master`.” But I had to!” Git was like “hegemony? what hegemony? if `master` has power then everyone has power.” Hah.
So my question is, based on this description, I am not sure that I see you have “drunk the same Kool-aid” about Git, I am instead seeing a declaration that you want something fast-and-easy-and-supports-Git.
Which, like, is fine. I don’t want to come across as crapping on your invention with a dream that I absolutely admit is hazy and crackpot, right? You have actually done the work and I am hypothetical and I have mad respect for you and your work. But I am sharing kind of my bigger vision to ask, “do you have a bigger vision? is it different than mine, some more systematic structure?” Is Tara just an easy way to do something like Jira with Git, or do you have a fundamentally new concept in mind that you are headed towards that will change how we track issues with our software?