What the community platforms timeline records

A timeline is a list of events with dates, and for most community platforms you will have the events and not the dates. Ownership changed at some point. Pricing tiers appeared. The self-hosted version stopped receiving releases. A protocol was adopted and then quietly dropped, which for a federated network changes who the community can talk to at all.

Each of these is real and each is hard to pin to a day. The announcements are gone, the blog was restructured, and the only surviving trace is that things were different before.

This page is about recording history you cannot fully date: which events belong on a platform timeline, what source proves each kind, and how to write an entry when all you can honestly say is "between these two points".

What to take away

The event types worth recording

Not everything that happens to a platform belongs on its timeline. Interface redesigns, renamed menus, and marketing campaigns produce noise. The events that change what a community organizer can rely on are a shorter list, and they sort into the same three kinds described in the notes on watching a large service change.

The list excludes launch dates. A launch is an anecdote about the past; nothing a reader does depends on it, and it is the date most often stated wrong.

Precision is a field, not an apology

Every entry carries its precision alongside its date. The values are simple.

Day. A document states it, or you observed it on the day.

Month or year. A document states it to that resolution, or an archived copy proves the state existed by then.

Interval. The earliest point at which the old state is proven and the latest point at which the new state is proven. Written as "between" two dates, each with its own source.

Unknown, before. The new state was already in place at the earliest point you can prove. Write "by" the date.

An interval entry is a complete, honest entry. A precise date reconstructed from memory is not. Readers can act on "pricing gate moved between the spring and autumn of a given year, per archived copies of the pricing page on these two dates". They cannot act on a confident date that turns out to have been guessed.

Announced versus effective

A policy revision usually has an announcement date, a published date, and an effective date, while a platform change often has a rollout that began somewhere and finished elsewhere. These are separate events.

A timeline that records only the announcement makes the change look earlier than it was for most members. One that records only detection makes it look later than the operator intended.

Where you have both, enter both, linked. Where you have only one, say which. The commonest case is a help article with a last-updated stamp and no announcement at all, which gives you a "by" date and nothing more.

Reconstructing what nobody announced

The events that matter most are reconstructed, not reported. Three techniques do most of the work.

Archived copies. Web archiving services hold snapshots of pricing pages, terms, and help articles. Two snapshots that differ bracket a change. The snapshot dates are the interval. This is the single most productive source for platform history and it is worth learning to search it well.

Your own saved copies. If you maintain a directory on a recheck calendar, you have been saving documents at each pass. Those are dated snapshots you control, and they resolve intervals that public archives miss.

Release histories. Self-hosted software usually keeps its history under version control, with a dated release list on top of it. A gap in it is an event. A change in who signs the releases is an event. A license change in the repository is an event. None of these get announced; all of them are on the record.

Community memory is a prompt, not a source. When a long-standing member says "they changed that a couple of years ago", go and find the two snapshots.

The entry format

The consequence column keeps the timeline from becoming a changelog. A reader scanning it wants to know what each event meant, not just that it occurred.

Writing the narrative on top

A table of events is the record. Above it, a few paragraphs tell the reader the shape: the platform started as one kind of thing, became another, and what changed hands along the way.

Write the narrative only from the table; where it has an interval, the narrative says "at some point during" rather than smoothing it over. The narrative can be short, but it cannot know more than the table does.

For how the same events look from inside a community when they happen, the community platforms overview covers the organizer's side.

Common questions

Is an archived copy of a page reliable evidence?

It is evidence that the page existed in that form on that date as seen by the archive's crawler, which may have been served a different version from what a logged-in member saw. Note that limitation; it rarely matters for terms and pricing, and it sometimes matters for help articles.

What if two sources give different dates?

Enter both, with their sources, and let the interval widen. Do not pick one. A timeline that shows a contradiction is more trustworthy than one that resolved it silently.

Should the timeline include the platform's own claims about its history?

As claims, sourced to the page that makes them, with their date. Operators write their own history selectively. A "our story" page is a document; it is not a fact.

How far back should it go?

As far back as the evidence does, and no further. The point at which the timeline begins is itself an entry: "earliest archived copy found" with the date.