Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Module and Input Documentation Reorganization #17

Open
jrawbits opened this issue Mar 26, 2024 · 0 comments
Open

Module and Input Documentation Reorganization #17

jrawbits opened this issue Mar 26, 2024 · 0 comments

Comments

@jrawbits
Copy link
Contributor

The documentation needs two top-level chapters called VisionEval Modules" and "VisionEval Inputs with detailed documentation for each module. and each input file. The high-level documentation structure should do tutorial information up front, then a series of technically detailed chapters on (1 - VisionEval Modules) what each module does and how the model was estimated, (2 - VisionEval Inputs) what each input file is (for each module), how to interpret what is in those input files (that element of the documentation is weak) and what sources can be used to generate that information. Ideally, the inputs would also cross-link to the policy-level discussion of scenarios (from Pooled Fund II Task 7) that explain which files might be altered (and how) to implement scenario evaluation.

The module documentation should come from two sources:

  1. The module_docs generated from a custom markup section at the beginning of each module (constructable during the VE build process with ve.build('docs') and placed in the docs folder in the built tree.
  2. The Pooled_Funds_Task4_VE_Estimation.xlsx spreadsheet in the data sub-directory of the user_guide, which discusses data sources for internal estimation (which can then be rebuilt using information in the model re-estimation chapter, currently Chapter 13 "Estimation in VisionEval").

The inputs part can be re-consolidated from input information contained in the Model Inputs chapter - that Chapter should retain its high-level information, direct people to the documentation for the individual models, and from there to the modules and input files for the model.

In layering the documentation, all the module documentation should be assembled into that chapter (and moved out of the various other places it exists). In the documentation of the individual models earlier in the documentation, we should only present tables as far down as the list of modules with sub-lists of the inputs required for each module. The modules should link over to their description in the Modules chapter, and the input files should link over to the detailed input files chapter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant