Fixing, Updating & Streamlining of Zcash Documentation (https://zcash.readthedocs.io/en/master/index.html)

1. Executive summary and decision snapshot

Foragers requests $40,904 for a 12-week overhaul of Zcash documentation, delivered by Michiel Degruytere and Evi Nova. The application is under review. Work covers broken links, outdated guidance, documentation rewriting, agent-readable documents, and a branding-aligned interface. Funding comprises an initial payment and three milestones. [1][4][5]

The strongest capability evidence is a collaborator’s firsthand endorsement of both applicants’ hackathon delivery—not demonstrated completion of comparable documentation work. Evaluation inference: the central funding questions are whether the proposed rewrite has a sufficiently bounded scope, whether maintainers will accept it, and whether acceptance tests establish technical correctness rather than merely publication. [5]

2. Applicant and team track record

• Michiel Degruytere: proposed solution architect, technical writer, and UX/UI lead; reports blockchain privacy/security work since 2022 and technical writing for companies. Evi Nova: proposed engineering lead responsible for technical verification and agent workflows; reports blockchain development and security-auditing experience. These are applicant descriptions. [1]
• External corroboration: jensei says they worked alongside both applicants on hackathons and within Web3Privacy Now, citing successful deadline-driven delivery and a shared winning streak. The supporter discloses having their own open grant application. No underlying project artifacts are supplied. [5]
• Prior ZCG milestone performance or independently demonstrated documentation outcomes: No grounded evidence found. This does not establish that the team has no prior grants.

3. Proposal scope, milestones, budget, technical approach, and dependencies

The approach combines manual and agent-assisted analysis, link repair, replacement or removal of obsolete information, sampling of example projects, reduced reliance on external links or archived alternatives, a consolidated rewrite, and agent-readable outputs. [4]

All timing, amounts, and stated criteria above come from the forum proposal. [5]

Calculated inference: milestone payments total $34,087, leaving $6,817 of the request for the initial payment. That is consistent with approximately two weeks of a 12-week budget, but the applicant should explicitly confirm the allocation. The applicant describes the total as €36,000, approximately €1,500 per person per week; hours and workstream-level costs are not supplied. [5]

The application commits to intended-user or representative validation. However, the supplied plan does not identify those reviewers, establish publishing authority, or specify the verification method and coverage. Its final step allows “merge or publish,” leaving the required publication destination unclear. [1][5]

4. Community discussion, arguments, responses, and resolution

• Strongest argument for: the applicant identifies a concrete maintenance problem—approximately 60 dead links among 262 external URLs—and argues that fixing developer guidance would complement onboarding expenditure. This is an applicant-reported diagnosis and benefit hypothesis, not measured evidence of developer impact. [4]
• Capability support: the collaborator endorsement supports confidence in delivery under deadlines, but does not establish accuracy or maintainability of a documentation overhaul. Inference: it is useful but narrower than the proposed assignment. [5]
• Strongest substantive caution raised: LowKey asks for explicit software-version notices on outdated guides, with links to current instructions, because users may arrive through search. Mf replies that this will be added to their notes. The suggestion was acknowledged, but no revised acceptance criterion demonstrates resolution. [5]
• Applicant clarification: DeBelg confirms that the financial figures are consistent and milestones evaluable. That is an assurance rather than additional budget or testing detail. [7]

Documented opposition or continuing disagreement: No grounded evidence found. The supplied discussion contains support and a practical improvement request, not a substantive debate over price or scope. [5]

5. Relevant precedents and documented outcomes

• Mastering Zcash Video Series — $23,500. Relevant as developer/educational content funding. The committee approved eight videos and three podcasts, citing existing high-quality work, community usefulness, a realistic budget, and payments after video release. The supplied evidence also records cancellation before completion, without explaining timing or delivered outputs; therefore, its eventual delivery outcome is uncertain. Inference: the useful comparison is demonstrated prior work and release-linked payment—not proven impact from this award. [8]
• Sapling Parameters Availability Hardening — $30,000, declined unanimously. Relevant because it proposed repairs to shared Zcash infrastructure requiring upstream acceptance. Committee concerns included existing alternatives, limited incremental value, price, architectural fit, and demands on core reviewers. Inference: documentation is a different technical undertaking, but the precedent makes maintainer agreement and review burden material funding considerations. [10]

Neither precedent establishes an appropriate price for this request.

6. Material risks and execution considerations

The following are evaluation inferences, not documented delivery failures:

• Scope expansion: a whole-documentation rewrite, example validation, visual redesign, and agent-readable outputs create several distinct workstreams within 12 weeks. Without a fixed content inventory, effort could shift toward presentation rather than critical corrections. [4][5]
• Technical quality: sampling examples may leave important instructions untested; agent-assisted rewriting increases the importance of clearly assigned human verification. [4][5]
• Durability: archived links address one failure mode, but the supplied proposal does not establish ongoing ownership or update arrangements after publication. [4][5]
• Value measurement: repaired links and publication are observable outputs; improved onboarding is a separate outcome. No grounded evidence found for a baseline or target measuring developer task success, time saved, or adoption.

7. Material gaps and questions for the applicant

• Scope: Which pages, software versions, and developer journeys are mandatory, and what is explicitly excluded from the rewrite? [4]
• Acceptance and integration: Which maintainers and intended users have agreed to review, by when, and does final payment require publication at the existing official documentation location rather than a separate site? [1][5]
• Technical verification: Which examples must run successfully, in what environments, and who signs off on technical accuracy—including agent-readable documents? [4][5]
• Budget and payment: Confirm the inferred $6,817 initial payment; provide estimated hours and allocations across repair, rewriting, interface work, and agent outputs. What happens if upstream review delays completion? [5]
• Capability: Can the team provide comparable published documentation or accepted technical contributions, identifying each member’s role? [1][5]
• Durability and value: Who maintains the result after week 12, and what before/after developer tests will demonstrate improvement beyond availability? [4][5]

8. Neutral decision considerations

Committee options, not an approval or rejection recommendation:

• Evaluate essential correctness repairs separately from interface and agent-document enhancements, allowing their incremental cost and benefit to be assessed.
• Consider an explicitly bounded first phase, with later commitments dependent on the audit, agreed content inventory, and maintainer review.
• Tie acceptance to tested developer journeys, reviewer sign-off, and an agreed publication destination; distinguish delivery requirements from longer-term impact measures.

These options address the proposal’s broad scope and qualitative milestone criteria without assuming either poor execution or demonstrated downstream benefit. [4][5]

9. Numbered source list

• [1] Grant Application - Fixing, Updating & Streamlining of Zcash Documentation (https://zcash.readthedocs.io/en/master/index.html) — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/460
• [4] Grant Application - Fixing & Updating of Zcash Documentation (https://zcash.readthedocs.io/en/master/index.html) — posts 1–5, part 1 — https://forum.zcashcommunity.com/t/grant-application-fixing-updating-of-zcash-documentation-https-zcash-readthedocs-io-en-master-index-html/57965/1
• [5] Grant Application - Fixing & Updating of Zcash Documentation (https://zcash.readthedocs.io/en/master/index.html) — posts 1–5, part 2 — https://forum.zcashcommunity.com/t/grant-application-fixing-updating-of-zcash-documentation-https-zcash-readthedocs-io-en-master-index-html/57965/1
• [7] Comment on #460: Grant Application - Fixing, Updating & Streamlining of Zcash Documentation (https://zcash.readthedocs.io/en/master/index.html) — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/460#issuecomment-5942335126
• [8] Mastering Zcash Video Series — comparison summary — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/263
• [10] Zcash Sapling Parameters Availability Hardening — comparison summary — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/201