The COB types are located in the Stored Copy, you would still be able to partial clone the working copy repo without the issues and patches, with your current git commands. There is a better explainer here: https://docs.radicle.xyz/guides/protocol#storage-layout

And Fossil is an entirely different VCS.

What’s the alternative? That at least N projects cooperate and agree on a common design before they do the implementation? (Then maybe someone can complain about design-by-committee.)

I'd like to note here that Radicle has defined our own version of issue and patch management, but they're not necessarily required to be used as part of the protocol. The protocol only defines that any and all COBs will be stored and replicated under the `refs/cobs` hierarchy.

If someone wanted to come along and define a way to embed Fossil wikis/issues as a COB then they could be replicated on the Radicle network and it's then up to application developers to load and interpret that data.

I think this is cool because it essentially allows developers to extend the Radicle ecosystem easily and define new workflows! However, that does not avoid our XKCD problem stated above ;P But hey, sometimes that's the beauty of these things -- we're given the power to define our own workflows and not locked into something everyone complains about coughGitHub branches PR flowcough