[tei-council] Draft of 2008-02-07 conference call minutes
Laurent Romary
laurent.romary at loria.fr
Thu Feb 14 02:59:06 EST 2008
Agree. I will prepare a short outline for the Board, and reading the
minutes allows me to recall precisely what I had understood in the
discussion.
I am not sure what a dittography is, but I guess "are key words are
key words" is one...
Laurent
Le 13 févr. 08 à 17:50, Daniel O'Donnell a écrit :
>
> 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/
>
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
More information about the tei-council
mailing list