MGRC Update 11-18-2020 and Meeting Minutes

Community Grants Community Grants Updates
1

Hey Zeal!

Sorry for the late posting of this Wednesdays MGRC meeting notes, it has been a busy week. This was an additional meeting in between the normal bi-weekly cadence. We really wanted to hammer out the grant review process with everyone in person (live video) so the majority of this meetings time was spent on discussing and updating that document. We are working to finalize the grant process document and once finished it will be publicly posted.

We are also working on the logo, website, and grants platform changes asynchronously to prepare for launch.

MGRC Zoom Meeting: November 18th, 2020

[Minutes taken by Danika]

Meeting minutes:

Attendance:

  • Hudson Jameson

  • Sarah Jamie Lewis

  • Shawn

  • Chris Burniske

  • Holmes Wilson

  • Danika Delano acting as notetaker

Notes:

  • Chris was getting 404 error message when he clicked on the GitHub invitation link so Shawn volunteered to contact Antonie so she can help resolve (make unprivate, add Chris, then private again)

  • Per Holmes’ request, everyone looked through the ticket on repo (Grants.io). Chris brainstormed how to change the banner where the Zcash foundation logo is currently. Everyone agreed it should say “Zcash grants.” Holmes stated that he would open tickets with Grant.io.

  • Discussed MGRC separate forum topics it was decided that there would be a header of grants then a subheader for “applications” and discussions. Shawn volunteered to create the new category before launch.

Chris led the discussion on the grants process by resolving questions on a Google doc. The committee made the following decisions surrounding the grant process:

  • KYC: At the beginning of the application, there will be language stating “You will be required to go through the KYC process if your grant is accepted (click here for info). Shawn explained it could be linked to a FAQ or sub-page. Hudson emphasized it should be the first thing the applicant reads in the terms.

  • Deleted a proposed step because the platform will not allow applicants to submit their application unless all forms are completed.

  • Temperature checks: Chris was not sure what the frequency of applications would be but voiced that everyone should temperature check in between meetings with a final “yay” or “nay” at meetings. Hudson thought we could do an async temp check (written beforehand). Chris wondered if there was a way the committee can do a written temperature check in a way that shields everyone from what everyone else has said. Holmes suggested it could be a google sheet on a scale of 1-5 (perhaps with the history feature removed). Hudson and the rest of the committee agreed that that was a good way to start and pointed out that they can adjust the process later if there are issues.

  • Anonymity to voting: Chris asked how do we have a layer of anonymity in the voting process? Shawn suggested we could make a helios and explained that anonymous voting registering a hash can be done. Hudson- brought up Doodle. Holmes suggested a spreadsheet that has columns for member 1, 2 ,3 ,4, & 5 and each member can pick a random column to vote. All members agreed.

  • Published to Forum- The group discussed if the applications will be published to the forum right after submission. Chris thought it should be encouraged but not required. Hudson and everyone initially agreed that it should not be automatic but after reviewing all of the steps of the application process the committee decided that it made more sense to have it be published automatically under [redacted] applicants. Chris added that there shouldn’t be an obligation to respond to everything on the forum but he thinks transparency is important if the grant went wrong (less room for conspiracy). Chris clarified with the members that the report should go on the forum so the initial application should be a post and everything else should be part of the same thread (all reviewable on a single page on the forum for future MGRC)

  • Option to edit instead of resubmit: The committee agreed that instead of a resubmit step, the applicant would have opportunities to edit their application so they don’t have to go through the entire application process again. Shawn agreed that this will be necessary if they have milestones we need to bake into applications and believed there is a way on the grants.io platform. Hudson agreed “[redacted] may request improvements to submitted application”

  • Rejected application: Holmes brought up the question, if they get a no (outright rejected) after they get community feedback, do they submit again? Hudson voiced they shouldn’t edit the same application because it wouldn’t record the rejection so a full resubmission is necessary. All members agreed.

  • Votes to approve: There was extensive discussion about how to vote on grants after the application is finalized. Chris suggested the option to vote during bi-weekly and was open to other ideas. Chris explained rough consensus is an art rather than a science and they also have the option of majority (3 of 5). Hudson pointed out that if there is a tough agreement or high value they should include community feedback and admitted that there is no way to formalize it, but it’s a good way to do. Chris agreed that including community input is helpful but MGRC still has 5 decision makers. Shawn said they should stick to a simple majority (3 of 5) and there shouldn’t be room for abstaining for temp checks. He also pointed out that they could have a bigger threshold (4 of 5) or (5 0f 5) depending on the size of the grant. Holmes liked the idea of unanimity because he wants everyone to be on board with decisions and pointed out that it brings all the members closer to understanding each other’s reasons (and one or 2 people could be left out of the thinking). There is risk if we invest money in things that go badly so we might want to tread carefully in first grants. When we have one person that is unsure then everyone has to understand where they are coming from. Hudson agreed with Holmes. Sarah shared that she is used to working in an org that operates with a strong veto (ok unless strong veto). She leans more toward rough consensus or somewhere in between. Hudson brought up that rough consensus could be a longer process than a simple majority. Chris built off of Sarah’s input and suggested that they could do a hybrid; a simple majority (3 of 5) with the ability for a one member strong-veto to halt approval and require more discussion. This will make it so they keep talking until all concerns are addressed or the member(s) that veto(s) convinces the other members. All members agreed.

  • Publish decisions in batches: The members decided to publish final decisions in batches to align with bi-weekly meetings. Shawn pointed out that some will be easier and some will be more difficult depending on number of applications.

  • Concrete milestones: Hudson shared that he thought milestones should be on a case by case basis because not all grants will need milestones (non-software applications), but there are KPIS. Holmes said we could still spread funding in non-software grants. It’s not software vs non-software but more of a size and time question. Hudson agreed that we should be able to have milestones for everything and we should say size and time in case we need an out. Shawn used the ZEC wallet as an example to show that some have a single set goal and wouldn’t need a milestone but there should be room for one. Holmes voiced that it’s better to have a package of work. The group also agreed that there needs to be communications with Zfnd about the timing of milestones. A member suggested that they should check if there are markers on Grant.io as they might want to have people post in the forum if they have broader questions before they meet the next milestone. Holmes pointed out that they should do due diligence on verifying milestones before sending money. Holmes and Hudson thought the members could ask the Zcash foundation to review interim reports. Danika agreed that she will do this with the caveat that she will communicate to the committee if it is too much of a time commitment.

  • Previous work- Holmes brought up the point that the committee should review applicants previous work and all members agreed.

  • Review process as public document: The committee agreed that the Zcash Major Grants Process doc would be public material and there should be a link under “how to apply.”

Summary of action items:

  • Contact Antonie she can help resolve Chris’s GitHub access (Shawn- done)
  • Create Header and subheaders on forum (Shawn)
  • Give ticket to Grant.io & product manage website (Holmes)
  • Beautify Zcash Major Grants Process Doc (Chris)
  • Resolve Twitter problem (Hudson)
  • Look at website with real world eyes and give a thumbs up if you approve (everyone)
10 Likes
2

Great update!

I am used to working on big projects that have rolling 6 month high payout milestones (development work for games/software publishers). monthly/weekly milestones (IT security contract work), or no milestones but no assurance of payment. (bug bounties)

Milestones are a very important part of my financial career stability, but there is an art to writing them. good milestones of any duration promote diligence and commitment. bad milestones or lack of any will cause issues and possible project failure.

an “out” for what?

What Major Grant would not need milestones? Every Major grant should have deliverables, these need to be broken down into milestones. can you please explain a bit more what you mean @hudson - what kind of grant do you see not needing milestones? (I get you are pro milestone from the rest of the post, just not sure what ones wouldnt)

Could you please give the example you used for zec wallet @shawn, if it was to get a Major Grant, surely there is major work going on. Its standard industry practice (any industry) to tie milestones to payments.

Just because there might only be one goal, it does not mean there is only one task. The thing about milestone breakdown, is once you have the format, it is so much easier to apply to other projects.

Id advise to use a bugtracker with workflow built in to manage the deliverables and milestones.

Basic and very incomplete milestone examples:

  • Rough feature request, with timescales
  • PoC, with revised timescales
  • Analysis of impact on other code
  • Test plan and test cases
  • Testing of new feature
  • Regression testing
  • Regression testing with new feature
  • Release procedures.
  • Release sign off.
  • Build and test release build.

Each of these points can be broken into individual milestones, from which progress and timescales can be seen. A Major Grant needs some Major Work. And all this is before a security and privacy reviews. Giving those teams full access to the bugtracker and workflow can save considerable time and money for specialist pentesting.

this is probably the most important part of the project This is when you find out if things are going right or wrong. I am not sure reviewing a report is enough, you need unit tests and testcases.

Which is why you write test based milestones then get someone to test that they have been met, this is hard to do when working with lots of different companies. being familiar with many development styles really helps. A strong background in requirements based test development is essential.

You are a group of 5, why is hidden voting desiarable? I personally would like all MGRC members votes on projects publicly recorded. For transparency if nothing else. The MGRC was elected to enact the spending will of the community. I would also like to see reasoning behind the votes for and against projects.

As an example you might not always have a odd number of voters. This should lead to a second round of discussion on the proposal, where those pro can directly speak to those who are against. This is a tried a true mechanism.

I do not understand this. @cburnake please could you elaborate on this. What is the logic for reducing interaction between the people getting community funds and the community?

The forums are the officially supported form of two way communication between the ZFND and the community.

A large part of the forum are domain experts on zcash, cryptography, ZK, development and security. - I understand trolls exist. that is a moderation fix. Discourse has a number of additional plugins that can help.

A probably more important part though is, the MGRC has 8/9 months left, after that we could have a new MGRC. It is very important to the applicants to integrate into the community. I am not saying they need to read every post in every subforum, but at a minimum they should be expected to maintain a thread/sub section related to their project.

we ae talking about a lot of money. they can task someone with a minimum 4 hours of forum interaction fortnight. Not just when things go wrong, but when things go right and how the future is shaping. They might get lots of unneeded advice - it goes with the territory. ( @zooko :wink: )

1014 “Major funding decisions should be based, to the extent feasible, on inputs from domain experts and pertinent stakeholders.”

Sorry, not quite sure what header means, you mean categories like this? (I am not sure how much weight the MGRC should put on the responses in)

Having a format like this will help everyone understand what is going on and what is expected of new applicants. I believe all posts directed at applicants/receivers deserves a response. I feel this is something that can be solved by forum moderation, not by noninteraction. Set those specific areas to mod post approval first if needed. (I understand that this causes you a conflict of interest, sorry about that)

	-> Desired Applications 
		-> Practical and needed stuff
		-> Applications to get up to speed (ECC replacement stuff)
		-> Wishlist stuff
		
	-> Official Applications 
		-> sub Category for _each_ application.
		Formal and informal responses from the applicants about how their application helps us.
	
	-> Accepted Applications
		-> sub Category for _each_ project.
		Formal and informal responses from the project about, timelines, problems, etc.
1 Like
3

An out meaning if we have to cancel a grant due to unforeseen circumstances.

ZecWallet has used a specific set goal to request funding, such as https://grants.zfnd.org/proposals/1446511155-zip-321-in-zecwallet

In this case would it make sense to have multiple milestones?

Final votes for projects will probably be public (I don’t recall discussing this detail yet) but during initial consideration we are trying to avoid one person pressuring the group to fund a particular project.

Yes, I have made a new category dedicated to the Applications. Grants>Applicants. Ideally it should be easy for future MGRC and applicants to look in a single category to see every proposal submitted.

I think it’s important to have each topic in this category self-contained so we can easily find the application, discussion, conclusion (funded/not funded), and results from the grant.

Perhaps we can make use of the title of the topic to show it’s status?

Something like [APP] to start discussions once submitted [FND/NFND], [CMPLT], etc… we can come up with something that makes sense. Ideally we should be able to just glance at the topics and see where it’s at. And that way community can comment anywhere along the process and provide feedback.

4

Yes it would. The proposal even has them. That example is not great tho. It does contain milestones, but no KPI’s. It needs both. Apple even have their own set standards (like the games industry) to get stuff fast tracked onto the app store.

It needs KPI’s. I have a hs tournament to prepare for, but I will rewrite the proposal to show you what I mean. - This also ties in with the opensource stuff I keep banging on about.

This is going to be a non trivial amount of work, to prove a point. so hopefully I can get this done for the weekend.

I think i see the problem you are trying to solve, idk. if this is the best way to do it though. I am not sure it accomplishes anything.

I was thinking categories with sub categories. discourse was a real pain to edit stuff after 3 months, remember the def fund proposals thread.

Main - MGS
then sub category for each project which contains the threads, could be a nice way to get community feedback for specific projects kept in one place

so you have it grants>applications

id suggest grants>applications>specific threads about general application process and performance, application feedback if the candidate wants that from the community and MGRC in non official capacity.

grants>application001>specific threads about that grant. (updates, feedback, meet the team, etc)

Seems tidier to me.