Records management

[Hmm, looks like this has stayed in draft form for quite a while. Not finished but better get it up there anyway]

Yesterday [i.e. some time ago] I met up with Sarah Demb, another newish recruit to the London Hub, who is running a project looking at records management across the Hub museums (4 core partners and a smaller one, I believe), where she's interviewing a large number of staff. The ideas is to develop a co-ordinated strategy, which seems most sensible. I've got a shed load of notes I made on the train this AM but I'm going to cut them down.

We talked about what I do generally, website management questions (backups, archives, security), how the CMS works, documentation, data management and sources. I was interested that Sarah saw her brief so widely, since I had rather narrowly conceived of "records management" as being business-centred activity, lots to do with finance and collections data, e-mails too, and a dash of archiving. In fact I think she's right to look more widely because aside from anything else we have a dearth of policies WRT "records management" pretty much everywhere I'm concerned with.

In our conversation, I noted that we use some 3rd parties to hold or represent some data, such as Google and Flickr, and this will probably increase (not even counting the forthcoming picture library arrangement). I think we agreed on the need for a digital collections policy too, which to my mind would be assembled with reference to diverse categories of material: UGC; born-digital material from the museum itself; derivatives; some things that might be suitable for full accessioning, others that might be required for a good archive. I mentioned knowledge management issues, and the complexity involved in recovering old versions of the CMS site (owing to the interwoven nature of content, template definitions, TP files, and executables).

With luck, the outcome of Sarah's work will be some form of archive post within the Hub. We certainly need one here, and I hope that we can use it as an opportunity to develop ideas about how our digital activities fit into the picture: which materials are like traditional "archive" material, which are like publications or ephemera, which should be valued and treated differently from other material, how all this ties to collections, collections metadata, oral history etc. Such a conceptual framework seems essential for deciding how to treat any sort of asset.

On the back foot with SMTP nightmares

Lots of catching up to do. Though I didn't post much before holidays, with too much going on at work, there are quite a few things I need to note down for my own benefit if no-one elses.
Firstly, though, my current trials.The last week or so have been a battle with e-mail. Mail from the web server has failed to get through and we have lost key capacity to diagnose and rectify the problem. The trouble is that it is a function that bridges several areas of comptetence and when we lost Rich May, network/helpdesk manager and good friend, back in April we lost vital knowledge, not to mention simple capacity. One of the great things about our team's structure is that we work side-by-side, pitching in as appropriate, whether we're developers, managers or HDEs, and I know it gives us an advantage over larger organisations with more differentiation/compartmentalisation because it we can have rapid, informal communication and the flexibility that comes from being all the same department. On the down side, the loss of one central member, not to mention the pitifully slow process of replacing him, leaves us badly holed. By the time a replacement is in position it will be three, perhaps four months since he left, plus one for his notice period. Of course, no-one will have exactly the same patchwork of skills nor the case-specific knowledge of the person they're replacing, but this is a study in how not to manage knowledge - far from allowing for a cross-over between outgoing and incoming employees the organisation has ensured that we have a 3 month gap between them. Of course, as much as possible was handed over to our excellent HDEs and to the rest of us on the team, but being short-staffed Help Desk have been unable to exercise much of its knowledge as they fight fires elsewhere. Projects have slipped and broken stuff gone unfixed - unavoidably, given the policies that left us underpowered for so long.
This brings me back to my e-mail issue. It turns out that e-mail from the web server does get through to external addresses (in fact, some, esepcially spam, gets through to our own mailboxes), and its looking like a spam filtering or probably DNS/SPF problem. I dabbled with these possibilities early on in diagnosing the problem but there were, as always, a number of overlapping or coinciding problems and red herrings and I spent a lot of time following these up. This is a very good example for me of how loss of capacity or knowledge can incapacitate our services or cost us dearly in time.