Purpose

These guidelines are designed to promote transparent, inclusive, and equitable decision-making within F-Droid. The aim is to ensure that community input is valued and that decisions serve the collective interests of the community.

Consensus

Consensus is defined as an agreement that all members can accept, even if it is not everyone’s first choice. Consensus is considered achieved when someone explicitly proposes that consensus has been reached and no one objects. The proposer should clearly state the consensus and the resulting actions, unless those actions are self-evident. If consensus cannot be reached, a voting process is initiated.

Inclusive participation

F-Droid encourages active participation from all community members through GitLab, the Forum, and other communication channels.

“Decision makers” are defined as individuals who are Members of the F-Droid group on GitLab.

If a member needs to be removed, there must be valid reasons, and the Code of Conduct Committee and/or Board will be asked to intervene.

Transparency

We are committed to making decisions as openly as possible, defaulting to public discussions and documentation.

All discussions, proposals, and decisions are recorded and made accessible to the community unless they contain sensitive information. If possible, once the content is no longer considered sensitive, it will be made public.

Conflicts of interest must be openly declared during decision-making.

Decision-making processes

Most F-Droid work is technical, such as bug fixes or metadata updates. Anyone can propose changes, and others may contribute, discuss, and vote with thumbs up or down. Typically, a concluding post summarises the decision and proposes consensus. For minor, non-controversial decisions, consensus is implied. If a committed change lacks consensus, maintainers can quickly revert it and continue discussions until consensus is reached. If a change may be controversial or requires broader input, the proposer should seek feedback from the group and the Board before proceeding. Examples include:

• Significant changes to website content or historical practices

• Merge requests from maintainers not approved by other Members

• Actions or statements representing F-Droid outside its core mission

The Board should be consulted for:

• Policy changes

• Allocation of F-Droid funds

In cases of conflict of interest, individuals should recuse themselves. If people with a conflict of interest do not self-identify, then others can notify the Board of a potential confict of interest and the Board will discuss with that individual.

When consensus cannot be reached

Core contributors (those with Reporter status), maintainers, and the Board should attempt to resolve issues in Gitlab comments, collaborative documents, or meetings as needed.

A designated timeframe should be set at the outset for efficient decision-making. Ideally, someone volunteers to track arguments, summarize points of agreement/disagreement, and guide the conversation. If consensus remains unattainable, the issue is put to a vote.

Voting procedure

Each proposal is submitted as a separate GitLab comment. Core contributors, maintainers and the Board are requested to vote thumbs up or down on each proposal. People can vote for multiple proposals. After the voting period ends, votes are counted and the proposal with the most support is adopted.

If a collective decision cannot be reached by vote, the Board will make the final decision, following its established procedures.

Board and Technical Lead roles

The F-Droid Board is a meritocratic committee responsible for making, delegating, and coordinating decisions on behalf of the user and developer community. The Board may establish committees or taskforces and assign roles to qualified individuals for advice and support. The Board assists in decision-making when consensus cannot be achieved, for controversial changes, policy updates, and fund allocation.

The Technical Lead may, in exceptional circumstances, overrule technical decisions made by Core Developers and Maintainers. Such decisions can be appealed to the Board. During the appeal process, the Technical Lead does not vote.