Governance model

Our goals in setting up the governance structures of Redcurrant is to ensure that there is a defined process that helps people contribute to decisions regarding the Redcurrant community and distribution. It should be clear who is responsible for any given decision, and how others might contribute to the making of it.

The diagram below illustrate the governance model chosen for Redcurrant (RC) :


Roles and responsibilities

It describes the formal roles and their authority within the project. It also describe the level of commitment required and how one seeks to engage in each role. The goal of this section is to make it clear who manages the project, who can contribute and how they may contribute.

The defined roles are :


A user is someone that uses our software. He contribute to the Redcurrant software by providing feedback to developers in the form of bug reports and feature suggestions.


A developer is a user who contributes to a project in the form of code or documentation. He take extra steps to participate in a project, provide patches, documentation, suggestions, and criticism. Developers are also known as contributors.


Board members are composed of WL collaborators and an industrial partner.
A board member can be a developer, user, product manager, project leader, functional person or a committer that was given write access to the code repository. Board makes the decisions, not the individual people. They have write access to the code repository, the right to vote for the community-related decisions and the right to propose an active user for committer ship. Board as a whole is the entity that controls and leads the project, nobody else.

Board :

  • Lead all technical aspects of the project; for example, the project roadmap, development, release cycles, versioning, and QA.
  • Designate Verifiers and Approvers for submitted patches.
  • Be fair and unbiased while reviewing changes. Accept or reject patches based on technical merit and alignment with the Redcurrant strategy.
  • Review changes in a timely manner and make best efforts to communicate when changes are not accepted.
  • Optionally, maintain a web site for the project for information and documents specific to the project
  • Is responsible for the technical direction that Redcurrant takes. It makes decisions on package selection packaging policy, installation systems and processes, kernel, X server, library versions and dependencies, Legal stuff. The board works together try to establish a consensus on the right direction to take.
  • Will insure the control of the quality and legal oversight of contributions coming from external users and developers, they will check if it is sufficiently robust to produce a reliable and legally sound software output.

Voting system

Certain actions and decisions regarding the project are made by votes on the project development mailing list. Redcurrant voting may take place on the private RD Board mailing list.

Who gets to vote?

  • Two representatives from Worldline
  • A representative from WL Industrial partner

Votes are normally open for a period of one week to allow all active voters time to consider the vote. If no quorum, then the vote fails, and would need to be raised again later. Votes relating to code changes are not subject to a strict timetable, but should be made as timely as possible.

Voting procedure

Discussion about the topic would have already happened in a [Proposal] email thread to express the issues and opinions. The [Vote] thread is to ratify the proposal if that is felt to be absolutely necessary.

The instigator sends the Vote email to the dev mailing list. Describe the issue with no ambiguity and in a positive sense. Define the date and time for the end of the vote period.

Votes are expressed by replying email using the voting symbols defined bellow. At the end of the vote period, the instigator tallies the number of final votes and reports the results.


Votes are expressed using one of the following symbols:

  • +1 : “Yes, “Agree,” that “the action should be performed.”
  • -1 : “No”, Not agree that “the action should be performed.”

All participants in the project are encouraged to show their preference for a particular action by voting.

Types of approval

Different actions require different types of approval:

  • Not approved : Requires more (-1) votes than (+1) votes
  • 2/3 majority : Requires at least 2/3 of the votes that are cast to be (+1)
  • Unanimous consensus : All of the votes that are cast are to be (+1).


Action Description Approval
Code change, RoadMap Changed A change made to a code base of the project by a committer. This includes source code, documentation, RoadMap2/3 majority or unanimous approval
Nothing to do Request rejectedNot approved

Submitting new feature requests

When submitting a request for a new feature make sure to keep it as brief. It is up to the board to determine when new features are added, according to the development plans they have made.

Contributors’ agreement

In order to accept a patch we require that you first complete an Individual Contributor’s Licence Agreement. Once this agreement has been completed and a patch is accepted then the differences will be applied to the original source code or documentation by the project team and committed to the source code repository.

User Tools