TEI Council Meeting

The TEI Council teleconference meeting took place on Thursday 7 February 2008 at 13:00 UTC.

Participants: Gabriel Bodard (GB), Arianna Ciula (AC), James Cummings (JC), Syd Bauman (SB), Lou Burnard (LB), Dan O'Donnell (DO), Sebastian Rahtz (SR), David Sewell (DS; minutes), Laurent Romary (LR; Chair), and John Walsh (JW).

Council members unable to participate: Peter Boot, Tone Bruvik, Elena Pierazzo, Manfred Thaller.

Scope of Council Activities

Technical Activities

Guideline Status

LR asks us to consider the current status of Guidelines. How are we handling updates and point releases? SR reminds us that he had raised the question of fixed release vs. varying bug-fix releases and had recommended a 2x per year schedule. GB, AC, and SB agreed that practice and consensus was for a fixed timetable. SR notes that the 1.0.1 release is a "release zero", not a 6-month release. LR concurs: the next release will be over the summer, unless serious bugs appear. JC notes that everyone has access to SourceForge for intermediate stages.

Should we have a "stable/unstable" distinction? It's helpful for people to test releases. LB: there is a fixed date in the TEI timetable, the November meeting. Shall we say there will always be a prerelease of next major release before Nov?

JC asks about numbering of releases, so people can cite the version of the Guidelines they are using. SR: the only way to do this is by release dates, where the date is the version number. LR notes that a release is more than just a source version on SourceForge, it involves a lot of checking. DO asks if someone could just write up a numbering system for us to put on a Web page? A new version number will be added when there is an actual feature/module change, not just changes to Guidelines language.

LR: can we stabilize the following formulation?

Releases every 6 months; a prerelease before the November meeting; unstable SourceForge branches are maintained and identified by SourceForge revision number. A "release" consists of the SourceForge update, creation of compiled packages and schemas, and an update of the Guidelines (LB).

Bug reporting

LR asks about the current situation with the stability of the Guidelines: do we still have major bugs, or just tiny issues over next months? JC: it's not clear where bug reports are going any more. LB: it is clear we want bug reports to go to SourceForge, into the tracker. But we haven't agreed on: (1) how to make sure Council provides input, or who is responsible; (2) the way to build a workflow to take suggestions & deal with them. DO: this will be an important thing to discuss in Galway. LB: is this channel best way of soliciting input? SB: no, many people are scared by SourceForge. We need to have an email/list mechanism. LB: then at the point in discussion where there is general agreement, someone needs to write it up as a SourceForge feature request. LR notes the gap between TEI-L and TEI Council. DO: So we need formally to keep an eye on TEI-L, and put into SourceForge bug reports and feature requests from there. JC: shouldn't all Council members do this? DO: but it helps to have someone designated. LR agrees; at the Members' Meeting, we discussed the dropping of Guideline editors, with work on them organized by Council, but LR strongly recommends that we provide stable editorial support to Oxford. DO: the decision about editors was made to increase flexibility, not to remove input from the current editors. There is no mandate for "editors" in the (TEI Consortium) Bylaws, but we can still assign certain tasks as needed.

LR recommends that Board discuss this matter; we need an air traffic controller.

There followed some additional discussion on bug reporting/tracking procedures. DS suggests the possibility of a Wiki area on the TEI Wiki for bug discussion. SB suggests having a single email address for bug reports. DO objects that this creates multiple unofficial channels for bug reports. We don't want multiple lists. SB replies that we're going to have this no matter what. LB replies we can insist on paying attention only to two places and having bug reports sent to specified venues. JC says that if bugs are to be discussed on an email list, surely that should be TEI-L. AC notes some people don't understand the distinctions between the different venues. We need a mechanism to facilitate communication for less technically adept users. DO asks, why not have a volunteer from Council as facilitator?

LR: there's a problem with having too many tools. Let's have a clear mechanism. TEI-L is a good place for all these discussions; let us not have lots of side discussions.

DO: Okay, let's use SourceForge as our single location, with mechanisms for helping people report who don't use SourceForge. LR: there should be tutorials on how to report. If we reduce number of tools, people can be more aware of them.

DO: it sounds like we have identified a need for a release secretary and a SourceForge secretary, and an editorial support group.

Outreach and Education

ODD

LR begins by suggesting that exemplars and

ODD are key words. One of main ways we can offer entry into the TEI environment is by adding ready-made schemas. SR cautions that if we create exemplars by committee, it will be difficult to get results. SB says that the current crop of exemplars are good for creating ODDs, but not so good for tackling various tasks. We don't have sample schemas that are good for encoding. For example: we don't show how to use constraints. SR observes that an exemplar constraining types might not be useful for individual needs. TEI Tite and TEI Lite, on the other hand, are intended to "be used"; LB concurs that whatever the original intentions behind Lite were, it is used as an "off the shelf" product. GB: we don't want example ODDs, we want example projects. [Unidentified] notes that the word

exemplar is ambiguous, especially for non-English speakers; can we find a better term? [Note from DS: this is correct, for English speakers as well. The

New Oxford Dictionary of English definition of exemplar is "a person or thing serving as a typical example or appropriate model". The latter sense is normative; the former is not.]

LB: this is what the TEI by Example project was supposed to provide. Unfortunately it's not doing that. It would be good to have set of examples of how people have solved things. JC agrees: "case studies". [Unidentified] says this is an issue of the scope of Council: instead of doing this ourselves, we should figure out how to liaise w/ other groups doing these activities. General agreement.

LR asks, what is status of ODD? Should we focus on improvements to ODD features? SB: yes, but we should defer this so we can address other issues first. SR agrees; this isn't a core business of Council in 2008; we should treat it as a parallel activity. LR objects that this ODD is in fact essential to outreach, as many TEI communities can contribute via ODD modules. The importance of ODD means it should be on our agenda (even if we don't make changes). GB concurs that it may be a mistake to segregate ODD activity; customizing TEI is a basic activity. Any outreach/education will connect with ODD.

SR: We don't want to send the message "here's the language to use, but we're going to change it". ODD is unusual because it is tied up with the software that implements it.

Other Outreach and Internationalization Goals

LR: Within Council, we should find a way to relate to external projects connected with TEI. We will integrate results of other groups; some of us will have duties to interact with specific ones. "I see more and more requests for short introductions on specific topics and offering examples." We could provide consultation on these matters. DO agrees: this has always been Council's duty. For example, current funding proposals before the National Endowment for the Humanities include two very TEI-centric projects.

LR: This is true of internationalization also.

Question: how do we identify the groups with which Council should interact? LR suggests this is part of Council's activity. DO asks whether we should issue invitations for groups who want Council involvement. JC notes that when someone comes to TEI-L an asks "can someone help me?" we need to provide a name. DO says this will become more and more important in funding projects.

LR concludes: we should systematize the responsibility of these "corresponding persons". This will be added to the Galway meeting agenda.

Global Organization of Council

Communication

The next discussion involved the TEI's communication platforms, specifically the TEI website and our mailing lists. LR notes a need for Council workgroups or people to oversee both. The Board has appointed a website workgroup that we can provide input to.

LB notes that service over the past year from Council email list has not been good; the server has been down too often. JC asks whether it wouldn't make sense to have all TEI email lists hosted on tei-c.org? SB raises a difficulty: the main list TEI-L is run on commercial software. No alternative software that he is aware of supports that level of service. Can we find open-source software? LB says that TEI-L is working fine and is not the issue. But perhaps the tei-council list should be moved. Level of service is more important than whether or not all the lists are in one place.

LR summarizes that we need to confirm ongoing support for the lists at Virginia, or explore the possibility of merging or moving list hosts. DS offers to confer with his Virginia colleagues on that status of the system hosting the lists. [He reported back that lists.village.virginia.edu, the host for the TEI Council and Board email lists, is indeed in the process of being merged with the new tei-c.org host, which will have 24/7 tech support; and the IATH system administrator is looking into adding full-text search on the tei-council list archive.]

Responsibilities

LR moves on to a discussion of general TEI Consortium responsibilities and Council's part in them. DO raises the issue of who "has the keys" to different things: who has responsibility, for example, for the SourceForge repository, for www.tei-c.org., etc? Should we survey who controls the different things we use? LR: Yes. if we know for example that U of Virgina has responsibility for the website, we need to have a single contact person. Likewise with Oxford's editorial support. DO: we don't have a single list of responsibilities. We should maybe put together before Galway meeting: SourceForge, mailing lists, website, Wiki... who has the passwords and oversight. SB agrees that such an inventory is important. LR asks that all "keyholders" please send a note to DS for inclusion in the minutes.

DS subsequently received the following information on keyholding responsibilities for TEI resources:

Highspeedconferencing account (used for conference calls)* Dan O'Donnell Mailing Lists (active)* @ Brown University: Syd Bauman default admin, plus others in

parentheses+ - TEI-L - TEI-MEET - TEI-MEMBERS (Veronika Lux) - TEI-MS-SIG (Elena Pierazzo) - TEI-MUSIC-SIG (Raffaele Viglianti, Gabriel Bodard, Dot Porter) - TEI-OL-SIG (David Durand) - TEI-SIGS (Susan Schreibman) - TEI-SOM (David Durand) @ Indiana University+ TEILIB-L (John Walsh) @ New York University+ tei-presentation (Matthew Zimmerman) @ Oxford: Lou Burnard and/or Sebastian Rahtz, admins+ - tei-chars - tei-extensions - tei-i18n - tei-iso-fs - tei-meta @ SourceForge (same admins as for SourceForge project, q.v.)+ - tei-choice - tei-ontology-sig @ University of Virginia, hosted at IATH (Daniel Pitti), list admin

David Sewell+ - tei-board - tei-council Membership Database* Veronica Lux. Syd Bauman has r/o access. Perforce repository (at OUCS)* Lou Burnard, chief administrator; others with r/w access are Syd Bauman,

James Cummings, Sebastian Rahtz. Servers* + www.tei-c.org.uk at Oxford, still used for Vault (Sebastian Rahtz and

Lou Burnard) + tei.oucs.ox.ac.uk, used for test Roma and Guidelines (Sebastian Rahtz)

— including Debian repository, administered by Sebastian Rahtz + www.tei-c.org at U of Virginia, main TEI server, administered by

Daniel Pitti SourceForge* Project admins are Syd Bauman, Lou Burnard, Sebastian Rahtz. As of these

minutes, there are a total of 14 developers (with rights to update source),

list viewable at

https://sourceforge.net/project/memberlist.php?group_id=106328 . TEI Live CD source* owned by Sebastian Rahtz TEI Website (on www.tei-c.org)* administered by Christine Ruotolo. Other people with read/write access to

the OpenCMS repository used for the website: Lou Burnard, Julia Flanders,

Sebastian Rahtz. System administration: Shayne Brandon (IATH), Amit Kumar (U

Indiana) TEI Wiki administrators* James Cummings (Council), Piotr Banski, Kevin Hawkins. The system

administrator in charge is Shayne Brandon of IATH at UVa.

Preparation for Galway Meeting

LR: Dates for the meeting are fixed, April 2-4. Organizer and contact person is Malte

Rehbein (malte.rehbein@nuigalway.ie). On Wednesday the 2nd there will be a symposium

organized by Malte, who has issued a Call for Papers. The Council meeting proper will

take place on the 3rd and 4th. We don't have a specific plan for Council members to

participate in the symposium, but it is expected that we will attend and contribute.

AC says that the organizers are focusing on presentations from the Irish TEI

community. They will see how many local presentations they have and will then ask

Council if they need supplementation. LR notes that we have a group hotel rate, so no

need to worry about lodging. We'll plan to start the Council meeting early on

Thursday, and to end by 4 p.m. Friday afternoon. DO will post to tei-council about

arrangements.

Information about Council funding of the meeting is on the TEI Wiki in the TEI Council FAQ.