Contribute on GitHub

Principles

As a community we want make it easier for new users to become contributors and maintainers.

The [codebase] community adheres to the following principles:

[codebase] is open source.

Welcoming and respectful as mentioned in our Code of Conduct [add link]

Transparent and accessible, changes to the [codebase] organization, [codebase] code repositories, and [codebase] related activities (e.g. level, involvement, etc) are done in public

Ideas and contributions are accepted according to their technical merit and alignment with project objectives, scope, and design principles

The maintainers of [codebase] have two steering teams, a technical one and a product one.

Through codebase stewardship the Foundation for Public Code supports the governance of [codebase], the product and technical steering teams, and its community.

Technical steering team members

The [codebase] technical steering team members are active contributors who are on a day-to-day basis responsible for:

Merging pull requests

Handling code of conduct violations

Overseeing the resolution and disclosure of security issues

If technical steering team members cannot reach consensus informally, the question at hand should be forwarded to the technical steering team.

Any active member of the community can request to become a technical steering team member by asking the technical steering team. The technical steering team will vote on it (simple majority).

Technical steering team meetings

The technical steering team has the joint responsibility to:

Provide technical direction for the codebase

Maintain a technical roadmap, an architecture and coding principles

Resolve issues in development or conflicts between contributors

Managing and planning releases

Controlling rights to [codebase] assets such as source repositories

The technical steering team meets regularly. Their agenda includes review of the technical roadmap and issues that are at an impasse. The intention of the agenda is not to review or approve all patches. This is mainly being done through the process described in CONTRIBUTING.md [add link].

If more than one technical steering team member disagrees with a decision of the technical steering team they may appeal to the product steering team who will make the ultimate ruling.

Ideally, no one company or organization will employ a simple majority of the technical steering team.

Product steering team meeting

Responsibilities of the product steering team:

Maintaining the mission, vision, values, and scope of the project

Collecting planned features and presenting them in a unified view

Refining the governance as needed

Making codebase level decisions

Resolving escalated project decisions when the sub-team responsible is blocked

Managing the [codebase] brand

Licensing and intellectual property changes

Controlling access to [codebase] assets such as hosting and project calendars

Members are appointed by the current product steering team members.

Changes in codebase governance can only be done by the product steering team and requires super majority.

Decision making process

The default decision making process is lazy-consensus. This means that any decision is considered supported by the team making it as long as no one objects. Silence on any consensus decision is implicit agreement and equivalent to explicit agreement. Explicit agreement may be stated at will.

When a consensus cannot be found a team member can call for a majority vote on a decision. Every team member has 1 vote.

Many of the day-to-day project maintenance tasks can be done by a lazy consensus model. But the following items must be called to vote:

Code of Conduct

[codebase]’s Code of Conduct is explained in CODE_OF_CONDUCT.md [add link].

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 product steering team contact, and the product steering team may choose to intervene.