Confirmed users, Bureaucrats and Sysops emeriti
969
edits
(make bullet points render correctly) |
mNo edit summary |
||
Line 1: | Line 1: | ||
This page tracks some of the specification issues we've encountered more recently while implementing SVG. | This page tracks some of the specification issues we've encountered more recently while implementing SVG. | ||
When we discovered SVG specification issues in the past we simply reported them to the SVG working group via their mailing list believing they would be tracked and (eventually) fixed. However, it has become clear that this system of reporting issues is an utter farce. Any reasonable issue tracking system would at least make it possible to: | When we discovered SVG specification issues in the past we simply reported them to the SVG working group via their mailing list, believing they would be tracked and (eventually) fixed. However, it has become clear that this system of reporting issues is an utter farce. Any reasonable issue tracking system would at the very least make it possible to: | ||
* search through existing issues without returning | * search through existing issues without returning non-issue mailing list chatter | ||
* know whether your reports are even actually being treated as issues | * know whether your reports are even actually being treated as issues | ||
* unambiguously mark the status of each issue so everyone can easily and clearly see when an issue has been closed/dropped (thus people can ask for further clarification if the solution | * unambiguously mark the status of each issue so everyone can easily and clearly see when an issue has been closed/dropped (thus people can ask for further clarification if the solution is unsatisfactory or unstated, instead of believing that the issue is still open and being worked on) | ||
* make sure the resolution is visible to all when an issue is closed | * make sure the resolution is visible to all when an issue is closed | ||