Add a workflow for deprecating notebooks and a codeowners file for reviews

[sosey]

This adds a codeowners file so that teams responsible for specific notebooks will be notified for PR review.

This also adds a suggested workflow for deprecating notebooks that are no longer needed because of updated to DMS.

[sosey]

I've tagged a few people to review this PR, specifically for review of the workflow to deprecate notebooks. Tag others that should be included. I'll send an email to the branch managers for their review offline as well.

[JeffValenti]

I suggest the following wording for the deprecation workflow:

Once JWST DMS infrastructure has been updated and the workarounds in a specific notebook are no longer neccessary or recommended, then the notebook shall be deprecated. The process for deprecating a notebook includes the following:

• Determine what Calibration software version and/or CRDS context mitigated the issue worked around in the notebook.

• Determine the DATE when DMS operations first began generating data products that no longer require the workaround described in the notebook.

• Insert a new cell at the top of the notebook with a deprecation comment in large font. The default deprecation comment is, "This notebook is deprecated. Data products generated with calibration software version x.y.z or later and CRDS context jwst_xxxx.pmap or later no longer require this workaround. Data products in MAST created after DATE no longer require this workaround. To check creation dates for files in MAST, substitute your program ID for 2288 at the end of this URL: https://mast.stsci.edu/search/ui/#/jwst/results?select_cols=fileSetName,dataset,cal_ver,crds_ctx,date&program_id=2288"

• Submit a PR that includes the updated files.

• Make sure that the JDOX Known Issues table entry has been updated appropriately.

• After all affected products in MAST have been reprocessed or after 3 months, whichever is longer, submit a PR that removes the notebook from the repository.

[sosey]

The deprecation workflow looks fine to me, for notebooks that are no longer relevant at all. Do we want to offer some advice on what to do if they still contain useful information, though?

For example, I'm thinking of the NSClean notebooks. The step is now implemented in the pipeline, but it will be optional and will frequently need manual intervention, so I am planning to modify these notebooks to call the pipeline step instead, but keep them around. I think they will still have useful guidance. Should they stay here or move somewhere else?

Good catch! yes, let's put some additional details in. It's likely good to check if the updates have been covered in JDOX or the pipeline docs, and anything further that is beneficially described in a notebook should be added to the JDAT repository, in which case the notebook here would be deleted and then an updated version submitted to JDAT for review and acceptance there. Lemme update the text and you can take a look.

[sosey]

Looks good to me. I'm curious if there's some mechanism for reminding us 3 months after updating the notebook to create a new PR that removes it? Maybe that's just a manually added calendar event.

Yah, let's see if we can put a reminder in somewhere. Jira allows for reminders, if these were issues in JP then we could automate that and notify folks.