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
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
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.
Show replies by date