it would be nice to have this but probably more effort than it is worth to go back and add obs reasons to all of the terms that do not already have one

One option is to give all the ones that are currently missing an obsolescence reason a blanket reason (say, "out of scope") or similar, so that we can activate the QC check for the future. We could also create a (closed) issue explaining the obsoletion "Deprecated classes without an obsoletion reason" and link all classes to this ticket; this ticket could then have an explanation that we did not track obsoletion reasons when this class was obsoleted, but if you want to know why it was obsoleted, you can open a new ticket?

I like both of these ideas @matentzn. I'm in favor of doing this.

I am in favor of adding the qc check and also adding the blanket reason with a ticket reference for any class that does not already have an obsoletion reason.

Yes, I didnt think to also say this clearly: Do we think that all obsoleted classes should be linked to a GitHub issue? I think this would be a pretty awesome show of transparency as well.

Yes to everything BUT I think there are a lot of "old" obsoleted classes for which there might not be a GH issue. So we need to have a plan for these.

The same idea as above: a blanket issue explaining that this term was obsoleted before there was a system, and there is therefore no issue tracker connected.

I am in favor of all of this

• @nicolevasilevsky can you create a beautifully formatted issue then, that explains this situation, and close it, and link it here? I will work on the rest.

• Also, I need to know which "deprecation reason" to use for these cases. Do you want to coin a new one? "MONDO:UnspecifiedObsoletionReason"? Or re-use one of the existing ones?