Inclusion criteria for full timeline in timelines

In many cases, the subject matter of a timeline is extremely vast. This means that in principle, the "full timeline" part of the timeline on the subject could grow arbitrarily. In such cases, it is helpful to have (implicit or explicit) inclusion criteria for rows in the full timeline. As the timeline grows over time (as more stuff happens, or more historical source information is uncovered) it may also be worth revisiting these inclusion criteria.

While inclusion criteria are specific to each timeline, there are a few general principles affecting their selection, and a few kinds of inclusion criteria that are recommended.

Purpose of inclusion criteria

Note that the purposes discussed here are not all conceptually distinct -- they overlap quite a bit, but represent different angles of thinking about the problem.

Communicating through meta-structure

Clear inclusion criteria make a timeline more legible by (implicitly or explicitly) communicating "meta" information about what kinds of things we want to focus on. For instance, if there's an inclusion criterion that says that all launches of new organizations will be covered, but incremental updates to existing organizations won't, that communicates the purpose of the timeline as a timeline of how new organizations enter, versus a timeline of the evolution of individual organizations. On the other hand, consider an inclusion criterion that says that major events for organizations above a certain size will be covered, but organizations below a size will not be covered. This communicates a structure that focuses on the big players in the space as the main ones to watch.

Reducing clutter

Sometimes, a bunch of events are easy to generate but can clutter the timeline. Examples include: entry/exit of employees at the organization that is the subject of the timeline, grants made by a foundation that is the subject of the timeline, blog posts by or about an individual that is the subject of the timeline.

Moreover, the extent to which these create clutter can depend on the specific topic. For instance, for some foundations that rarely make grants, each grant might be an important window into what's going on. For organizations that make hundreds of grants, adding information about each grant can clutter the timeline and make it harder to find meaningful stuff.

Deduplicating against better ways of communicating specific information

In some cases, there are external tools and websites that are much better at capturing and presenting certain kinds of information, and it's better to use those. For instance, for employee entries and exits, it may be better to use a tool such as Org Watch, that is designed to explore precisely that.

In some cases, it does make sense to put the information in the timeline, but as a separate table outside of the full timeline. For instance, the Bitcoin Core version history was initially part of the full timeline at timeline of Bitcoin, but we moved it to its own table. That table has two advantages: it can be much more compact (it can strip verbiage that would be needed when putting the same information in the full timeline) and it declutters the full timeline.

Keeping the raw size in check

It is generally recommended that the full timeline not grow beyond 300-500 rows, with 300 being a level at which it makes sense to start thinking of no longer working on the timeline, and 500 being a soft upper bound on the rows. This limit is based on what humans are capable of processing as well as on the sizes of pages that browsers and the MediaWiki editing software can conveniently handle.