Governance.md
The Standard for Public Code is a community governed project.
Principles
The Standard for Public Code community adheres to the following principles:
- Open - as little restrictions as possible for anyone to adapt the Standard for Public Code to their context
- Welcoming and respectful - as a community we want to make it easier for new users to become contributors
- Transparent and accessible - changes to the Standard for Public Code, its governance, and any other related activity are done in public
- Ideas and contributions are accepted according to their alignment with project objectives, scope, and design principles
Steering team
The community of Standard for Public Code has one steering team.
Composition
Any active contributor in the community can request to become a steering team member by asking the steering team. The steering team will vote on it (see voting below).
The current team members are:
- Claus Mullie
- Johan Groenen (Tiltshift, Code for NL)
- Rasmus Frey (OS2)
- Josef Andersson (Digg)
- Matti Schneider
Ideally, no single organization will employ a majority of the steering team.
Responsibilities
The steering team members are active contributors who are on a day-to-day basis responsible for:
- Merging pull requests
- Handling code of conduct violations
Besides the day-to-day activities, the steering team has the joint responsibility to:
- Provide technical direction for the codebase
- Maintain a roadmap, and contributing principles
- Resolve issues in development or conflicts between contributors
- Managing and planning releases
- Controlling access rights to Standard for Public Code assets such as source repositories, hosting and project calendars
- Maintaining the mission, vision, values, and scope of the project
- Refining the governance as needed
- Making codebase level decisions
- Managing the Standard for Public Code brand
- Licensing and intellectual property changes
Meetings
The steering team meets regularly. Their agenda includes review of the roadmap and issues that are at an impasse. The intention of the agenda is not to review or approve all patches. (Reviewing and approving patches is done through the process described in CONTRIBUTING.md.)
Decision making process
The decision making process is consent as a default, and voting for certain matters.
Consent
For this community, “consent” means that if you think that a decision is uncontroversial you can just go ahead and make that decision. Any decision made this way is considered supported as long as no one objects. Of course, you have to be prepared to roll back your work if someone does object.
If there is uncertainty about a decision, a steering team member can inform the rest of the team that they are about to take a certain decision. If no team member objects within 96 hours, the decision is considered supported. If objections are made, and no solutions can be found through discussion, a team member can call for a majority vote on a decision, see below.
Voting
Every steering team member has 1 vote. All votes are recorded publicly.
Many of the day-to-day project maintenance tasks can be done with the consent decision-making process. But the following items must be called to vote:
- Adding a team member (simple majority)
- Removing a team member (super majority)
- Changing the governance rules (this document) (super majority)
- Licensing and intellectual property changes (including new logos, wordmarks) (simple majority)
- Adding, archiving, or removing sub-projects (simple majority)
By simple majority, we mean that at least half of the steering team members have voted in favor, and super majority two thirds of the steering team members.
Code of Conduct
The Standard for Public Code’s Code of Conduct is explained in CODE_OF_CONDUCT.md.
If the possible violation involves a team member that member will be recused from voting on the issue. Such issues must be escalated to the steering team contact, and the steering team may choose to intervene.