Project

General

Profile

Actions

GovernanceResearch

Introduction

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

It would be better to include more people in it to make the decisions more horizontal:
  • It would remove the single points of failure on the few people that are there
  • The decisions would be better as more point of views would automatically be taken into account
  • 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 rules1.

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

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 Respect your freedom certified on such laptops and desktops to use and contribute to Replicant.

We should also work toward using system that don't force users to run JavaScript even if the code is free software, as forcing people to run code through arbitrary execution of code in a browser is not a good idea. The GNU ethical repository criteria also stated that not forcing users to run JavaScript is a good thing: "All important site functions work correctly (though may not look as nice) when the user disables execution of JavaScript and other code sent by the site. (A0)"

As not everybody runs FSDG compliant distributions we also try our best to enable people running other distributions to participate as well. For instance many Replicant versions can be build in Trisquel lxc chroot. The only exception is probably Replicant 6.0, as we didn't manage to fix that, despite trying hard. As more work went into Replicant 9 and 10, we starting investing more and more effort on Replicant 9 and 10 as they already build with Trisquel 8.0.

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.

The fact that Replicant is fully free software also limits the liability risks as we don't have to redistribute any nonfree software.

References

1 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

Updated by Denis 'GNUtoo' Carikli over 4 years ago · 14 revisions

Also available in: PDF HTML TXT