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
^dfa0a7
ML: How would a site which combines wikis and blogs look? As both ML and WLA pointed out above, authorship is very different.
In a collaborative site like massive.wiki, bloggers might be reticent to write a blog post there, as all other members can edit it. On the other hand, if they are interested in massive.wiki, chances are they want to share their thoughts to spark a conversation. In blogs, that means attracting comments. But what happens when the blogger learns something from those comments? The blogger can either:
If, however, there's a permanent version system in place, the blogger can:
So pemanent versions users on a collaborative wiki site to blog and contribute their ideas to a more collective intelligence.
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?
^aeddc3
ML: In our chat we discussed a "first class function" for Massive Wiki for making a new major version of a file, (currently version "N"). With one click, this function:
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 and any other blog posts on this wiki.
How is set out in detail in Manually creating permanent versions on this wiki. In brief, the creation of a major version entails the following manual processes: