Any Free/Libre Open Source Software project will have elements of do-ocracy (rule of those who do the work) but this approach does not work for all decisions a software community must make.
Largely of necessity in heavily volunteer-driven projects, all people who must carry out a decision have to consent to the course of action. Everyone should get a say in the direction and conditions of their work (and no one gets to say they are just following orders).
A good decision-making process requires everyone involved be heard from, and encourages making decisions based on data and scheduling a time to revisit decisions.
We'll talk about ways we can do even better, but the nature of needing the consent of people to do the work, to carry out a decision, gives us a good minimum baseline in our processes for much of what we do.
When a decision strongly affects more than those who cary it out, however, we need better ways of making these decisions. We can scale conversations and decisions in a fair and truly democratic way.
- Come with at least a passing familiarity with various ways decisions are or have been made in Drupal.
- Leave knowing about sociocracy and sortition and how these esoteric concepts could make our community scale
I have presented at multiple DrupalCons — Boston (Knight Foundation panel), Washington DC (Taxonomy), Paris (Taxonomy and RDF sessions), Portland (Decision-maker training), Munich (RDF) — and led Birds-of-a-Feather at many more (on topics such as contributing to the community, authoring (well-regarded) Drupal books, and worker cooperatives), in addition to panels, presentations, and workshops at multiple Drupal and non-Drupal summits and camps, including NYCCamp, Design for Drupal Boston, Boston GNU/Linux Meetup, New England Drupal Camp, the NERD Summit, and most recently DrupalCamp Montreal 2017 and Twin Cities DrupalCamp 2017.