Elizabeth: Found the process fairly intuitive. A few places where the code was a bit confusing and could only make guesses about what the code is doing.
Kevin: There are errors in the code where it looks like it’s following some conditional logic, but there might be some error in, for example, a regular expression.
Valerie: Reading the code only tells you what it does, not what it doesn’t do.
Elizabeth: We can address issue of code matching spreadsheet. More difficult to address issue of, is code doing what it should be doing.
Kevin: The code/spreadsheet documents a lot of fields that will probably never be used. If we focus on the 20-25 most commonly used notes for more complex efforts. For example, getting the 300 field as correct as possible.
Elizabeth: Should we commit to maintaining the documentation and testing for those most commonly used fields?
Valerie: The code also does a lot of cleanup on punctuation, too. Is there a need to document that?
General discussion about MARC records, punctuation, etc. and whether or not that sort of logic should or even could maintain the correct punctuation-based functionality going forward.
Discussion about sustainability of this particular sub-team reviewing the code going forward. Suggestions to better comment the code and contribute to unit tests to make it more maintainable going forward.
How do we get notified that something in the code has changed?