[tei-council] Draft of 2008-02-07 conference call minutes

Dan O'Donnell daniel.odonnell at uleth.ca
Wed Feb 13 17:08:08 EST 2008


Yeah. I've been wondering who this Paul might be who sounds like me:
perhaps my middle name? We're always getting confused ;)


On Wed, 2008-02-13 at 16:35 -0500, John A. Walsh wrote:
> And I was a participant.  Maybe David had me confused with Peter,  
> although our accents are quite different. :-)
> 
> John
> --
> | John A. Walsh
> | Assistant Professor, School of Library and Information Science
> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405
> | www: <http://www.slis.indiana.edu/faculty/jawalsh/>
> | Voice:812-856-0707 Fax:812-856-2062 <mailto:jawalsh at indiana.edu>
> 
> 
> 
> On Feb 13, 2008, at 3:26 PM, Peter Boot wrote:
> 
> > I'm surprised at finding my name among the participants, as (as I
> > announced) I couldn't take part in the conference call!
> >
> > Peter
> >
> > David Sewell schreef:
> >> 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
> >>
> >>
> >>
> >> ------------------------------------------------------------------------
> >>
> >> _______________________________________________
> >> tei-council mailing list
> >> tei-council at lists.village.Virginia.EDU
> >> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> >
> > _______________________________________________
> > tei-council mailing list
> > tei-council at lists.village.Virginia.EDU
> > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> 
> _______________________________________________
> 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
Associate Professor and Chair, Department of English
Director, Digital Medievalist Project http://www.digitalmedievalist.org/
Chair and CEO, Text Encoding Initiative http://www.tei-c.org/
University of Lethbridge
Lethbridge AB T1K 3M4
Canada
Vox: +1 403 329-2378
Fax: +1 403 382-7191



More information about the tei-council mailing list