I propose that:
VulTech, LLC (i.e. @MrNerdHair) be compensated for leading the Security Workstream at the rate of $16,250/month for the 6-month period starting on January 1, 2022.
The Security Workstream be allocated $50,000 from the DAO Treasury. This is a lump-sum allocation to be used to cover contributor compensation, fixed costs, and test funds, and will be refilled as needed through future proposals.
I propose that the DAO pay the Security Workstream Leader on a salary basis, commensurate with the compensation of the leaders of other workstreams. The downside to this approach is that it may potentially create an appearance that the security workstream leader is paid out-of-proportion to other workstream contributors; personally, I expect to spend a significant amount of my time contributing to other workstreams (primarily Engineering – after all, code quality and investment in sound architecture are first-order security concerns!) but that time will effectively be paid for from the security budget.
Given this structure the Security Workstream Leader will not be eligible to receive compensation via the Coordinape process outlined below, in the interest of preventing even the appearance of a conflict of interest. They will remain eligible for funds made available to Security Workstream members via other proposals (the on-call stipend suggested in SCP-46 is an example of this).
I’ve asked for advice from a few members of the community about the best way to structure workstream leader compensation in this case, and the consensus seems to be that the wisest choice is to stick with the salary model for this role for the sake of simplicity. This seems appropriate to me in the context of a appropriate general bias towards continuity and what we know works, and well as the avoidance of any potential unintended perverse incentives that might be created by a more complicated setup.
While the workstream currently does not have any fixed-cost expenses, this may change in the future as it expands. For example, this could include payment for tools (such as software licenses), services (such as a VPN connection), or even work (such as hiring a consultant or paying an engineer for a one-off project).
Fixed-cost payments such as these will be managed on the basis of consensus, as measured via the Colony reputation system. Any contributor may make a payment motion via Colony for such an expense once consensus has been reached. The Workstream Leader will be responsible to moderate the consensus-forming process and veto any abusive motions.
Security needs a compensation system that’s flexible enough to adapt to a variety of circumstances: from “slow days” through to crisis response. I don’t envision a huge flow of security-specific work, which makes the traditional salary-style model of compensation less of a good fit, and I also expect that some Security Workstream contributors (hopefully, most of them!) will also be contributors to other workstreams.
As such, I propose that the DAO utilize Coordinape to determine Security Workstream contributors’ compensation, with the Workstream Leader acting as a referee (and ineligible to receive funds from the process). This will provide excellent flexibility by valuing contributions using a well-socialized price-discovery mechanism and a broad set of perspectives.
- Coordinape epochs will occur the last week of each month, with the interval subject to adjustment based on real-world experience with the process.
- Each epoch, the Workstream Leader will choose an amount to be distributed. (As we gain experience with Coordinape, my goal is to figure out some kind of consistent formula for this and eliminate my discretion from the process.)
- Coordinape will be used to divvy up the funds allocated for each epoch according to each contributor’s input over the previous month.
- Contributors to any workstream may participate in the Coordinape process, but only those who have made contributions to Security will be eligible to receive GIVE tokens.
- The output of the Coordinape process will be a Colony motion to pay out the appropriate funds; the Workstream Leader will be responsible to veto any such motions that don’t match the Coordinape output or involve abuse of the system.
The Workstream Leader will manage a task-tracking system which will provide the community with transparency into how funds are spent. Tracking tasks will help new contributors to see how they can get started, as well as helping participants in the Coordinape process stay informed about who’s doing things that matter.
Security tasks relevant to a particular repository will be tracked in concert with Engineering; at the moment that means GitHub issues on the associated repo, probably with an extra ‘security’ tag or linked to a Security project board. A different system will be needed to track more general Security tasks, such as review of prospective partners’ code, or ones which need to remain confidential for a period of time; the precise system is TBD at the moment, but there are a number of options. The goal is a Kanban-ish “cards moving right” paradigm with “eventual transparency”, in the sense that any tasks that do require confidentiality (i.e. remediation of reported security issues) will still be tracked in a manner that will eventually (i.e. after the issue is fixed) end up publicly visible.
Security tasks will generally require a degree of trust in the contributor. (A contributor performing a security review will have to be trusted to disclose the issues they find rather than hiding them and exploiting them later; a contributor asked to help remediate a serious security issue will have to be trusted to maintain confidentiality.) For this reason, some tasks may require the approval of the Workstream Leader before beginning work, and some confidential tasks may only be visible to certain approved contributors.
I hope to get this dialed in to a much more deterministic system in the future, but we’re still evolving as an organization and security usually deals with unknown unknowns. There’s also still some level of split-responsibility to be sorted out between workstreams, like which tasks belong as Security initiatives and which belong to Engineering more generally, as well as what’s appropriate to handle via longer-term plans like the roadmap and what should be fast-tracked through the Security process.