• While I agree with the cynical bits about never getting agreement from the exact people who are the biggest block in getting the job done, I also think Tony's request for an outline of policy areas, for new and aspiring DBAs, is a good idea.

    I also think a wiki would be the easiest way to get it done.

    Could start with just "you'll need policies on backups, downtime, hardware requirements/configuration, security/auditing, DAL/DB APIs (procs vs inline code vs isolated DAL), coding standards, data access (possibly including PCI compliance), data retention (PCI again), patching, dev-to-prod path, on-call schedules, source control/change tracking, and beer popsicles", just to start out. Easy to expand from there, since I'm sure I missed a few of the top-level things. With those in place, it would be a matter of stubbing out some suggested policies based on shop-size, et al. If each policy is defined on the main page, and links to details, it would be easy to read and learn from.

    Make it operate under a beerware license, so anyone can copy-and-paste into their own document for internal editing and use, and you're good to go.

    I think anything other than a wiki is going to require too much editorial oversite to coordinate. It can be locked down to approved authors only, and probably should be, but there should be open comments (moderated, of course).

    - Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
    Property of The Thread

    "Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon