Exam season has been upon Oxford over the last few weeks. Throughout the city we’ve seen students in formal academic dress (‘subfusc’ and gowns) usually ornamented with colourful carnations (white, pink or red, according to whether a student is on the first, middle or final exam of a series) making their way to and from exams, often armed with bundles of notes for last-minute revision. Whether taking preliminary or final exams, most students have spent at least a few weeks in careful preparation for this moment, and revision is a key part of that process.
In preparing the dictionary too, the process and the result depend not only on an initial stage of drafting that can be likened to a student’s first forays into each new subject; preparation similarly continues through repeated readings and improvements, a series of ‘revision’ processes in which the content is reviewed and refined. Although such revision is perhaps somewhat more ordered and systematic than the labours of even our most diligent students, it is nonetheless a good parallel: by looking again at the draft text with fresh eyes and concentrating on particular aspects, we can find that problems that have not previously been noticed can stand out, while solutions to others that have previously seemed intractable can suddenly open up.
In fact, as well as the fascicule(s) in preparation at any point, the dictionary as a whole can equally be considered a work in progress too, as can only be expected for the output of nearly 50 years of concerted editorial work. In that time we have published well over 3,000 pages of text, and within them many tens of thousands of entries containing hundreds of thousands of quotations. Thus even after a fascicule has gone to press, sometimes many years afterwards, we are bound to observe things in the published text that we would wish to correct or amend in the light of discoveries made by us and by others as work has gone on.
Because of the size and complexity of the dictionary, handling these corrigenda is by no means a straightforward exercise. Therefore establishing an appropriate revision workflow has been an important task for the project over the last couple of years, especially as we now approach the time when we will wish to do the work of dealing with these both in print and in our final XML data. This development process has gone through some significant steps in the last few weeks, and so this is the first of a series of posts in which we take a look at how we have gone about this task given the various constraints we have to operate within.
As the first stage of the process, clearly the possible corrections need to be recorded when they are noticed. Possible corrections come in many types. Sometimes we know what the desired change is, i.e. we know what we would want to print instead of what has already been printed, whether that is a deletion of some existing text, an insertion of new text (such as an additional quotation), or an amendment. Sometimes, however, we can only recognize a difficulty in something published but we do not yet have enough information (such as a full quotation or its reference) to be able to know what we would want to print; for these, further research will be needed before we can decide what, if anything, to do.
For many years suggested items for attention had been collected on slips in the traditional manner and sorted alphabetically in boxes. In more recent times they have been recorded electronically within our Editorial Management System, an installation of the issue-tracking system Redmine (also used by the project for more general tracking of the editorial workflow for material being prepared for publication). The tracking system allows us to record in a structured searchable form as much information as we have (and to add to it as new information is found). This means that we can concentrate on our current primary task of preparing new material for publication, leaving ourselves a well-ordered set of queries to work through in due course.
Using a structured form for recording ‘issues’ means, for instance, that we can categorize possible changes as being either ones that affect only our electronic data (e.g. discrepancies in tagging or between the captured XML and the printed text), such that it would not relevant to publish a correction of this kind in print, or ones where a amendment should be included in a published corrigenda list. Similarly, we can record whether an issue would affect only a single entry or whether it is something we might wish to amend globally across the whole dictionary text (e.g. changing a bibliographic abbreviation or sim.).
Neither of these groupings would have been easily extracted from the earlier box of paper slips (though admittedly the former distinction would not be relevant to a purely paper-based dictionary, and the latter largely impossible to implement without having structured data such as XML or the like on which to work)! Both are important distinctions, however, because they will allow us to prioritize and order the revision process: for instance, a global change could affect any entry and so it will be important for us not to have entries undergoing individual revisions at the same time in such a way that they miss a relevant global change or in such a way that the results of the two changes are incompatible.
It is in fact worth highlighting the decision we have made to use an off-the-shelf system rather design or cobble together our own from generic tools such as a database, spreadsheet, or set of word-processed documents (e.g. mimicking the previous collection of corrigenda slips): it illustrates the fact that these days there is rarely a task so specialized that there is not already some existing software solution readily available, very often free and open source, that can be used directly or at least with easy adaptation to meet the demands. While such software will come with some of its own challenges (in setting up, customizing and learning) that might be absent if one used more familiar software (Word, Excel, etc.), there are certainly long-term benefits of getting a more specialized solution that does roughly what is wanted and adapting it to the particular needs.
Redmine, for instance, is easily customized for various types of workflows and classifications for issues (i.e. items for correction), and for various user roles and privileges with regard to their review and management; at the same time it provides a user-friendly interface for editorial staff to contribute items, and it can securely handle multiple simultaneous users. (It is also exceptionally easy to deploy, using the Bitnami stack.) In a later post we will look at how the workflow management capabilities of an issue-tracking system transform a simple database of issues into a powerful organisational tool to enable efficient processing.
In the next post, however, we look at the amendments made to our XML schemas to enable the various stages of the workflow once a suggested issue gives rise to a change that is identified as needing to be incorporated into the dictionary.