We design and build lots of websites for our school. Normally it’s fine, but there’s a project coming up which wanted us to build the website which had me worried. (or at least planning how to cope with it)

The reason being, all the people with the power to make decisions are too busy to do so. This can be a real pain as they’ll expect the site to be all things to all people, but not give any guidance on what they want. Which is understandable, but makes an otherwise reasonable job into an utter pain in the arse.

The good news is it looks like the website responsibility will be delegated to a non-professor member of staff who can set our priorities and make decisions (we’ll offer advice, but there needs to be an executive).

I’m thinking that this might be a very good model for any design work we do, that we insist that we have a single liason for a project. We can talk with lots of people, but only one has the responsibility to make decisions. That way we can avoid design by committee, crossed wires etc. When someone wants something “out of scope”, or that we think is a poor choice, we can ask them to go via the liason. Also the liason would have responsibilty for getting us any information we required to progress. My experince is that Profs just don’t have the brainwidth to deal with the niggling details, which is to be expected but does mean they absolutely must delegate them.

The worst case of this was a really big project which got stalled for 2 YEARS because a Prof. wouldn’t let it go live until they signed off on it, but never had time to look at it. I’m still bitter about this one, although he wasn’t a bad bloke it was utterly demoralising.

There’s a good tip for academics here; if you ask our team to get something done ASAP we will. Maybe even in an evening or weekend if we’re online and it’s not too much bother. However, if the site/wiki/blog/database then sits unused for six months, we’ll probably not go the extra mile for you again. On the flip side, if you immediately start heavily using the thing for which we put a rush on, then mucho respect.

Better still, don’t ask for rush jobs. It’s not fair to know that you need a website, but only ask for it 2 hours before it’s due to go live. We do our best, but sometimes people mistake our normal excellent turn around for a guaranteed service level. More notice is just polite, and allows us to do a batch of similar tasks together thus reducing our workload.

Right now we have a whole heap of domains registered for our department. About 30% of websites on core servers are not *.soton.ac.uk but some are under the same registration, like roar.eprints.org and demoprints.eprints.org.

We’ve never kept track of these registrations in any really organised way. I build a daily list of the primary DNS for every virtualhost on our infrastructure kit, but not for the 100 or so research webservers. People may have registered DNS in any old place, not just our own DNS server!

• ECS (280)
• auth-ns0.csail.mit.edu., auth-ns1.csail.mit.edu., auth-ns2.csail.mit.edu. (3)
• dns0.brad.ac.uk., dns0.soton.ac.uk., dns1.brad.ac.uk., dns1.soton.ac.uk. (4)
• ns.hosteurope.COM., ns2.hosteurope.COM. (2)
• ns.newdream.net., ns2.newdream.net. (1)
• ns1.dreamhost.com., ns2.dreamhost.com., ns3.dreamhost.com. (1)
• ns1.ecs.soton.ac.uk., ns2.ecs.soton.ac.uk. (1)
• ns29.domaincontrol.com., ns30.domaincontrol.com. (1)
• ns41.domaincontrol.com., ns42.domaincontrol.com. (1)
• raven.ecs.soton.ac.uk. (1)
• unknown (16)

My system regards “ns0.ecs.soton.ac.uk” as ECS. It’s odd that we’ve got a site on ns1 & ns2 only, and also one with raven.ecs listed as the DNS (this is the true name of ns0, but it should be using the alias in case we wish to move ns0 to another server)

It’s getting the data by parsing the output of /usr/bin/dig ns0.ecs.soton.ac.uk -t any domain and also checking an external DNS to ensure they tally.

The newdream and dreamhost entries are for my own personal projects, so I’m hardly blameless.

I’ve not got any solutions to this one yet, and it’s not really an urgent problem, just one I’m mulling over. In an ideal world we’d force everybody to use only .ecs.soton.ac.uk but there’s plenty of good reasons not to do that.

The best compromise would be to insist that we handled all DNS registrations and kept a careful track of both the person and the project which pays for it. Forcing people to pay upfront for years of registration to put-off the problem of what to do when registration runs out and the site remains with valuable content (research output, or worse URI’s which mean something which someone else could usurp!) – this solution is also too draconian for our users.

A more reasonable solution will be to:

• Find out about the existance of all non *.ecs.soton.ac.uk entries referring to our IP range. Using some clever web-fu or what-not.
• Keep track of one or two “owners” for each, linked with a website db entry if appropriate.
• Any sites registered in external DNS’s should be gently encouraged to move them to our DNS.
• We should make the path of least resistance to get people to let us register DNS for them and for many years past the end of the project.
• We should collect all relevant info. when the domain is registered.
• We should discourage people from creating non ecs.soton.ac.uk domains if there’s no good reason. Especially when using such domains to create URIs.

But, like I said, this is a gentle plan of attack. What we’re already doing works well enough, the above ideas would just streamline what we already do, and move knowledge into a database rather than a few people’s heads.