Practical governance
Welcoming practices of the AnarBib network
Practical governance document, complementary to the charter. This text describes how the network concretely welcomes a new library applying for membership. It aims to avoid two pitfalls: the bureaucratic bottleneck (where each adhesion requires an unmanageable plenary) and opaque cooptation (where a handful of people decide for the network without debate). It is meant to evolve with practice.
1. Principles
Welcoming a new library is a political act, not an administrative one. It commits the network to cooperate with a new collective over time. It therefore deserves to be taken seriously, without becoming an elitist filter: the network grows naturally through adhesions, it is not a closed club.
Four principles guide the practice:
Welcomed by humans, not by an algorithm. No application is automatically validated or rejected. At each step, it is comrades of the network who read, exchange, decide.
Presumption of welcome. An application is welcomed by default. The network looks for reasons to welcome, not reasons to refuse. A refusal requires explicit and collective justification.
No universal plenary. The network does not gather all libraries to validate each adhesion. That doesn't scale and exhausts comrades.
Decision by silence-consent. Applications are presented to the network through an asynchronous channel (mailing list, chat). Without motivated objection within a given delay, the adhesion is acquired.
2. Practical steps
2.1. Reception
An application arrives (by email at the coordination address, or later via the online form). A coordination person — designated by rotation among the comrades of the network who accept this role — acknowledges receipt within a few days, no more than a week.
The acknowledgement of receipt does not constitute validation. It only says: "we have received, we will process".
2.2. Designation of sponsoring libraries
For each application, one or two libraries of the network propose themselves as sponsors. They can propose themselves spontaneously if they have an affinity (linguistic, geographical, thematic) with the candidate, or be solicited by the coordination.
The role of sponsors:
- get in touch with the candidate, get acquainted;
- answer their questions about the network, the tool, the practices;
- write a short presentation of the candidate to the network (who they are, what they seek, their collection, their roots);
- vouch for them to the network: "we have exchanged, we find this application coherent, we propose to welcome".
Sponsorship is not a moralistic filter. Sponsors do not judge the candidate; they meet and present them.
2.3. Presentation to the network and consent delay
The sponsors send their presentation to the network channel (main mailing list, or equivalent). The message explicitly announces:
"Application from [name of library]. Presentation below. Without motivated objection within two weeks, the adhesion will be considered acquired."
During these two weeks:
- Any member library may ask questions to the candidate (via the sponsors or directly);
- Any member library may formulate an objection;
- Any objection must be motivated publicly on the network channel, not in private.
2.4. Handling objections
If an objection is formulated, the adhesion is suspended for the time of discussion. Three possible outcomes:
The objection is lifted after exchange (misunderstanding, missing information, additional presentation) → the adhesion resumes its course, with a new one-week delay.
The objection persists but remains minority → in-depth discussion on the channel, seeking consensus rather than vote. If consensus does not emerge, we move to the third outcome.
The objection is grounded and shared → the network may decide not to welcome, or to welcome conditionally (for example: adhesion validated, but with a prior exchange on a specific point before opening the instance).
A pure and simple refusal is rare and requires explicit collective justification, communicated to the candidate.
2.5. Validation and activation
Without objection at the end of the delay, the adhesion is acquired. A coordination person:
- notifies the candidate;
- triggers the opening of the instance (according to the chosen formula: network hosting or autonomous installation);
- orients the candidate towards the first-configuration documentation and the sponsors for accompaniment.
3. Roles
Three practical roles appear in this process. None is permanent or hierarchical. All rotate.
First-contact coordination. One or two persons, by rotation of a few months, who read incoming emails at contato@anarbib.org, acknowledge receipt, solicit sponsors. Not a power, a shared chore.
Sponsoring libraries. One or two libraries per application. They get acquainted, present, accompany. Sponsorship ends with the activation of the instance; technical accompaniment for first configuration may continue longer if sponsor and candidate wish.
Network. All member libraries. It is the network that welcomes, through silence-consent or motivated objection. The network has no central body that speaks in its place.
4. What this text does not say
Many things, intentionally.
It does not say how long a coordination person stays in office — that will depend on practice, and probably on a rotation every six months or a year.
It does not say how the network resolves lasting conflicts between libraries. When the moment comes, another practice text will be drafted.
It does not say either how a member library can be excluded from the network (for example if it gravely violates the charter). It is a case that has not yet arisen. When it does, it will be handled with the same horizontality as welcoming: public motivation, debate, consensus, and preferably dialogue before exclusion.
It does not say how to vote, because we do not vote. We seek consensus.
5. Evolution
This text is versioned publicly. It is amended through discussion on the network channel. Any improvement coming from practice is welcome. A short text that describes what the network really does is better than a long text that describes what it should ideally do.
Version 1 — 29 April 2026.