How to track community platforms updates without missing a policy change

A community platform rarely announces the change that matters. The announcement covers a new feature. The real change sits in the third paragraph of a revised terms page, in a help article that lost a sentence, or in a release list nobody read.

Catching it is a watching job: a fixed set of documents, fetched on a schedule, plus a way of reading a difference.

What to take away

The six documents worth saving

Six documents, saved with the date each is fetched.

Blog posts, social announcements and feature tours are prompts to check the six. They are not sources in themselves.

Diffing a policy without being fooled

Policy revisions are mostly restructuring: sections renumbered, headings renamed, sentences reordered. A raw diff shows hundreds of changed lines and buries the three that matter.

Normalize before diffing. Strip numbering, collapse whitespace, and sort sections by heading where you can, so a moved section does not read as a deletion plus an insertion. The tools are ordinary. The discipline is doing it every time.

Raw, that pair reads as one deletion and one insertion. Normalized, both lines match, so the renumbering vanishes and the only real change in the revision stands alone.

Then read for verbs. In the normalized diff, watch what the operator may do, what the member must do, what is retained, and who receives what. A new "may" for the operator or a removed "will" for the member is substance. A rewritten sentence that says the same thing is not.

Findings worth recording take a handful of shapes. A new category of third party the operator may share with. A retention period lengthened or made indefinite. A license widened to cover uses beyond running the service. A notice period shortened or removed. An appeal route added or removed. A jurisdiction changed.

Reading a release history

For self-hosted software the release list is the document, and its shape tells you more than its content.

A steady cadence that stops is the loudest signal on the whole watch list: maintenance has paused, and a community running that software accumulates unpatched risk.

A change in who publishes the releases suggests a change in control. A license file change alters what an organizer may run. A major version with a migration note means the upgrade is no longer routine, and communities that skip it will be stranded.

None of this is announced. All of it sits in the repository, dated by version control whether anyone meant to publish it or not.

Triage: three bins, then edit

Every difference goes into one bin before anything is edited.

Field change. A recorded field of the entry now holds a different value. Log old value, new value, both dates, both copies. Update the entry, keep the old value visible, and add the event to the platform's timeline with its interval. That is the change log discipline applied here.

Context change. Nothing in the entry moved, but the reason it held did: an ownership change, a license change, a pause in releases. Log it, and mark the affected fields due for recheck ahead of schedule.

Noise. Restructuring, redesign, renamed features, marketing. Note that the document was checked and found unchanged in substance. Do not log the details.

The third bin exists to keep the first two readable. An entry whose change log records every renamed button is an entry nobody reads.

What an organizer needs from the catalog

An organizer who picked a platform from this catalog wants one thing from its updates: to be told when the ground moved.

So the catalog should carry, per platform, a short dated list of field changes and context changes only, each with the one-sentence consequence for a community running there.

"Export now omits timestamps on the free tier, as of the following date; organizers relying on export for archives should test theirs" is the form, because data portability is the field whose quiet narrowing hurts most. The diff evidence sits behind it for anyone who wants it.

The community platforms overview covers what an organizer does once the ground does move: the migration, the announcement to members, the choice of where to go. The catalog's job ends at telling them early and specifically.

A cadence that holds

Fetch and diff the six documents quarterly for hosted platforms. Check the release list monthly for self-hosted software. On any prompt, whether news, a member report or a reader's message, fetch out of cycle.

Record every fetch in compact form: document, date, unchanged.

The watch list entry for each platform holds:

Common questions

A platform's terms changed, but the entry's fields did not. Is that a field change?

No. If no recorded field moved, it is a context change: log the revision with its diff, then reread the entry for fields whose value depended on the old wording. Terms changes travel in groups, and the next revision may move a field.

The help article I was watching was deleted. What do I record?

The deletion, with the date detected and the last saved copy. A vanished article about export or deletion is a finding in itself. The field it supported becomes "documentation removed; last known value as of" the copy's date.

Is it worth watching the status page?

For the pattern, yes. A status page that reports incidents promptly and in detail is evidence about the operator. One that is always green is evidence too, of a different kind. Record the pattern once a year rather than every incident.

How do I know the six documents are the right six?

Because every field in the entry traces to one of them, which is how the entry was built in the first place. If a field is added whose source is a seventh document, add that document to the watch list the same day.