Create a weblink which will retrieve all deprecated tickets, for use when doing new release to ensure they are acted upon when ripe, and also for people to see when a deprecation ticket has been acted upon
At some point a ticket category was created for deprecation. This category can be applied to any of the four ticket types (bug, feature request, patch, or support request).
While my previous comment suggests that we create a new ticket type for deprecation (besides "bug" and "feature request"), I wonder whether we should instead keep the category that someone has already created. That way we can reclassify an existing ticket into this category if that's the way we decide to implement it. Not sure of the best workflow here.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
taking ticket; will also investigate transforming XML output from SF trackers at same time just to see if anything useful for historical lists.
As we are at it, can we make also this page http://www.tei-c.org/Activities/Council/Working/tcw17.html a bit more pretty?
Is it possible to do this by adding to the four types of tickets in SF Tracker?:
https://sourceforge.net/tracker/?group_id=106328
That would be more straightforward that forcing each of our "deprecation tickets" into the bug or feature request structures.
Regardless, I suggest adding these two links (for pending and past deprecations) to the following pages:
* http://tei.sourceforge.net/
* http://www.tei-c.org/release/doc/tei-p5-doc/en/html/
* http://www.tei-c.org/Guidelines/P5/
At some point a ticket category was created for deprecation. This category can be applied to any of the four ticket types (bug, feature request, patch, or support request).
While my previous comment suggests that we create a new ticket type for deprecation (besides "bug" and "feature request"), I wonder whether we should instead keep the category that someone has already created. That way we can reclassify an existing ticket into this category if that's the way we decide to implement it. Not sure of the best workflow here.