- Tei-council - lists.tei-c.org

Stylesheets coop meeting
by Scholger, Martina (martina.scholger＠uni-graz.at) 06 Jul '20

06 Jul '20

Dear all, I've set up a zoom meeting for our cooperative Stylesheets meeting tomorrow at 6:00 PDT / 9:00 EDT / 14:00 BST / 15:00 CEST: https://us02web.zoom.us/j/83142838842?pwd=NUFSS05UNXVEWnlTQkpzUDBmVDdndz09 Best, Martina

1 0

ack! bad Syd, bad!
by Syd Bauman 04 Jul '20

04 Jul '20

I just went to see from whom I am taking over as ticket triage person only to find that I screwed up, I was the ticket triage person for June, not July. Elisa -- you are the ticket triage person for July. I plan to make a run through the tickets tomorrow, and will hand the baton over to you shortly thereafter, OK? Sorry, y'all.

3 4

Git branch naming
by Hugh Cayless 03 Jul '20

03 Jul '20

Hi All, Some of you may have come across the recent move toward changing the default branch name in Git away from "master" to (probably) "main". My understanding is that GitHub is working on this, and that it will probably happen in Git as well. I'm aware of a number of projects that are moving ahead immediately on renaming their master branches. On the one hand, I'm generally in favor of this. The "master" terminology probably came from BitKeeper, which had "master" and "slave" repositories (rather than branches). I had always assumed it was meant in the sense of "master copy", like in sound recordings. But see also https://twitter.com/xpasky/status/1271477451756056577 from the person responsible for the name (not a native English speaker). On the other hand, I'm slightly cynical about this sort of thing, as it's the kind of change one can make and feel righteous about without being *actually* significantly anti-racist. It's a bit performative, but sometimes it's important to set an example. So I think we should consider going through the renaming process for TEI repos. There are probably some implications to doing that, broken links being the first one that comes to mind. What do you all think? Hugh

10 20

Re: [Tei-council] WG: A new tool for the TEI!
by Raffaele Viglianti 30 Jun '20

30 Jun '20

Didn't hit reply all. See below On Tue, Jun 30, 2020, 12:12 PM Raffaele Viglianti < raffaeleviglianti(a)gmail.com> wrote: > Hi Martina, > > Overall, it seems pretty fast to me, and I like how it's simple to create > a TEI file from a template and that elements and attributes are suggested > as you type. > Here are a few comments from testing on Ubuntu 18.04.4 LTS. > > These things should be there to make it truly useful in a teaching context: > - validation doesn't seem to trigger automatically, one needs to click > "Parse Buffer" to initiate it. This isn't bad per se, but it took me too > long to figure it out. I would recommend making the button more visible > (icon?) and call it something more descriptive (e.g. "Parse and Validate") > - show <a:documentation> values from the RNG when scrolling through > possible elements and attributes. This is the easiest way to know whether > an element is appropriate or not; I rely on it as a training device > - attribute values from closed or semi lists should be shown and documented > > Desiderata (besides the ones already mentioned by them): > - I'm not a jEdit user, but when the plugin is activated, all its > components appear in tiny floating windows that need to be docked. It's a > one-off operation, but frustrating, and I suspect younger students will not > be familiar with this kind of UI. It's possible that nothing can be done > about this, unless jEdit's API allows for a plugin to start "docked". > - it would be great to have a wrap element button or shortcut (Oygen's > Ctrl+e) > > Best, > Raff > > On Mon, Jun 29, 2020 at 8:12 AM Scholger, Martina ( > martina.scholger(a)uni-graz.at) <martina.scholger(a)uni-graz.at> wrote: > >> Dear Council, >> >> >> >> Marjorie Burghart and Conal Tuohy have released their TEI plugin for the >> open source editor in jEdit. They would like to invite us for testing the >> tool and sending them feedback. >> >> Please see Marjorie’s email with all the details below. >> >> >> >> Best, >> >> Martina >> >> >> >> *Von:* Marjorie Burghart <marjorie.burghart(a)gmail.com> >> *Gesendet:* Montag, 22. Juni 2020 16:51 >> *An:* Scholger, Martina (martina.scholger(a)uni-graz.at) < >> martina.scholger(a)uni-graz.at>; James Cummings < >> James.Cummings(a)newcastle.ac.uk>; louburnard <lou.burnard(a)gmail.com> >> *Cc:* Conal Tuohy <conal.tuohy(a)gmail.com> >> *Betreff:* A new tool for the TEI! >> >> >> >> Dear Martina, Lou, Hugh and James, >> >> >> >> Conal and I are very pleased to let you know that a TEI plugin for the >> open source editor jEdit has been officially released: >> >> >> >> http://plugins.jedit.org/plugins/?TEI >> >> The plugin is slowly propagating through the mirrors of jEdit's Plugin >> Central, if you don't see it there yet it should appear shortly. >> >> >> >> Before making an official announcement, we would appreciate getting >> feedback from "power users" of the TEI :) We thought of you (and through >> Martina, of all Council members). If you have the time to give it a try, we >> would very much appreciate your feedback on potential bugs, ergonomy >> issues, etc. Conal thinks those first bugs could be fixed in a new release >> in a couple of weeks. >> >> >> >> Conal is hosting the source code on his github, where you could report >> issues: >> >> https://github.com/Conal-Tuohy/jEdit-TEIPlugin/issues >> >> and he has created a wiki page: >> >> https://github.com/Conal-Tuohy/jEdit-TEIPlugin/wiki >> >> >> >> How to proceed: >> >> - Install the latest version of jEdit http://www.jedit.org/ >> >> - Through the plugin manager (Plugins > Plugin Manager...), search the >> "TEI" plugin and install it with all its dependencies >> >> NOTA BENE: if you already had jEdit with the XML plugin installed, you >> will also need to update the XML plugin to the latest version. >> >> >> >> What it does: well, not everything :) The aim is NOT to replace Oxygen >> entirely, but to offer the community a viable free alternative, especially >> for teaching workshops and users with basic needs. We tried to cover the >> needs listed here (basic, and even some some deemed superfluous) : >> >> https://wiki.tei-c.org/index.php?title=Editor_for_teaching_TEI_-_features >> >> >> Conal is currently working on two other improvements: >> >> - schematron support >> >> - a mechanism akin to Oxygen's validation scenarios. >> >> >> >> The plugin has been developed by Conal, and the first steps in its >> development funded by a small grant I obtained from DARIAH - but Conal has >> done much more work "pro bono", and is kindly continuing development to >> enhance the features. If the community sees some use in this first step, I >> am planning to do my best to get further developments funded. >> >> >> >> Best wishes, >> >> Marjorie >> >> >> >> >> _______________________________________________ >> Tei-council mailing list >> Tei-council(a)lists.tei-c.org >> http://lists.lists.tei-c.org/mailman/listinfo/tei-council >> >

1 0

TCW30
by Scholger, Martina (martina.scholger＠uni-graz.at) 30 Jun '20

30 Jun '20

Dear Council, I've published the "Workload and Guidelines for Resignation" as TCW30: http://teic.github.io/TCW/tcw30.html Best, Martina

2 1

WG: A new tool for the TEI!
by Scholger, Martina (martina.scholger＠uni-graz.at) 29 Jun '20

29 Jun '20

Dear Council, Marjorie Burghart and Conal Tuohy have released their TEI plugin for the open source editor in jEdit. They would like to invite us for testing the tool and sending them feedback. Please see Marjorie’s email with all the details below. Best, Martina Von: Marjorie Burghart <marjorie.burghart(a)gmail.com> Gesendet: Montag, 22. Juni 2020 16:51 An: Scholger, Martina (martina.scholger(a)uni-graz.at) <martina.scholger(a)uni-graz.at>; James Cummings <James.Cummings(a)newcastle.ac.uk>; louburnard <lou.burnard(a)gmail.com> Cc: Conal Tuohy <conal.tuohy(a)gmail.com> Betreff: A new tool for the TEI! Dear Martina, Lou, Hugh and James, Conal and I are very pleased to let you know that a TEI plugin for the open source editor jEdit has been officially released: http://plugins.jedit.org/plugins/?TEI The plugin is slowly propagating through the mirrors of jEdit's Plugin Central, if you don't see it there yet it should appear shortly. Before making an official announcement, we would appreciate getting feedback from "power users" of the TEI :) We thought of you (and through Martina, of all Council members). If you have the time to give it a try, we would very much appreciate your feedback on potential bugs, ergonomy issues, etc. Conal thinks those first bugs could be fixed in a new release in a couple of weeks. Conal is hosting the source code on his github, where you could report issues: https://github.com/Conal-Tuohy/jEdit-TEIPlugin/issues and he has created a wiki page: https://github.com/Conal-Tuohy/jEdit-TEIPlugin/wiki How to proceed: - Install the latest version of jEdit http://www.jedit.org/ - Through the plugin manager (Plugins > Plugin Manager...), search the "TEI" plugin and install it with all its dependencies NOTA BENE: if you already had jEdit with the XML plugin installed, you will also need to update the XML plugin to the latest version. What it does: well, not everything :) The aim is NOT to replace Oxygen entirely, but to offer the community a viable free alternative, especially for teaching workshops and users with basic needs. We tried to cover the needs listed here (basic, and even some some deemed superfluous) : https://wiki.tei-c.org/index.php?title=Editor_for_teaching_TEI_-_features Conal is currently working on two other improvements: - schematron support - a mechanism akin to Oxygen's validation scenarios. The plugin has been developed by Conal, and the first steps in its development funded by a small grant I obtained from DARIAH - but Conal has done much more work "pro bono", and is kindly continuing development to enhance the features. If the community sees some use in this first step, I am planning to do my best to get further developments funded. Best wishes, Marjorie

1 0

circular build headache suggestion
by Syd Bauman 16 Jun '20

16 Jun '20

The circularity of the P5 and Stylesheets builds depending on each other has bitten us once again. (Ouch!) We have a situation now where the Stylesheets tests can succeed only against either the release branch of P5 or the dev branch of P5, but not both simultaneously. This sucks. Right now Stylesheets dev branch is successfully building against P5 release[1], but failing against P5 dev branch[2]. We believe that the reverse would make a lot more sense. While it is desirable that it build against both branches, it is frequently impossible. So we have to pick one, and we (Martin & Syd) think we should pick them as follows: * P5 release branch should be built with the P5 release Stylesheets * P5 dev branch should be built with the P5 dev Stylesheets * Stylesheets release should be built against P5 release branch * Stylesheets dev should be built against P5 release dev as a general rule. This means we would have to always release a new Stylesheets the same day we release P5 every time. It also means that if we ever had a reason we needed to do an interim release of either, we would have to fight with the circularity problem (probably by trying to make sure both branches work against each other, or temporarily suppressing some finicky tests). But the advantage is that "normal" releases and updates would work properly. So what we would like to do is: * Update Stylesheets deb branch tests so that they work against P5 deb (which will break them against P5 release branch) * Have Peter & Martin agree on a consistent set of explicit job names in Jenkins that perform the 4 builds listed above. Notes ----- [1] E.g. on jenkins.tei-c job "Stylesheets-dev" and jenkins2.tei-c job "Stylesheets-dev-against-P5-release". [2] E.g. on jenkins.tei-c job "Stylesheets-dev-against-TEIP5-dev" and jenkins2.tei-c job "Stylesheets-dev-against-TEIP5-dev".

3 8

off topic: new ODD based non-TEI schema
by Peter Stadler 16 Jun '20

16 Jun '20

Dear all, here I want to bring to your attention a project of a colleague called "Music Performance Markup" (MPM): https://axelberndt.github.io/MPM/ I want to share this with you because it’s a great example of an ODD based non-TEI schema, and it features a nice rendering of the documentation. If we ever wanted to redesign our Spec pages, this might give us some ideas :) Have fun Peter

1 0

Another thought on <annotation>
by Hugh Cayless 12 Jun '20

12 Jun '20

Had a bit of a brainstorm this morning, and I came up with another idea re representing WADM annotations. See #9 at https://docs.google.com/document/d/15lPVs89ehDNpQQ3Qf79kfRAECSN-MT_SpBlQpHU…. I'd be grateful for your opinions. Hugh

1 0

Progress on labeling tickets
by Martin Holmes 11 Jun '20

11 Jun '20

Hi all, Today Elisa and I added all the labels we think appropriate for all tickets starting at the oldest and running up to #319. That seems to be half of the tickets, so we think our work is done. A few tickets got closed in the process. Cheers, Martin -- ------------------------------------- Humanities Computing and Media Centre University of Victoria mholmes(a)uvic.ca

1 0

housekeeping: delete stale branches
by Peter Stadler 10 Jun '20

10 Jun '20

Dear all, here’s yet another(?) proposal for housekeeping: Both Stylesheets and Guidelines repo feature various stale branches which I would like to get rid off [1,2]. Some of those are prefixed with a Councilists name so I encourage everyone to look through his/her branches and eventually delete outdated/unused/forgotten branches. Some of the stale branches are even just behind dev without featuring any commits *ahead* of dev (e.g. the TEI/help branch). I think those can safely be removed and would do so in the next days if no one objects. This does include release branches which I’d also like to get rid of because IMHO they do not serve any purpose anymore (the important information is kept in the tags). Best Peter [1] https://github.com/TEIC/Stylesheets/branches/stale [2] https://github.com/TEIC/TEI/branches/stale [3] https://github.com/TEIC/TEI/tree/help

3 3

call in 10 minutes
by Scholger, Martina (martina.scholger＠uni-graz.at) 09 Jun '20

09 Jun '20

Dear all, Our call starts in 10 minutes: https://docs.google.com/document/d/1MK5fPZS0sHMJ1HMumwU6YpqH6JKgMRhB72lv38w… Best, Martina

1 0

Reminder: Council meeting tomorrow
by Scholger, Martina (martina.scholger＠uni-graz.at) 08 Jun '20

08 Jun '20

Dear all, This is a reminder that our next Council meeting is tomorrow, June 9 at EST 09:00-10:30, GMT 14:00-15:30, CEST 15:00-16:30 Please find the agenda here and add topics that we should discuss https://docs.google.com/document/d/1MK5fPZS0sHMJ1HMumwU6YpqH6JKgMRhB72lv38w…<https://docs.google.com/document/d/1MK5fPZS0sHMJ1HMumwU6YpqH6JKgMRhB72lv38w…> You can find the zoom link for the meeting in the google doc. Best, Martina

1 0

Next Council meeting: Tuesday, June 9
by Scholger, Martina (martina.scholger＠uni-graz.at) 05 Jun '20

05 Jun '20

Dear all, Our next Council meeting is on Tuesday, June 9 at EST 09:00-10:30, GMT 14:00-15:30, CEST 15:00-16:30 Please find the agenda here and add topics that we should discuss https://docs.google.com/document/d/1MK5fPZS0sHMJ1HMumwU6YpqH6JKgMRhB72lv38w… You can find the zoom link for the meeting in the google doc. Best, Martina

1 0

P5/Utilities-1 and P5/Utilities
by Peter Stadler 04 Jun '20

04 Jun '20

Dear all, while working on some old TEI->LaTeX->PDF issues I stumbled (once again) across those two folders P5/Utilities-1 and P5/Utilities in the Guidelines repo. Can somebody shed some light on the difference of these folders? I’m especially interested in the file guidelines-latex.xsl which exists in both directories but only the one in Utilities seems to be used for building the PDF version of the Guidelines? Many thanks Peter

2 2

Noto fonts
by Peter Stadler 03 Jun '20

03 Jun '20

Hi Martin, I'm about to push some changes to the TEI repo that will set the Google Noto fonts as default for the PDF Guidelines (processed via LaTeX). That requires the fonts-noto-cjk package (on Debian) in the respective build environment. It is already included in our Jenkins Docker image but you might need to add that manually to your Jenkins? Just wanted to give you a warning (shortly) ahead of time ;) Best Peter

2 1

plan for Stylesheets, and versions, and tags, oh my!
by Syd Bauman 03 Jun '20

03 Jun '20

At one point we had a Stylesheets meeting planned for this Tue 02 Jun at 13:00Z. Various other plans have cropped up since. Basically, Elisa, Martin, Peter, and I have not finished the Stylesheets categorization project; although we have made good progress, we still have more to go, and would like to use that time slot. Furthermore, Peter has suggested (and I readily agree) that we, Council, need to talk about teidata.version. Thus my suggestion is 1. a 1-hour meeting at 13:00Z with as many Council members as will show up to discuss version numbering and (time permitting) Stylesheets 2. a 1-hour meeting at 14:00Z of PS & SB and MH & EB to do more Stylesheets labeling. I, for one, have another meeting at 15:00Z which I do not want to be late for.

10 11

Do we need better issues?
by Raffaele Viglianti 29 May '20

29 May '20

Hi all, After today's meeting, I started thinking about why we often end up in loops of discussion. Keeping in mind that this is a partial and personal view, I think that this happens for a few reasons: some are good (e.g. disagreement that needs to be worked out), some are ok (e.g. someone forms an opinion while missing a key piece of context --mea culpa), others are due to the ticket (e.g. it's verbose, it's unclear, it's too short, the discussion is long, etc.) To address the latter, I think we need to ask more of our submitters (including ourselves when creating issues). Each issue should state clearly what the problem is, show clear examples, and offer a solution. Many issues do (I think of the UVic ones are particularly exemplary, however extreme their requests may often appear to me :) ), but the style varies too much and it makes it time consuming for us to figure out what the real issue is and to reprise quickly on second iterations. I wonder if a strict issue template may help us here. GitHub allows to configure multiple templates <https://help.github.com/en/github/building-a-strong-community/using-templat…> (e.g. a bug report template could be default, with the possibility to switch to a feature request one, and perhaps others). Templates pre-populate an issue with headers and a description of what's required for consideration, thus at least encouraging a standardized way of formulating a bug report/feature request. Even if these templates were fairly simple we would still benefit. But I think we could go further and take inspiration from software design documents as a template, which will require the issue reporters to not just do their research, but present it properly too. The DocNow project at MITH creates such documents (publicly) to help discussion within the dev group, and as a crucial means to remind ourselves of why we set to do something (because we all work on dozens of projects and forget things). Here is a very good example <https://www.docnow.io/design/2019-05-21-conversation>. I think forcing this on submitters will weed out partially thought out requests, which will always result in us at least wasting time at best closing or getting back to the submitter, at worst engage in loopy "what if" discussions. We have plenty of issues, so I'm not worried about scaring people away. In fact, i wonder if more structure may even encourage less proficient users to contribute more meaningfully. Templates will also give us -- hopefully -- clearer requests with a proposal for a solution built-in. What do you think? Finally, if we did choose to use this GitHub feature, we should also look at their recommendations for adding a code of conduct <https://help.github.com/en/github/building-a-strong-community/adding-a-code…>. TEI's is hidden deep in the tei-c site <https://tei-c.org/about/code-of-conduct/> but we may want to bring it into the repository and close to the issue submitting process. Thanks for indulging me and I'm well prepared to be told that this in an unnecessary complication and that we should proceed as usual :) Best, Raff

6 6

labels for Stylesheets issues
by Syd Bauman 25 May '20

25 May '20

Martin and I came up with a proposed list of labels for Stylesheets issues today. My suggested schedule is that over the next week we review and tweak the list as needed. Then on or about Sun 17 May someone who has some color sense will go ahead and actually change the label values in GitHub. Then during the week of the 18th, flowing over to the week of the 25th as needed, the subgroups (SB, PS, MH, EB|MS) work on categorizing the 139 open issues with the new labels. The list proposed is not intended to be definitive. I expect it to be adjusted both now by Council, and then during the actual cataloging exercise. So take a loot at https://docs.google.com/spreadsheets/d/1TugARD1amG-ZeMPl2Fo-e88VXqirHawmOs5… and comment away.

6 15

meeting in 30 minutes
by Scholger, Martina (martina.scholger＠uni-graz.at) 19 May '20

19 May '20

Dear all, Our meeting starts in 30 minutes. Please find the zoom meeting link in the google doc: https://docs.google.com/document/d/1tIA1pWABSJlL9KfCwK6t6zwVXm762LNAbvs45YU… Best, Martina -----Ursprüngliche Nachricht----- Von: Scholger, Martina (martina.scholger(a)uni-graz.at) <martina.scholger(a)uni-graz.at> Gesendet: Samstag, 16. Mai 2020 21:16 An: tei-council <tei-council(a)lists.tei-c.org> Betreff: Meeting on Tuesday Dear all, In our last meeting we agreed to continue one more time with reviewing issues from the VF2F on Tuesday, May 19 at 9:00 EDT, 14:00 BST, 15:00 CEST. Please find the zoom meeting link in the google doc: https://docs.google.com/document/d/1tIA1pWABSJlL9KfCwK6t6zwVXm762LNAbvs45YU… Best, Martina Von meinem Huawei-Mobiltelefon gesendet

1 0

Meeting on Tuesday
by Scholger, Martina (martina.scholger＠uni-graz.at) 16 May '20

16 May '20

Dear all, In our last meeting we agreed to continue one more time with reviewing issues from the VF2F on Tuesday, May 19 at 9:00 EDT, 14:00 BST, 15:00 CEST. Please find the zoom meeting link in the google doc: https://docs.google.com/document/d/1tIA1pWABSJlL9KfCwK6t6zwVXm762LNAbvs45YU… Best, Martina Von meinem Huawei-Mobiltelefon gesendet

1 0

Council meeting tomorrow
by Scholger, Martina (martina.scholger＠uni-graz.at) 11 May '20

11 May '20

Dear all, For the Council meeting tomorrow (9:00 EDT, 14:00 BST, 15:00 CEST) we continue with our tickets review in the VF2F google doc: https://docs.google.com/document/d/1tIA1pWABSJlL9KfCwK6t6zwVXm762LNAbvs45YU…<https://docs.google.com/document/d/1tIA1pWABSJlL9KfCwK6t6zwVXm762LNAbvs45YU…> The link to the zoom meeting is the same - see beginning of the document. Best, Martina

1 0

reuse TEITechnicalCouncil user at GitHub as DockerHub build bot
by Peter Stadler 07 May '20

07 May '20

Dear all, you might have received a notification from GitHub that I added the docker-pkp-ojs repo to the TEIC realm at GitHub. Next, I wanted to integrate with DockerHub for automated builds but DockerHub changed something (already some time ago) in that step that makes it necessary to re-connect a GitHub account with DockerHub. They recommend to use a dedicated service user for that rather than using an individuals account because otherwise the whole TEI group/organization at DockerHub would get access to that individuals repositories. Makes sense … So, I’m now looking for a service account I could use and found the existing user TEITechnicalCouncil – which is not really needed, methinks? The only caveat I see is that this user is currently in the group „owners“ and has admin access to all repositories. We should downgrade that user but that might have side effects? If I was to create a new account at GitHub I’d need an email-address that is not already registered with GitHub. So, it'd probably result in two new accounts which seems a bit messy to me. Any objections to downgrading the TEITechnicalCouncil user and turning that into a bot? If I do not receive any objections I will proceed in that direction. Best Peter

4 4

Meeting tomorrow
by Scholger, Martina (martina.scholger＠uni-graz.at) 04 May '20

04 May '20

Dear all, For our Council meeting tomorrow (9:00 EDT, 14:00 BST, 15:00 CEST) I propose that we continue with our tickets review in the VF2F google doc: https://docs.google.com/document/d/1tIA1pWABSJlL9KfCwK6t6zwVXm762LNAbvs45YU… The link to the zoom meeting has not changed (see beginning of the document). Best, Martina

1 0

Virtual F2F meeting
by Scholger, Martina (martina.scholger＠uni-graz.at) 30 Apr '20

30 Apr '20

Dear all, Our Council meeting is just around the corner. Please find the schedule and agenda for our virtual F2F meeting here: https://docs.google.com/document/d/1tIA1pWABSJlL9KfCwK6t6zwVXm762LNAbvs45YU…<https://docs.google.com/document/d/1tIA1pWABSJlL9KfCwK6t6zwVXm762LNAbvs45YU…> The Zoom-Link for the meeting is in the document. Meeting Times: Friday, May 1 all 09:00-13:00 EDT 14:00-18:00 GMT 15:00-19:00 CEST Saturday, May 2 European break-outs 9:00-12:00 GMT 10:00-13:00 CEST all 09:00-13:00 EDT 14:00-18:00 GMT 15:00-19:00 CEST American break-outs 15:00-18:00 EDT Sunday, May 3 all 09:00-13:00 EDT 14:00-18:00 GMT 15:00-19:00 CEST Looking forward to seeing you tomorrow! Best, Martina

1 0