[tei-council] Draft of 2008-02-07 conference call minutes
Daniel O'Donnell
daniel.odonnell at uleth.ca
Wed Feb 13 11:50:48 EST 2008
Looks good to me. I think it is an accurate reflection of the general
thrust of the discussion: there were one or two places where I thought
"is that really what x said?" but I think we wouldn't be able to get
more accurate without a meta-meeting and the conclusions are, as far as
I'm aware, all accurate.
I saw a couple of dittographies of a couple of words but now I can't
find them.
The question-marked attributions to me are all things I'm willing to
have said ;)
-dan
On Wed, 2008-02-13 at 11:33 -0500, David Sewell wrote:
> 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/
> _______________________________________________ tei-council mailing list tei-council at lists.village.Virginia.EDU http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
--
Daniel Paul O'Donnell, PhD
Department Chair and Associate Professor of English
Director, Digital Medievalist Project http://www.digitalmedievalist.org/
Chair, Text Encoding Initiative http://www.tei-c.org/
Department of English
University of Lethbridge
Lethbridge AB T1K 3M4
Vox +1 403 329-2377
Fax +1 403 382-7191
Email: daniel.odonnell at uleth.ca
WWW: http://people.uleth.ca/~daniel.odonnell/
More information about the tei-council
mailing list