- Present: Clinton, Alex, Antti-Jussi, Alec, James, Dulip, Sonya, Marisa, Ronald, Marc
- Regrets:
- Who
- Marc:
- OJS official docker: Images and docker-compose avaliable for 3.x branches and most of the 2.x ones. Testing is welcome.
- Generic upgrade script (based on docker).
- Theming for OJS 3.2.0-1.
- Testing XML-JATS plugins.
- AJ
- OPS. Beta release ready:
- Moving on to work with OPS taxonomies. Here we aim to introduce editor assigments based on Categories and use the Category taxonomy as the main method of organising preprints in OPS.
- Google Scholar ported to support OPS/OJS
- Open Graph Plugin for OJS/OPS https://github.com/ajnyga/openGraph
- Tackling some community priority issues:
- Almost ready, save review forms without submitting: pkp/pkp-lib#3698
- Next, invite an user to a role (GDPR related): pkp/pkp-lib#3022
- OMP: Crossref plugin, starting next week
- Sitting at home, watching the very worrying Corona statistics. Stay safe!
- OPS. Beta release ready:
- Clinton
- Little PKP focus currently, but a Student Assistant is working on improvements to the Better Password Plugin
- Interested in connecting with Marc re: Testing Docker. (Student tried deploying from DockerHub but was not able to.)
- Dulip
- Released: DAR import/export functioanlity for texture XML editor (Requirements from Clinton)
- Ongoing: minor improvements to ORCID plugin
- Ongoing: new Datacite Plugin for OMP
- Ronald
- we've been extremly busy with OJS2 -> OJS3 upgrades
- lots of issue with files not showing in OJS3
- clients (Austrian Academy of Science) insist on having these files available in OJS3
- Alec
- Application dev work:
- OJS and OMP 3.2.0-1 released
- OPS moved to official git home: https://github.com/pkp/ops
- OPS 3.2.0-1 to be released within a week or so
- Working on roadmaps for 3.2.1, 3.3, 3.4
- PN
- Building/testing PN packages now (a few QuickSubmit issues need tweaking)
- Native import/export plugin patches for 3.1.x available now: pkp/pkp-lib#5372 (comment)
- Application dev work:
- Alex
- Testing/configuring OPS for SciELO (SciELO Preprints); bug reporting.
- Intention to launch pilot version in April to promote COVID-19 preprints.
- Updating OJS to its latest version for SciELO Brazil.
- Marc:
- Next steps for current OCS installs or future interest?
- Define what features need to be implemented to transform OJS3 in an OCS. Start with the essential (upgrade from 2.x, translation and registration?). Then relase and increase in features during time. Look for partners or sponsors that need OCS and like to contribute to this development.
- If we decide to discontinue OCS, suggest a free software to move (ie: indico).
- PKP is currently migrating a large OCS install to OJS.
- Goal is to integrate with existing calendaring/scheduling tools rather than recode. This remains a heavy lift, however (and unscheduled).
- Proposed Survey: representatives list and questions
- We've collected a good list of needs, but it may be long for a survey ask
- Could we use this a conversation starter with users just to inquire of their needs?
- The subheadings within this list map nicely with some of the priorities and roadmapping of the product.
- The individual asks may suffer from conflicting goals, or overwhelming needs, or reactive requests. These may lead to a larger redesign.
- Another challenge is the competing sources of requirements (grants, community requests, hosting)
- PKP is trying to articulate milestones better in a public facing way (milestones feel good from a development perspective).
- Goal is to have broad conversation with the community to help guide workplans and recommendations to PHP from the Technical Community.
- Feedback could reflect both user stories / requirements documentation and also prioritization.
- There is concern that asking prioritization might conflict with existing tasks for limited developer resources.
- Important to communicate the roadmap clearly to help set expectations.
- Example of voting platform as another approach: scholaronemanuscripts.ideas.aha.io
PKP's current draft focus and timeline (James):
Our 2020 goal is to release a suite of plugins, and associated documentation, suitable for specialist production use by November 2020. The suite of plugins should work relatively well together, and the most common article elements should be supported (at least at the editing and typesetting stages). Support documentation, as well as an easily understood evaluation result-set, should be publicly available. Editors who are interested in using these tools should be able to determine whether the tools are currently ready for their own use case by reviewing the evaluation toolset and the documentation.
Our timeline has three stages: an alpha/internal release of draft documentation and evaluation schema + results in May (we may choose to publicly post this, and open the door for wider testing); a more public beta release of documentation, evaluation schema, and packaged plugins in August; and a production-level release of everything, pending final feedback, testing and development, in November.
The following are considered core components of any package or release.
- JATS Parser (Vitaliy)
- Default theme support for full-text HTML (Vitaliy, Sophy, Nate)
- DOCX Converter (Vitaliy)
- Libero Editor Plugin (Dulip)
- Grobid Service Plugin (Vitaliy/James)
- Evaluation schema (James)
- Documentation (James)
- May 2020: alpha/internal draft release of evaluation criteria and documentation + test Grobid service
- August 2020: beta release of plugins + docs + evaluation + default theme support (& through custom theme extension)
- November 2020: release plugins, documentation + more themes
We are also investigating how to best integrate XML production more completely into the production workflow - whether and how to use JATS as the behind-the-scenes data model, how to reconcile content from the JATS file to the database, how to use Libero Editor to edit specific components of a submission (like TinyMCE for abstracts currently), etc. The larger work here will be around reconciling JATS content with the OJS database, and vice-versa.
- Where is this working?
- Open Library of Humanities? Larger publishers, who probably buy the conversion.
- Harvard University Press (with privative soft and XML transformations).
- What are the blockers?
- Marc: The standard itself is not so standarized (multiple sets and versions). No good open/free XML processors.
- AJ: people doing layouts are used to work with PDF's and print. There are very few people who understand XML. We need automatic conversion tools and easy wysiwyg with preview and validation. The wysiwyg should not edit the head section of the file. The head should be generated based on OJS metadata. For advanced users, the editor should allow raw editing.
- AJ: we should consider if it would make more sense to save the XML content to the db instead of files. If we would use the db, we could have easier versioning, editing, commenting etc. The db version would then be used to convert final proofs: HTML and PDF.
- What should we be looking at for future directions?
- First decide what standard (set and version) are we going to cover in all OJS tools. Then ensure we can show those JATS in a proper way (JATSParser). Then focus in conversion (docxConverter, grobid) and edition (texture, now Libero?). Finally, work on JATS transformations to generate PDF, HTML, ePubs... from JATS. This geneation need to be easy to personalize to allow publishers create a layout that fits with their brand/style.
- AJ: Choosing a standard is definitely the most important starting point. After choosing a standard, we should impose it on all existing OJS tools.
- See also MECA as a transport standard: https://www.manuscriptexchange.org/wp-content/uploads/2018/06/MECA_JATS-Con_2018_for_distribution.pdf
April 16th, 2020: 8am Pacific