You won’t find any Star Wars characters in our department, but you will soon find a Wiki.
When you enter your cataloguing department every day, you bring with you information that cannot be found in AACR2 or MARC. In addition to the many tools we use such as DDC, Bookwhere, Cutter tables, Validator, LC and so on, there are internal cataloguing rules that many of us have not bothered to write down because we just “know it”. But, when I first started my position, I didn’t “know it” because I was new to the system.
After creating two handwritten binders full of notes and collecting “cheat sheets” from all of my cataloguers, I began to think that there had to be an easier way to organize this information. There are rules based on rules that were based on a meeting three years ago. This is the type of information that only exists as long as there is no turnover or retirement within the department. However, this information is vital to retain when people leave the department because we will no longer have them as our resource.
Having experienced this “cataloguer’s knowledge” firsthand, I began exploring different options to organize and retain this information. How can we have a shared space where the department can access “cheat sheets” and other resources? Can I create a space where we can collaborate as well? At first I considered creating a simple database. Then, I thought about having all of the documents typed up and creating one master binder for the department. All of these just didn’t feel right. I looked at blogs but wasn’t really sure that it was right for our department and then I stumbled upon wikis.
Wikis are free, open-source software created for the purpose of sharing information. This really grabbed my attention the first time I saw it. After further reading, I found myself attracted to the real-time factor and potential of the Wiki. The real-time factor means that I can spend less time fielding emails and sending around internal cataloguing rules in draft. Instead, I can post one draft and collaboratively have all of the cataloguers critique and edit it until it works. I like the idea of having the cataloguers play a role in creating internal rules and accessing them immediately. In addition to storing all of our in-house cataloguing rules, I plan on including minutes from our meetings, announcements from LC, SirsiDynix, other vendors and links to all of our online resources. I can even include a professional development element.
Currently, I am in the beginning stages of setting up a Wiki for our department. I have had the opportunity to “play” with the software and get a feel for its potential. I have also been speaking with staff, seeking their input and really pushing the buy-in factor. I’m fortunate because my cataloguing department is full of people who are really keen on new technology and are always willing to at least try something new. At the present time, I am organizing all of the information that we want on the Wiki. This is a bit labour intensive. Sorting through old meeting notes and cheat sheets is time consuming. Once I have chosen the base information for the Wiki, I still need to type it, organize it and assign access points to it. I need to design not only the content of the Wiki, but its general layout.
There are also privacy issues and editing restrictions that need to be addressed. Because it is open source software, I need to be careful who can edit the Wiki and who can see it. Should we store it on a web server or on our own intranet? Should all the cataloguers have editing access? Who should monitor the edits in addition to myself?
As this project goes on, I’ll be able to share my experiences with you. Overall, I see this as a very good thing for our cataloguing department. There are so many steps ahead and I am not naive about the time that it will take to create the Wiki. Once the Wiki is finally in place, there is always the staff training and evaluation. However, I am optimistic that this will be a great asset to our department.