[tei-council] Draft of 2008-02-07 conference call minutes
David Sewell
dsewell at virginia.edu
Wed Feb 13 11:33:52 EST 2008
All,
Here is a preliminary text version of the minutes, which I'll plug into
the XML template once it is final. Could everyone look it over and
provide me with any necessary corrections or additional info? In
particular:
* search for '??' to see queries, mostly involving email list ownership
* double-check attributions. I may not always have distinguished
properly between Lou and Gabriel's voice (and possibly Sebastian once or
twice), or between Paul and Dan. To give me better distinction in
regional accents, I no doubt should have asked for ground rules at the
start, e.g. "Lou, can we have you use a broad Scots dialect on this
call, and Dan, could you emphasise the Canadian by doing either Bob and
Doug McKenzie or Jean Chrétien, your choice?"
David
==============
MINUTES OF TEI COUNCIL CONFERENCE CALL, 7 FEBRUARY 2008
Called to order 1300 UTC
Participants:
Gabriel Bodard (GB), Peter Boot (PB), Arianna Ciula (AC), James Cummings
(JC), Syd Bauman (SB), Lou Burnard (LB), Dan O'Donnell (DO), Sebastian
Rahtz (SR), David Sewell (DS; minutes), and Laurent Romary (LR; Chair).
Unable to participate:
Tone Bruvik, Elena Pierazzo, Manfred Thaller, and John Walsh.
1. Scope of Council Activities
1.1 Technical Activities
1.1.1 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 "stable/unstable" distinction? It's helpful for people to
test releases.
GB: there is a fixed date in TEI timetable, the November meeting. Shall we say
there will always be a pre-release of next major release before Nov?
JC asks about 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
language 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 a formulation?
Releases every 6 months; a pre-release 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).
1.1.2 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
Member's Meeting, we discussed the dropping of Guideline "editors", with
work on them organized by Council, but I strongly recommend we provide
editorial support. We should make sure that Oxford has stable editorial
support. DO: the decision 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 Bylaws mandate, 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 2 places and having bug reports sent to specified
venues. Members disagree over whether that venue should be SourceForge,
LB arguing yes, SB and AC saying no. 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.
1.2 Outreach, Education
1.2.1 ODD
LR begins by suggesting that "exemplars" and "ODD" are key word 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. Peter Boot notes word
"exemplar" is ambiguous, especially for non-English speakers; can we
find a better term? [Note from DS: Peter is right, and this is true in
English 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".
PB 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.
1.2.2. 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.
3. Global organization of Council
3.1 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.]
3.2 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.
3.2.1 "Keyholders"
DS received the following information on keyholding responsibilities for
TEI resources:
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 Board, Dot Porter)
TEI-OL-SIG (David Durand)
TEI-SIGS (Susan Schreibman)
TEI-SOM (David Durand)
@ Indiana University
TEILIB-L [who is admin??]
@ New York University
tei-presentation [who is admin??]
@ Oxford [who is admin??]
tei-chars
tei-extensions
tei-i18n
tei-iso-fs
tei-meta
@ SourceForge [same admins as SourceForge repository??]
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 (+ others??). 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,
Sebastian Rahtz(??).
TEI Wiki administrators:
James Cummings (Council), Piotr Banski, Kevin Hawkins, Sebastian
Rahtz. The system administrator in charge is Shayne Brandon of IATH
at UVa.
4. Preparation for Galway meeting
LR: Dates for the meeting are fixed, April 2-4. On Wednesday the 2nd
there will be a symposium organized by Malte Rehbein, 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. Susan Schreibman is the contact person/organizer. 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:
http://www.tei-c.org/wiki/index.php/TEI-Council-FAQ#What_funding_is_available_for_Council_Activities.3F
--
David Sewell, Editorial and Technical Manager
ROTUNDA, The University of Virginia Press
PO Box 801079, Charlottesville, VA 22904-4318 USA
Courier: 310 Old Ivy Way, Suite 302, Charlottesville VA 22903
Email: dsewell at virginia.edu Tel: +1 434 924 9973
Web: http://rotunda.upress.virginia.edu/
More information about the tei-council
mailing list