August 10, 2016

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

• Nick Ruest
• Ben Rosner
• Bryan Brown ⭐
• Ryan Townshend
• Melissa Anez
• Aaron Coburn
• Kirsta Stapelfeldt
• Ed Fugikawa
• Rosie Lefaive
• Danny Lamb
• Diego Pino

Agenda

1. Alpaca

• How does Alpaca fit into the PHP microservices architecture?
• How do we adapt Alpaca to work with Drupal 8
• How can we incorporate some of Amherst's work in to Alpaca?
• How does Alpaca fit into the MVP? What is the priority?
• What do we need to do to clean up and get to a 0.0.1 release

2. PDX

• ObjectService and FileService status
• What is the priority for PDX moving forward MVP-wise?

3. August sprint planning

• Priorities and focused efforts

4. What to do with D7 version now that we're focusing on D8?
5. Versioning documentation

• https://github.com/Islandora-CLAW/CLAW/issues/265

Minutes

1. Alpaca

• Danny Lamb: Alpaca doesn't currently fit flush with the PHP microservices, but the microservices are also in heavy flux. We need to get the microservices ready for an MVP release, and refactor Alpaca to work with them in parallel
• Nick Ruest: Amherst has some interesting code up at https://gitlab.amherst.edu/acdc/repository-extension-services that overlaps with what CLAW has been working on
  • Danny Lamb: All Java Camel OSGI stuff, which has a steep learning curve and isn't the Islandora community's wheelhouse. Amherst code doesn't just overlap with Alpaca, but with PDX & Crayfish too (perhaps even more than Alpaca)
  • Nick Ruest: Also involves some PCDM services/extensions. Code written to fit similar use cases could be ripe for collaboration, but that would require bringing in even more unfamiliar tech to an already complex stack. Still, better to work on an existing project than roll your own?
  • Danny Lamb: Perhaps the Amherst Java stuff can be like a black box, one doesn't have to know Java/Camel/OSGI to use the services?
  • Aaron Coburn: Yes, these services are all decoupled black boxes that work independently of each other
  • Aaron Coburn: They're designed to work with Fedora API-X (API-X requires community buy-in and is still in development) but they can be run independently, too.
  • Aaron Coburn: Amherst code could be cut into Maven releases if CLAW wants, which would make it easier to use
• Nick Ruest: What are some actionable next steps for Alpaca?
• Danny Lamb: Currently in the process of auditing Alpaca codebase to see what needs to be done for an MVP release
• Should derivative creation be an Alpaca service, or a standalone PHP microservice?
• Nick Ruest: Perhaps the August sprint should involve a lot of exploration/analysis of Alpaca's MVP goals
• Danny Lamb: Whatever we decide to do, we should keep decoupled services as a major design goal for CLAW architecture

2. PDX

• Bryan Brown: Ben Rosner and I have spent time exploring PCDM but found it kind of vague, which makes it difficult to visualize a working implementation. API design might not be a good thing to hand off to newbies since we don't want to be tied to a poorly thought-out API from the beginning
• Bryan Brown: Perhaps we should have a PDX/PCDM specific call with interested contributors to spec out PDX design goals?
• Danny Lamb: What version of PCDM should we use? 1.0 or 2.0?
• General agreement that we should stick with 1.0 for now
• Danny Lamb: How should we handle the ongoing nature of PCDM 2.0?
• Nick Ruest: The PCDM community seems to be stuck, disproportionately favoring Hydra ideas
• Danny Lamb: Perhaps we should just resolve to be more active on the list and get more representation
• Aaron Coburn: Apache philosophy is "If it didn't happen on the list, it didn't happen." We should engage with this stuff in a public way so that our opinions/use cases are well documented.
• Nick Ruest: Hydra is going to do what Hydra wants, it's the Hydra way. Perhaps we shouldn't be tied to an ontology we don't have control over.
• Aaron Coburn: My personal design philosophy is to describe resources with as few triples as possible and not worry too much about consumption by downstream apps. Use OWL for inference.
• Diego Pino: We need to figure out how CLAW is going to handle data modeling in general before we get lost in specific implementation details. Data modeling discussions have been ongoing, but not satisfactorily resolved

3. August sprint planning

• Nick Ruest: August sprint starts on the 22nd. We should use the next CLAW call to discuss sprint priorities, perhaps even doing a no-coding sprint where we focus on design goals/analysis/data modeling/etc (lots of agreement)
• Danny Lamb: +1, ideally we shouldn't code anything if we don't really understand what it should do/how it should do it. A design sprint would be great.
• We should put our design goals forward in the form of the smallest possible issues/tickets to make it less of a commitment for new contributors to get involved
• Nick Ruest: dons project manager hat I can talk to bosses if people feel like they aren't getting institutional support for sprint time.

4. Transitioning from Drupal 7 to Drupal 8

• Danny Lamb: How should we handle this transition in the versioning? Should we just cut a d7 release and be done with it?
• Nick Ruest: Let's just walk away from Drupal 7 entirely, cutting a release implies a certain level of support that we don't actually want to commit to.
• Discussion of how to apply semantic versioning to CLAW ensues, comparing "true" semvar of major.minor.patch to Drupal's "fake" semvar of DrupalMajor.x-major.minor.patch. No conclusion is reached, and it is agreed that we should discuss this further at the next meeting.

5. Versioning documentation

• Nick Ruest: We need to figure out what to do about the docs because its getting a bit fractured, but how we handle this may depend on eventual software design decisions. Lets put this at the top of next call's agenda.