GovernanceResearch¶

• Table of contents
• GovernanceResearch
  • Introduction
  • Challenges
    • Examples
    • Good practices
      • Explain any project decision
      • Having ways to publicly review and/or challenge decisions.
      • Try to use tools and process that include people
  • References

Introduction¶

The Replicant project sometimes needs to take decisions. The decisions are currently taken by the 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.

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

Examples¶

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

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².

Good practices¶

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 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.

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.

Try to use tools and process that include people¶

Not requiring extra skills for things that don't really need it¶

We cannot expect all Replicant users and contributors to know git or programming, and enabling as much people as possible to participate as much as possible is a good thing.

In order to fix specific issues in the documentation that is on our wiki (duplication, no automation, no integration with Wikidata), we decided to migrate to Mediawiki and not to documention systems like Sphinx in order to make sure that people that were already contributing to the wiki, and other potential contributors weren't excluded.

With mediawiki we can use both programming (through various ways) and simple wiki syntax in the same system, which enables both users that don't know git nor programming to participate, while trying to keep the maintenance cost low enough by automatizing many tasks and not duplicating information.

However if we want to enable people to be paid to work on projects as part of Replicant, and that they need to be able to send patches as part of that, we could ask them to send a specific project description as a patch, as they are already expected to know how to send patches, or at least to learn that for the occasion.

Tools and human interfaces¶

Another area of inclusion would be to use tools that offer several interfaces. For instance if some people are used to forums, while other are used to mail, if that's not too much work, it would be a good idea to have tools that bridge both by exposing a forum interface to the mailing list.

Hardware and infrastructure speed and resources¶

Ideally we should enable people without ultra powerful computers and ultra fast Internet connection to also be able to build Replicant. However while some effort on our side is made to keep the requirements as low as possible (for instance #2056), we still depend on the design choices made by Android which doesn't make that easy. To radically improve in this area, we would probably need to do a huge amount of work by packaging all the Android components in a GNU/Linux distribution in order to enable people to not have to download and build the whole source code just to modify one library. While this could be done, we would also need to have more people involved in such project to maintain it and adapt it to newer Android versions.

As for the Internet connection, we can increase the speed of the fetch by using clone bundles, however we still need to find how this was made to make more clone bundles.

We can also host some repositories for contributors working on Replicant or project closely related to it.

Hardware and software¶

People should be able to contribute to Replicant with laptops and desktops that run fully free software, and that run fully free software distributions.

In practice that means that we should be able to only use FSDG compliant distributions on RYF hardware.

Laws¶

Contributing to Replicant should not require people to break any laws as everyone is not necessarily in position to take legal risks.

Replicant has access to FSF lawyers to help the Replicant project and its contributors to stay away from legal risk.

References¶

¹ 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