Need some higher level documentation and better discoverability

[christine-e-smit]

Describe the bug I knew that there was a python CMR library. So I googled python cmr and I found https://pypi.org/project/python-cmr/, which is not supported by ESDIS. But you know what it does have? A top level Readme.md with both installation instructions and examples for use. The top level Readme.md for your project has detailed installation instructions, including information that is clearly aimed at people contributing to the library rather than newbie users. What is does not have? Documentation on how to use the library or a description of what the heck CMR is beyond a link somewhere else. Note how python-cmr does this: it includes a link to CMR, but also gives a brief description (https://github.com/jddeal/python-cmr):

Python CMR is an easy to use wrapper to the NASA EOSDIS Common Metadata Repository API. This package aims to make querying the API intuitive and less error-prone by providing methods that will preemptively check for invalid input and handle the URL encoding the CMR API expects.

I saw a "docs" directory, so I clicked in there and got what looked like function-level documentation. This is a great reference for later, but I need a getting started section.

My suggestions

1. Move any documentation relating to how someone can contribute to this project to a separate contributor document.
2. Update the top level Readme.md:
   1. Include a brief description of what CMR is, including what the acronym stands for, so people know that they are getting a library that will let them search for earth data!
   2. Include at least a teaser of how to use the library to call CMR and do a basic search.
   3. Include a link to "getting started" documentation.
   4. Include links to your jupyter notebooks.
   5. Include links to the rest of your documentation, where ever that resides.
   6. Include links to documentation where users can learn what granules, collections, products, etc. are.
   7. Describe briefly what earthdata login is and provide a link to further documentation. (Also explain why someone might want to use EDL with this library.)
3. Consider creating a read-the-docs entry. This is pretty standard for python documentation.
4. Consider adding a mybinder link for the notebooks that don't use EDL. https://mybinder.org/ This will allow users to run your notebooks without downloading a thing. (I can't find it now, but I'm pretty sure mybinder has documentation explicitly telling you to not do anything with passwords on mybinder because it isn't secure.)
5. Consider storing the notebooks in the repository with outputs. This will let people see what the search does without having to actually run the notebooks.

In summary, when I read your top level Readme.md, I should be able to:

1. determine what the library does, even if I am unfamiliar with EOSDIS terminology.
2. do a search and get some results using sample code provided and installation instructions in the top level Readme.md.
3. navigate my way to other relevant documentation without digging through the repository.
4. know where to look for rules on contributing back to the project.