Sarah Jamie Lewis announces her candidacy for the Major Grants Review Committee

[sarahjamielewis]

@mistfpga

Defining the standards for certification and doing the testing, including milestone testing really is not that big of a deal. It is certainly not a part time job in the first year, but after the standards are defined, the testcase database made and a bug tracker put in it is not full time work.

@mistfpga

Sure but micromanagement is not part of this either. 6 week to 3 month milestones with community reports should not be an issue for the MGRC. Just tie funding to passing milestones. Then define passing the milestones based of unit tests and predefine requirements outline at grant approval time.

While I agree with you, to some extent, that certification standardization is a front-loaded process, I also think that tracking grants along any such standard is a very minor portion of what I would consider the work of the committee. These are the ideal cases and the major work of the committee needs to be focused on where these tests fail.

Referring back to a reply I gave in the main thread on the MGRC I think it likely that the committee will be called upon to spent a lot of time responding to deviations from the milestones and ensuring that grant money is invested effectively - I feel the need to emphasize that that often means the most work happens when things don’t go to plan:

@sarahjamielewis

Ideally it would be the role of the committee to shepherd through such applications which, depending on the scope of the work this can take weeks to months of dedicated meetings with applicants, followed by reviewing check-ins and deliverables as they occur once the project is underway. The work doesn’t stop once the grant is approved, arguably that is when the real work of the committee begins.

For example, we must also consider the work required when things don’t go to plan. Schedules fall behind, accidents happen, budgets are overrun, and worldwide pandemics undo weeks of work. Different grant applicants run into duplication of effort or conflicts of interest. Committee members need to be available to respond to requests for changes in scope, budget reallocations, project cancellations and a potential stream of requests for input and oversight.

All that work is multiplied by each project. That oversight takes time and work to do properly. It may be the case that the community prefers to leave such effort to the wider community but that, in my view, would be a mistake and one of the firm reasons I think the committee needs full time effort in some form.

I also think it is worth pointing out that even if we were to accept the idea that the work of the committee might taper off once all the processes and procedures have been put in place, time still needs to be spent building and field testing those processes and procedures in the first place. We can debate the potential steady states of the review committee, but we must acknowledge that the initial term will very much be not a steady-state, it will require dedicated effort from committee members (and with planning that effort should eventually become sublinear to the number of grants). As you put it:

It is certainly not a part time job in the first year

Some more specific thoughts:

@mistfpga

For developers to use the zcash trademark if they need to pass a series of tests. These would be requirements and unit tests.

This seems explicitly outside of the scope of the MGRC given that it has no authority over the zcash trademark (while I could see such a scheme in the future of the MGRC, I don’t think it is a wise use of the MGRC time or resources in the initial few years).

@mistfpga

I really think certification is the way to go not audits. I mean what would be audited against? what standards?

As I mentioned, I don’t think audits are the most effective mechanism for evaluating grant recipients or outcomes but there are several domains in which audits can and might be considered (although these would primarily be financial / organizational audits and I will stress again that I think these should be the exception to applicants, not the rule)

That being said, I will clarify:

@sarahjamielewis

if elected I would push to have a standardized security review process be a mandatory requirement of a technical grants. This may involve funding a team dedicated to this work, or working with existing [external companies] to conduct the reviews.

The MGRC is in a position to help set standards of excellence and practice - and back that up with funding to help teams reach those levels.

Privacy and Anonymity are very peculiar risk models that aren’t served well by most commercially focused security review processes. As Zcash starts gathering a larger number of apps promising the mitigations of such risks I think it is vital that we don’t repeat the mistakes we have seen in other ecosystems and in the early days of the zcash app ecosystem where anonymity is heralded and then apps fall over and expose users at the first hurdle or inappropriately promise anonymity in the name of zcash while doing little to mitigate risks outside of the ones that zcash can protect against.

I think this includes an expectation (and funding of):

• Ethics Review for studies and software (see the Zbay link in my previous post for an example) to discover and capture risks. Grantees (and the committee) have a responsibility to ensure that they aren’t harming the communities they are purporting to support - this means setting up and engaging in ethics reviews and responding to the outcomes. Sometimes this will mean stopping a grant, other times it will be reworking it. I have lost count of the number of community groups, charities and marginalized people I know who will not touch cryptocurrency because earlier groups showed up promising the world, parachuted in a bunch of half working technology and then left those groups to clean up the mess. We need to be better than that.

• Design Review milestones than include explicit risk models and mitigations. One of my biggest fears around Zcash is we end up with a large ecosystem in 5 years that does nothing to advance financial privacy or censorship, and Zcash suffers the same fate as many other privacy ecosystem projects - offering great privacy at one layer while ignoring all others.

• Peer Review of new technologies and software outside of traditional academia and industry committees (e.g. community review where grants are targeting specific groups) - the MGRC should act as a bridge between various parts of the ecosystem, connecting and encouraging work between groups to avoid rework and encourage reuse and integration.

All of that is why I think it is important to push for an active and full time inaugural committee; some of these processes will shape out, others won’t. But developing them in concert with grant applicants, recipients and the community at large is going to take dedicated time and effort. Anything beyond is speculative.