Angie,

Keep in mind that as Records Managers we are looking at content, context and structure. In addition these wiki's must also have legal, administrative, fiscal or historical value to the organization. Those folks that are attempting to schedule wikis solely on the basis of content are making a mistake. A rough approximation for internal wikis would be shared drives. Shared drives allow access from multiple individuals to records and documents. These records may be viewed, and altered by any of the individuals with access. Historically there was no tracking on the changes, who changed them, when they were changed, and what the changes were. Legal went nuts over this. The records are subject to discovery and there were a number of problems with content. The owner becomes responsible for the record on the shared drive. 

You can ban the use of wikis. This is probably the safest move. However, wikis are highly addictive. They are an efficient business tool and halting there use might not be possible. If you continue to use them you will need to capture the entire process on a given record. It will be critical that you keep the context and and structure in place. Keep in mind that your ROI on the use of this tool will impact the organization. I recommend that your business rules operate on the back end as much as possible. If your solution becomes a burden to the user your internal issue will become an external issue. 

I would recommend that you define internal wikis as a record restrict use of the wikis to business use. . Assign a retention period. I would say that if you are going to allow the use of wikis, you have the tiger by the tail. The volumes are going to to add up and risk my be considerable. About the only folks that are going to back you on this is the IT/ECM folks.  Say hi to Faust when you see him.

Chris Flynn




> Date: Tue, 1 Jul 2008 13:23:49 -0500
> From: [log in to unmask]
> Subject: Retention Periods for Wiki's
> To: [log in to unmask]
> 
> Internal wiki's for organizations are getting very popular.  The good
> news is that you can share a lot of information very quickly.  The bad
> news is that, like the internet, not everything is accurate or
> appropriate for publication and anything can be changed on the fly.
> 
> Anybody have any experience doing retention scheduling for wiki's?  Much
> like blogs, it is impossible to classify any of it as a record until
> after you know what the content is...so a one size fits all policy would
> be impossible to defend.  I was thinking that one strategy might be to
> ask the initial creator of the web page to classify the posting in
> advance by selecting a Record Category that could have some business
> rules attached.  
> 
> Can anybody think of a different approach?
> 
> 
> 
> List archives at http://lists.ufl.edu/archives/recmgmt-l.html
> Contact [log in to unmask] for assistance
> To unsubscribe from this list, click the below link. If not already present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of the message.
> mailto:[log in to unmask]

_________________________________________________________________
Watch “Cause Effect,” a show about real people making a real difference.  Learn more.
http://im.live.com/Messenger/IM/MTV/?source=text_watchcause
List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance
To unsubscribe from this list, click the below link. If not already present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of the message.
mailto:[log in to unmask]