June 22, 2022

Time/Place

This meeting is held virtually via Zoom, with an open channel for chatter on Slack. Anyone is welcome to join. The hosting can be claimed by anybody with the host ID. The Host ID is in the header of the TAG slack channel.

• Time: 1:00pm Eastern Time US (UTC-5)
• Zoom link: https://zoom.us/j/97345581392
• Passcode: 919241
• Join us on the Slack Islandora Channel https://islandora.slack.com/archives/CM5PPAV28

Chair Roster

These are the core members of TAG and will take on chair of the meeting if there are no volunteers, and will support volunteers who are chairing for the first time:

• Don
• Seth
• Rosie 🪑
• Willow

Attendees

• Rosie Le Faive (Chair)
• Alan Stanley
• Connie Wu
• Willow Gillingham
• Don Richards
• Yamil Suarez
• Alexander O'Neill
• Will P
• Seth Shaw
• Larry Yang
• Chris Day
• Benicio Lopez
• Jordan Dukart
• Rebel Cummings-Sauls
• Adam Vessey
• Dmitriy Sychev
• Isabella Nikolaidis (notes)

Agenda

Note that links are to the document repository only. New issues in other repositories or organizations will not appear in this list, and should be added by interested parties directly to the agenda.

1. Modularizing Islandora Defaults

Town Hall Minutes

• We have an item on the Roadmap - modularize islandora defaults and consider going back to solution packs.

• Ended up focusing less on modularizing islandora defaults.

  • Features don't necessarily work well as solution packs.

• The document has involved consultation with folks from didscoverygarden

• Plan proposal

  • Reimagining way of working with islandora defaults, and stop using features.
    • As features, it's hard to manage and create clean PRs against it.
  • Modularizing islandora a bit more - take those that are in sub modules, taking them out and making them their own modules.
  • Envision a new way of islandora.

• If you or your institution or your service company are interested, please

  • Email by July 18

• Want to gather feedback before creating the call

Phase 1

feasible things to do right now

• 1. Change defaults from a feature to exported site
  • If the feature involves changing configs we can help with that
  • Containing: composer.json, composer.lock, config, sync, and content sync
  • This would be the starting point for the site.
  • If you look back and its been 8 months since you installed the defaults site, we want good documentation about recent updates for people to refer to.
  • This will have effects on ISLE, the playbook, and how they launch a site.
• 2. Extracting IIIF and Mirador to individual Drupal modules
  • A lot of Phase 1 Tasks have been done by the folks at UTSC - on their work on Islandora Lite.
  • They have some modules they are willing to contribute back into islandora.
  • A lot of this would be administrative work to make the playbook and ISLE, defaults, to use these new things.
• 3. Extract Advanced Search to Drupal Module
• 4. Adopt Views Nested Details into islandora codebase
• 5. Themes
  • Themes are hard to maintain so there are reasons to not want to continue.
  • Proposing we move themes to deprecated.
  • Jordan: Initiative right now in Drupal - system of how to ship things thats been changing, led by Aquia?
  • https://www.drupal.org/project/ideas/issues/3274999
• 6. Change viewer mechanism
• 7. Create a "DC Content type"

Phase 2

• Emphasis on, enhancing an existing framework - Drupal
• This will allow us to interact with Drupal integratedly
• Limiting interdependence between our modules and other contrib modules

Discussion

Phase 2 - Imagining Islandora

• Don: How would this impact instiutions that forked modules like islandora defaults and made customizations to it?

• Jordan: seconded

  • anything after phase 2 would be a major version of islandora
  • would support it with an upgrade path

• Jordan: the big goal in the distance is to simplify the stack. to make as much of the stack optional.

  • trying to lower the footprint of what islandora needs to run

• barrier to entry to setting up a stack

• Alexander: previously, positive feedback about using Drupal Advanced Queue - that lives inside of Drupal

  • Jordan: providing a plugin for this sort of module, custom choice by user

• Rosie: Phase 2

  • changing the node media connection direction
  • numerous export methods -
  • islandora module itseflfd does fedora, derivatives, viewers thta use transcripts. these could be packaged up in their own module if we want to. most of those modules are features we want in a repository, but are not dependent on each other
  • would need to refactor documentation
  • this could allow us to move modules to Drupal.org
    • this raises questions - how would it work with patches, PRs through the Drupal ecosystem? There could be a lot more contributing into the community if they were a part of Drupal
    • testing needs to be done separately
  • Don: we created a module for export for bibliographic citations https://github.com/jhu-idc/idc_export
  • Jordan: minimizing what islandora requires out of the box.

• Rosie: would the islandora maintain the ansible roles that set up the whole network?

  • Alexander: if we get closer to what we're talking to, we could switch to using something like Lando (a Drupal module)
  • Jordan: also DDev

• Alexander: have ISLE be what it describes itself as, Enterprise Islandora -

• Jordan: want to lower the barrier to entry - but letting sites that have the resources can expand into ISLE for those who want scale

• A lot of this would encompass breaking changes that would affect existing sites

  • goal would be to have one major upgrade tooling

• Phase 2 are more breaking upgrades - the goal is to do this in one shot.

  • Will P: An upgrade path is the solution.
    • Phase 1: there's dedicated room there to narrow down particulars of Phase 2 which is a more intimidating endeavour

• Alexander: will there be expectations that ongoing development have ongoing communications

• Rosie: concerns about Phase 2?

  • Don: the upgrade process
    • from a vanilla site, this will be possible
    • for those that have customized and are in production, that upgrade process isn't going to be clear
      • Jordan: "off the beaten path" content types

• Jordan: the upgrade process, needs defintion of how someone who's gone off with their own config, are able to implement what has changed

• Don: on the non-developer side, it will require retraining of library staff with drastic changes

  • Is there any way to make phase 2 less of an impact? is there a way to make these major changes on the backend but retain the UI?

• Jordan: most of this stuff is back end changes. Obviously with the viewer mechanism one chaging, that will need to be documented because it's core.

  • If materials have been created internally, they do have to be updated because of the shift in relationships between nodes and media
  • Custom made views based on relationship structure will change

• Rosie: We might not even have the media tab

• Will P: documentation would be consdiered a key deliverable on any UI changes - that should go towards limiting the burden of retraining. We should keep an eye out for any place where we can minimize the retraining burden.

• Will P: easier issue-by-issue

• Alan: updating the documentation and putting in a What's changed section

  • highlight reel for what's been updated

• Yamil: How could people see recent changes from documentation, add link?

• Don: github actions?

  • https://github.com/jhu-idc/idc-isle-dc/releases/tag/v0.7.5

• Don: Born-digital's profile was the origin for the current install profile

  • Willow: IIIF manifest - need

• Don: not entirely dropping the community version - if we're modularizing everything out, having a location for your own custom stuff would be ideal

• Alexander: Install profiles -

  • Problems inherent in the one shot and done of how they work
  • If islandora doesn't depend on many different modules because it has features that work with those modules, you probably do want another place with everything enabled (could be a module enabled that gives other functionality).

• Will P: a lot of the value you're describing would still be encapsulated in the starter site and would be in a much more common format

• Rosie: install profiles allow you to write code that is interesting, and also serves as a boilerplate starter deployment thing. So as a vendor, having an install profile is convenient because you can make adjustments

  • +1 to Will's point
  • but haven't used such a starter site before - has anyone used these?
  • Will P: there's no bounds with what you can do to it
  • Don: I want to create a module override. Do we need to create a module to then just hold that solr processor, for example?

• Jordan: What we're proposing is not so far from a install profile.

  • Drupal constrictions on install profile. you have to pick and choose what you want.

• Will P: with Drupal 11 and 12 may have a new paradigm to adopt