Replicant

h1. GovernanceResearch

h2. Introduction

The Replicant project sometimes needs to take decisions. The decisions are currently taken by the [[SteeringCommittee|steering commitee]].

It would be better if this is made more horizontal:

* It would remove the single points of failure

* The decisions would be better and less horizontal

* Potential individual bias could be smoothed out by having more people taking decisions.

h2. Challenges

The main issues with a more horizontal governance in Replicant are:

* To ensure that the decisions being taken are informed decisions

* The Replicant project doesn't become a nonfree distribution

h3. Examples

Project governance can work in completely horizontal way, however to do that projects typically need to implement some rules[1].

Examples:

* Some free software projects require to follow meetings or pay a membership to be able to vote. The goal behind that is to avoid taking uninformed decisions.

* Events organization projects do manage to take very well informed decisions in a very efficient and fast way[2].

h3. Good practices

h4. Explain any project decision

The decision we take impact the whole Replicant community and potentially beyond as well. So it's a good practice to explain why a decision was taken.

For instance if we decide not to support devices with non-replaceable battery we need to explain the rationale behind that very clearly, this way people can understand the rationale and challenge it if necessary. For instance the [[TargetsEvaluation#Minimal-requirements|Minimal-requirements]] explain why this choice was made.

Not doing that could be very violent for people directly affected by the decision, as they would probably feel that the decision is imposed on them in an arbitrary way, when in reality the Replicant had to do it for the reasons stated (which can be challenged).

It's also a good practice to add the rationale with the decision as people are sure not to miss it and understand the decision better.

h4. Having ways to publicly review and/or challenge decisions.

Since we took the decision on not supporting devices with non-replaceable battery we explained the decision at several occasions, such as the report from the Replicant conference in Paris, the FOSDEM BoF meetings, on the mailing list, on the IRC. If we had found interesting argumentation challenging that decisions we would have been forced to take it into account and document it.

For instance, if many new smartphones with non-replaceable batteries are added in Linux (that situation may or may not reflect the reality), we could add: Complete support for many new smartphones were added in Linux and could work in Replicant if we support devices with non-replaceable battery, however despite that we still decided not to support them due to the increased difficulty to support them for a long time, as we expect to support devices for years after they started shipping.

In a case like that, we could also encourage interested people to fork Replicant to collectively maintain them for as long as possible, and see how well it worked for them, and see if their experience in doing that could be taken back into account in such policy to potentially change it. In a case like that it could also depend if maintainers could all be willing to work on and/or use devices with non-replaceable batteries as well.

h2. References

fn1. https://en.wikipedia.org/wiki/Elinor_Ostrom

fn2. https://media.ccc.de/v/Camp2019-10204-participatory_art_event_tools_co-creation_and_silk_road_networks