Skip to content

August 3, 2016

Jump to bottom Edit New page
Nick Ruest edited this page Aug 3, 2016 · 10 revisions

Time/Place

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

Attendees

  • Nick Ruest
  • Danny Lamb
  • Ben Rosner
  • Diego Pino
  • Bryan Brown
  • Marcus Barnes
  • Mark Cooper
  • Melissa Anez ⭐
  • Brandon Weigel
  • Don Richards
  • Jared Whiklo
  • Aaron Coburn
  • Ryan Townshend

Agenda

  1. What it means to have a Tech Lead
  2. MVP with Drupal 8
  3. Revisit Architecture
  4. Content Modeling
  5. Revisit API Design
  6. Revisit RDFUI / RDFUI Builder
  7. Revisit Install Procedure

Minutes

irclog

What it means to have a Tech Lead

Danny: Now working for the Islandora Foundation exclusively. Would like to explain his role (there's a pending blog post for islandora.ca as well). His job has three main parts:

Islandora 7.x-1.x, where he will be overseeing the next release, but otherwise deferring to the Committers Workflow (with occasional special attention to move along things that have sat too long or when there is a security issue).

Special Project - The IF is part of a grant to fulfil certain requirements (part of which funds Danny's salary) which dovetails with CLAW development, to build a system for UBC.

But most relevant for us:

Islandora CLAW - Where Danny hopes devote most of his time. He is here to make sure that this project happens. Get people involved, get them to help out - but also, where he's now full time, to devote time to the move to Drupal 8 and define what that means, how it will change things, and what our Minimum Viable Product (MVP) should be so we can get out something that people can start playing with. Wants to create a whole specific, use that to inform the sprints so we can act in a more focussed way. Make a full-blown specification, break that down into the smallest pieces possible, use those for the sprints.

Difference between Nick's role and Danny's role: Nick is acting as the 'Project Manager' (although his title is Project Director - MA). Reporting, bringing people into the fold, reporting to the Board and Roadmap Committee. Danny will be on the ground driving CLAW development. Looking for as much feedback as possible. Trying to be realistic about time commitments and how much help contributors are able to give.

Question for the team: How best to work with you? Expects to write documents for comments. Google docs? GitHub?

Nick: What is this document? How may are there?

Danny: - Expects it will end up being the Project Plan, but does not want to just write over the existing one. There will probably be multiple version (tech, non-tech, etc. Different contexts).

Nick: Suggests we follow Fedora's lead with Fedora API Specification and API-X, use a Google docs to hash it out, then move it over to GitHub when it's finished, and then use pull requests if it needs further updates.

General assent to this plan in irc.

Nick: suggest that the document should be 'owned' by the IF (Melissa and Danny) and others contribute via Google Docs suggestions

Danny: Does not know everything. For the record.

Nick: Calls for question from the group for Danny as Tech Lead

Mark: There seem to be three different ways to build the stack. What's up with that?

Nick: The alpha version of CLAW, that lives at future.islandora.ca, is done. We have split out the project quite a bit since then. The contract work to build and Ansible playbook and Docker for CLAW was built off of that work, so those methods need to be updated to work with the latest development. Vagrant works with the latest. Once we get somewhere with the MVP, we can update the Docker and Ansible work to work with the latest again.

Mark: It could be confusing for newcomers trying to adopt. Will put in a ticket so we have a record of the issue.

Bryan: Is there anything about this role that's specifically OUT OF SCOPE that you want us to know?

Danny: There is a lot going on with the different communities. Doesn't think it's a good idea for him to be liaising everywhere and going to a bunch of meetings because that could eat too much time. There are a lot of integration suggestions out there, and we can't say yes to them all.

Nick: Notes the importance of having representation in these other communities, but to make it sustainable, we nee to spread that duty around.

Danny: Will always try to help with coding questions, answer stuff on the listserv, code review/testing/merging - all while trying not to get overwhelmed and lose sight of the key tasks. Realizes after three days on the job that this role was badly needed, there is a ton to do.

Diego: When will be the last 7.x-1.x release?

Danny: Unknown. He will manage the next release and try to get a volunteer manager to take over again after that. Not sure when we can call it End of Life. Still very widely used. There's enough interest that even once it's EOL for the Foundation, a group from the community could take it over, so it may just keep on going.

Nick: It's a conversation to happen when we have an official 1.0.0 Islandora CLAW release. Similar to what Fedora did, where once Fedora 4.0 was released, Fedora 3 End of Life timeline was decided.

MVP

Time to take stock. A lot of what was done in the beginning needs to be changed. Diego and Jared have had a lot of discussions, especially about content modelling.

Danny: We need to look at everything. All of it. Some will stay, some will go, some will get put on hold because we do not have the resources to do all that we want to do. We solicited use cases before, we had good ones, but maybe not enough for a full specification. If we solicit again, we'll probably get similar results, with maybe some extra conflicting ones on the pile.

So... instead, tale all the use cases we have now. Try to find the smallest possible project that will fulfil as many of them as possible. And when folks start to ask "what about X?" and "What about Y?", we can have those discussions. Basically, put something out there, and then take reactions to refine it.

  • Need to look at the API. Easier to be RESTful in Drupal 8
  • Push some things back into Drupal that were done elsewhere in 7.x
  • Simplify - one entity per 'thing'. Datastream, metadata objects, etc. Use entity relationship for the LDP look and feel.

Diego: Has been playing around with how to describe what is in Fedora 4 in Drupal 8, and back. Mostly discovered how to get around to the new Drupal 8 Symfony-like API. How it's modular and you can slap on services and extended services. Talked with Jared about who to build tuque-like entity types. Keep on using the "Add Content" button in Drupal, which is so appealing for the community. Two ongoing developments:

  • a way to maintain the 'node idea,' but it's actually a view of joined entities. Best of both worlds, because you still have nodes, but beneath that you have custom entities that describe what is in Fedora 4.
  • For last sprint, create JSON-LD serializer (needs integration tests)

Basically, Drupal 8 is more than just rewriting. It's completely. Developing is complicated but fun. It will allow us to do a lot that we are not even thinking of. We need to get further in to appreciate what we can do with it.

*Danny: That's a good indication of what we're going to do with content modelling. API design will be built around these entities.

For the MVP: Focus on Drupal 8. It's something a lot of people in the community can get behind. People want to learn it. Not cram everything into Drupal, but focus on the Drupal end of things. Build our needs in Drupal, find ways to push back to Fedora. Not so much wireframe stuff; API first. We'll get user interface for free if we do it the Drupal way.

Checks in to see if everyone is cool with this or concerned about having their work tossed out.

Nick: Destroy it all if need be. My work is not a sacred cow. Looking ahead to next week's discussion about Alpaca and how we can slim down the code as much as possible.

Danny: Will likely liaise with the API-X stuff. Has missed out until now due to schedule conflicts.

Aaron: APIX is really just a framework for running, distributing, and deploying services. The service itself is a black box. If CLAW has particular needs, they should fit right in.

Danny: Might be something we can do with derivative creation. Write them as services. Is that realistic?

Aaron: Affirmative.

Danny: There's a lot we could talk about. Too much. Drops a bunch of acronyms and tools that are definitely not spelled like they sound, to make the notetaker's life interesting; Swagger, RAML.

Nick: Reminds us that Format Policy Registry is a thing, and shared a link the Amherst repository extensions work. Also: ldpath (and blogged by Chris Beer).

Aaron: The ldpath that currently works with Fedora paths doesn't quite work. Ok for demos, but he is working on something more functional. It's like XPath, but XPath that can go out and walk the linked data cloud.

Danny: Channels Andrew Woods, talks about the 'long game'

You may be looking for the islandora-community wiki · new to islandora? · community calendar · interest groups · roadmap

This is an archive. For new Tech Call notes, click here

⚠️ ARCHIVED Islandora Tech Calls

⚠️ ARCHIVED Islandora User Calls

Clone this wiki locally