Ah, I probably wasn't clear enough: my point was that the core of the feature (i.e. omitting non-tech users) can be implemented so cheaply that it seems a bit s

Ah, I probably wasn't clear enough: my point was that the core of the feature (i.e. omitting non-tech users) can be implemented so cheaply that it seems a bit superfluous to require a built-in implementation. However, Fossil's documentation[0] has some answers: Some other distributed bug-tracking systems store tickets as files within the source tree and thereby leverage the syncing and merging capabilities of the versioning system to sync and merge tickets. This approach is rejected in fossil for three reasons: 1. Check-ins in fossil are immutable. So if tickets were part of the check-in, then there would be no way to add new tickets to a check-in as new bugs are discovered. 2. Any project of reasonable size and complexity will generate thousands and thousands of tickets, and we do not want all those ticket files cluttering the source tree. 3. We want tickets to be managed from the web interface and to have a permission system that is distinct from check-in permissions. In other words, we do not want to restrict the creation and editing of tickets to developers with check-in privileges and an installed copy of the fossil executable. Casual passers-by on the internet should be permitted to create tickets. Point 3. indeed requires additional software; Point 2. could be solved by storing the tickets in a distinct repository. Regarding point 1., as far as I understand, a check-in is an atomic series of modifications to the repository database, so it seems there is a strong correlation between the tickets and the "commits"? If so, why not, but I'm not sure why this is necessary either. [0]: https://www.fossil-scm.org/home/doc/trunk/www/bugtheory.wiki https://www.fossil-scm.org/home/doc/trunk/www/bugtheory.wiki