Next steps

[ocefpaf]

• [x] codespell
• [x] pre-commit
• [x] PDF/Docx
• [x] publish HTML
• [ ] TOC
• [ ] fix look of the converted PDF/Docx/HTML
• [ ] create an index for the manuals
• [ ] add all manuals!
• [X] add with the currents manual
• [ ] insert code example for each test
• [ ] use ioos_qc notebooks for the examples
• [ ] consolidate common assets like images, tables, acronyms, qartod explanations, etc
• [ ] cross reference figures and tables
• [ ] request the original images to replace the low resolution captured from the published docs
• [ ] use mathjax for the equations
• [ ] add refences

[MathewBiddle]

I see this is organized as all the manuals in one repo. Should each manual have it's own repo?

I'm just curious about the reasoning for this organization.

[ocefpaf]

I see this is organized as all the manuals in one repo. Should each manual have it's own repo?

I'm just curious about the reasoning for this organization.

This is a test repo and I just "dumped" one manual. If this is approved we can decided on the best course of action.

With that said. I would do a monorepo with all manuals into a single repo b/c they are (will be) light, just markdown files, and we can save some "resources" like a single repo to maintain the boilerplate GHA, pre-commits, etc.

[MathewBiddle]

This is a test repo

Understood.

Your approach makes sense. I guess I was thinking about user engagement. If GitHub is acceptable to the community for discussions about the manuals, it would be slightly more straightforward to discuss a manual if it was it's own repo. However, we can use labels to classify them too... thinking out loud.

[ocefpaf]

it would be slightly more straightforward to discuss a manual if it was it's own repo.

I'm on the fence on that approach. In fact, that is an ongoing discussion in the "gh realm," by that I mean the "monorepo" vs the distributed approach over an org. I see advantages and disadvantages in both, With that said, if we go to the org approach, we would need a QARTOD org to make things slightly easier to manage. If we go the monorepo we place the repo in an existing org.

Again, not strong opinion here but we should figure this out before we go "live" with the HTML manuals.

[jcoogan87]

I tried to organize the next order of things to get done based on what we talked about today, with an initial focus on getting one manual formatted to a level that we are happy to share with the NOAA repository for review (a lot of this is already on your task list )

• [x] add higher res photos (me)
• [ ] add latex for equations and variables
• [ ] add references (I can help with this)
• [ ] Read through the manual for headers being clean, equations and variables being standardized, other formatting changes ( @ocefpaf let me know when you think we are at this step and I can find people to review it)
• [ ] send the pdf to NOAA repository to check it meets their standards
• [ ] Reorder next manual to convert issue (me)
• [ ] Standardize existing equations and variables across all manuals
• [ ] Read through and double check manuals as they are finished
• [ ] Find a IOOS home for the manuals and set them up as individual repositories
• [ ] Start letting the QARTOD community know about the github transition
• [ ] Work on documenting the IOOS_QC code in the QARTOD manuals