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.
1.**Digital commons**: all software produced by the YunoHost project is published as Free Software and will remain Free. YunoHost is developed and maintained mostly by volunteers in an open, horizontal community, that does their best with the time, means and energy they have.
2.**Accessibility**: the design of YunoHost is centered on people with little technical knowledge. Its processes, interfaces and documentation should be simple and educational.
3.**Security**: YunoHost must provide a fairly up to date system, with reasonable security by default, and guide the users on ways to harden their system.
4.**Hackability**: YunoHost must allow its users to take ownership of and modify their installation, to adjust it to their needs, or specific use cases, or uses that are not yet covered, or to tweak the look and feel.
The community organizes regulary meetings who are open to everyone. You can find the date on the forum of project. <small>(Actually these meetings are planned the 1st and 3rd tuesday every month on Mumble.)</small> The notes of these meetings are public as well.
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:
- **Core Group**: work on the central system part of the project (mainly YunoHost, YunoHost-Admin, Moulinette, SSOwat repositories) and on the distribution tools (.deb packages, preinstall images) and development (ynh-dev)
- **Apps Group**: focus on new applications packaging and collectively maintain current apps, work also on catalog index, define good packaging practices and metrics tools for quality control.
- **Infra Group**: deploys, administers, maintains and saves the various services needed by the project (documentation, forum, chatrooms, demo, paste, stack mail, CI, diagnostic, dynette, dashboard, …)
- **Support / doc / comm group**: animates the mutual aid on the forum and the support rooms, ensures the maintenance and update of the doc, communicates on the evolutions of the project on the forum, the social networks, or in conference.
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.
- When a job has significant implications (or, for occasional contributors), it is strongly encouraged to discuss it in advance with the rest of the team to ensure that the imagined implementation fits with the spirit of the project and with the other work of the team.
- Correctly describe its RP and the problem it addresses (and if applicable, the technical details needed to test)
- Ensure the correction of problems reported by the automatic testing tools (CI)
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.
- The "micro" PR: it is a typographical correction, a correction for an obvious bug... These PR can be integrated by its author without explicit validation by another member of the group.
- Medium" PRs: these are maintenance operations (e.g. updating an application, minor cleaning/refactoring, adding a small feature, ...). It is usually better to get a validation from another member of the group.
- The "big project" PRs: these are new features or important refactorings, with major consequences for the future of the project or the app. It is then strongly advised to obtain a thorough validation by at least one other member of the group, and an agreement in principle from the other 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.
- permission to create branches and merge PRs on all app repositories (respecting the rules stated above)
- GitHub: member of the [`Apps` team of the `YunoHost` organization](https://github.com/orgs/YunoHost/teams/apps)
- permission to create branches and merge PR on the catalog repository (apps), exampleynh, packagelinter, packagecheck, ... (respecting the rules stated above)
- Forum: moderator status, member of the [`Support & Doc` group](https://forum.yunohost.org/groups/SupportDoc), possibility to have the group badge visible next to the avatar.
- Diaspora*: access to the account [YunoHost](https://framasphere.org/people/01868d20330c013459cf2a0000053625),
- Twitter: access to the [YunoHost](https://twitter.com/yunohost) account,
- Weblate: administrator on the [translation tool](https://translate.yunohost.org/projects/yunohost/).
