[tei-council] editorial services
lou.burnard at retired.ox.ac.uk
Wed Dec 15 06:32:33 EST 2010
As you all probably know, I retired from OUCS at the end of October, and
cannot therefore directly contribute to the "editorial services" which
Oxford has hitherto been supplying to the TEI via me, Sebastian, and
James, as part of its role as a TEI Host. By coincidence, at more or
less the same time, it was decided at Board level to issue a new call
for TEI Hosts, which gave us the opportunity to rethink the situation.
We don't yet know who will be TEI "partners" (the new name for "TEI
Host") nor what services they will be willing to offer. But it seems
like a good time to make a clear statement about what services are
essential to the continued development of the TEI.
This note is to ask the Council's help in deciding the best way forward
for the continued maintenance and development of the Guidelines. It's
not to identify who should do what; rather we need to identify the costs
associated with our current activity, and the most cost-effective way of
going forward with the TEI's work. The ideas presented here have been
discussed briefly amongst myself, Laurent, Sebastian, and James but
they're by no means complete or decisive, so anything is up for
discussion and your input is highly valued. Once we have a consensus as
to the best way forward, Laurent will take this to the Board.
1. What are the "editorial services"?
We start by distinguishing:
* Release engineering (producing and distributing new releases from the
* Source updates (any kind of update to the SVN repository, ranging from
minor modifications to existing specifications or prose to the addition
of entirely new specifications or sections in the Guidelines)
* Software maintenance (bug fixing and maintaining the existing TEI
software environment -- stylesheets, Roma, etc. -- to continue to be
able to produce new releases as operating systems etc develop)
2. What is needed for a Release?
The pattern that seems to have emerged over the last few years allows us
to do three releases a year, usually in October, February, and June.
Originally one of these (in October) was a "provisional" one for the
members' meeting. However many of them there are, and whenever they
happen, over the last two years a full release has usually required
something like 50 to 60 days effort:
* 5 days contributed by the editorial team in testing, validation,
* 15 days contributed by the editorial team in monitoring, implementing,
and testing feature requests and bug reports; making textual and schema
mods approved by Council
* 25-35 days contributed by council members reviewing, discussing,
deciding on issues, currently partly by email, partly at face to face or
* 5 days coordination provided by council chair
The "release engineering" is now more or less automated, if fiddly. It
could be improved by investing effort in a more modern set of tools to
facilitate better working within a "continuous integration" paradigm.
The other parts cannot readily be further automated as long as we
maintain our current working practice. To move to a proper CI
environment would require (I think) quite a bit more development of our
current test suite, which at present is at best sketchy in its
enforcement of those areas of TEI conformance which are vaguely hinted
at or informally stated in the Guidelines but not enforced e.g. as
schematron rules. And defining such rules would certainly imply a
significant amount of user consultation and discussion.
3. What is needed for Software maintenance?
Sebastian has estimated that he spends about three days a year
maintaining the Roma tools and Stylesheet test suite in their current
state; these are currently essential to the whole process of generating
and testing new versions. This aspect (software maintenance) should be
distinguished from development of new complementary TEI applications, of
There is an outstanding need to provide additional ODD processing tools,
if only to meet the common W3C requirement for dual implementation. This
should be organised as a distinct project, however.
4. How cost-effective is this method?
If we cost in Council members' time, as we have above, the cost of a
release organised in this way is high -- 50 to 60 days FTE. In practice,
it is difficult to estimate the cost: some Council members contribute
disproportionately more time than others, depending on their other
committments and the nature of their jobs.
Our experience is that telephone conferences are a good way of
confirming decisions and monitoring progress, but they are not as
effective as face to face meetings for issues which require prolonged
discussion or reflection. Moreover, it is unreasonable to expect busy
people to contribute significant levels of effort without some kind of
focus or motivation for that effort, such as participation in a specific
Council meetings are currently only held once a year, and they are not
therefore directly linked to the release cycle, which is faster. The
travel costs associated with a ftf meeting should be regarded in the
context of the cost of the effort provided by meeting participants
(which is not charged for): although it may cost 20k to bring ten people
together for a two day meeting, the resulting 20 person-days of
productive work do not cost the TEI anything more.
5. How should we proceed?
We should formalise and cost the procedure of making a new release. Here
is a (rough) proposal for such a procedure, based on the assumption that
we want to retain more or less our current working practices:
a. Triage of support tickets
- Green tickets: it's clear what needs doing; and an implementation
is proposed on the ticket, which will normally be implemented after 5
days, unless a majority of Council members veto it before the deadline.
- Amber tickets: it's clear what needs doing, but the implementation
needs extra input (e.g. more examples, more text). Implementation is
held for 20 days, pending receipt of the additional material, after
which the ticket becomes green.
- Red tickets: it's not clear what needs doing. Within 15 days, the
task is allocated to a subgroup of Council to debate and formulate
b. Review of externally-developed proposals (e.g. from SIGs)
- A Council subgroup should normally "nuncle" such proposals,
transforming them into groups of related tickets if possible
- A ftf meeting should be held to finalise each release, 15 days before
the release itself.
- A triage of outstanding tickets should be made 40 days before each
6. How many releases can we do each year?
We currently do three. If the frequency is too low, there is a risk that
we will not be able to process all the proposals that accumulate in the
course of a year; if too high, there is a risk that we will not have
enough proposals to warrant the effort of a release. We propose two, one
in the spring, and one in the autumn before the Members Annual Meeting
(but not in conjunction with it).
7. How should this work be resourced?
Council members may need to justify to their employers the work time
they devote to the TEI. In some cases, no justification is needed,
because such work is regarded as in the employing institution's
interest, as contributing to the individual's career development etc.;
in other cases the amount of such work needs to be carefully specified
(as we have tried to do here) so that a good case can be made. However,
it seems reasonable to hope that people do not stand for election to
Council without expecting to have to commit some effort, either on
behalf of their employer or in their own right. As we've argued above,
we need to make the best use we can of such time as they can commit.
There remains a residue of 25 days FTE (about half or a third of the
total) for each release which is arguably a different kind of work,
requiring specialist knowledge of the existing system and arguably also
benefitting from continuity. It is essential that it should be the
Council as a whole which decides how the TEI should develop and change
and which makes the technical decisions about how each change should be
implemented (or not).
So far, the model has been for the Council to delegate responsibility
for actual implementation to a centralised agency, providing "editorial
services". As mentioned above, these services have till now been
provided by Oxford, partly as a host contribution, and partly paid for
by the TEI. If Oxford decides to tender as a "TEI Partner", it may wish
to continue to contribute some part of that effort, or it might prefer
to contribute to the TEI in some other way, for example by further
software development, but that is not for me to say.
The Council Chair has the responsibility of deciding where
these services are to be obtained -- they might be provided by existing
Council members, by TEI partners, or by private contractor -- and of
doing so in the most cost-effective and practical manner, so I won't
pronounce on that either. I will however say that I would like to go on
contributing to the development of the TEI provided that an appropriate
means of doing so can be found.
p.s. In case you were wondering, there's no immediate probability of my
withdrawing from TEI activities entirely! I have just signed a contract
with the French ADONIS project to assist in the development of an active
TEI community in France. But that's another story.
More information about the tei-council