Wikipedia:Aggregate data into lists rather than stubs
|This essay contains the advice or opinions of one or more Wikipedia contributors. Essays are not Wikipedia policies or guidelines. Some essays represent widespread norms; others only represent minority viewpoints.|
This essay, WP:Aggregate data into lists rather than stubs, explains the reasons to focus on using lists to write about numerous minor items on Wikipedia. Rather than creating thousands of tiny stub pages, perhaps start, instead, with a combined list-of-items in an article, as a common aggregate of minor items.
Group items for wider view
Although it is great to have stubs to capture every notable river, valley or town, those stubs alone will risk the danger of "Cannot see the forest for the trees" as too many tiny articles which fail to describe the whole region. Meanwhile, there are list-of-area articles which can be translated, first, such as from German Wikipedia. This is the concept of "List of tiny stuff" where not all items in a list have separate articles. For example, a river valley in Germany, such as article "de:Zschonergrund", is a small part of a list of 147 river valleys in Saxony (German: Sachsen), as one list of the 16 Bundesländer (federal states) in Germany:
- de:Liste der Landschaftsschutzgebiete in Sachsen - one of 16 lists of valleys
Before creating hundreds of stubs for valleys, start with the 16 list articles (for 16 states in Germany), including tables of valleys showing the location and area (in ha/acres) for each entry. Even in the German WP, a list of 147 valleys has red-links for dozens of valleys (no articles yet), and perhaps some valleys are so minor that there are no sources which focus on a tiny valley as notable in "continued coverage". Let's avoid stubs for every tiny thing listed in a book of geographic areas.
Lists of asteroids from Harvard
Remember that WP's current 2,000+ asteroid-list articles began at Harvard University (Boston) as only 37 large data-files, listing thousands of obscure asteroid numbers in each of the 37 lists. A notable, yet obscure, asteroid number can redirect into a list of related "minor planets" where we figured 200 lists of numbered asteroids was "efficient" and 2,000 lists were perhaps too small and too many. Of course, there are over 5 thousand more-notable asteroids, which have separate articles, but the other 200,000 numbered asteroids are described in the combined list-of-asteroids articles.
Updating a list is much faster than stubs
Similarly, using lists of rivers in each small county (parish), or district, is a much easier way to cross-check the length, flow, depth, etc. of many rivers in a list of 100 small rivers, rather than using 100 stub pages, needing to be edited to describe each river and set the river-size data. WP's unfortunate prior hatred of lists, in earlier years, thwarted the reality that lists are the way of the future. It is perhaps 100x times easier to cross-check and update a list of 100 items, then edit 100 articles by name.
Search in lists rather than titles
So, we can consider the initial genius concept behind Harvard's 37 lists of numbered asteroids, with similar lists of hundreds of smaller items (+data columns), and then redirect common titles into those lists, rather than start with 999,000 stubs to be given data in the next decade. In many cases, an item is so obscure, it should be searched by name (to be found within a list article), rather than expect a stub's title, or even a redirect title to pinpoint to an article about a minor river, hill, or other item. Aggregate the minor data into lists, rather than creating so many tiny stubs.
- [ This essay is a quick draft, to be expanded later. ]