Deprecation policy

[nschneid]

We need a story for what happens when the guidelines change in a structural way (beyond altering descriptions or examples):

• If a supersense, construal, or usage is removed, do we keep the old page around with a deprecation message? Should the models have a "deprecated" field so deprecated items are excluded from lists/counts and links to them are displayed with a strikethrough?
  • Should there be a deprecation message field? A way to view the history of deprecations?
• When a new version of a corpus is imported, what happens? Should there be a way in the site to access old corpus examples? What about displaying old corpus examples for a deprecated supersense, construal, or usage?
  • If we include old examples they should clearly be marked as deprecated.
  • Or, the site could ignore old versions of corpora entirely, though they'll be available in the database.

[lgessler]

For now, we decided:

• Boolean field on SupersenseRevision for deprecated or not
• String field on SupersenseRevision with a message explaining the deprecation (which guideline revision etc.)
• Extension of the Supersense edit field to accommodate these fields
• Strikethrough hyperlinks to the Supersense if it is deprecated
• Show a banner on the Supersense page to explain that it is deprecated
• Get rid of it on the Supersense tree, show a list of deprecated supersenses at the bottom

[nschneid]

• On the supersenses tree page, can we add a "show deprecated supersenses" checkbox that is off by default? To toggle with Javascript

[nschneid]

• Create Construal form should omit deprecated supersenses from the dropdown lists

[nschneid]

• When the p (or pspecial) macro is used for a usage, e.g. [p en/of Whole--Whole] should there be any visual indication when one of the construal's supersenses is deprecated? I guess it wouldn't hurt to give it a special CSS class so it can be displayed with a red background or whatever to signal that it's an out-of-date link.