[tei-council] editorial services

Laurent Romary laurent.romary at inria.fr
Wed Dec 15 07:28:22 EST 2010


Hi James,
Not sure I understand the question here, but we are discussing here  
what impacts on the maintenance of the guidelines and the council  
work. What did you have in mind?
Laurent


Le 15 déc. 10 à 12:46, James Cummings a écrit :

>
> 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
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Laurent Romary
INRIA & HUB-IDSL
laurent.romary at inria.fr





More information about the tei-council mailing list