Extractor development support & documentation

[max-zilla]

Trying to figure out how to make it easier to deploy extractors following https://docs.terraref.org/developer-manual/developing-clowder-extractors

• Jupyter notebook? (talked to LSST people who are using Jupyter notebook)
• Github hooks?
• Automatically identify missing tests, documentation, code style, etc.
• Other changes to the docs - break out which type of person is responsible for which part of the process (developer, pipeline maintainer, etc.)

[max-zilla]

@ZongyangLi suggests defining a more rigid template/structure for kinds of extractors e.g. the laser3D scan-line based extractors, full field extractors, etc. so there is more similarity and so on.

[max-zilla]

what is desired outcome? how do we know when this is satisfied?

[abby621]

It would be nice to have a template for documentation to make sure that everything is being appropriately documented, and to facilitate the developers filling in the documentation as they do development.

Open question: is it better to provide documentation in Google Docs (easy to read and edit, but more separated from actual code), or in a readme that exists alongside the code?

[dlebauer]

@abby621 I think it is nice to have it in the README, but in the end, we need something that people will use. This is also part of a larger discussion about how we can get the team to contribute to the documentation currently at docs.terraref.org, which we are discussing moving to bookdown

Pros for readme are that it is always with the code, gets versioned, archived, and published at the same time. That said, we can export google doc to pdf and check it in with each version.

Would developers find it easier to contribute if it were on google docs?