What is the difference between Catalyst’s current Proposal-Reviewers model of proposal review before community vote, and the deployment of a refinement + consent process per proposal described in general terms in our recent post: “How could Catalyst (and other distributed organizations) be better, more efficient, more resource-conscious (money, time, requirements, etc.) for Catalyst itself and for the Proposer’s community? By deploying a refinement + consent process per proposal. What is that?”?
It turns the former proposal reviewers, now a consent group, into co-creators of it, leading to rapid refinement of its text and effective debugging.
This concept is close to the heart of the open-source development community, with the Linux kernel as one of its most emblematic success stories. One of the things that the building of a system as complex as Linux has demonstrated is that creating mechanisms for participation is not enough: an environment must be created in which people move from being users to co-developers, stimulated by the desire to find the bugs in the latest code release. Such a situation, put in place in the confines of a system like Catalyst, whose community of Reviewers fund after fund is considerable, would turn proposals into living entities in state of improvement and transformation.
In the current Proposal-Reviewers model of proposal review, Reviewers are miles away from being able to modify and contribute to the code that shapes the proposal. The refinement + consent process puts Proposals and Reviewers in the same room, with the proposal content ready to be debugged for possible objections (Objections: Reasoned concerns that identify risks that could prevent the proposal from being carried out efficiently).
— -
Thanks to Eric S. Raymond for his time-proof essay, “The Cathedral and the Bazaar”