User:RobLa-WMF/CBCI
Consensus-based conceptual integrity (CBCI) an attempt to satisfy the following simultaneously:
- Have a system with conceptual integrity
- Develop Wikimedia's site software by the consensus of the developers working on it
Conventional wisdom suggests that these two are mutually exclusive. Fred Brooks wrote in 1995: "Having a system architect is the most important single step toward conceptual integrity...after teaching a software engineering laboratory more than 20 times, I came to insist that student teams as small as four people choose a manager, and a separate architect."[1]
An efficient and effective CBCI process would allow us to defy conventional wisdom, ensuring our site software still maintains conceptual integrity despite the lack of an authoritarian central architect.
How to do it[edit]
The short answer: I don't know, but I'm really trying to figure it out. Much of my past year has been spent working ArchCom in the direction where we can provide conceptual integrity for the MediaWiki architecture and other important elements of the Wikimedia software stack. A lot of the work has been in developing ArchCom's team practices.
Other reading on the topic:
- Good meetings - these guidelines were developed in anticipation of WikiDev16
- Consensus - this document spun out of the "Good meetings" document
- IETF RFC 7282 - On Consensus and Humming in the IETF - the spiritual parent of this document
- Reinventing Organizations Wiki: "Decision_Making" - This describes the AES "Advice Process", which appears to be very similar to IETF's "Rough Consensus"
- "Simplifying Management: Why Organizations Without Hierarchy Really Work" - Dan Wellers - Another description of the AES Advice Process.