User:LeTopographeFou/Consensus
Jump to navigation
Jump to search
This page is a DRAFT in progress Feel free to improve it.
A consensus, in OSM project, is a generally accepted opinion, and the conclusion of a decision based on collective agreement[1] regarding the way a map feature can be tagged in the database.
Recognized ways to reach consensus inside OSM project
- Widespread acceptance and use of some mapping schema - such tags are attempted to be listed at OSM Wiki as tags with a "de facto" status.
- Discussions on OSM Mailing lists and/or forums and other contact channels.
- Proposal process: Based on three pillars (discussion, documentation and vote)
Nota: While it is highly recommended to document a used schema in this wiki it does not turn the schema into a consensus unless it has been recognized by the community rules as such.
Considerations to have in mind regarding consensus
- A consensus is not an absolute Truth: If any (as a result of a vote or a discussion) it is valid at a certain point in time (we hope: In an infinite time frame), in a given context (we hope: All contexts), among the persons who approved (we hope: All OSM past, now and future members) that such solution is ONE consensus (we hope: THE consensus).
- Consequently a consensus can change, and it is totally ok as soon as it went through a careful impact analysis and a wide discussion. Don't call a past consensus as a protection against a new consensus.
- Even if it is better for OSM to have it worldwide, a consensus can be local (to a country for instance).
- OSM contributions are not constrained by approval of past, present and future consensus inside community but is an open project which rely heavily on every tag you like principle. Consequently human nature will make sure that debates can always happen even after a "consensus" is reached.
- No contributor owns a veto right regarding establishment of a consensus.
- Only DWG can officially interpose against a consensus.
- Consensus is better reached if everyone follows OSM Code of conduct. This implies to be fair in its opinions, in its wording and in its behavior.
- By behavior we include modifying the wiki (or whichever support), on purpose or not, during a hot debate, without highlighting that such modification is not yet a consensus, that a discussion is going on and without notifying the debating peoples.
- A consensus (or an absence of consensus) can be recognized as such only if it is properly documented in a public and recognized place such as in this wiki. Take time to document proposals or existing tag usage even if a consensus is not yet reached and/or a debate is going on. Few contributors are active in the discussions and searching in all mailing list histories can be very hard. This way it makes the information, pros and cons more accessible to new comers in order for them to step into a discussion or propose a solution, even years after.
- A consensus can't be called-out when no evidence of a discussion and shared documentation exists on a topic.
- Consensus quality is not a 48h rush debate where everyone need to give its opinion on the first day and then its urgent to close the debate. It requires time, arguments and reflections (like for votes). Give people (and yourself) time to think.
- For a better consensus quality try to involve in the loop a large panel of contributors but also of data users.
Read more
Consensus decision-making on Wikipedia- On Consensus and Humming in the IETF
- Since late 2019, the openstreetmap-carto project has failed to reach consensus on the process for achieving consensus
- See these Conflict Resolution Patterns in the HackerSpaces wiki: Consensus, Democracy, Command, sudo, Responsibility, Debate Culture, Anti-Bikeshed, Private Talk, Spooky Action Anti-Pattern
Case studies of previous consensus failures
We should list all major previous OSM incidents involving failed consensus after a lengthy debate. Try to enumerate explanations of every factor that could have led to the failure.