Auditing from within MOSS (SharePoint Server) is quite simple -- There is a UI for enabling and disabling all of the events you may want to audit.  There is also a facility for viewing and exporting these logs.

However, what if you would like to use auditing features in WSS 3.0 without MOSS?  Believe it or not, most of the same auditing functionality is available, but without a UI.

Most of the information you need to do this is available already on the web, however its very spread out and difficult to digest.  Rather than repeat information that is available elsewhere, let me point you to all your options with some explanations:

You can enable auditing on the list or site level via code -- Here's an example of what that looks like:

SPSite siteCollection = SPContext.Current.Site;
siteCollection.Audit.AuditFlags = SPAuditMaskType.All;
siteCollection.Audit.Update();

You might do this in a feature, or as an application page.

Here is additional information on enabling Auditing for a document library.

Here is information on enabling auditing for a site collection.

You can also enable the auditing without writing any code, using this custom STSADM command from Gary Lapointe.

Then you might ask yourself...

But how do I view my logs?

There is less information available about this.  First, let's talk about where the logs live.

Audit logs are stored in your sites content database, in a table called "AuditData".

That table has a logical schema, and looks like this:

[SiteId] [uniqueidentifier] NOT NULL,
[ItemId] [uniqueidentifier] NOT NULL,
[ItemType] [smallint] NOT NULL,
[UserId] [int] NULL,
[MachineName] [nvarchar](128) NULL,
[MachineIp] [nvarchar](20) NULL,
[DocLocation] [nvarchar](260) NULL,
[LocationType] [tinyint] NULL,
[Occurred] [datetime] NOT NULL,
[Event] [int] NOT NULL,
[EventName] [nvarchar](128) NULL,
[EventSource] [tinyint] NOT NULL,
[SourceName] [nvarchar](256) NULL,
[EventData] [ntext] NULL

You may need to join this data to your Site table via the SiteID if you want to report on it effectively with SQL Reporting Services or even Excel.

Additionally, the Audit API has a more 'proper' way to access the audit data which will be safe in the event that the underlying schema changes in a future update.

Ted Pattison has prepared a sample with the ability to configure the logs and view the log data using the API.

Oh, and of course I plan to add the ability to view audit logs to my SharePoint Log Viewer in a future version!

As a developer working on SharePoint customizations within Microsoft, I can attest to the end-user benefit of a clear and concise customization policy for any MOSS deployment.

Sean Livingston has made available a document which was the basis for Microsoft's own SharePoint customization policy, and that you can use as a starting point for creating your own policies.

Save yourself some time (and impress your manager!) ... Grab Sean's whitepaper and put together your own customization policy today.

Abstract from Official SharePoint Product Group Blog:

The SharePoint Products and Technologies 2007 Customization Policy white paper is a starting point for companies to develop their own policies for implementing and managing customizations in a SharePoint based environment. A version of this document is currently being used as a key component of the hosting policy for SharePoint customizations within Microsoft's internal SharePoint hosting team, which manages what may be the world's largest SharePoint environment. This document was designed to act as a bridge between system administrators and developers so that both sides could evaluate SharePoint customizations with an emphasis on administration concerns such as supportability, performance, and deployment issues. This document will be added to over time as new information and best practices become available.