YunoHost project organisation

Document objective

This document aims at allowing contributors to feel legitimate in contributing to the YunoHost project together with collective feedback. The project is community-based and hasty decisions made by a restricted group of contributors can generate frustrations at a later stage. To address this issue, the proposed solution here is to ensure that decisions are taken collectively and that they are sufficiently thought out. An advisory council provides orientations for the evolution of the YunoHost project and special interest groups allow more efficient contribution in relation to each specific topic.

Definition of YunoHost


The goal of YunoHost is to make accessible to the largest number of people, the installation and administration of a server, without prejudice to the quality and reliability of the software.


A free and community-based software

YunoHost is a software under free licence, fully community-based and based on applications which are themselves community-based and often free (roundcube, baikal, etc.)

That everyone can appropriate

Historically, the project has been very close to initiatives which aim at creating a neutral and decentralised Internet. This proximity especially with the FFDN, has materialised by having some contributors to create the whose mission is to facilitate self-hosting by providing a complete solution including a service (via a VPN) and a device. This militant aspect does not inhibit commercial software initiatives hereby companies could propose support or hosting.

YunoHost organisation

A theme-based, open structure

The objective of the YunoHost organisation is to allow the largest number of people to contribute to software improvement, whether from a technical point of view (development, application packaging) or otherwise (communication, end-user assistance, documentation, etc.). Inspired by the projects which were reviewed at a recent event (Kodi, Debian, Django, Fedora, Wikipedia, etc.) and by ideas stemming from YunoHost contributors (Jérôme, Bram, opi, scith, ju), a decision was made to organise work by special interest groups, federated thanks to a council to key contributors.

YunoHost project organisation schema

Definition and structure of groups

Groups are structured as a result of the fact that YunoHost counts many sub-projects (a total of 13), but without always knowing who is in charge or who is competent. It has therefore been decided to simplify the organisation into sub-projects according to theme-based groups:

Groups are open to all contributors willing to participate to the development of YunoHost. Everyone can register with the communication channels associated with the group they want to get involved with. Everyone is free to exchange with the rest of the group and to submit a decision point which will follow a prior stage of exchange and improvement of the proposal. In order to facilitate its management, each group names a coordinator (and a deputy) whose role is:

The choice of a communication tool is left to each group depending on its relevance (forum, chat, email, etc.)

Definition and structure of the Council

YunoHost is growing and it's important to maintain a coherence among all the groups. However, it is impossible to impose on every member within every group to take interest or to get involved in all aspects of the project (due to time and competency constraints). To address this, it has been suggested that a meta-group be created where every group has at least one representative: hence the Council. The Council is independent of groups and brings together contributors wishing to get involved in the project to the maximum extent. It's role is to:

To take part at Council-level votes, you must have contributed to the project and have obtained a right to vote (or right of entry) at the Council. This right is delivered by the Council (and may be upon request). The Council is free at any moment to change its decision process. To be a member of the Council does not imply that you have access to all resources (infrastructure, repositories, etc.).

A decision process based on soft consensus

Decisions to be taken can be of 2 kinds:

  1. for a group (for example, "to merge a PR" would be assumed by the Dev Group whereas to "post a tweet" would fall under the responsibility of the Communication Group)
  2. for the overall project (for instance, to decide on a release with new features)

If a consensus is not reached over a decision within a particular group, they must refer to the Council for further discussions. If no consensus has been reached, the proposal will be submitted to a vote by all contributors.

The decision process in detail

1) Initiating a decision
2) Opening a discussion with several possible responses:

Anyone can change their position at any moment, but it's expected to let the group react if necessary (e.g. avoid going from positive to negative to reject a proposal altogether after just 3 minutes).

3) Suspension/Postponement
4) Request for modifications
5) Closure
Minor decision
Standard decision:
Major decision:
6) Application

Then a member of a group can announce their decision as effective (and proceed with necessary actions such as releasing, merging, announcing, etc.). If certain actions are required, it's important that people commit themselves to performing them, since a decision without designated people is of little use

Composition of groups

Summary table of the number of views required for a decision

Values are rounded (e.g. 5.4 => 5 and 5.5 => 6).

Minor Standard Major
Standard closure 2 4 5
Anticipated closure 3* 5
Closure by voting 5 5 6
Core Dev
Standard closure 2 3 5
Anticipated closure 3* 4
Closure by voting 4 5 5
Standard closure 2 5 8
Anticipated closure 3* 7
Closure by voting 7 8 9
Standard closure 2 3 4
Anticipated closure 3* 3
Closure by voting 3 4 5
Communication -> Com
Standard closure 2 2 3
Anticipated closure 3* 3
Closure by voting 3 3 4
Communication -> Doc
Standard closure 1 1 Council
Anticipated closure 2* 2*
Closure by voting Council Council Council
Standard closure 1 Council Council
Anticipated closure 1 Council
Closure by voting 1 Council Council

* of which 1 view can be external to the group

For the translation group, the process needs to be adapted.

For the documentation group, the number of views for an anticipated closure of a minor decision eat for the moment limited (there are only 2 people in the group). The other types of decision are taken by the Council.

For the distribution group, since there's only Heyyounow at the moment, the Council will have the task of making Standard and Major decisions.

Administration group's rights

This part list administration rights for differents groups of YunoHost project:

(Warning, this is not decision rights here).


Core Dev







Mutual assistance (support)


Pending decisions for the groups


Core Dev Group

Apps Group

Communication Group


Current means of communication