Join the MontiCore Community!

Stay connected, exchange ideas, share your experience, and help shape the future of MontiCore.

Join the MontiCore community mailing list now:

MontiCore Open Source Project - Governance

Overview

This is a consensus-based community project. Anyone with an interest in the project can join the community, contribute to the project design, and participate in the decision-making process. This document describes how that participation takes place and how to set about earning merit within the project community. In general, this project follows an open-source governance strategy, which is a combination of a do-ocracy for operative decisions and a self-appointing council for strategic alignment.

Roles and responsibilities

Users

Users are community members who require the project. They are the most important members of the community. Without them, the project would have no purpose. Anyone can be a user; there are no special requirements. The project asks its users to participate in the project and community as much as possible. User contributions enable the project team to ensure that they are satisfying the needs of those users. Common user contributions include (but are not limited to):

evangelizing about the project (e.g., a link on a website and word-of-mouth awareness raising)
informing developers of strengths and weaknesses from a new user perspective
providing moral support (a ‘thank you’ goes a long way)
providing financial support (the software is open source, but its developers need to eat)
supporting new users (existing users are often the best people to support new users)
providing examples (e.g., languages, models)
providing success stories from their user perspective in projects

Users and other stakeholders may add themselves to:

The MontiCore community mailing list (reading and unmoderated writing)

Users who continue to engage with the project and its community will often become more and more involved. Such users may become contributors.

Contributors

Contributors are community members who contribute in concrete ways to the project. Anyone can become a contributor (and is being denoted in the Contributing.md), and contributions can take many forms. There is no expectation of commitment to the project, no specific skill requirements, and no selection process. In addition to their actions as users, contributors may also find themselves doing one or more of the following in the context of MontiCore:

reporting bugs
identifying requirements
providing graphics and web design
programming
assisting with project infrastructure
writing documentation
fixing bugs
adding features

Contributors engage with the project through the issue tracker and developer mailing list, or by writing or editing documentation. They submit changes to the project itself via patches, which will be considered for inclusion in the project by existing committers (see next section). The developer mailing list is the most appropriate place to ask for help when making that first contribution. Contributors get access to:

The MontiCore community mailing list (reading and writing)
The MontiCore developer mailing list (reading and writing)

As contributors gain experience and familiarity with the project, their profile within and commitment to the community will increase. At some stage, they may find themselves being nominated for committership.

Committers

Committers are community members who have shown that they are committed to the continued development of the project through ongoing engagement with the community. Committership allows contributors to more easily carry on with their project related activities by giving them direct access to the project’s resources. That is, they can make changes directly to project outputs, without having to submit changes via patches. This does not mean that a committer is free to do what they want. Committers have no more authority over the project than contributors. While committership indicates a valued member of the community who has demonstrated a healthy respect for the project’s aims and objectives, their work continues to be reviewed by the community before acceptance in an official release. The key difference between a committer and a contributor is when this approval is sought from the community. A committer seeks approval after the contribution is made, rather than before. Seeking approval after contributing is known as a commit-then-review process. It is more efficient to allow trusted people to make direct contributions, as the majority of those contributions will be accepted by the project. The project employs various communication mechanisms to ensure that all contributions are reviewed by the community as a whole. By the time a contributor is invited to become a committer, they will have become familiar with the project’s various tools as a user and then as a contributor. Anyone can become a committer; there are no special requirements, other than to have shown a willingness and ability to participate in the project as a team player. Typically, a potential committer will need to show that they have an understanding of the project, its objectives, and its strategy. This is demonstrated by having provided valuable contributions to the project over some time. New committers can be nominated by any existing committer. Once they have been nominated, the project steering committee (PSC) will vote on them using a majority vote. Committer voting is one of the few activities that takes place in the PSC. This is to allow PSC members to freely express their opinions about a nominee. Once the vote has been held, the aggregated voting results are published on the public mailing list. The nominee is entitled to request an explanation of any ‘no’ votes against them, regardless of the outcome of the vote. This explanation will be provided by the PSC Chair and will be anonymous and constructive. Committers get access to:

The MontiCore community mailing list (reading and writing)
The MontiCore developer mailing list (reading and writing)

Nominees may decline their appointment as a committer. However, this is unusual, as the project does not expect any specific time or resource commitment from its community members. The intention behind the role of committer is to allow people to contribute to the project more easily, not to tie them into the project in any formal way. It is important to recognize that committership is a privilege, not a right. That privilege must be earned and once earned it can be removed by the PSC in extreme circumstances. However, under normal circumstances, committership exists for as long as the committer wishes to continue engaging with the project. A committer who shows an above-average level of contribution to the project, particularly to its strategic direction and long-term health, may be nominated to become a member of the PSC.

Project Steering Committee (PSC)

The project management committee consists of those individuals identified as ‘project owners’ on the development site. The PSC has additional responsibilities over and above those of a committer. These responsibilities ensure the smooth running of the project. PSC members are expected to review code contributions, participate in strategic planning, approve changes to the governance model, and manage the copyrights within the project outputs. Members of the PSC do not have significant authority over other members of the community, although it is the PSC that votes on new committers. It also makes decisions when community consensus cannot be reached. In addition, the PSC has access to the project’s private mailing list and its archives. This list is used for sensitive issues, such as votes for new committers and legal matters that cannot be discussed in public. PSC members get access to:

The MontiCore community mailing list (reading and writing)
The MontiCore developer mailing list (reading and writing)
The MontiCore PSC mailing list (reading and writing)

Adding Members

Membership of the PSC is by invitation from the existing PSC members. A nomination will result in discussion and then a vote by the existing PSC members. Nominees must receive a majority vote from existing members to be added to the PSC.

Stepping Down

Turnover within the PSC is allowed and expected as people move from one project to another or simply move on to a different role. If for any reason a PSC member is not able to fully participate then they are free to step down. If a member is not active (e.g., no voting, mailing list, or convention participation) for six months then the PSC reserves the right to remove that member from the PSC via suggestion from a PSC member and a majority vote. Likewise, should a member of the PSC repeatedly begin to act counter to the goals of the project as a whole, then a PSC member can suggest removing that member from the PSC. Again in this case a majority vote is required to remove that member from the PSC. In both cases, the PSC is then free to seek nominations to fill that position.

PSC Chair

The PSC Chair is a single individual, voted for by the PSC members. Once someone has been appointed Chair, they remain in that role until they choose to retire, or the PSC casts a two-thirds majority vote to remove them. The PSC Chair has no additional authority over other members of the PSC: the role is one of coordinator and facilitator. The Chair is also expected to ensure that all governance processes are adhered to and has the casting vote when the project fails to reach a consensus.

Support

All participants in the community are encouraged to provide support for new users within the project management infrastructure. This support is provided as a way of growing the community. Those seeking support should recognize that all support activity within the project is voluntary and is therefore provided as and when time allows. A user requiring guaranteed response times or results should therefore seek to purchase a support contract from a community member. However, for those willing to engage with the project on its own terms, and willing to help support other users, the community support channels (i.e., mailing lists and issue boards) are ideal.

Contribution process

Anyone can contribute to the project, regardless of their skills, as there are many ways to contribute. For instance, a contributor might be active on the project development mailing list and issue tracker or might supply patches. The developer mailing list is the most appropriate place for a contributor to ask for help when making their first contribution.

Request for comments documents (RFC)

RFCs are more formal documents that are required for significant technology, process, or political changes to the project. They typically include both the motivation behind the proposal and a detailed description of the change. Any interested party can write an RFC not just PSC members and committers. Once written they are posted to the project site and an announcement is made to the PSC mailing list. Technical RFCs should also be announced on the developer mailing list. The author should incorporate and/or respond to all comments received within one week and repost an updated copy of the RFC. At that point, a motion can be brought to the PSC for a vote to either accept or reject the RFC. An RFC is required when:

Significant new features are added to the project.
Changes affect the architecture of the software or component interaction.
Changes require API or file format modification.
Changes may impact backward compatibility.
Changes to project policies or procedures.
Anything that establishes or affects relationships with external entities.

An RFC is not required for bug fixes or minor enhancements that do not rework any substantial amount of code. After reading this if you are not sure whether an RFC is required or not, ask the PSC via e-mail and we will decide.

Decision-making process

Decisions about the future of the project are made through discussion with all members of the community, from the newest user to the most experienced PSC member. All non-sensitive project management discussion takes place on the project contributors’ mailing list. To ensure that the project is not bogged down by endless discussion and continual voting, the project operates a policy of lazy consensus. This allows the majority of decisions to be made without resorting to a formal vote. Decisions can also be made at the MontiCore Symposium by the actively participating committers. Those should normally be prepared in advance allowing each committer to understand the consequences.

Process

The decision-making process is based on reaching a democratic consensus by having an open discussion followed by a vote. Decision-making typically involves the following steps:

Proposal (or RFC)
Discussion
Vote (if consensus is not reached through discussion)
Decision

Any community member can propose for consideration by the community. To initiate a discussion about a new idea, they should send an email to the developer mailing list or submit a patch implementing the idea to the issue tracker (or version-control system if they have commit access). This will prompt a review and, if necessary, a discussion of the idea. The goal of this review and discussion is to gain approval for the contribution. Since most people in the project community have a shared vision, there is often little need for discussion to reach a consensus.

Proposals can be brought forth by any interested party on the developer mailing list, or in regular Sprint-like (DEV) meetings. Depending on what is being proposed it may be informal (e.g., email description sufficient) or based on an RFC. After an open discussion of the proposal, a motion to vote on it must be made within one week.
All voting is based on a motion made either on the PSC mailing list or in a DEV meeting.
If the motion is made on the mailing list a deadline of at least two working days and preferably one week must be given.
If the motion is made in an DEV meeting there must be a 2/3 quorum in attendance in order to vote. Members not present can still veto within 24 hours of the meeting minutes being posted and distributed on the PSC mailing list.
PSC members can vote "+1" to indicate support for the change request and a willingness to support implementation.
PSC members can vote "-1" to veto a proposal, but must provide clear reasons and alternate approaches to solving the problem.
A "0" vote indicates no opinion.
Anyone may comment or provide input to motions, but only PSC member votes will be counted.
A motion will be accepted if it receives "+2" (including the proposer if applicable) and no veto's "-1".
If a motion is vetoed, and it cannot be revised to satisfy all parties, then it can be resubmitted for an override vote in which a majority of all PSC members must vote "+1" in order to pass it.
Upon completion of the discussion and voting the proposer should announce whether they are proceeding (motion accepted) or are withdrawing their motion (vetoed).
The addition and removal of PSC members and Committers is handled as a motion, however, a majority vote is required in these cases.
The Chair gets a vote and is responsible for adjudicating should there be a voting dispute.

Lazy consensus

In general, as long as nobody explicitly opposes a proposal or patch, it is recognized as having the support of the community. This is called lazy consensus - that is, those who have not stated their opinion explicitly have implicitly agreed to the implementation of the proposal. Lazy consensus is a very important concept within the project. It is this process that allows a large group of people to efficiently reach a consensus, as someone with no objections to a proposal need not spend time stating their position, and others need not spend time reading such Emails. For lazy consensus to be effective, it is necessary to allow at least 72 hours before assuming that there are no objections to the proposal. This requirement ensures that everyone is given enough time to read, digest and respond to the proposal. This time period is chosen so as to be as inclusive as possible of all participants, regardless of their location and time commitments.

Voting

Not all decisions can be made using lazy consensus. Issues such as those affecting the strategic direction or legal standing of the project must gain explicit approval in the form of a vote. Every member of the community is encouraged to express their opinions in all discussions and all votes. However, only project committers and/or PSC members (as defined above) have binding votes for the purposes of decision-making.

Responsibilities

The PSC is responsible for all aspects of managing the Open Source project including setting the overall direction of the project and releases, determining what features go in and when, and how those features are implemented. This section outlines the responsibilities of the PSC as a whole and the responsibilities of its members.

Committee Responsibilities

Feature Development and Release Management

The PSC is responsible for defining the project roadmap, deciding which new features and significant code changes are accepted into the project, and into which release the change will appear. Deciding what features are accepted and when is a multi-faceted decision, but the roadmap will always have a strong influence. New project features and/or functionality are proposed to the PSC via an RFC. Once the request is submitted, the PSC uses the decision-making process to decide if the change will be accepted and which release it will go into. In addition, the PSC determines when a branch enters the stabilization phase and ultimately when it is ready for release.

Project Policies and Procedures

The PSC is responsible for defining the policies and procedures for the MontiCore Open Source project, including:

Code Reviews
Documentation Requirements
Granting and Revoking Commit Access
Testing Requirements
Branch Practice
Release Schedule (Frequency and Timing)
Version Numbering

Preparation and Implementation of the MontiCore Convent The PSC organizes an annual convent (summit, workshop, conference) inviting the MontiCore community, i.e., developers and users, to participate physically to exchange information, ideas, new findings, insights, etc. As part of the convention, the PSC discusses and decides future topics, research, and development directions.

Member Responsibilities

Guiding Development Efforts

PSC members should take an active role in guiding the development of new features they feel passionate about. Once a change request has been accepted and given a green light to proceed does not mean the PSC members are free of their obligation. PSC members voting "+1" for a change request are expected to stay engaged and ensure the change is implemented and documented in a way that is most beneficial to users. Note that this applies not only to change requests that affect code, but also those that affect the website, procedures, and policies.

Regular Development Meeting Attendance

Committers are expected to participate in the regular development meetings. If known in advance that a committer cannot attend a meeting, the committer should let the organizer know. Continuously missing the development meeting may result in the committer being asked to step down to make way for a more active committer - in case this committer is a PSC member, it is also asked to step down from the PSC. Non-Project Developer PSC members are expected to review the development meeting records.

Mailing List Participation

PSC members are expected to be active on both the user and developer mailing lists, subject to open-source mailing list etiquette. Non-developer members of the PSC are not expected to respond to coding-level questions on the developer mailing list, however, they are expected to provide their thoughts and opinions on user-level requirements and compatibility issues when Change Request discussions take place.

Founding PSC

Nico Jansen
Judith Michael
Bernhard Rumpe (Chair)
David Schmalzing
Andreas Wortmann

Aachen and Stuttgart, 11.12.2024