This is a permanent version, or snapshot, of this page. Please see Revision notes, below, for more details.
ML: we (Mathew Lowry, Peter Kaminski, Bill Anderson) had a great chat as we prepared version 1 of this site on the difference in philosophy between wikis and blogging. We decided to write something together on it using Massive Wiki, to explore the issue by writing about it and to test he various collaboration Contribute and Commenting options we are proposing to this site's contributors. Key links:
ML: I am keenly aware, as I write this opening paragraph of this newly created page, that I'm writing this like a blog post - for one thing, I'm labelling each paragraph as 'mine', which is a very blogger* thing to do (* a polite way of saying 'author egocentric'). By the time we show this to more people, however, this content will have been wikified through collaboration, and this paragraph may be gone.
ML: But not, perhaps, forgotten - there may be an early version of this page kept somewhere, because our discussion started when we considered version control and permanence in Massive Wiki: should previous versions of a wiki page be made available? Which ones? How? Does it matter if visitors to an old version cannot find the latest one? Who does it matter to?
Different CMS do version control differently. Most sophisticated ones use major and minor versions. My rule of thumb for my day-job context, where online content is sometimes legally important and/or massively multilingual:
But what of a wiki, and what about blogs? Wiki pages are changing all the time - they're living documents, maintained by (hopefully) armies - whereas blog posts are supposed to be snapshots of what the blogger was thinking the very moment they hit 'publish'.
Co-editing this page will hopefully surface an answer. To launch and explore that discussion, I'm:
Of course, blog posts do get updates, but in the blogosphere it was always a matter of honour to explicitly state any 'major version' updates upfront, to avoid accusations of surreptiously editing "what I said 3 years ago" to better match today's reality. With the reverse chrono presentation of blog posts, many bloggers will simply write a new post when their views change rather than update an old post few people will read anyway.
Personally, as a blogger, I find writing a new post just to update an old one is a pretty bad solution: after all, the old one remains online unchanged. Of course I could add a quick update to the old post pointing to the new one... but what happens when I have 5 versions of the same post? When I add a sixth I'll have to update all 5 manually!
Better, perhaps, to have a canonical blog post which sets out the current version of "what I think about this thing", date-stamped with the last major version, with an auto-link back to previous versions. Ideally all previous versions auto-link not just backward, but also forward to both the next and canonical versions.
ML: The above applies to blog posts because blog posts are (usually) written by a single author and are presented in a reverse chronological feed which implies Newer is Better. Wiki pages, on the other hand, are collaborative efforts where the authorship can be almost impossible to track.
WLA (2022-12-11): It seems to me that on wikis the authorship is not as important as the text of the wiki pages, and, perhaps, how well that content is written and cited.
ML: They are also not time-critical in nature and so are presented as part of an interconnected body of knowledge organised more by topic than creation date (how often do you visit Wikipedia to view it's "latest page"?).
So how would version control and permanent versions look like in this context?
tbc
ML: How would a site which combines wikis and blogs look?
tbc
ML: In the current version of Massive Wiki, Git manages every version of every file, committed by each contributor, ideally with the contributor's comments. While these "Git commit comments" can distinguish between new versions submitted to fix a typo and versions which totally transform the page's contents, they are not visible to site visitors, although they can be accessed on github if the repository is public (see this site's).
(Note that this does not factor in possibilities offered by GitHub such as branches, which provide something intermediate between minor and major versions.)
ML: Personally, I think Git fulfils the requirements for managing minor versions off-the-shelf, but major version changes need to be better signalled to visitors by the wiki's editors on the site content itself. How might that look?
ML: In our chat we discussed a "first class function" for Massive Wiki for making a new major version of a file. With a click:
One problem I see here is that the Editor must decide to create a major version before starting editing, not after having worked on the content.
ML: Note that almost all of the above can be done easily manually, which is what we'll have to do for this file - ie:
Hence the creation of a major version entails the following manual processes:
As set out above, I'm testing this with versions 1 & 2 before pushing both to the repo and opening the discussion.