# November 18, 2021

In Attendance
-------------

- Present: Alex, Alec, Ronald, Davin, Antti-Jussi, Clinton, Marc, Sonya, Nathalie
- Regrets:
- Dulip

Introductions
-------------
- Davin has joined the TC (Erudit / Coalition Publica)

Quick Updates
-------------
### What have you been working on lately?
- Alec
- Automated upgrade testing in place for OMP, OPS, OJS
- Planning for OJS/OMP/OPS 3.5 and 3.6
- Alec can share out documentation with the TC via dev channel for questions and feedback
- Marc
- Moving all service to an external server (nice experience to write about).
- Dulip
- Grant application writing
- Investigations / Problemsolving
- (Implementing in 2022: the broken functionality of automated crossref doi import in Texture-Editor (obsolelete software), Implemented: Docuemnt Type support for Galley Creation (with Depdendant files) in Texture-Plugin.
- Current JATS-XMLs generated by Texture are not Valid against JATS [DTD](https://jats.nlm.nih.gov/publishing/1.2/JATS-journalpublishing1.dtd). Reason: (jornal-meta) fails and cname incompatibility.
- Sonya
- planning Library Publishing Forum (submit your proposals!)
- Alex
- Upgraded SciELO Preprints to OPS 3.3.0-8. Scheduling OJS upgrade now for SciELO Brazil journals.
- AJ
- Working on OMP imports and preparing a conversion script for generatin OMP XML files from Excel sheets
- Starting to prepare for OJS 3.3 upgrade
- Planning what we will have for lunch in the PKP Sprint in June 2022
- Ronald
- Upgrade DNB plugin for OJS 3.3 (adding new features: depositing Orcid ID, supplementary files, writing tests)
- Developing plugins for OMP (Langsci Press)
- Writing grant application (with Dulip)
- Clinton
- Pitt continues to work on updating our contributed plugins to support OJS 3.3+

Introductions
------------
* Welcome to new member Davin Baragiotta from Érudit
* Welcome to Nathalie Vallieres, PKP Communications

Old Business
------------
* October minutes are here: https://github.com/pkp/technical-committee/blob/main/meeting-minutes/2021-10-21.md
* Testing Working Group update:
* Minutes are now here: https://github.com/pkp/technical-committee/tree/main/testing-committee/meeting-minutes
* Terms of Reference are here: https://docs.google.com/document/d/1-sW2pwGSnkAqpG-NzMR5N-bNm9KywJXPamPm-L_7AiQ/edit
* will start with a upgrade testing and performance testing, with our next meeting focused on defining specific activities and planning how to proceed.
* Any further discussion, feedback or comments on the LTS proposal? https://docs.google.com/document/d/1_kdl-PgH653m9PC2v0kh-KU7l_3XPUtVSnkKoa7uKCg/edit?pli=1#
* are there action items for TC?
* Next steps:
* Take the proposal to the directors (Alec)
* Schedule a slot in an operations meeting and invite Sonya (Alec)
* New community members

## Question of the Month
### Are there actions we (TC) can take to help folks running unsupported versions?
* Marc's brainstorm of potential "solutions" or "helpers":
* More documentation?
* A high level upgrade-wizard for editors to help them localize their pain areas and get the proper help?
* An upgrade "black-box" that gets you mysqldump and your files and returns a new dump and upgraded files in the last stable version?
* A compilation of well-known errors and their solutions (a troubleshooting DB)?
* An "upgrade" campaign focused to those specific journals (offering pkp services and a list of organizations that can help them in the upgrade process)?
* others?
* What do we know about why the community doesn't stay up to date?
* There is some commentary in beacon presentation with inferences from detailed version data (Slides 27-33, https://dataverse.harvard.edu/file.xhtml?fileId=5378724&version=1.0)
* Should we do a survey?
* Unmaintained installs might not result in survey answers.
* May not be technical:
* There are unmaintained/abandoned installations in the wild. e.g. where systems and editorial teams are different, editorial group disappears, systems doesn't know.
* Ideas about why installs might be old:
* Hardcoded OJS: As far as the code is open, it's quite common to see forked versions of OJS. Once you open the "pandora's box", you never stop and you finish with a frankenstein-ojs that nobody have the courage to touch. And then, it's difficult to keep the track of the changes (think 2.x is before git) and you need to merge manually.
* I love my theme: Yes, it's a variant of the former one. Some times journal spend some money in a nice theming and now they don't like to lose it.
* Multiple OJS: If you decided to go with a single-tenant model, you got some benefits, but one big donwside... you need to upgrade multiple ojs.
* Damaged OJS: Shit happens. Sometimes you get a journal with corrupted files or an inconsistent DB. And it makes the upgrade crazy.
* Old plugins: If an specific plugin that is essential to you is not released for 3.x, you can not upgrade.
* Lack of tech resources: In most of the universities I know the IT services are centralized and it's difficult to get their atention in a project that is not in their hands any more. I mean, sometimes would be difficult for a sub-organization that asked for an OJS installation 10 years ago to request an upgrade...
* A weird error: Long time since OJS 2.x but is not impossible to think that somebody is getting an upgrade error that don't know how to deal with.
* ...
* Is this work that we should tackle?
* Dev team (not TC necessarily) needs to protect its time -- there are improvements starting in 3.3 but going back to older versions will be very time-consuming.

Other topics
------------

Next Meeting
------------

December 16, 2021

Third Thursday of the month: 8am Pacific