Planning and project management

Scope

Running an open-source project includes defining its rules of operation and its future. Open-source projects should do this in an inclusive way, fostering community engagement in any part of the process.

Defining the rules

Open-source projects should have their rules of operation written down, visible to the public. This includes at a minimum the elements discussed in this page.

Rules should include a code of conduct; the use of the Contributor Covenant is recommended. This adds to the requirements imposed by the contributors' employer; for any project hosted at CERN's github, the CERN Code of Conduct applies as well. This should be made explicit on the project's website.

Changes of the rules should be rare and by consensus; unanimity might be required among institutional / key contributors.

Rules should be enforced, community-wide. This adds to the credibility of the project; if done well it encourages people to engage and say their mind rather than scare people away.

Running the project

The project should have regular, announced meetings for which attendance is open to all contributors / developers. Minutes of these meetings should be public.

Decisions should be made by consensus; votes should only happen in exceptional cases to not marginalise developers and not further materialise lines of conflict / disagreement.

Keeping a project inclusive is work: it is insufficient to stop scaring people away. The project should actively invest in the visibility and acknowledgement of all main contributors and contributing institutes. Common approaches are AUTHORS or CONTRIBUTORS files, and / or logos of contributing institutions on the project's website.

Evolution

Discussing and deciding on a project's evolution should be part of the formal process of the project. The plan for new features and even the plan of work of the developers should be publicly shared. Input should be solicited from users and contributors.