You might have a look at “CONTRIBUTING.md” files in repos.

• Set quality standards (no giant PRs, follow documented coding style, include tests for changed functionality, etc).
• Establish a way to discuss contributing work before they do it. Generally, have them open an issue discussing the proposed change and get buy-in from the maintainer (you) before starting work.
• document any high-level goals and non-goals in the README.md for the repo, and refer to that when discussing changes. You can always amend it as you discover more about what should be built.

Initially, contributors can fork and send a pull request for you to review and merge. You do not need to give them any write access to the main repository. Be respectful of their time and review PRs promptly.

If multiple people want to collaborate on a branch, they can do that in their fork. In my experience, this is pretty rare, usually you don’t want multiple people committing to the same branch (except for merges to master/main/stable, etc).

If you have a few dedicated contributors that have a history of submitting good quality patches, and alignment with you on your project’s goals, you can invite them to have more control in the main repository, at which point there should be minimal concern about granular controls.

Should everyone push contributions from their forks?

Yes.

In that case, how would people work together on a particular feature.

They can grant permissions to eachother (and even to you) to commit directly to their forks.

Since their fork isn't the main repo, it is easier to reset and try again if things go sideways.

Restrict to PR until trust is established.

Sounds like you need branch protection rules, which you only get on paid plans. Setting up a org is also a good idea anyway if you plan on working as a team of more then 1-2 additional folks.