Change Details

NOTE: removing the preference should only be done after the wikimedia community has been consulted. **Summary:** The "stub threashold" option drastically degrates performance of page views for users who have it enabled. It also is a special case that introduces complexity and surprising behavior in the source code. The value of the feature, when working as intended, also seems dubious. It is probably best to simply remove the option. **Context:** The "stub threashold" option allows users to highlight links to articles that are smaller than a given size. The intend was originally to make it easier for editors to find articles that need attention in a field that they care about. Currently, seven values between fifty and ten thousand bytes are suppoerted (plus "disabled"). The highlighting of the links is implemented in the LinkRenderer class used by the wikitext parser. **Problems:** Usually, the HTML generated by the wikitext parser is cached for later re-use. This is done because parsing is relatively slow - depending on the size and complexity of the page, it can take several seconds. However, when the "stub threashold" option is used, this caching is disabled. This is necessary because it would not be feasible to update the cache whenever the size of a linked page changes. Also, if all of the eight supported values were in popular use, this wouldlead to eight times as many cache entries (cache fragmentation). Because the stub threashold disables the use of the parser cache, all pages have to be parsed on the fly for users that have this option set. This makes loading tha pages very slow. Also, the mechanism that bypasses the parser cache is somewhat obscure and has led to confusion in the past. It is implemented in ParserOptions::isSafeToCache(), but the option itself is not mentioned there, bypassing the cache is a result of "stubthreashold" being counted as a "used" option but not being listed as a "cache varying" option. This is surprising for a parser option coming from a user preference. Fianlly, the benefit of the option seems dubious. While providing a way to discover articles that need attention while reasing is a nice idea, going simply by the size of the page is probably not the best mechanism. If there is sufficient demand for this feature, other options should be explored, perhaps based on categories or other metadata. **Usage:** An ad-hoc analysis among users of en.wikipedia.org who have edited in the last 30 days shows that about 0.25% of active editors have the "stub threashold" option set (roughly 500 out of 200,000). The median edit count among these users is 1675, pointing to a niche feature used by a few power users. **Solution: ** There seems to be no feasible remedy for the performance issue mentioned above. A complete redesign of the feature would be necessary. Since the feature does not seem to be used much, it seems best to simply remove it from core. If desirable, the underlying need could be addressed by asynchronously loading meta-data about linked pages to surface pages that need attention.

NOTE: removing the preference should only be done after the wikimedia community has been consulted. **Summary:** The "stub threshold" option drastically degrades performance of page views for users who have it enabled. It also is a special case that introduces complexity and surprising behavior in the source code. The value of the feature, when working as intended, also seems dubious. It is probably best to simply remove the option. **Context:** The "stub threshold" option allows users to highlight links to articles that are smaller than a given size. The intend was originally to make it easier for editors to find articles that need attention in a field that they care about. Currently, seven values between fifty and ten thousand bytes are supported (plus "disabled"). The highlighting of the links is implemented in the LinkRenderer class used by the wikitext parser. **Problems:** Usually, the HTML generated by the wikitext parser is cached for later re-use. This is done because parsing is relatively slow - depending on the size and complexity of the page, it can take several seconds. However, when the "stub threshold" option is used, this caching is disabled. This is necessary because it would not be feasible to update the cache whenever the size of a linked page changes. Also, if all of the eight supported values were in popular use, this would lead to eight times as many cache entries (cache fragmentation). Because the stub threshold disables the use of the parser cache, all pages have to be parsed on the fly for users that have this option set. This makes loading the pages very slow. Also, the mechanism that bypasses the parser cache is somewhat obscure and has led to confusion in the past. It is implemented in ParserOptions::isSafeToCache(), but the option itself is not mentioned there, bypassing the cache is a result of "stubthreshold" being counted as a "used" option but not being listed as a "cache varying" option. This is surprising for a parser option coming from a user preference. Finally, the benefit of the option seems dubious. While providing a way to discover articles that need attention while rading is a nice idea, going simply by the size of the page is probably not the best mechanism. If there is sufficient demand for this feature, other options should be explored, perhaps based on categories or other metadata. **Usage:** An ad-hoc analysis among users of en.wikipedia.org who have edited in the last 30 days shows that about 0.25% of active editors have the "stub threshold" option set (roughly 500 out of 200,000). The median edit count among these users is 1675, pointing to a niche feature used by a few power users. **Solution: ** There seems to be no feasible remedy for the performance issue mentioned above. A complete redesign of the feature would be necessary. Since the feature does not seem to be used much, it seems best to simply remove it from core. If desirable, the underlying need could be addressed by asynchronously loading meta-data about linked pages to surface pages that need attention.

NOTE: removing the preference should only be done after the wikimedia community has been consulted. **Summary:** The "stub threashold" option drastically degratesdes performance of page views for users who have it enabled. It also is a special case that introduces complexity and surprising behavior in the source code. The value of the feature, when working as intended, also seems dubious. It is probably best to simply remove the option. **Context:** The "stub threashold" option allows users to highlight links to articles that are smaller than a given size. The intend was originally to make it easier for editors to find articles that need attention in a field that they care about. Currently, seven values between fifty and ten thousand bytes are suppoerted (plus "disabled"). The highlighting of the links is implemented in the LinkRenderer class used by the wikitext parser. **Problems:** Usually, the HTML generated by the wikitext parser is cached for later re-use. This is done because parsing is relatively slow - depending on the size and complexity of the page, it can take several seconds. However, when the "stub threashold" option is used, this caching is disabled. This is necessary because it would not be feasible to update the cache whenever the size of a linked page changes. Also, if all of the eight supported values were in popular use, this would lead to eight times as many cache entries (cache fragmentation). Because the stub threashold disables the use of the parser cache, all pages have to be parsed on the fly for users that have this option set. This makes loading thae pages very slow. Also, the mechanism that bypasses the parser cache is somewhat obscure and has led to confusion in the past. It is implemented in ParserOptions::isSafeToCache(), but the option itself is not mentioned there, bypassing the cache is a result of "stubthreashold" being counted as a "used" option but not being listed as a "cache varying" option. This is surprising for a parser option coming from a user preference. FianllyFinally, the benefit of the option seems dubious. While providing a way to discover articles that need attention while reasingrading is a nice idea, going simply by the size of the page is probably not the best mechanism. If there is sufficient demand for this feature, other options should be explored, perhaps based on categories or other metadata. **Usage:** An ad-hoc analysis among users of en.wikipedia.org who have edited in the last 30 days shows that about 0.25% of active editors have the "stub threashold" option set (roughly 500 out of 200,000). The median edit count among these users is 1675, pointing to a niche feature used by a few power users. **Solution: ** There seems to be no feasible remedy for the performance issue mentioned above. A complete redesign of the feature would be necessary. Since the feature does not seem to be used much, it seems best to simply remove it from core. If desirable, the underlying need could be addressed by asynchronously loading meta-data about linked pages to surface pages that need attention.