TEI Technical Council Fall F2F, 2017-11-16/18 Parkside Hotel, Victoria, BC

Discussion topics (numbered)

  1. Stylesheets Issues, Stylesheets Issues, Stylesheets Issues
  2. OxGarage
  3. Roma(+JS)
  4. Spring F2F
  5. TEI/Stylesheets Issues that need extended discussions
    1. @mode in ODD see https://github.com/TEIC/Stylesheets/issues/272
  6. Chapter 11 tickets (see http://www.tei-c.org/release/doc/tei-p5-doc/en/html/PH.html)
  7. LingSIG tickets (PS to prepare those)
  8. Docker proposal
  9. Council communication channels: use more Slack (but can we make our Slack open for others to read?)
  10. Should SG still cover RELAX NG? (would be good to have LB’s input)
  11. New Saxon & oXygen plug-in. Breakout Group (MH, SB, JC)
  12. Elections stuff
  13. Processing Model extensions Saturday morning
  14. MT: Publication SIG proposal
  15. JC suggests that 1 day of all TEI Council Face to Face meetings be open to any TEI member. i.e. they should be allowed to attend, contribute thoughts/ideas but not have voting rights if something is voted on.
  16. Periodicals SIG proposal

F2F Agenda

Nov. 16

Morning

Started @ ~09:15.

#15: opening Council meetings or parts of them

JC derails the agenda of the meeting for the first 20 minutes by suggesting an ‘easy’ topic to council members and thus the meeting descends into 20 minutes of chaos and destruction. (Praise Cthulhu!) He does this by suggesting that he wants to open up council business so people can see what goes on by possibly having it be tradition that one day or morning/afternoon of council meetings is open to any TEI member. Broad brainstorming on the role of the council and its practices re openness, transparency, bringing kind of expertise required on the Council (or for the maintenance of TEI) out to the world.

JC: in favor of this because this opens up what the Council does, it’s a way to bring in new people by showing what we do. EB-this is a way of cultivating wisdom in the community - special kind of event - for ex. A workshop SB: likes idea, but wants decision to be part of meeting planning. EM: Bring council work to the fore during the Members’ meeting. Schedule conference sessions where we present discussions about important issues: to clarify the way Council deliberates. MH: Workshop: Council could select 2 or 3 tickets. Go through process of cloning the repo, work on solving the tickets and generating a pull request during the meeting, perhaps. JC: problem of perception of "high priesthood" working in exclusion RV: we need time to work, and opening Council session to community loses time we need.Have some community-facing workshop or session associated with any F2F meeting. [ACTION] on HC: will raise this with the board.

Summary:

  1. General agreement with JC’s proposal that we try to open part of the Council meeting — not hard policy, but by tradition & custom rather than by requirement.
  2. Program committee reserves panel slot for the Council to discuss real issues for discussion and present them to the membership, discuss motivation, problems, possible solutions, constraints - needs to be discussed with the conference committee
  3. Workshop: Council member(s) could propose issues for discussion & deliberation to provide a guided introduction to Council work.

MT: Are we having problems with any below, if so, to what extent and what are possible actions to take Transparency:

#12: elections stuff

Council member rotation:

Community participation

Transmission of knowledge essential to TEI maintenance & development

#14 - Publications SIG:

MT with Julia Flanders and Gimena del Rio Riande: to discuss publication options for bringing TEI ODD Processing Model to TAPAS. MH: interested in join as long as it's not focused only on the processing model. JC: Concentration should be on publication technologies. Magda urged to write proposal and submit. We all think it’s a great idea. JC warns that name is ambiguous--rethink it. (i.e. it isn’t about ‘publications’ like journals, or the publishing industry, it is about publishing tei.

#16 Council also says yes, approving Periodicals SIG proposal.

Related: Does there need to be a Council Liaison for this and other SIGs?

Discussion: Council should make sure new SIG leaders actively reaches out to periodicals TEI projects not represented at meeting(s). EM points out the organizers should be encouraged to reach out to existing projects doing newspapers with TEI. JC: Notes that really the Chair of Council already liaises with the SIGs. PS suggests to actively approach people/groups who are preparing some larger proposals (to the Guidelines) and name some Liaison from Council EB: should SIG appoint liaison to communicate to Council (instead of other way around)? Discussion: that's really the job of the SIG convener. "Anything you would like me to bring up at the Council meeting." Council liaising is difficult to maintain...(What are the logistics?) EB: asks about slack channel agenda item, whether this is related. SB protests that managing SIGs is not Council's role. PS: We shouldn't wait for SIGs to approach us, but actively communicate with SIGs. HC: Do we need a special label for tickets to be brought to SIG attention? PS: Council members could check in with inactive issues AND SIGs JC: Plenty of SIGs don't always propose tickets, and we don't necessarily need them to stir up new tickets all the time. They are often birds-of-a-feather with similar interests. Not all SIGs' raison d’etre is to propose tickets and improve the Guidelines. SIGs like that are perfectly fine also. HC: Council members could open special tickets could be points of contact for connecting with people/ encouraging people with nascent proposals for Council to act on. Translate concepts to actionable tickets. What to do about gigantic messy discussions on tickets? Maybe we need better/stable/sustainable places to flesh out ideas.

Website right now is in no condition to help. Site migration is a serious problem right now. Resolution: we don't really need SIG liaisons. SIGs are centers of activity, but not the only ones, emerging from TEI community. Council members just need to be aware of what's going on and open tickets accordingly. Suggestion that we have standing SIG “what’s up with the SIGS” agenda item. Keep an eye on good mechanisms for communication!

#1: Battleplan for Stylesheets!!!!

Need to

RV: What major issues with current architecture? HC: They are ingenious and impenetrable: takes a long time to figure out what has to be fixed and where? If we had "smaller bits that did smaller things" that might be easier. RV: Maybe we don't need keys any more JC: remove stuff that's legacy of XSL 1 MH: When they worked on JTEI, they broke free of Stylesheets architecture, to Sebastian's concern--but it was just too difficult to work in that framework. Markdown <--> TEI different from DocX . Need to understand the differences. SB: Worth remembering that converting to DocX isn't really Council's responsibility. MT: Can we use ODD proc model to produce the Guidelines? JC: That was Sebastian's intention. RV: We'd need to be able to do this outside of eXist SB: "Rub-a-dub-dub project": clean up stylesheets for consistent variable names, consistent location of function definitions. Perhaps prioritize that and look at the results--is it easier to maintain a cleaned up version. JC: Due date? MT: Clean up, or better direction to do a rewrite? SB: Perhaps rewrite only the bits we need. EB: One goal of "rub-a-dub-dub" was to understand the code and its interdependencies better, identify the outdated parts. PS: Hard to tell what's Council's responsibility or not here: People rely on these transformations. JC: ISO paid TEI to produce a seamless transformation to/from DocX. MH: Not clear whose responsibility that was to maintain, but lots of people use. MH: We need to start with odd2odds.xsl RV: try rewriting odd2odds from scratch--considering the probs we've had with modes, etc. TEI Website parts that aren't Guidelines--about to be handled by Wordpress? Summary: MH and RV want rewrite. SB wants clean-up first--could be more efficient.; Functions need documentation of input, output, expected behavior. JC: Lots of this is provided by the auto-generated documentation. Consistent code format would help improve this. Formatting, variable naming, key naming. SB could work alone, but EB maintains there ought to be lots of us watching and checking and making sure the documentation is clear. JC: Otherwise we create conditions for a new Sebastian. **Council suggestion is: [ACTION] on SB:**Syd works on cleaning and documenting odd2odd.xsl stylesheets reports back in January. Works with frequent pull requests so there is code review. This is a test case to see what the scope of this work is. If he can do this in a reasonable time, it’s a good sign, others can start to work as well on other stylesheets. Also, Syd might report back on some workflows.

Afternoon

12:00–13:00: talk with Christian-Emil Ore about Ontology issues: 327, 1655, 367, …? We (TEI) are missing elements to describe physical objects and abstract objects. <msDesc> does this for manuscripts. So one method is to see if these elements can be generalized. Thus clean up TEI a bit w/ respect to ontological categories. Another method would be try to make a hierarchy of some TEI elements.

Lunch: MH and SB suggest the Old Spaghetti Factory. The Ghost of Lou revulses in horror. RV refuses to return to this monstrosity after council visited it in this instance. MT gathers data on elections in 2002-2017 period and gives some tentative answers:

Day 1 Groups and Stylesheets tickets:

Nov. 17

Morning

The council sang Happy Birthday to its chair, HC.

Discussion

#4: Spring face to face meeting discussion

#2: Oxgarage:

#9: Slack

#11: Oxygen

#6: Chap. 11

#8: PS: Docker proposal

[ACTION] on PS: Peter will build the various docker containers. Various people can host. Day 2 Groups:

Group A: (JC, MH, MS, SB)

Group B: (EB, SS, EM, PS)

Group C: (RV, HC, MT)

(Got to here by 16:21)

Afternoon

Group A: (JC, MH, MS, SB)

Group B: (EB, SS, EM, PS)

===Group stopped here===

Group C: (RV, HC, MT)

Nov. 18

Morning

Resume yesterday's issues.

@mode in ODD elementSpec

Backing up TEI repos

Next release date and personnel

#13: Processing Model extensions / behaviourSpec

#3: Roma report

RV runs through roadmap. Touches on areas where he needs help (OxGarage, design). Continue to organize regular meetings explaining what he’s been doing. Useful for RV to stay on track. RomaJS report from the members meeting

Telecon dates/times

#11: oXygen Plugin (again)

Amber tickets we didn't cover:

Unlabeled Issues

Ticket and Pull Request Triage on TEI and Stylesheets Repos

December JC
January EM
February SB
March RV
April SS
May MS
June HC
July EB

Afternoon

We'll have the room all day. Several of us will be departing in the afternoon, so general business should stop by 2–2:30, but those who are staying can keep working on tickets if they want.

#7: LingSig discussion

Ling Sig trying to bring linguists back into the TEI fold. Motivates the issues they are submitting. Have clone repo of their own and are sending pull requests to TEI Examining #1670 - very detailed. General feeling in the room was that:

**NOTE:**We decided to use the combination of “Go” and “Needs discussion” labels to indicate that the assignee is cleared to do more work on an issue, we expect it to move forward, but we expect more discussion before it is a “Go” to put into the Guidelines. Ended ~16:37

Who is leaving when?

HC has a 4:45pm flight JC (Flight AC 8080), EM and EB have 8:40pm flight taxi at 6ish from Marriott SB leaves Sun 11-19 10:00 (from harbor)