[tei-council] editorial services

[James Cummings]

Should we expand this list to include all those things done by 
other hosts?

-James

On 15/12/10 11:32, Lou Burnard wrote:
> Dear Council
>
> 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
> SVN repository)
> * 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,
> packaging, distribution
> * 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
> telephone meetings.
> * 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
> course.
>
> 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
> meeting.
>
> 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
> possible resolution.
>
> 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
>
> c. Timetable
>
> - 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
> release.
>
> 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.
>
>
> Lou
>
> 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.
>
>
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council


-- 
Dr James Cummings, Research Technologies Service
OUCS, University of Oxford