Merge pull request #43 from nasa-fornax/requirements_file

Adding requirements file preference in the review notes

notebook_review_process.md

@@ -18,17 +18,18 @@ For authors: consider these checklists requirements for your code.
       - if not, is that justified
 - Does it include work linked to a buzzword:
 	- big data, spectroscopy, time domain, forced photometry, cloud
-- Has each NASA archive been given option to comment on modules for their relevant data access?\
+- Has each NASA archive been given the option to comment on modules for their relevant data access?\
   	- TODO: a preferred contact method for each archive should be listed here, ie., archive helpdesk, NN slack channel #fornaxdev-daskhub? ??? 	
 	- Is archival data accessed in the most efficient way according to that archive?
 ## Tech Review Checklist
 - Documentation:
 	- Is every function documented?
 	- Does it follow the style guide? https://github.com/spacetelescope/style-guides/blob/master/guides/jupyter-notebooks.md
    	- Do all code cells have corresponding narratives/comments?
-   	- Include information about runtime on fiducial Fornax server
-   	- Include information about which "image" the notebook uses when loggin into Fornax, ie., "Astrophysics default image"
+   	- Include information about which server type and environment to choose when logging in to Fornax and the notebook's expected runtime given that setup. For example: 
+   	- "As of 2024 August, this notebook takes about 3 minutes to run to completion on Fornax using Server Type: 'Standard - 8GB RAM/4 CPU' and Environment: 'Default Astrophysics' (image)."
 - Notebook execution, error handling, etc.:
+	- Does the notebook have a corresponding `requirements_<notebook_filename>.txt` file listing all its direct dependencies? Is it used in a commented-out cell in the notebook  with `pip install -r <filename>`?
 	- Does the notebook run end-to-end, out of the box?
  	- Are errors handled appropriately, with `try`/`except` statements that are narrow in scope?
 	- Have warnings been dealt with appropriately, preferably by updating the code to avoid them (i.e., not by simply silencing them)?
@@ -39,12 +40,9 @@ For authors: consider these checklists requirements for your code.
 	- Is memory usage optimized where possible? 
 - Cleanup:
 	- Have blocks of code that need to be re-used been turned into functions (rather than being duplicated)?
-	- Have un-used libraries been removed from the requirements.txt file and the `import` statements?
-	- Has un-used code been removed (e.g., unused functions and commented-out lines)?
+	- Have unused libraries been removed from the requirements.txt file and the `import` statements?
+	- Has unused code been removed (e.g., unused functions and commented-out lines)?
    	- Are comment lines wrapped so all fit within a max of 90 - 100 characters per line?
    	- Are code lines reasonably short where possible? some code lines can't easily be wrapped and that is ok
    	- Do plots use color-blind friendly palettes for plotting? try this [simulator](https://www.color-blindness.com/coblis-color-blindness-simulator/#google_vignette) for visual check
 
-```python
-
-```