I learned today
a) that this blog site allows editing of blog posts, even when they are quite old and have been responded to
b) that this blog site does not seem to have versioning
c) similarly,Google docs does not have versioning.
I think this is interesting, because I have long felt that the main difference between a blog and a wiki is that a blog is a "point in time", whereas a wiki is supposed to be updated to be the latest and greatest.
In practice, wikis and blogs shade into each other. Many wiki pages are really "point-in-time", or even flow of consciousness. Similarly, apparently blogs can be edited.
Now, with wikis it is rather typical for a point-int-time wiki page to be reorganized eventually, after a while, to be more of a reference article. Similarly, wiki pages sometimes regress - a reference article may get a lot of conversational stuff added to it.
Blogs, in my experience, do not evolve that way. Given that you can edit the original blog post, I suppose that you could go and edit the comment stream. But I have not seen that done.
If you edit the original post of a blog, then comments may be "orphaned" - they may no longer apply to the revised main page. I.e. they become inconsistent. Now, the edits I made today do not render the blog inconsistent. Mainly, company name. But I wonder how folks who administer large blog sites handle this?
Who should the right to change blog comments? The original poster? But then the point of unmoderated blog comment discussions rather goes away.
I have this rather inchoate vision of a blog/wiki hybrid. Pages start, perhaps, in a blog-like manner. With a title, but also with an implicit date. Comments accumulate in the usual blof like manner.
At some point you may want to "fork" the blog into a more wiki-like, reference, structure. Hit a button, and you get two versions of the original page: first, the blog page TITLE-DATE, with comment stream, and then also TITLE-CURRENT. Cross linked in all possible ways. I.e. you can go from TITLE-DATE to TITLE-CURRENT, back, to all of the comments, etc. Eventually you may want to fork again, to produce TITLE-DATE2.
Automatic version control on a wiki is much like this. All of the information is there. However, it is hidden behind the version control system. Sometimes I think that you want to maintain the versioned TITLE-DATEn topic pages for external viewing.
Ideally: (1) preserve everything under version control. But, (2) automate the process of snapshotting a particular version. Automatically create TITLE-DATEn. Make it possible to give meaningful names to such versions. And automate the process of cross-linking. I think it quickly becomes evident that the links want to be managed by a database, not by hyper-text style links, once again to ensure consistency.
Note: such snapshotting or forking doesn't just apply at page level. It also applies to groupsor webs of pages.
I've been doing much of this by hand when I create a release of a wiki based specification. Of course I want to automate what I now do by hand.
---
I want to do something similar for email archived into a wiki store. I want to preserve the original "point in time" email. But I want to enable the forking and revision of such email into reference material.
---
Back to versioning: I like versioning.
This discission indicates that individual versions need to have different access control. Ideally, a "point-in-time" original blog post or email is read-only - the email, immediately when sent, the blog post perhaps after a small interval. But attempts to edit such read-only blog or email items should produce a copy-on-write type behavior, with automatic renaming, as described above.
Also, although I like versioning, and I think that everything should be versioned, occasionally it is necessary to be able to remove an object, or a version of an object, completely, cleanly, without any hope of recovery. E.g. IP.
No comments:
Post a Comment