|
|
| (6 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| − | This is very helpful. The first thing that occurs to me is that the "soft deprecation" method is hard to notice in the Guidelines; the Note in which it's mentioned in e.g. <relationGrp> is right at the bottom of the page:
| |
| | | | |
| − | <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-relationGrp.html>
| |
| − |
| |
| − | and many people would use the tag unknowingly without getting that far. The fact that <relationGrp> is no longer mentioned in the chapter linked from the element page is perhaps a clue, but not a very good one. We could make the deprecation more evident by putting some signal directly into the first row/cell of the element page (such as the red text shown in the hard-deprecated @targets definition).
| |
| − |
| |
| − | Personally, I don't like the distinction between hard and soft deprecation. What "soft" really means in the case of e.g. relationGrp is that the element is retained for backwards-compatibility; I think that should always be temporary, albeit perhaps long-lasting, and the end-result of deprecation should be eventual removal/replacement. ([[User:Mholmes]])
| |
| − |
| |
| − |
| |
| − | Let me try at least to state the workflow I would have in mind for the use of tickets for deprecation:
| |
| − | * when the council decides to deprecate "something", a ticket with status="deprecated" is created that describes the actual deprecation thing. This ticket also states a deprecation period (or open until the council decides the "thing" should definitely disappear)
| |
| − | * closing the ticket means that the deprecation period is over, namely that the element, attribute,feature etc. has been removed from the guideline
| |
| − |
| |
| − | The ticket has thus a multiple roe:
| |
| − | * it documents the deprecation (thus making it easy to publicize (in particular on the TEI website)), as a sort of reified warning
| |
| − | * it allows the community to react to the ticket ("no, stop! I have a zillion documents using this")
| |
| − | * trace back decisions/reasons for changes
| |
| − |
| |
| − | In no way, IMHO, "old" tickets should be changed to status="deprecated" , but a new one should be made, which in turn may point to the initial discussion(s) that lead to its creation.
| |
| − |
| |
| − | And this for both soft and hard, I would say. ([[User:Romary]])
| |
| − |
| |
| − |
| |
| − | I've always viewed soft deprecation as an entirely unofficial form of deprecation. I.e. we're not yet stating that this is deprecated, we're just trying to remove active recommendations for its use. (i.e. making sure our examples use @ref instead of @key)
| |
| − |
| |
| − | I believe that what Laurent recommends [. . .] is the deprecation procedure we agreed to previously. That when we decide to really really deprecate something, that we not only add a @status="deprecated" to it, remarks noting that it is deprecated, but open a ticket with the deprecated category on sf as a place to document and have discussion concerning it post-deprecation. That ticket should contain a date by which the object should be removed from the guidelines.
| |
| − |
| |
| − | An example of where we've partly done this is @targets on alt/join/link but I've no recollection if we created a ticket concerning it? ([[User:James]])
| |
