A precursor to gClouds and gReports

I've been doing some more thinking about, well, all sorts of Gaia-related stuff, and I've come up with an idea that could be a sort of precursor to gClouds and a Gaia wiki system, "gReports". Essentially, it's a way of macgyvering a wiki "knowledge base" system inside a pod.

Here is a description of the group-based Knowledge Base and how it might work:

Overview

It has been noted by some that Gaia lacks a “wiki-esque” system for the collaborative creation of “knowledge articles” (see my gClouds blog post and related thread in the Think Tank), which could be very useful in bringing together the knowledge of the community – currently fragmented and dispersed more or less randomly throughout the community – into a single, easily accessible place. Until Gaia has such a system in place, one way of partially filling this gap is for groups to set up dedicated boards to act as a repository for a given community’s knowledge.

To keep the knowledge articles contained in this “knowledge base” easy to reference and maintain, discussion related to the articles should be kept in another board, ideally one specifically created for such discussions. Although it's also possible to link to articles anywhere in the group or, indeed, anywhere around Gaia or beyond.

Because only group moderators can edit posts (and therefore also these articles) beyond the 15 minute window available after submitting a post, special procedures for updating knowledge articles need to be followed. These procedures are described below (see “Editing an Existing Article”).


Creating a Knowledge Article

Before posting a knowledge article, your group will need to have a “Knowledge Base” board and preferably also a dedicated article discussion board.

When you are ready to post a new article, you will need to start the article “thread” in the knowledge base board with a brief post that contains a synopsis or the intention of the article to be written. In part, this is necessary from a technical standpoint for the ongoing article editing process because we don’t want the actual article to be the first post in the thread for reasons we will see in a moment.

This initial post should also contain a section for links to the related article discussion threads (and be sure to start such a thread before creating the article if one doesn’t exist already), and may also include a section for links to other discussion threads (even in other groups), blogs or other content related to the article. These additional links can even be to content from outside the Gaia community.

Once this initial post has been created, the actual article should be posted as a reply to the thread.


Editing an Existing Article

When it comes time to make changes to an existing article for whatever reason, you will need to copy the entire article in its current form and paste it into a new post, which you will need to create using the “reply to thread” function (and NOT the “reply to post” function). Then you can make changes to the text and submit the revised version to the thread.  At this point, you will have both the old and the new versions of the article in the thread as follows:

Synopsis and links
==Old article
==New article

In order to have the old version of the article removed, click “reply to post” for the OLD article and write a message that says something like “OLD VERSION TO BE DELETED”. You may also add references such as “as per discussion”, including a link to the discussion related to the changes that have been made.  Adding an indication such as “minor edit” can also be helpful in determining how much care needs to be taken before deleting the old version, while still keeping the delete request brief.

(Note: If only one or two changes have been made, these changes can be indicated in the delete request.  For multiple changes to an article, you may want to consider enclosing the changes in "***", or something similar, so that it's easier to see what changes have been made. Then when the old article is deleted, the moderator can also remove the markup.)

Now you should have a thread structure like this:

Synopsis and links
==Old article
====Delete request
==New article

At this point, the exact procedures can vary from group to group, but it’s recommended that you agree to a certain time period, say a number of days, that needs to elapse before an article like this can be deleted by a group member with admin privileges. This time period (which may vary depending on whether the edit is substantive or minor) would give other article editors an opportunity to approve or reject the changes before the previous version is lost forever. Once the time period has elapsed with no reasoned objections to the changes being proposed, the old article and any related reply posts may be deleted.

Brief approvals or objections may also be posted either as replies to the delete request or as replies to the new version of the article, but any detailed comments should be kept in the discussion board (and linked to) so as not to overly clutter the actual article thread. Once agreement has been reached as to which version should remain, all of these approval or objection posts in the article thread should be deleted (which is why detailed comments should be posted in the discussion board).

Note: The reason we don’t want the actual article to start an article thread is that, by doing so, when the original article is deleted, the entire thread would be deleted.


Adding Related Links

Here, too, procedures may vary from group to group, but one recommendation for adding related links to an article is to create a new post using the “reply to thread” function. You would end up with a thread like this:

Synopsis and links
==Article
==Additional links

Then this links post can be updated as necessary following the same procedures as for editing the article.

Another option would be to start a new thread with the new introductory message and added links. You would then copy the article over into this new thread and request that the entire old thread be deleted, again leaving a period of time for such deletion to be opposed. However, because creating new threads like this could make management of the knowledge base more complicated and difficult to control, it might be best to discourage creating new threads for the same article as much as possible. Otherwise, there’s a very real risk of ending up with multiple versions of essentially the same article without being able to decide which is the “right” one.


Knowledge Base Index

It’s also a good idea to create an “article” (following the procedures described above) that will serve as an index and/or table of contents for your knowledge base (or two separate articles: a table of contents and an index). This could be structured and sorted in a variety of ways, but try to keep it as simple yet useful as possible.  And don’t forget to link to the articles directly in the index.

With a good, up-to-date index in place, article writers can check here first to make sure a similar article to the one they had in mind hasn’t already been written. The index should also be made “sticky” (by a group moderator) so that it’s easy to access.

Note: Another reason not to start new threads for the same article is to avoid having to update the index when the article is updated.  For this same reason, in fact, you should ensure that the index links to the thread (or the first post in the thread) and NOT to the article post. Otherwise, when you delete an old article, the link from the index will be broken.


The Future of Gaia

One benefit of creating Knowledge Bases like this is that, if Gaia ever does have its own, more sophisticated wiki system, there will already be a store of articles out there just waiting to be added to it.  And if this idea really catches on, it may help Gaia to see the need for such a system in the first place.

So let’s spread the word and spread the wisdom!


P.S. And feel free to copy these instructions for your own knowledge base and adapt them to the needs and preferences of your group!