I've finally "finished" my reaction to Chris Krycho's provocation, Feeds are Not Fit for Gardening. (ht Erlend Sogge Heggen).
I think I now have infrastructure sufficient to publish evolving content, that might start as an unfinished sketch and "blossom" over time (and with help and interaction from you, dear reader).
The approach I've taken — of course since I am an RSS fanboy — is to graft what I need on top of existing RSS infrastructure. Among RSS infrastructure, I include both conventional feed readers and "announcers": RSS consumers that notify parties about new items in ways that may be more disruptive than just another item in a well-populated feed.
An example on an announcer is my own feedletter, which notifies RSS items by e-mailing posts one at a time or in digests, and also by posting to Mastodon.
My approach is quite manual. No software determines when an "update" has been made. "Tweaks" — which may include correcting typos, reworking sentences, or even rewriting whole paragraphs without changing the intended meaning — shouldn't be notified as updates. Modifications, however big or small, that substantially augment or alter the content of the item usually should be notified. In my view, which is which is the author's judgment call. So authors manually add an item to their post's update history when they wish to provoke such a notification.
Once authors begin to define an update history, that history becomes appended to the end of posts. Example.
When authors declare a meaningful update, all they must provide is a timestamp. An atom:updated element will be included in the RSS item with that timestamp.
Authors also may provide a description, a "revision-spec" (usually a git commit identifier) for the revision superceded, and an author list (if authorship as well as content is changing with the update). Example.
The more authors provide, the richer the update history. Update histories will include any description given, along with links to the prior ("superceded") revision, and a diff between the updated post and the superceded revision.
Whenever a new update is declared, a synthetic post will be produced, whose publication date is the moment of the update, announcing the update. Example.
That post will have its own RSS guid and permalink. So, without requiring any change to the behavior of existing feed readers, followers will be notified of these updates.
The RSS items generated for these updates will be marked "synthetic", of "type" UpdateAnnouncement, so that announcers (for the moment only my feedletter, but please join in!) can decide whether they wish to notify these items.
They include a "hint" for announcers to adopt a Piggyback policy, meaning the synthetic update notifications should be included in digests and other multi-post announcements that include at least one not-piggyback post, but they should not trigger announcements on their own. Announcers are free to follow this hint, or to make a different choice.
For subscribers to notication services that accept the hint, synthetic update posts will not cause people to get spammed with "here's an update!" messages. That would be annoying. On the other hand, e-mail subscribers will not be notified of all updates to existing posts. One-at-a-time subscribers will see none of the update notifications. Digest subscribers will see update notifications only when the digest would also include at least one "organic" post. There is a trade-off to navigate between annoyance and information.
For posts intended to evolve over time, that might invite the attention of particular followers or collaborators, authors can explicitly declare a post to be a "sprout". Example.
The term is taken from Chris Krycho's essay. These posts will be accompanied by their own RSS feeds (example), and will track declared updates only to that particular item. The implementation is not great — ideally each notification would include and highlight the changes — but so far my diffs are too lame for that. However, subscribers will be notified, via a dedicated feed, of each update to evolving items that they mean attentively to follow.
Obviously, nothing is really "finished". Everything in life is a garden!
But I think that this is enough that I can start sketching and evolving posts intended to develop over time, rather than finished-product "atomic" posts.
Thanks to Chris Krycho and Erlend Sogge Heggen for inspiring me to think about all this!
Update: Chris Krycho credits Maggie Appleton for some of these ideas, so I will too!