February 19, 2020

Time/Place

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

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

Feel free to add agenda items...

iCampAZ branch of the playbook
Collection management adjustment to handle as a separate content type
Ship with an "EDIT me!" version of the default content type
1. Ship with an "Islandora 7 migration" Content type (the BIG one) and a simpler version for greenfield?
Scholarly (media) content - embargo date field on the media - https://github.com/Islandora/documentation/issues/1161#issuecomment-585321120 and is there functionality in https://www.drupal.org/project/moderation_scheduler that couldn't be handled by additional date fields for example: embargoing, scheduled update or transition dates, etc? How to handle access control and other node changes related to a given date action. Views can be made to display all upcoming "Embargoed" items and "Tombstoned" as well.
Milestone Issue Roundup
1. Documentation not linked to menu
  1. PR Here
2. Imagemagick can't create JP2s on Ubuntu
  1. PRs here and here
3. File upload fails if user doesn't have fedoraAdmin role assigned
  1. PR Here
4. Can't upload large files
  1. Needs another tester with better internets than myself
5. Can't use tomcat manager
  1. Potentially resolved by disabling syn?

Special branch of islandora-playbook for iCampAZ will be available.
ASU looking at Collections as a separate content type.

Is that how the community wants to move that direction.

We need to make that request to the larger community.

ASU has been able to make all necessary changes to have Collections as this new content type and everything seems to be working. Community seems to be moving this way but it would be nice to get some clarity on what we want.
What is an islandora object, this discussion seemed to boil down to the member_of field.

The "model" field (while used in the "Is Islandora Object" Context reaction) is not required.

Should we define what we expect from an Islandora object instead of what IS an Islandora object.

UNLV has lots of objects with member_of fields but they are not in Fedora, so this is not even a hard requirement.

Concerns that if anyone can have anything as "Islandora" then is there the same re-usability between Islandora systems?

What about adding Islandora to the name of the media types as media has more of an effect on how it is dealt with.
Duplicate the core Repository Item in a quick manageable way or ship with at least 2 copies so people don't worry so much about editing it.

Perhaps the second type doesn't have ALL THE FIELDS, and is more slim for non-Islandora 7.x users.

Charlie has been considering doing a DC to DC migration instead of MODS to RDF, as we are pairing down anyways.

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