Keeping these in sync, and giving book readers the context they're looking for is tedious.
Do you recommend a solution?
The simple solution is to link to an external DAG rendering, BUT:
A super fancy nice solution would be to embed the DAG directly into the book.
For the high-level TFL-scoped tech-tree, if the DAG renderer could collapse milestones into nodes (where any ticket in Milestone X which depends on any ticket in Milestone Y would cause the node for X to depend on the node for Y). One gotcha here: there could be cycles!
Then the fine-grained TFL-scoped tech-tree would be the current rendering scope of the DAG tool (one node per issue, with milestone groupings).
What is the problem?
The book has text describing a broad/general roadmap…
Meanwhile, we use the https://github.com/zcash/developers DAG tool to plan the fine-grained work to be done.
Keeping these in sync, and giving book readers the context they're looking for is tedious.
Do you recommend a solution?
The simple solution is to link to an external DAG rendering, BUT:
A super fancy nice solution would be to embed the DAG directly into the book.
For the high-level TFL-scoped tech-tree, if the DAG renderer could collapse milestones into nodes (where any ticket in Milestone X which depends on any ticket in Milestone Y would cause the node for X to depend on the node for Y). One gotcha here: there could be cycles!
Then the fine-grained TFL-scoped tech-tree would be the current rendering scope of the DAG tool (one node per issue, with milestone groupings).