A Conversation with Jeff Calado, Release Engineering Manager and WikiChampion
1. Why did you choose a wiki?
When I started here two years ago all project communication and collaboration was done through email, meetings, and networked drives. It was widely accepted that certain people were the keepers of information on topics they were experts on. The only way to get this knowledge was to email or talk to them, and they’d often send you a document they had sitting on their computer or forward you an old email.
From past experience I knew first-hand the collaboration benefits a good wiki could have given the team’s commitment. I put together a sample wiki demonstrating how team and project collaboration could happen and then I ran a series of 1-on-1 demos with the more influential members of the organization to sell them on the solution. Upon going through the demo and answering their questions the benefits were so clear that it took no further convincing.
2. What type of wiki are you using?
We self-host a Confluence Enterprise wiki that was chosen, for among other reasons, because it allows us to flexibly control access rights to various areas in the site.
3. How are you using the wiki?
We create a space for each team within the organization and for each project, plus one space for information relevant to the entire organization.
Each project home page provides an introduction to the project and posts the latest status information. Meeting notes and specs are also posted. Technical details about the project, testing tips, and the like are all captured.
People still love their email around here so we often create an email account for the wiki and add it to the project email group. Confluence is able to download those emails to the project space so they are archived with the rest of the project information. This is great because it lets someone that jumps on the project mid-way to view all of the email history that happened for the project before they started.
Each team also maintains its own space with information relevant to the group. In particular, information on getting their systems up and running, which is priceless when new employees join the team. Each round of new hires feels indebted to those that posted the information that got them started and they do a great job improving the content and making it even easier for the next round.
4. Which patterns are in use on your wiki?
I serve the role of Champion, Maintainer, and WikiGnome.
As described above, we’re using the One Wiki Space per Group pattern to organize the site. Some projects are more private than others and this structure gives us an easy way to limit access to projects as necessary.
Every new employee is immediately added to the wiki and sent a welcome email with login information and a link to a wiki page containing a screencast that I recorded to provide an introduction to using the wiki. This is our approach to the Invitation pattern.
The IdentityMatters pattern comes into play because people that used to keep everything in their head know they’ll still be recognized for the information now that it’s out in the open and won’t lose their expert status.
The Design group loves to serve the role of WikiZenMaster / WikiFairy and beautify the site.
Confluence provides the Automatic Index pattern for us, displaying the recently updated pages on the home page. Also, many people subscribe to daily email updates to see what has changed over the past 24 hours.
The Trellis pattern is fitting for the evolution of the startup guides the teams have built. When new employees are getting up-to-speed they document what they discover and sprinkle comments throughout the document asking for validation and elaboration on the points they are most unsure of. This gets the easy stuff out and the more experienced employees come in and fill out the details since the tedious work of getting all the little details out there was already done.
Finally, two great examples of the SingleProblem pattern are out of the office calendars and release notes. People here use iCal to track their schedules. We have an internal WebDAV server where they can publish their iCals and each team member maintains an out of the office calendar that they publish to the site. Confluence has a plugin that displays a calendar in the wiki and lets us subscribe it to any number of iCals. For each team they create an out of the office calendar page in their team or project space and subscribe to the relevant team member’s iCals. This lets individuals manage their time-off and automatically communicate it to the broader groups they work with.
The other SingleProblem pattern example is our management of release notes. Each build has release notes documented for it. We capture those in the version control system when tagging the build but that doesn’t provide a very visible means for documenting the release. Part of the build process is to automatically publish release notes to the wiki. This puts the history of all builds in one easy to read location. There is the added benefit of providing a pull system for people that want to get email each time a build is released. They simply subscribe to receive email updates each time the release notes index page is updated and now they get emailed each time a build goes out. Before this solution, the entire team got emailed the build release notes whether they wanted them or not and there was no central repository of this information outside of the version control system.
5. What changes have you seen as a result of using a wiki?
The greatest improvement has been centralization of project information on the wiki, it really helps the team to collaborate better.
There is now an expectation that people take relevant information out of their head and share it on the wiki. The most valuable benefit from this has been the decrease in time and effort needed to get new employees up-to-speed as well as an improvement in the consistency of the process. The benefit of improving the knowledge and skills of the broader team is another valuable result.