Came across this interesting document <https://rfc.zeromq.org/spec/42/> referenced from another project I was browsing. It is a set of guidelines for how Free Software projects should be managed. Some choice extracts: The project SHALL use the git distributed revision control system. The project SHALL use a share-alike license such as the MPLv2, or a GPLv3 variant thereof (GPL, LGPL, AGPL). All contributions to the project source code (“patches”) SHALL use the same license as the project. All patches are owned by their authors. There SHALL NOT be any copyright assignment process. Some specifics of how to use, and not to use, Git: The project SHALL have one branch (“master”) that always holds the latest in-progress version and SHOULD always build. The project SHALL NOT use topic branches for any reason. Personal forks MAY use topic branches. To make a stable release a Maintainer shall tag the repository. Stable releases SHALL always be released from the repository master. Actually that last one seems a bit questionable. For example, Blender does not structure its repos that way. Each stable release has its own branch, which may continue to accumulate bug fixes for as long as it is under support, while main development of the next version continues on the master branch. Plus there guidelines for handling people-management issues, of course: Administrators SHOULD block or ban “bad actors” who cause stress and pain to others in the project. This should be done after public discussion, with a chance for all parties to speak. A bad actor is someone who repeatedly ignores the rules and culture of the project, who is needlessly argumentative or hostile, or who is offensive, and who is unable to self-correct their behavior when asked to do so by others.