The population you desire to be able to update tickets is... shall we say, "larger" ? ;) than the population you desire to be able to update code.
For any project where the bug-updaters and the code-updaters are plausibly the same set, this could be a useful thing.
But even for modest projects I'm doing for customers, it'd be awkward.
I also think the type of data your bug-updaters or bug-reporters would generate would be very different. Do you really want 23 gargantuan screenshots as blobs retained in perpetuity?
My kneejerk is that the bug metadata is a different _kind_ of data than the source, and trying to shoehorn them into the same container will be stuffy in most cases.
Each bug is stored independently and in particular independently of the source code, so older bugs could be archived or simply left on the git remote.
I don't see your point about the permission model.
You will have access permission for the code as you normally do for your git remote as well as an extra user for the web UI that will store bug edits as one of the "public" user with whatever external authentication system you want.
>Do you really want 23 gargantuan screenshots as blobs retained in perpetuity?
A really good point. I'd say you should use something like this for internal bug tracking, and link to external bug reports instead.
Whether you accept an external bug report as an actual bug is a question in itself, which should be dealt with beforehand. I'd say this is good for notetaking for the team and for seeing which bugs are resolved in which version.
> Do you really want 23 gargantuan screenshots as blobs retained in perpetuity?
There's a whole bunch of ways to handle large files in git nowadays without bloating the size of the repo. Hopefully the distributed bug tracker would work with those...
The population you desire to be able to update tickets is... shall we say, "larger" ? ;) than the population you desire to be able to update code.
For any project where the bug-updaters and the code-updaters are plausibly the same set, this could be a useful thing.
But even for modest projects I'm doing for customers, it'd be awkward.
I also think the type of data your bug-updaters or bug-reporters would generate would be very different. Do you really want 23 gargantuan screenshots as blobs retained in perpetuity?
My kneejerk is that the bug metadata is a different _kind_ of data than the source, and trying to shoehorn them into the same container will be stuffy in most cases.