December 8, 2021

Time/Place

This meeting is held virtually via Zoom, with an open channel for chatter on Slack. Anyone is welcome to join. Here is the info:

• Time: 1:00pm Eastern Time US (UTC-5)
• Zoom link: https://zoom.us/j/97345581392
• Join us on the Slack Islandora Channel https://islandora.slack.com/archives/CM5PPAV28
  • Chair rota
    • Mark
    • Melissa 🪑
    • Danny
    • Rosie
    • Seth
    • Eli

Attendees

• Alan Stanley
• Jared Whiklo ⭐
• Seth Shaw
• Kristina Spurgin
• Kirsta Staplefeldt
• Melissa Anez
• Adam Vessey
• Nat Kathan
• Don Richards
• Alexander O'Neill
• Jordan Dukart
• Rosie Lefaive
• Daniel Lamb
• Kyle Huynh
• Yamil Suarez

Agenda

1. Issue Roundup
2. PR Roundup
3. Don Richards: Adding Statuses for things that are waiting for review and pulling 1 .For information: Sprint Planning Document
4. (from Roster) Review DevOps Repo descriptions/dependencies / ticket https://github.com/Islandora/documentation/issues/1910
5. (from Roster) Review maintainers. Current maintainers
6. Anything you want to add...

Topics Backlog

• Fix Chair Rota?
• What are workflows around releases that ensure testing, RCs, documentation, etc.
• Drupal.org - when and how?
• From Adam - Automatically create box? https://stackoverflow.com/questions/66261101/using-vagrant-on-github-actions-ideally-incl-virtualbox/66261102#66261102
• Islandora Labs needs cleaning
• How we should break up Islandora Defaults - Document on this
• Protecting default/main branches
  • Github's docs
• Deprecation workflow
• Should we be testing against a single deployment method? (From Bethany)
• https://github.com/Islandora/documentation/issues/1941

Minutes

1. New tickets

   1. https://github.com/Islandora/documentation/issues/2000 - Covers work Kyle is doing to adapt some stuff from Born Digital theme to a more theme-agnostic style.
   2. https://github.com/Islandora/documentation/issues/1996 - It appears to be pulling from an incorrect field, but unclear who is using the existing setup. Easy answer is to pull from the date issued field.
   3. https://github.com/Islandora/documentation/issues/1994 - The plan is to drop the reliance on migrate_tools as the new Drush (version 10.4 or newer) has the required commands internal. Because these commands are now in Drush, you can't install a new version of Drush until you uninstall migrate_tools. You do lose the UI for migrate, but that UI is not that good. Merged in the meeting.
   4. https://github.com/Islandora/documentation/issues/1993 - This issue relates to the submitted PR.
   5. https://github.com/Islandora/documentation/issues/1991 - Remove the words "Fedora-based" from the Github descriptions. Will be passed up to Leadership group. Is this a technical issue? There is code in "core" that is specifically for Fedora. Should that be pulled to a sub-module or should some stay in core (like Flysystem) in-case you want to extend it.

2. PRs

   1. https://github.com/Islandora/controlled_access_terms/pull/75 - Could use review, Nat will take a look.

3. Adding statuses to sprint planning dashboard, this was handled with additional columns have been added to Kanban board.

4. https://github.com/Islandora/documentation/issues/1910 - some dev-ops things rely on other dev-ops things, this is figuring out what each repository is for and what dependencies it might have.

5. Review maintainers list - https://docs.google.com/spreadsheets/d/1E7W0VNcBDsi8xM58KBa5UxvMgJoFNlrWLToFmFcHM2o/edit#gid=0 Now that modules are dis-entangled from each other, so we need to refresh all maintainers at a set time or do we look at each individually. Do we remove maintainers and just have people handle issues. Add a generic statement where people could find support and remove the maintainer. Ex-officio because github provides data for commits.

   • no maintainers but a credit section
   • develop maintainer requirements and find them
   • have credits if no maintainer can be found.

   Kirsta will create some language to replace but wants to leave open pathways for people that want to maintain more control over their code.

6. What is a core module? "Core" is anything important enough that we want to make sure it is maintained with certain requirements. It is not "required" to use, the "core" is more about it's importance to the community then to any specific installation.