This post is part of a series that are components of my “Expert Plan” at my school, looking to create a shared resource for my colleagues as the school moves towards greater adoption of laptops and technology in our pedagogy.
This is actually a classic use of wikis — the one for which they were developed, in fact — and one that I have found very useful in the past. By documenting my work on a project in a public, shared space, I am both sharing information that needs to be known and inviting other participants to contribute their knowledge as well. I use wikis both for shared projects with my colleagues (as a way to guarantee that only the most current documentation is available, rather than distributing instantly out-dated paper handouts) and as a way of pushing my students to document their own work so that I can grade them on process. Additionally, wikis are a way for me to document my own thought process for both professional development and future planning purposes.
I have found that many of my colleagues (both at [my current school] and [at previous schools]) are hesitant to edit existing documents. The most reliable contribution that I have found my colleagues make is on meeting minutes, when I invite those who did not attend a meeting to insert their contributions to the meeting as comments on the page.
When working on a project with a similarly technically-inclined colleague (say, in the Education Technology department), the process is more likely to be more collaborative, as we edit each other’s work more liberally (although even this is not a guarantee).
Students don’t document their working voluntarily. I have only had success in asking students to document their work when I have both assigned the documentation for a grade (usually a grade separate from the end product of their work, so that I can distinguish between process and outcome not just in narratives but also in my gradebook).
The closest that I have come to developing a true classroom culture of collaborative documentation was last spring at [my previous school] in my Application Design classroom. In this case, I worked with the students to help them select and design an open-ended project for which they had to do immense amounts of research (they were creating a computer-controlled CNC lathe). I found that there was an inverse relationship between the amount of expertise that I demonstrated and the amount of work and thought that my students contributed: when they could rely on me for answers, they were lazy about documenting their work and finding their own solutions. When I professed no knowledge (often truthfully), students were far more likely to both do much more exhaustive research and to present their findings more clearly.
One challenge of creating a truly collaborative wiki environment (whether with colleagues or with students) is to get all of the participants to read, respond, revise and/or react to each other’s contributions. For example, I am doing a miserable job, on this page, of linking to the work of others in the Laptop Leaders program. I suspect that a major part of this is simply the “drinking from the fire hose” feeling incurred by the stream of data as everyone contributes simultaneously. In a classroom, I have had some success dividing students into groups around a shared research interest. To that end, I need to sift through the other Laptop Leader documentation that refers to, say wikis.
At the basic level, my sense is that wikis represent such a shocking change in paradigm for how the web is used that the average user is either befuddled or intimidated by them. I found that I was explaining how wikis work to my classes and the students were fascinated and mildly horrified at both the ease with which they could make changes and the ease with which I could track their use of the wiki. I don’t know for certain, but I wonder if my colleague’s reluctance to update wikis is a combination of fear of the unfamiliar (editing the wiki) and fear of speaking out (publishing their words/ideas to a broader arena in a way that feels more permanent than, say, an email — more on par with a faculty meeting).
Seth Battis November 22nd, 2009
As we steam towards the end of the year here, I’m watching my next few weeks and, in fact, my summer start to disappear under encroaching project creep. Not that I object too much: most of the projects are pretty cool — in fact, some of them are projects that I’ve been dying to find time to work on during the school year.
I’m painfully aware of my propensity to put off inordinate amounts of work for my next medium-sized chunk of free time. My canonical example is the year in college that I put off about a dozen errands until my Thanksgiving break. Boy howdy, was it ever a rude awakening to realize that Thanksgiving break is only about three or four extra days on the weekend, and probably at least two to four of those days are chock full of commitments to family and friends. Not so much time.
With that in mind, I was fascinated by Steve Pavlina’s article on calculating your fudge factor: that ineffable amount that your horseback estimate of the time necessary for a project is off from reality. My fudge factor is approaching 1.0 for things like driving time — and has been for years. But for coding projects and curriculum development, it might be closer to 3-10 (as in, it takes me 3 to 10 times as long as I plan for).
I’m not convinced that I have Steve’s discipline, but I rather suspect that I can use old data to get some sense of how off I usually am in my time estimates. I have surely made lots of promises archived in my email and then documented my progress (and extensions) in that same medium. Sounds like an interesting project to work on this summer…
Although building an intelligent project monitor that used heuristics to identify project commitments and updates in my incoming and outgoing email and automatically calculated the fudge factor… Now, that could keep me off the street for days at a time. Or weeks. Depends on what my fudge factor is.
Seth Battis May 23rd, 2008
Posted In: Educational Technology