April 26, 2017

Time/Place

This meeting is a hybrid teleconference and IRC chat. Anyone is welcome to join. Here is the info:

• Time: 1:00pm Eastern Daylight Time US (UTC-4)
• Dial-in Number: (641) 715-3570
  • Participant Code: 304589#
  • International numbers: Conference Call Information
  • Web Access: https://www.freeconferencecallhd.com/wp-content/themes/responsive/flashphone/flash-phone.php
• IRC:
  • Join the #islandora chat room via Freenode Web IRC (enter a unique nick)
  • Or point your IRC client to #islandora on irc.freenode.net

Attendees

• Bryan Brown
• Jared Whiklo ⭐️
• Diego Pino
• Mark Baggett
• John Yobb
• Robert Waltz
• Danny Lamb
• Melissa Anez
• Nat Kanthan

Agenda

1. https://github.com/Islandora-CLAW/CLAW/issues/611
2. https://github.com/Islandora-CLAW/CLAW/issues/612
3. https://github.com/Islandora-CLAW/CLAW/issues/613
4. Scholar in CLAW

Minutes

1. The first 3 issues are pending an API-X issue that Aaron Birkland may have resolved.

   These are low hanging fruit if someone would like to take these on.

   1. is using the API-X header for some services.
   2. Create description RDF for these services.

   Finishing up some pieces in a Camel route to complete the Milliner/Gemini integration.

   Need a viewer next.

2. Scholar thoughts

   Bryan: After the the IR meeting, they were talking about the Scholar specing at IslandoraCon and Bryan had been thinking about reimplementing all the features in CLAW but not calling it Scholar and instead have it as smaller features with their names. Many people like the name recognition of Scholar.

   Developers find Scholar hard to maintain because it has so many sub-modules.

   It also seems to have some image issues as people are not aware of the actual way Scholar works and how you can use other features in your IR.

   Want to carry the name forward, but have an easier way to setup and include these. Perhaps "Scholar" just includes and enables all the separate modules/features needed for a base IR.

   Perhaps a Drupal distribution which includes the modules and features needed for an IR.

   Jared: I don't like the distribution plan as it makes it harder to add the IR features on to an existing repository.

   Robert: My main interest is that all the dependencies that are required can be managed separately or easily overriden. More loose bindings would make it easier.

   Bryan: My history with distributions is it gives you an simple out-of-the-box setup. But how do you manage the configuration, once you start to move away from the normal.

   Danny: Features might be useful as well to help if we want to lock down certain parts. Probably good to research how Features is different D8. Also perhaps providing a drupal composer file to build a simple setup.

   Bryan: Distributions seem to handcuffs you once you want to move away from the standard setup. The module route seems the most sane.

   Diego: http://lightning.acquia.com/blog/packagist-switch as an example

   Bryan: Just want to have everyone keep Scholar in mind as we move forward and look for any tools that would make the integration of multiple modules under the "Scholar" heading easier.

   Jared: Would it be better to keep configuration in one place or multiple places.

   Bryan: Embargo is a perfect example, as this can be used for scholar and non-scholar objects it shouldn't be in a Scholar admin page. It would be nice to have a sub-set of options on a scholar page, and then all options on embargo?

   Danny: Things that have multiple uses could go in a bunch of places, hard to say where they should go.

   Jared: Perhaps having links appear on the Scholar admin page that points to the other installed modules, so we aren't duplicating functionality. Instead if the modules exists (ie. embargo) we add a link in the scholar admin page to point to the other modules admin pages.

   Bryan: That sounds like a good way to also avoid someone's scholar specific configuration overriding the default (example: embargo) module configuration.