UK Web Focus (Brian Kelly)

Innovation and best practices for the Web

The Project Blog When The Project Is Over

Posted by Brian Kelly on 15 Mar 2010

Last year I asked the question “Should Projects Be Required To Have Blogs?“. This generated a lively discussion with JISC Programme Manager Nicole Harris pointing out the potential dangers of a formal requirement that JISC-funded projects should be expected to provide a blog:

If a project has to have a blog, does it have to have a wiki, does it have to twitter? I think JISC should be telling projects to maximize their use of communication channels and providing the platforms to enable that, but i don’t think we should be mandating or recommending any particular route.

Although a formal requirement to provide a blog may be inadvisable, many projects are likely to chose to provide a blog to support their user engagement and dissemination activities. But what happens when the project has finished? The blog might continue if there is felt to be a business case to justify the effort in writing new posts, moderating comments, etc. But what if it is felt that it would not be appropriate to continue to post articles to the blog?  Should the blog be deleted? Should the content be migrated to another location? Or perhaps the content and blog software continues to be provided, but no additional content is published.

The JISC-funded SIS (Shared Infrastructure Survey) Landscape Study was completed recently by colleagues of mine at UKOLN. The JISC SIS Landscape Study blog played a key role in gathering information related to the study and keeping users engaged in the various stages of the project. Following the termination of the project and the announcement of the project’s final report the blog was kept open for three weeks to allow users to provide any comments on the final report. The blog was then formally closed and an announcement made which included a summary of how the blog had been used to support the work:

We made seven posts (this one is number eight) making various announcements about the progress of the study. We created 47 Pages in all, 16 of which were used to collect evidence based on specific work tasks; these attracted 186 comments from a wide range of respondents. We also used a Page to record the findings of our literature survey and share it with viewers, and used Pages for the 22 Case Studies we published.

In addition we described how the blog content is being ‘mothballed’ but the content, comments and URLs will continue to be available for the new future:

The blog will remain visible for the next three years (a condition of the JISC funding) but will be frozen in terms of adding new content and viewers will not be able to add any further comments.

I feel this is an  appropriate approach to the management of a project blog when the funding ceases. It should be noted that the process also included changing the blog’s configuration options so that no additional comments made be made to the blog, in order to avoid the need to manage spam comments.

However there may be occasions when it is not possible to simply lock down the content of a blog.  A case study on “Archiving Pebble Blogs at ramble.oucs” published back in 2007 provided an example showing why it may not be possible to continue to host the software used to provide a blog.  This case study illustrated how the content continued to be hosted without changes in the URLs of the posts, thus ensuring that bookmarks to posts continue to work correctly.

This approach though, did require technical expertise which may not be readily available for all projects hosting a blog.   It is possible to create a PDF copy of the content of a blog, which is another way of preserving the content of a project blog if it is not possible to maintain the content using the original blog software. However this approach will fail to maintain bookmarks and results in content which is not as easily reused or cited as the original blog content.

So my clear preference is to continue to host the content on the blog, whilst locking down the content if it is not possible to continue to manage the content, including spam comments.  I also feel that the policy decision on what is to be done with a project blog after funding has ceased should be made during the life time of the project.  Is the approach taken for the JISC SIS Landscape Study blog one that may be useful to be adopted by other project blogs?

2 Responses to “The Project Blog When The Project Is Over”

  1. We run a blog server in ECS because without it projects which must blog either have to go offsite, like wordpress.com or set up their own local server (hello increased support team work).

    If a mailing list, blog or wiki is a tool for organising a project then there’s not pressing need to preserve it far beyond the end of the project. However if it contains research output or reports then there should be an obligation to preserve the content, but keeping it editable is only important if the project had a key goal of community creation.

    As for preserving a site because you can’t maintain the underlying software anymore, my professional advice is to do ALL of:
    a) save a the data including an SQL dump AND the version of the software it ran.
    b) save a human readable version. a PDF print (not thought of that before!) or a spider wget of the site.
    c) save a machine readable version. If possible one big Atom file. Don’t forget to rescue any uploaded images if they can’t be embedded in the file.

    There is a project with ESRC to actually collect dynamic PHP sites which continue to provide value, and try to give them a long term home: http://www.ncrm.ac.uk/research/other/restore/ they are not yet looking at blogs or similar.

  2. […] The Project Blog When The Project Is Over […]

Leave a comment