This document aims at describing the structure and the way the collective works to make development and maintenance of YunoHost possible. More specifically, in line with the values of the project, it is important to:
In a context where the evolution of technological tools lead to major societal challenges, YunoHost advocates an Internet that is decentralised and that allows people to remain in control of their data and their digital tools. One of the tenets of such an Internet is to drastically simplify, make accessible and to democratise server administration, when this is traditionnaly reserved to a technical elite.
As such, the goal of the YunoHost project is to build an operating system and all the necessary tools to install and administer, autonomously and without too many technical skills, a server and digital services in a private context (family, group of friends…) or collective (non profit, company, school…).
The YunoHost collective is close to other like-minded collectives, such as FFDN, Framasoft, CHATONS, or La Quadrature du Net. The collective is also sensitive to ecological issues and inclusivity.
Yunohost is developed and maintained by community of volunteers. The community has an open and horizontal structure.
Members of Yunohost are part of :
The community organizes regulary meetings who are open to everyone. You can find the date on the forum of project. (Actually these meetings are planned the 1st and 3rd tuesday every month on Mumble.) The notes of these meetings are public as well.
This refers to the people who use YunoHost in their daily life, who ask for help, speak about bugs and make contributions.
The community is aware about the importance to listen to users and take advice about their contributions for the future of the project.
These are the people who contribute to the project on an ad hoc basis. Any person wishing to do so is, without prior agreement, welcome and entitled to contribute to the project (provided that they do not go against the values of the project).
The community provides as much documentation and tools as possible to guide new contributors in their first contributions in a spirit of caring.
Contributions often take the form of Pull Request (PR) (for example, on the core, on the apps, on the doc, ...) but can also be translations, graphic elements, security audits, etc...
With some exceptions, occasional contributors can help with reviews, but they do not act to integrate their work into the project. They also do not have a vote in formal decision-making. They are, however, welcome to express their opinions if they wish.
These are the people who regularly contribute to the project in the form of work, ensure the review and integration of the work of other contributors, as well as the short and long term maintenance of the project as a whole.
Regular contributors are organised into working groups:
Since there are multiple connections between these different themes, it is not uncommon for a person to be a member of several of these groups. Nevertheless it is necessary and sufficient to be a member of one of these groups to obtain the status of regular contributor.
Anyone who has already contributed at least once to the project can apply for regular contributor status. This request is then subject to a vote of acceptance by all the other regular contributors.
Being a member of a group entitles you to certain administrative rights detailed in appendix A, typically the right to validate and integrate your own work or the work of other contributors. Good use should be made of these rights as described in the next section. Being regular contributors also makes it possible to propose a vote when it is necessary to formally record a decision for the project.> 
Regular contributors are expected to coordinate regularly with the rest of the team, for example by participating in meetings or via chat and forum.
The loss of membership of a group takes place by voluntary departure of the person, or following a vote of radiation for inactivity, non-respect of the charters or the values of the project, or abuse of the rights of administration.
Due to the nature of the project, contributions are mainly made in the form of "pull requests" (PR) or "merge requests" (MR). The realization, the review, and the collective validation of PRs are important issues, since they are precisely what makes the project alive from a purely technical point of view.
Behind each integration request can be hidden various human and technical issues among which stability (not breaking everything because of an unforeseen branching), security (not introducing flaws or malicious code), durability (limiting the bus factor and the technical debt), pragmatism ("good enough"), agreement with the spirit of the project (UX, ..), evolution on the short and long term. The review and validation process of a PR is also a complicated exercise insofar as it is time consuming, and can be a source of tension or frustration. One of the obstacles to the validation of a PR is also often linked to a feeling of lack of legitimacy in accepting the integration of a PR, or to the psychological impact of being the person who has accepted the integration of a PR.
A crucial issue in the organization of the project is therefore to find a set of rules and good practices that allow for a fluid, balanced operation, with validation as much as possible by consensus, and that distributes the responsibility to the collective rather than to individuals.
This section details the process of validating the RPs in the different repositories of the project. The objective of this process is to achieve a "soft consensus".
Contributors are individually and collectively responsible for gauging the importance of an RP to define the extent to which it should be lightly or thoroughly validated by other group members.
Other contributors may freely take part in the review of an RP. The author of an RP may also request or remind other contributors that their RP is awaiting review. After a certain period of time, if it appears that no contributor has time or energy available to participate in the review of an RP, then it can still be merged by its author.
If a disagreement emerges during or after the validation of a PR, a cordial discussion should be held with the rest of the team in order to reach a consensus on the way forward. If no consensus is reached, a vote is held to make a decision, in which all regular contributors to the project can participate.
When Regular Contributors need to make a formal decision about the project ("resolution"), or to resolve a conflict after a consensus search has failed, any Regular Contributor can initiate a formal voting process. All regular contributors can take part in this vote.
This part lists the administration rights for the different groups of the YunoHost project.
N.B. these are not decision making rights, but access and modification rights on the different platforms used by the project.
Members of these groups agree to abide by the project's system administration policy.
Appsteam of the
Infrateam of the
Docteam of the
Support & Docgroup, possibility to have the group badge visible next to the avatar.
Last updated on 2022-03-15
Found errors? Think you can improve this documentation? Simply click the Edit link at the top of the page, and then the icon on Github to suggest changes.