Proposed experiment: A Writers Workshop for Systems

\label{sec:writers-workshop}

Richard Gabriel \cite{gabriel2002writer} describes the practise of Writers Workshops that has been put to use for over a decade within the Pattern Languages of Programming (PLoP) community. The basic style of collaboration originated much earlier with groups of literary authors who engage in peer-group critique. Some literary workshops are open as to genre, and happy to accommodate beginners, like the Minneapolis Writers Workshop¹; others are focused on professionals working within a specific genre, like the Milford Writers Workshop². The practices that Gabriel describes are fairly typical. Authors come with work ready to present, and read a short sample, which is then discussed and constructively critiqued by attendees. Presenting authors are not permitted to rebut these comments. The commentators generally summarise the work and say what they have gotten out of it, discuss what worked well in the piece, and talk about how it could be improved. The author listens and may take notes; at the end, he or she can then ask questions for clarification. Generally, non-authors are either not permitted to attend, or are asked to stay silent through the workshop, and perhaps sit separately from the participating authors/reviewers. There are similarities between the Writers Workshops and classical practices of group composition \cite{jin1975art} and dialectic \cite{dialectique}, and the workshop may be considered an artistic or creative space in its own right.

In PLoP workshops, authors present design patterns and pattern languages, or papers about patterns, rather than more traditional literary forms like poems, stories, or chapters from novels. Papers must be workshopped at a PLoP or EuroPLoP conference in order to be considered for the Transactions on Pattern Languages of Programming journal. A discussion of writers workshops in the language of design patterns is presented by Coplien and Woolf \cite{coplien1997pattern}. Their patterns include:

We propose that a similar pattern-based approach should be deployed within the Computational Creativity community to design a workshop in which the participants are computer systems instead of human authors. The annual International Conference on Computational Creativity (ICCC), now entering its sixth year, could be a suitable venue. Rather than the system’s creator presenting the system in a traditional slideshow and discussion, or a system “Show and Tell,” the systems would be brought to the workshop and would present their own work to an audience of other systems, in a Writers Workshop format. This might be accompanied by a short paper for the conference proceedings written by the system’s designer describing the system’s current capabilities and goals. Subsequent publications might include traces of interactions in the Workshop, commentary from the system on other systems, and offline reflections on what the system might change about its own work based on the feedback it receives. As in the PLoP community, it could become standard to incorporate this sort of workshop into the process of peer reviewing journal articles for the new Journal of Computational Creativity³.

In order to facilitate this sort of interaction, it would be necessary for systems to implement a basic protocol related to \[\text{ {\tt presentation}, {\tt listening}, {\tt feedback}, {\tt questions}, and {\tt reflections}.}\] This protocol could be thought of as a light-weight template for creating design patterns that guide system-level participation in the context specified by Coplien and Woolf’s pattern language for writers workshops. Table \ref{tab:reinterpret} uses this framework to recast the four “perfectly” serendipitous patterns from van Andel – Successful error, Side effect, Wrong hypothesis, and Outsider – in a form that may make them useful to developers preparing to enter their systems into the Workshop. Further guidelines for structuring and participating in traditional writers workshops are presented by Linda Elkin in \cite[pp. 201-203]{gabriel2002writer}. It is not at all clear that the same ground rules should apply to computer systems. For example, one of Elkin’s rules is that “Quips, jokes, or sarcastic comments, even if kindly meant, are inappropriate.” Rather than forbidding humour, it may be better for individual comments to be rated as helpful or non-helpful. Again, since serendipitous discovery is an overarching goal, in the first instance, usefulness and interest might be judged in terms of the criteria described in Section \ref{sec:evaluation-criteria}.

We would need a neutral environment that is not hard to develop for: the FloWr system described in Section \ref{sec:foundations} offers one such possibility. With this system, the basic operating logic of the Workshop could be spelled out as a flowchart, and contributing systems could use flowcharts as the basic medium for sharing their presentations, feedback, and questions. Developing around a process language of this sort partially obviates the need for participating systems to have strong natural language processing capabilities. Post-it notes, which have provided us with a useful example of serendipitous discovery, also provide indicative strategies from the world of paper prototyping (Figure \ref{fig:paper-prototype}).

Gordon Pask’s conversation theory, reviewed in \cite{conversation-theory-review,boyd2004conversation}, goes considerably beyond what we have presented here as a simple process language, although there are structural parallels. In a basic Pask-style learning conversation: (0) Conversational participants are carrying out some actions and observations; (1) naming and recording what action is being done; (2) asking and explaining why it works the way it does; (3) carrying out higher-order methodological discussion; and (4) trying to figure out why unexpected results occured \cite[p. 190]{boyd2004conversation}.

Naturally, variations to the underlying system, protocol, and the schedule of events should be considered depending on the needs and interests of participants, and several variants can be tried. On a pragmatic basis, if the Workshop proved quite useful to participants, it could be revised to run monthly, weekly, or continuously.⁴