Wikipedia:Tracking issues
 | This is an essay. It contains the advice or opinions of one or more Wikipedia contributors. This page is not an encyclopedia article, nor is it one of Wikipedia's policies or guidelines, as it has not been thoroughly vetted by the community. Some essays represent widespread norms; others only represent minority viewpoints. |
The following describes some benefits and techniques for monitoring, or tracking, various issues (or problems) noted about related articles, template features, report pages, etc. An issues-tracking system could be used to help prioritize major issues, to reconsider them at regular intervals when there is more time to resolve them.
A simple list of major issues noted for each template, or report page, could work to re-focus efforts to improve them. So although it would be great to have an issues-tracking system, even if there had been a written list of the major issues, expanded for each template set or report page, then that could have helped remind people to keep reassessing the unresolved problems from years ago.
Format of an issues-list page
[edit]Perhaps there could be a subpage name, such as "Template_talk:Xxx/Issues_list" which could contain a simple sortable table of each issue noted, with link to each talk-page/archive thread, plus date, status, suggested importance level, and extra note. Even such a simple list could be periodically reviewed, at least every 3 months, so that the above problems would not be left unresolved for 2-4 years. In each table, the "status" column would indicate completion, and the "importance level" could be increased if a problem was noted as still causing much grief months later. In the case of multiple similar templates, then a common template-talk page could be used to keep the central issues list.
Sample issues which could have been resolved years earlier
[edit]If each major problem had been tracked, from the outset, within an issues-tracking system, then they could have been fixed much sooner, years sooner, as in the following cases:
- Swiss flag icon needing 17px height: Even the related Template:CHE had the Swiss flag icon (now in over 27,300 pages) resized as 17px over 5 years ago, when some editors noticed the 20px height was too large, and other editors discussed reducing it, but the fix affects multiple templates and was dropped.
- The kg-to-lb fix was logged/forgotten 4 years ago: Among the top, most-used measurement conversions, kg/lb (kilograms/pounds), are in the top 5, where Template:Convert/kg is used in over 60,100 pages, inside many of the Who's-Who of major articles, compared to {{convert/cm}} in 26,825 pages.
- Common WP:FRS was slow for 2 years: The wp:FRS list (wp:Feedback request service) has been popular, as viewed ~30x times per day (as compared to wp:Admin with 35 pageviews per day). The prior slow speed, reformatting in 28-60 seconds, was a known issue for 2 years (since 2011), but not on a tracking list of problems to improve, until mentioned at wp:PUMPTECH and reduced to 4-second reformat, as 7x to 15x times faster.
In all three cases, each issue would have remained near the very top of priorities on a list, but they were in minor or busy talk-pages, where other newer issues were getting the attention, and people were coping, such as using {{CHE}} with 17px height when the {{flag|Switzerland}} icon was too large in the 27,300 pages, or using Template:Convert/kg with a rounding parameter to override the poor default precision of 3-pound swings among 60,100 pages. So, an issues-tracking list could have fixed each issue much sooner. The distractions which eclipsed each of the 3 complex issues had occurred weekly, not daily, and all 3 could have been fixed by techniques known 3-4 years ago if reconsidered each day.