The technical work of the Text Encoding Initiative (TEI) is performed by work groups composed of volunteers from the community of those using electronic texts for research. The work groups are the core of the TEI, and the quality of their work is crucial. This document describes administrative procedures which should be followed by work groups in order to ensure that the work of the TEI is conducted efficiently, reflects systematic analysis of the topics addressed, represents or creates a consensus of interested parties, and is thoroughly documented.
With some exceptions as indicated, the procedures given here apply to all TEI-chartered work groups, whether internal (chartered and funded by the TEI), external (chartered and funded by some other body, but recognized by the TEI and given a TEI work group charter), or mixed (anything else or anything in between). In addition to specifying procedures, the document includes some words of advice, gleaned from the authors' experience in work group meetings both inside and outside the TEI. Unlike the administrative procedures defined here, these words of advice are not formally binding on TEI work groups -- although the issues they raise will often be more important for successful work than the administrative procedures for naming funded and non-funded members, announcing meetings and their agenda, preparing minutes, etc.
This document is intended primarily for the use of Work Group heads and Work Group members; it assumes the reader is familiar with the TEI, the TEI Guidelines, and SGML. For information about these and other related topics, the interested reader is directed to the TEI Web page at http://www-tei.uic.edu/orgs/tei.
Work groups are formed by the TEI's executive committee, on the advice of the TEI's technical review committee (TRC), whenever the TEI undertakes a new work item which does not fit into the area of responsibility of any existing work group. They serve until they have finished all their outstanding work items, or until discharged by the TRC. (The TRC may discharge work groups which are making no progress on their work items, in order to be able to form a new work group which will, it is hoped, have greater success.)
Work groups can undertake any sort of technical work, but in general the work items assigned to a work group will be something like these:
The general procedures for TEI technical work and the maintenance and extension of the TEI Guidelines are all discussed in document TEI ED W48, Procedures for Maintenance and Extension of the TEI Guidelines.
The TEI is a community-based project; work groups consist of volunteers who donate their time and expertise in order to maintain and develop an important tool for scholarly research. The results are intended to serve community needs. It is important that the TEI's technical work be open to public participation, scrutiny, and comment, to ensure that the results reflect consensus in the community of affected users. For this reason, TEI work groups are required to give public notice of their meetings, to publish minutes of their meetings and drafts of their work, and to respond to public comment and suggestions.
Membership in a TEI work group is normally controlled by the work group head, though the TEI executive committee and TRC may impose particular requirements on the membership, or may name individual members of the work group. In general, members must be drawn in roughly equal numbers from North America and Europe; this requirement may be waived in individual cases for externally funded work groups, but will not normally be waived for TEI-funded groups.
The work group head is responsible for informing the TEI central secretariat of the membership of the work group and providing full contact information for all members; those listed as full members of the work group will be named in the acknowledgements to the Guidelines.
In many cases, it will be necessary for work group members to fund their own attendance at work group meetings. In some cases, it will be possible for the TEI to fund travel for a small, fixed number of members; it is up to the work group head whether to allocate these travel funds ad hoc, meeting by meeting, or to distinguish TEI-funded members from self-funding members of the work group. The only limit on the non-funded membership of a work group is the work group head's willingness to accept self-funding members, and their willingness to serve.
Members of work groups are expected to attend meetings regularly, and to participate in the technical work between meetings. The TEI does not impose particular attendance requirements, but a rule used by many successful groups is that two successive unexcused absences from meetings terminate one's membership, as does the passage of a year or so during which a member has produced no substantial contribution to the work group in the form of working papers, drafts, or active and useful discussion in meetings or by email.
Work group members have the right to reasonable consultation in the scheduling of work group meetings, and to at least four weeks' notice of the meeting time, place, and agenda. They have the right to examine and discuss work group drafts before the drafts are labeled as having been approved by the work group. Members of work groups may attend (at their own expense) meetings of any TEI work group; they may participate in the discussion if allowed by the head of the host work group. They have the right to examine technical working papers internal to the TEI, and to comment on drafts prepared by other work groups. Like members of the public, members of work groups have the right to suggest new work items and pose technical questions to the TEI Technical Review Committee.
Academic funding being what it is, work groups are urged to conduct as much of their business as possible by electronic discussion or telephone conference call. This reduces the overall cost of the group's work, and makes it much easier for penurious but energetic members to participate fully.
Face-to-face meetings, however, remain necessary, and in general work groups should expect to meet at least once a year, and possibly as often as every few months. The TEI's experience is that work group meetings should last at least two full days; TEI funding will not be provided for meetings of less than one and a half days.
All meetings must be called at least four weeks in advance, with the meeting agenda described in the announcement. This ensures that members will have time to prepare (and to buy reduced-fare air tickets). When a meeting is called, the TEI central secretariat should be notified and public notice given to all participants in the TEI of the meeting date, agenda, and local organizer, so that other work groups know when work relevant to their own is being discussed. (Normally, public notice will consist of the work group head or the central secretariat making an announcement on TEI-L giving the place and date of the meeting, the major agenda items, and contact information for the local organizer and work group head.)
All participants in the TEI (members of the TEI executive committee, members of the TRC, members and heads of other work groups, and the official representatives of affiliated projects) have a right to attend work group meetings (at their own cost), and participate in the discussion. Others may attend if permitted by the work group head. Public notice of meetings is required in order that participants in the TEI may exercise their right of attendance if they choose.
In general, documents to be discussed at a meeting should be prepared and distributed in advance of the meeting. We have experienced meetings in which important results stemmed from notes members had scribbled on the plane to the meeting, but the odds of good results are better if documents are finished and distributed beforehand.
During the meeting, discussion should be kept firmly on the technical merits of the proposals under consideration. Since technical questions can evoke surprising intensity of feeling, it is important to keep the discussion substantive, and not allow it to stray to questions of motive, or to degenerate into personalities. In TEI work groups, all members have an equal voice, and equal responsibility for persuading their colleagues of the proper course of action. Seniority in age or position does not relieve work group members of the responsibility for supporting their position with well chosen examples and arguments.[1]
In the past, most TEI work groups have managed to work by consensus, continuing their discussion until they find a position to which all members can assent. This is the recommended practice. In some cases, it may be necessary for members to agree to disagree, and to take a vote, in which case the normal procedures for clearly stating the motion, discussion, and voting should be followed.
Minutes are required for all TEI work group meetings; they should be filed with the TEI secretariat for distribution to all interested parties.
No travel reimbursements will be made for meetings not announced or meetings for which the minutes have not been sent to the secretariat. Decisions made at such meetings will be null and void, and will not be recognized as binding on any TEI work group or committee.
Like any complex project, the TEI involves the work of many people. In order that those who come into the project later can know what has already been done, work groups should take pains to generate a helpful paper trail of documents, recording their goals, their discussions, and their results. When questions of information or interpretation arise after a work group has completed its work and been discharged, the documentary record is the only source of information about the meaning of the work. It needs to be complete.
Work group documentation will normally include:
In general, responsibility for the final work products of a work group should be borne by the work group as a whole. For that reason, the work group as a body is normally named as the author of a document approved by the work group. Individual members of the work group may and should sign their own names to documents prepared for discussion, or drafts not yet adopted by the work group. Such individual authorship attributions should normally be removed when a document is prepared for distribution after being discussed and approved or adopted by the work group.
All TEI documents are either publicly available, or available only within the TEI. All TEI-internal technical documents are accessible to all participants in the TEI; documents may not be restricted to members of the work group. Public documents will normally be placed on TEI file servers; TEI-internal documents will be made available to TEI participants by the TEI central secretariat upon request.
All TEI documents should be labeled clearly with boilerplate text describing their status. In particular, the status description should indicate:
The TEI maintains a registry of TEI documents, in order to allow anyone interested in the TEI to keep informed of developments. Members of work groups are encouraged to use the TEI central document registry, in order to inform themselves of relevant work being done by other work groups.
Work groups should maintain a registry of work group documents, using the standard TEI document numbering scheme described in document TEI A1. As new documents are prepared, or as document numbers are assigned to documents to be prepared, the work group head is responsible for notifying the central secretariat, so that the central registry can be updated.
The head of the work group must file a written progress report with the TEI executive committee every six months.
All drafts should be submitted in SGML form, using either the TEI Lite DTD or another DTD specified by the TEI editors for use in TEI work group documents and drafts. For further information, see document TEI ED W55.
Public comment should be taken seriously.
In general, public comments on work group drafts or proposals should be considered explicitly, and the minutes of the meeting should record whether the comment was resolved or found unresolvable (and why).
The TEI does not prescribe a particular approach to solving technical problems. You're on your own there. But it is usually a good idea to begin by surveying thoroughly the prior work in your field: not just work on electronic representation of blorts, [2] but standard works on the nature and importance of blorts. In particular, a list of what researchers have always considered the salient features of blorts -- and how they have dealt with those features in print -- is a very useful first step toward a tag set, as well as a final check to ensure that the TEI tag set for blorts is at least as capable as existing schemes. In general, work groups will do well to consider existing attempts to summarize or formalize a field both at the outset and as part of the evaluation of their working drafts.[3]
It is almost always a good idea to check ideas against concrete examples, early and often. Specific examples may be misleading and must not be allowed to prevent attempts to generalize and theorize about an issue. But specific examples also allow a work group to ensure (a) that everyone is talking about the same thing, and (b) that the general theory you have just developed actually applies in at least some cases.
Some work groups avoid tagging specific examples because the members don't feel comfortable with SGML tagging. In general, our advice is for members of work groups to make strenuous efforts to become comfortable with SGML markup, since it's hard to take any markup scheme seriously if its developers won't use it themselves. Most TEI work group members need no more information about SGML than they can get from the relevant introduction to SGML in the Guidelines themselves, but you do need at least that much.
Specific examples can also cause trouble because it's not always clear what to call things. It may be clear that certain portions of a text belong together, but not clear what to call the grouping. A useful technique in such situations is to call it nothing at all for a while: just tag it with empty brackets, or tag it as a <blort>:
<chant>
<l>sha na na na</l>
<l>sha na na na</l>
<blort>
<l>hey hey hey</l>
<l>good bye</l>
</blort>
</chant>
This example conveys the idea that the last two lines of verse
are felt to constitute a unit of some kind, without forcing you
to stop right away and find a name for the unit.
It seems obvious when we say it bluntly, but it is often overlooked: start with simple examples. Then work up to more complicated ones. But do not try to finish your work without tagging some real examples. When examples are part of work group documents, it will be helpful if bibliographic details of the source and a photocopy or scanned image of the relevant pages can be provided to the central secretariat, so that the image can be linked to the document electronically, for consultation by readers.
The task of a work group is to produce a final document of the kind requested. If you are charged with studying an issue, you should produce a technical report. If you are charged with drafting a new section of the Guidelines, or with revising an existing section, you should produce a fully worked out draft, complete with reference documentation. Resist the temptation to produce, instead, a list of instructions to someone else, explaining what the chapter ought to do. There is no one else to do the drafting: it is your job, as a work group.
If you are revising an existing section of the Guidelines, it is a good idea to provide a summary of the changes you make; this will allow the editors and TRC to concentrate on the essentials.
If you have questions about SGML, about how the work of your work group fits into the TEI as a whole, about the interface between your work and that of other work groups, or about any technical problem, feel free to ask the editors, or to refer a query to the TRC.
Comments on this document may be directed to:
[1]
Arguments from authority (of the form "well, I've been
doing this for twenty years, and I think ...") may of course be
made. But Thomas Aquinas, the great Scholastic philosopher, is
reputed to have observed that the argument from authority is the
weakest of all arguments. (And he should know.) It is much better
if, from your years of experience in the subject matter, you can
adduce relevant examples and muster compelling arguments. Authority
without arguments has never won consensus in TEI work groups, and we
hope it never will.
[return to text]
[2]
TEI documentation often speaks of blorts, and more often of
<blort> elements, when it is desired to be concrete and general
at the same time. The word blort is much
shorter than "whatever phenomena your work group is charged with
handling", but means much the same thing. The term was introduced
to the TEI by Sebastian Rahtz, to whom be thanks.
[return to text]
[3]
The
TEI tag set for bibliographic information, for example, would have
been much better had we consulted existing bibliographic tag sets
before designing it, and not just afterwards.
[return to text]