Skip to content

Latest commit

 

History

History
116 lines (96 loc) · 4.94 KB

governance.adoc

File metadata and controls

116 lines (96 loc) · 4.94 KB

Governance

The objective of this document is to describe the process of decision making and defines the social rules of interaction for our project.

If you’d like to speak to maintainers of this project, you can reach us through a bunch of different channels.

  • GitHub On github.com, you can always notify the entire project team by using the @github/Continuous-Architecture-Toolkit handle.

  • Slack We’re pretty active on slack.

  • Users are community members who have a need for Continuous Architecture Toolkit. They are the most important members of the community and without them the project would have no purpose. Anyone can be a user; there are no special requirements. We asks users to participate in community and give us as much feedback as they can. User contributions enable the project team to ensure that they are satisfying the needs of those users.
    See Contributor guide for more details.

  • Contributors are community members who contribute in concrete ways to the project. It could be anyone who identify requirements, report issue, add value to the project with a merged pull request, evangelising or help the community to grow.
    See Contributor guide for more details.

  • Maintainers are people responsible over the direction of the project and are committed to improving it in the long run. There are the only people in a project with commit access. See Maintainer guide for more details.

The default decision making mechanism for the Continuous Architecture Toolkit project is lazy consensus. This means that any decision on issues is considered supported by the core team as long as nobody objects.

Silence on any consensus decision is implicit agreement and equivalent to explicit agreement. Explicit agreement may be stated at will.

If any team member raises objections, the team members work together towards a solution that all involved can accept. This solution is again subject to lazy consensus.

To approve change proposals from contributors, Continuous Architecture Toolkit projet apply the Review-Then-Commit policy which requires that all pull-request changes receive lazy consensus approval by maintainers, meaning at least one binding +1 vote and no vetos (-1) in order to be committed.

For other matters that need consensus like:

  • Keep oversight of the pull-requests and ensure that the codebase does not have copyright and license issues, and that the project is heading in the desired direction.

  • Keep oversight of the communication channels and community to ensure that the open development ideals are upheld.

  • Decide what is distributed as products of the project. In particular all releases containd must be approved by the Governance Committe.

  • Guide the direction of the project.

  • Strive for and help to facilitate a harmonious productive community.

  • Nominate new Governance Committee members (i.e. maintainers).

  • Maintain the project’s shared resources, including the codebase repository, communications channels, websites.

  • Speak on behalf of the project.

  • Maintain these and other guidelines of the project

The Continuous Architecture Toolkit project uses a Governance Committee Meeting as the primary forum of decision making. This meeting is organized as required and conducted using a video call. Participation is open to all maintainers. Agenda items can be added by any maintainers by simply adding topics to the Governance Meeting Agenda.

Decisions are taken with a lazy consensus approach except nominated maintainers membership.

Maintainer member status may be given to those who have made major ongoing contributions to the Continuous Architecture toolkit for at least 3 months. This is usually in the form of assets improvements and/or notable work on documentation, but organizing events or community support could also be taken into account.

New members may be proposed by any existing maitainers. It is highly desirable to reach consensus about acceptance of a new member. However, the proposal is ultimately voted on by a formal majority vote (requires more binding +1 votes than binding -1 votes) during Governance Committee.