Skip to content

Latest commit

 

History

History
146 lines (132 loc) · 8.43 KB

2021-07-15.md

File metadata and controls

146 lines (132 loc) · 8.43 KB
Raw

July 15, 2021

In Attendance

  • Present: Alex, Alec, Clinton, Marc, Nate, Dulip
  • Regrets: Sonya, Pierre

Quick Updates

What have you been working on lately?

  • Name - Summary of items FYI
  • Marc
    • GDPR helper plugin: that will include 3 features:
      • A checklist: to confirm your meet GDPR requirements.
      • A "enable warnings": to advice users when they are doing activities that could break the GDPR.
      • A cookie banner: that let you select what cookies enable or disable (demo).
    • Docker image review and upgrade.
      • Built ojs 3.3.0-6.
      • Testing stable-3.2.1 image.
      • Fixing image dependences.
    • Translating/Commenting Nate's bulletins to OJS-ES.network.
    • Admin's upgrade guide.
  • Sonya
    • drafting call for new members (thank you Dulip and Pierre!), seeking feedback from Advisory committee on standing members from Dev partners and wording of call.
  • Dulip
    • Dev
      • Long-time archving plugin
      • Explore XML to PDF : CSS based approaches.
    • Operations
    • General:
      • OJS -Job posting (no suitable candidates found) thus rewriting with more general tech know-how.
      • XML Grant application
  • Alex
    • Specification, Portuguese translations and testing for the PREreview (external peer review platform) plugin for OPS.
  • Clinton
    • Back to strategizing how to deploy OJS 3 with locals in 3rd party libraries; hoping to avoid composer mods.
  • Ronald
    • Dev
      • Slider Pugin, DNB-Plugin for OJS > 3.2
    • Operations
      • Extension of OA, OJS servies in the context of the Berlin University Alliance
      • setting up of new journals (up to 6 in the chain)
    • General
      • XML Grant application (together with Dulip)

Old Business

Previous Minutes

Ongoing Work

  • Admin documentation group update

  • Call for new members. Sonya, Dulip and Pierre worked on draft call and got some good feedback from James. Seeking feedback from Advisory Committee. Hope to send out end of July begining of August.

  • Retirement of OCS

    • support needed here from TC? We had volunteers to provide support on the Forum following an announcement.
    • PKP Hosting / TC conversation on #pkp-dev Slack channel re: migration path to OJS
      • Please add suggestions to this thread regarding any recommending tools
    • Public announcement: note added to OCS download page. Alec will raise a formal annoucement request with the operations group.
    • Note also the upcoming retirement of the PKP Index (and PKP Harvester)

Question of the Month

  • Welcome to Nate for discusson re how to connect suvey efforts with dev / release efforts.
    • Survey lifecycle:
      • Toughest part of the suvery was to collect and categorize the feature requests from multiple sources.
      • A subsequent survey's categorization could align with this past survey's categorization
      • Free text collection was complicated, perhaps could be refined in future.
        • Value seen in free text answers, but could be reduced
      • Hope is to automate the survey process, if desired.
        • Equity, Diversity, and Inclusion is also intersted in automating similar work; connect with them in Slack.
        • Hope is to improve transparency in the development cycle
      • Known gaps: missing targets, and categorization of respondents.
    • Feature requests:
      • Git Issues include both feature requests and bug reports, leaving a long backlog
      • Community is primarily chatting in the Forum, but GitHub is the source of Issues
        • PKP staff are filing GitHub issues from the Forum
      • Other projects close issues due to inactivity
      • Could feature requests be categorized as part of triage (for survey purposes)?
        • Requires design effort and shapes PKP's response
        • Is the categorization a self-fullfilling prophecy (via the Roadmap)?
        • There was alignment with the Roadmap, but not a 1:1 mapping for the Survey
    • Release cycle:
      • Start of cycle is decision on priorities
      • Community input at the start of cycle could be helpful
        • Integrate the Technical Committee here?
      • We target 1 - 3 big things each year
        • Deep community feedback is useful, but detail may exceed our capacity to meet requests.
      • We need to balance product design against the loudest voices and feature requests
        • Become less reactive to individual requests and more proactive about identifying pain points
        • Look at qualitative and quantitatve data to identify targets
        • Real value of the survey from the design perspective was rating of pain points and free text comments.
        • Qualititive feedback also comes from user testing and focus groups.
      • Would be nice to see how pain points are addressed over time for community and communications use.
      • We hope to improve release communications, especially with the new communications hire. See, for example, the 3.4 announcement.
  • Related conversation re: version policy and PKP updates.
    • In short, the number of versions released by PKP can lead to the abandonment of some journals that, given their very limited resources, cannot assume the migration to the latest stable version. .. or they cannot update as often as new releases are released.
    • The TC we should stop for a moment to talk about how to achieve a flatter upgrade process... evaluating changes in the version policy (debian/php model? often "non-braking" releases, only a few breaking ones), improvements in upgrade tools (selfbackup, one-click upgrade) or whatever we can think of so as not to leave anyone behind.
    • Proposal of a "once" per year "major release".
      • This is important in plugin development.
      • We have improved the contract with respect to theming.
        • template segmentation, documentation of variables
      • We need stability of database and infrastucture/API
        • very unstable since 3.1/3.2 with past and upcoming code modernization
        • code modernization is needed to reduce maintenance burden and make the code accessible to other developers
        • concern with planning for code changes which have a two year lifespan (spanning three major versions)
        • release notebook should help with allowing for adaptation
        • Could mark function deprecated in the last stable release
    • One major problem remains the lack of a true historic version and the lack of testing in brand new releases.
      • This especially comes out in upgrading old journals with legacy data.
      • Next meeting: continue discussing end-user stability

Other topics

To talk in future

  • Google FLOC

    • Q from Nate W: “I’d like some feedback from our community, especially the Tech Committee, on the new surveillance technology being added to Chrome, and whether we should take steps within our applications to block this. Details here: pkp/pkp-lib#6961

  • PKP soft continuity:

    • PKP hosting team is working on OCS to OJS conversions; reach out to them on pkp-dev Slack channel.
    • Should PKP retire OHS and OTS too?
      • Is there a way to discover how many people is still using OHS and OTS?
      • If we decide to recomend the discontinuation of OHS or OTS, which free developments do we consider to be the best substitutes for these tools?

Next Meeting

Third Thursday of the month August 19, 2021: 8am Pacific August meeting: Conversation around processes and consultation for decommissioning products.