You can simply choose to give anyone who presents themselves as capable of working with the project a Fossil developer account. Then they do pretty much as you've proposed under the same tent as everyone else. This model is only "cathedral" insofar as there's someone with the moral and technical authority to accept and reject proposed changes to the next release, or trunk, or whatever. No one's really planning the next release, as in a proper "cathedral" model. I call the role the "maintainer," as opposed to planner, architect, etc.

It simply isn't worth it to most people to fight over control over most FOSS projects. If you call yourself the leader, most people will just let you take the headache.

My experience in being part of FOSS projects, and managing them, is that the hardest part about managing contributions is in getting them in the first place. Anything that's a barrier to that reduces the number of contributions, which just makes The Hard Part even harder.

If someone gives me a working code patch to one of the public FOSS projects I manage, I'm inclined to give them an account. I've never had to lock someone out of an account once given, due to abuse. Most people are too busy leading their own lives to spend time wrecking your repository.

A contributor might inadvertently wreck things, but that's a teachable moment. Handling such conflicts well is a key skill of a project manager. If you're unable or unwilling to cultivate and exercise that skill, federating the repository as you propose isn't likely to result in better code from the central repository. It'll just result a bunch of people going off on their own tangents, sowing confusion in the user base as they lose certainty about which repo to clone from.

Bundles are fine for the first 1-3 introductory commits from an outsider, but after that, bring that person into the tent.

You might like to read through my HACKERS.md file, in particular the Submitting Patches section. This document started out as the contributor's guide to a project I've been managing since 2004, so it covers a lot of detail that one-off documents tend to miss. The document is liberally licensed, so you are free to copy it into your project as-is and modify it to suit your purposes.

The Fossil project has a series of documents with the same purpose, rooted here, which is also worth idea-mining.

Well, yes, if the project has contributors on regular basis, I will give them permission to push the changes directly.

But sometimes, the contributors are occasional. For example, on the mentioned project the contributions provide mainly translations to another languages and their contributions are single act, not regular work.

In addition, as a rule they have no experience with fossil, so they prefer to simply send me the files instead to commit them by themselves. As a result, the development history and the authors name and comments are lost.

That's why my Sending Patches section starts off with the patch(1) option instead of fossil bundle: I'm keeping the barrier to one-off contribution as low as possible.

As for maintaining a history of contributors, I put that info into the checkin comment when integrating patches, and I mine that commit comment stream when building the ChangeLog and AUTHORS/CREDITS file for the next release.

If someone wants full credit in Fossil for their contributions, they need an account.

Bundles aren't a great way to preserve authorship information, because local user names on clone repos aren't trustworthy. Fossil does nothing to ensure that they're trustworthy or even meaningful. I can send you a bundle containing a series of checkins by johnfound, and your Fossil instance will accept that blindly. Since that means the burden of ensuring proper attribution lands on the shoulders of the person integrating the bundle, it's really no different from the situation with patches.

Even if you set aside the possibility of such masquerading, there's the problem of later synchronization of user tables: I can send you a bundle today containing checkins by user tangent, my local user name, but later get an account on your repo as wyoung, perhaps because you have a policy against pseudonymous user names. Now my earlier contributions are disassociated with my current account on your repo. You avoid that problem by giving your contributors an account on the central repo ASAP.

To me, bundles are about preserving commit comments, branching decisions, file additions, renamings, and deletions. That is, detail not preserved in the unified diff format. And that means bundles are only useful when a contribution contains one or more of these things. Since most drive-by contributions can be expressed as a simple patch file without losing anything, there's no reason to insist on bundles by default.