Warning:
This wiki has been archived and is now read-only.

Socio-Technical Issues in Outreach

From W3C eGovernment Wiki
Jump to: navigation, search

This is a note prompted by a discussion during the telcon of 11th Feb 2010.

I guess I was raising the flag that "outreach" should not focus exclusively (or even primarily) on technical issues.

I am hopeful that I can attempt to discharge the action by providing some text I put on the uk-government-data-developers list following some suggestions that the civil servants might be reluctant participants. I am not sure where it takes us, and am happy to do something else if it is felt necessary.

The text:

Hi Guys, I don't agree, and also think that this is a self-defeating attitude to pronounce.

I find that the vast majority of public servants that I have contact with have long ago embraced the objective of making data available. They accept the general principle that has been around for a while, and the more specific mandates that have recently been enunciated.

However, they have very serious problems in achieving their objectives in this aspect of their work, and we need to recognise the problems and seek to help them overcome them, not dismiss genuine problems as unwillingness.

Perhaps the biggest problem is that we can't actually tell them how to do it technically, certainly with any community agreement. Andy is right that "public agencies are rarely known for being tech pioneers": perhaps this is a good thing? They are also very well aware that significant IT projects can be very expensive disasters. I would hope that public servants do take some reasonably conservative view before embarking on such things. And we are in times of great financial restraint, where the agencies are struggling to maintain what they see as their core business (such as dealing with patients and pupils). So for example, if a public servant, having strained might and main to add RDFa to their existing web pages announced it on this list, I predict they would get a flurry of responses explaining politely and less politely why that was not right/good enough.

A related difficulty is the business process problem. Information flow is tied intimately with the internal processes of any organisation. These cannot be changed quickly, for very good reasons in terms of cost and effectiveness. Working with organisations to understand their business process, so that a suitable technology for publishing can be chosen is crucially important here. Bald pronouncements on how things should be done that do not take cognisance of the business and system processes are likely to fall on deaf ears.

This really is a socio-technical problem, and needs to be approached as such.

This is not meant to be defending those who would maintain a tradition of secrecy - it is rather to recognise that such a view of public servants may well be outdated (I think it may have been more accurate in the past), and that we need to be supportive of a very difficult challenge for them.