How will the Collective Code Construction Contract (C4) alter the historical process for reviewing commits contained in Monero pull requests?
How does ZeroMQ relate to the decision to implement C4?
Add a comment
|
1 Answer
C4 is a ZeroMQ spec inspired by Pieter Hintjens and the Monero ZeroMQ implementation meant meant to provide a
reusable optimal collaboration model for open source software projects
According to the specific spec the goals are:
To maximize the scale and diversity of the community around a project, by reducing the friction for new Contributors and creating a scaled participation model with strong positive feedbacks;
To relieve dependencies on key individuals by separating different skill sets so that there is a larger pool of competence in any required domain;
To allow the project to develop faster and more accurately, by increasing the diversity of the decision making process;
To support the natural life cycle of project versions from experimental through to stable, by allowing safe experimentation, rapid failure, and isolation of stable code;
To reduce the internal complexity of project repositories, thus making it easier for Contributors to participate and reducing the scope for error;
To enforce collective ownership of the project, which increases economic incentive to Contributors and reduces the risk of hijack by hostile entities.
For purposes of Monero development the C4 process going forward is designed to look like this:
for i = 1 to 180 days # 6 months of 30 days each, this is a magic for loop that knows when a day passes for i = 1 to 180 days # 6 months of 30 days each, this is a magic for loop that knows when a day passes
new PR gets eyeball review
PR is merged to dev branch
- if merge == crap, new PR made to address crap, goto 1. elseif, goto 4
- if i == 180, merge to master. elseif, goto 1
Compared to historical practices the above will help reduce the workload of some Monero core developers, whose previous practice was to thoroughly review each new PR upon submission. In the past PRs often went to master right away and in the new system they will sit in dev branch for quite some time before being moved to master. This will allow more time (and eyeballs) to review the code long before it has have potential to do harm in master.
This process should be more welcoming to developers new to the XMR codebase who don't need to worry about immediately breaking something in master or requiring a lot of time from the core development team to thoroughly review their PRs right away.
The system is not perfect and it is still possible that hard to detect malicious code could eventually by merged into master, but there are safeguards in place to minimize this risk. On balance the benefits of inclusion and efficiency outweigh the risks in the opinion of the Monero core development team.
