Some rather loosely strung together elaborations on yesterday’s post.
I still don’t know a lot about open source methods, so tonight I’ll do my best to describe what little I do know, and then describe what I see as the points of possible overlap with the writing classroom.
As I understand it from Tom Adelstein (link courtesy of, again, Chris Worth), the open source software development process (and I’m appreciative here of the fact that the focus seems to be on process; thank you, Donald Murray) begins by defining a project and then looking to an existing base of standards and finding a software “vocabulary” and set of tools with which to work.
To me, this seems to be very much in line with composition instruction’s recent refocusing on genre as an essential component of rhetorical invention, although the apparent split would be that open source development would seem to take revision of the standards themselves as a task entirely separate from development of software under those standards, whereas some writing teachers often favor pieces of writing that themselves expand or test the boundaries of a genre. Also interesting is that the problem of defining the project according to genre seems to fall much more on the writer/developer rather than on the teacher (or does it? suddenly I’m not so sure), so that the work would seem to become more learning-centered than task-centered.
The process model of writing instruction seems to now carry with it the seeds of an open source concurrent versioning system, as well, by which the essay/software development team — which I take to mean simply the class — can view the code and comment on it, in its use of small peer response groups. Electronic management, distribution, and tracking of texts can serve to facilitate versioning and revision, and one might even imagine an environment in which the whole class, or even the whole university, or the world at large — rather than a group of three or four — could serve as peer responders and commenters. And, as I understand the process, those who actively contribute code typically tend to comprise a much smaller body (perhaps just one’s peers in the writing classroom) than the mass of reviewers and testers.
The stumbling block, of course, would be the question of who gets the privileges to make changes to the code base or, in the case of writing instruction, to the essay itself. And the roots of that stumbling block go all the way down to the grading system and our conceptions of individual ownership and compensation. I’m not sure what to think about that, so perhaps the best thing to do is acknowledge it as a problem, put it on the shelf for the time being, and move on, with the understanding that we’ll have to come back to it before long.
Beyond the motivational advantages that I mentioned the other day, it also seems appealing that projects begun under an open-source approach would have the potential to continue long after the semester’s over and grades are in, thereby increasing the use value of the project to the student and helping to attenuate any writing’s grade-based exchange value. These projects might also usefully muddy the boundaries of the class and the classroom, opening it up to outside participation and interaction, which seems like a fine thing; so, too, they considerably open up possibilities for collaborative work, which I’ve assigned in my classroom with varying degrees of success, but have always enjoyed the challenge of working on myself.
With that in mind, what I was seeking in yesterday’s post (and am continuing to seek) was a group of people who might want to collaboratively think through concrete ways of applying such practices in the university classroom. The goal might ultimately be a syllabus or several syllabi, a description of classroom practices and pedagogical method, a discussion of the implications of such practices and methods for things like grading and plagiarism policies, and — ultimately — the composition of a collaboratively-written essay describing our findings. In other words, doing research that might illuminate for us how to implement what we learn. And part of the reason this all sounds so vague is that I don’t see any real structure for it, as yet: while this is a stab at defining a project, I’m not sure on my own of the vocabularies and toolkits with which one might undertake such a task.
Hence the request for collaboration.
Pingback:sources