Now, as I'm sure you all know by now modifying the files in the 12 hive of a MOSS isntallation is not supported by Microsoft, as when they release updates or service packs any of your changes can and will be lost, and may even prevent an update from happening etc. etc. So what do you do when you need to modify SharePoint's out of the box site definitions? They live in the 12 hive so you can't (shouldn't) go and just change the files. In most circumstances I would just say to make a new site definition and use that instead, but the particular circumstance I have come across at work is that we need to change the inbuilt meeting workspaces. These site defintions differ from the others in that there appears to be some hard coded bits in MOSS that handle these sites differently (for example, only the site definitions and templates based off the MPS template will appear when you create a meeting workspace for a calendar event). So if you want a new meeting workspace, creating a new definition wont cut it because whatevery ou do, it just wont be the MPS template.
This is where feature stapling comes to the rescue. Feature stapling allows you to attach a feature to all sites of a given template and configuration, so you can do things to the site definition without actually modifying it. Chris Johnson has a very helpful blog post where he describes how to staple a feature to a site definition. Lets have a quick look at how it's done.
First, create a feature like usual (it must be scoped for the 'Farm' level and activated in the central administration site), and in the elements file add a tag like this:
<FeatureSiteTemplateAssociation Id="29D85C25-170C-4df9-A641-12DB0B9D4130" TemplateName="MPS#0" />
This tag will assign the feature with an ID of 29D85C25-170C-4df9-A641-12DB0B9D4130 to all basic meeting workspaces (Configuration option 1 for the MPS template). When you think about it, this is a really powerful way to get things done. So in my example at work,I have bound many features to the blank meeting workspace (MPS#1) so that when someone creates a site based off that definition,all of my features are turned on in it by default. So if I have features that created document libraries, deploy master pages, or do whatever else, they all happen automatically when the site is created. Even cooler than that is that if the stapled features if are hidden ones, the users of the site won't see them and can't turn them off, so the whole experience is much more transparent. It really does give the effect of having the site definition changed, but without modifying the files in the 12 hive.
Another very cool thing to do with this is to implement features that have recievers (a receiver is a piece of code that runs when the feature is activated/deactivated). If you write some code into a receiver, it will effectivly run whenever a site of the given template is created, perfect for doing all sorts of things that feature's wont normally do for you, so your new site really can be customised to be just like you need it to be - all without modifying the site definiton. So if you have managed to read this far down, I have hopefully explained why you (as a develoepr at least) should love the idea of feature stapling - it is just cool.