Skip to content

November 10, 2021

Jump to bottom Edit New page
kstapelfeldt edited this page Nov 15, 2021 · 21 revisions

Time/Place

This meeting is held virtually via Zoom, with an open channel for chatter on Slack. Anyone is welcome to join. Here is the info:

Attendees

  • Seth Shaw (Chaired), Adam Vessey, Alexander O'Neill, Annie Oelschlager, Danny Lamb, Don, Drew Heles, Eli Zoller, Jared Whiklo, Jordan Dukart, Kristina Spurgin, Kyle Huynh, Marcia Johnson, Nat Kanthan, Sarah Goldstein

Agenda

  1. Issue Roundup
  2. PR Roundup
  3. Islandora Governance Proposal for Feedback - any additional comments before this goes to Leadership?
  4. Sprint Signup Sheet - Sprint issues voting progress - emerging topics from sprint sign up sheet are default experience/Isle DC changes/Access Control
  5. Could we make some decisions about the purpose and future of Islandora_Defaults - what is its role in the Islandora 2.0 ecosystem (managing updates) before the sprint?
  6. Protecting default/main branches
  7. Kirsta - can I move Github issues to separate repositories during the sprint and create a Github project to bring them together?

Topics Roster (Backlog of issues to discuss)

Minutes

  1. Issue Roundup

https://github.com/Islandora/documentation/issues/1980 <-- need to tweak some configs as field names changed. Doesn't hurt anything (isn't damaging). One exception might be in Mirador (where some of the references are). Might explode Mirador. Could be rolled into other changes.

https://github.com/Islandora/documentation/issues/1979 <-- New use case. Another use case "Google Scholar" added.

Call to see if there are other issues people are interested in. Kristina says the alternative title - are the ones in the link the only ones that need to be resolved? Seth: Only looked through defaults. That's the full repo. Eli Zoller: Pretty sure it breaks islandora_mirador Kristina: Is this just a matter of changing fields? I'll do it and let somebody test it. Everybody claps for Kristina! Many thanks!

  1. PR Roundup

Everything discussed last week

  1. Islandora Governance Proposal for Feedback - any additional comments before this goes to Leadership? Seth notes he will take a look at revisions. Danny requests access. Kirsta grants it.

  2. Sprint Signup Sheet - Sprint issues voting progress - emerging topics from sprint sign up sheet are default experience/Isle DC changes/Access Control

Decisions:

  • We will talk Access Control next week - bring your research and concerns. Kirsta will send a message out on the listserv so that people who are interested will come.

  • As part of this message, Kirsta will announce the three emerging threads for the sprint, and introduce the first sprint meeting on November 29th, when groups will break up, nominate issues, and we will use these issues to build the sprint board. No sprint discussion on American Thanksgiving, so after next Wednesday we won't discuss again until the start of the sprint.

  1. Kirsta - can I move Github issues to separate repositories during the sprint and create a Github project to bring them together?

People don't seem like they are in objection to this. Kirsta will send out a message on the listserv for feedback and leave it open for comments until November 29th.

  1. Could we make some decisions about the purpose and future of Islandora_Defaults - what is its role in the Islandora 2.0 ecosystem (managing updates) before the sprint?

Danny - Drupal Profile does this. Let's consider dropping Islandora_Defaults. Alex - drawback is that if you have things in Islandora install profiles, you can't install it in a Drupal site. What belongs in a defaults module vs a profile? We might need something to be not just on fresh sites. Kristina - this came up in MIG - the metadata folks don't know install profile from config from composer from etc etc. Somebody gives them a site set up and they see the content type and there's a lot of confusion about whether or not it is required. It sounds like people have based things on it, but are not using it. Seth - tying our own local to Islandora_Defaults didn't work. Steps forward:

  1. Clear documentation about what Islandora_Defaults is supposed to be. Supposed to be like the solr_defaults.

Nat: It's different for a few reasons:

For one, a lot of the functionality that Islandora provides is packaged into Islandora defaults: Almost all the viewers, paged content, search stuff, etc. If you just install the core, you don't have a bunch of stuff.

What about a metadata profile? It would make sense to provide one, but it makes sense that when you've installed, it's yours.

What about breaking up Islandora Defaults? Extracting code - Seth agrees: Independent submodules or other places. Danny chimes in that's an acceptable way of burning defaults - to break it down.

Jordan - echoes Nat's sentiment. We need to decouple things. Most people aren't going to understand the difference and it can't be the install profile.

Danny is pro breaking it all up if people are pushing back on us not doing update hooks.

Kristina - the best thing about the defaults is that it goes into the sandbox and people can play with things. Having a set of things people can play with and experiment with is useful.

Controlled access terms is another candidate for this.

Jordan: Agrees that this would be a good one to break out.

Kristina: Let's do field types.

Seth: No code in defaults. It's a base config that pulls in what people might like.

Nat: One approach is that the content type is a plain content type consisting just of the fields (doesn't prescribe any behaviour at all). Move any viewers related stuff as well as anything that drives behaviour into core and separate modules.

Provide the content type as a default and once you modify it, it's part of your site config.

Move display into one or more separate modules.

Seth will be difficult - to Nat: you guys are doing separate actions for indexing things, but we use contexts for a lot more stuff. Makes sense to have a separate defaults that pulls in a lot of these pieces so it's a lot easier for a site (turn on defaults and then turn off what I don't want).

Kristina - +1 I am endlessly troubled by the mixing of super-important fields that drive SYSTEM BEHAVIOR in with mostly descriptive metadata.

Kirsta - is it as easy now as moving forward with this?

Alex - one under-discussed things is that it's hard to create a field and then write the YAML for this. We should make it easier to do that config in the gui.

Jordan Dukart - that goes for indexing as well.

Kristina - One thing we need as metadata people is a way to share our metadata configurations so we can learn from each other. One thing that Drupal/Islandora could do to help would be to generate a .csv. What if you could push a button and get your YAML in a machine readable format to get an overview of settings. What about using something like this. Field definition APIs. Maybe if you could see other folks update field configs and you could edit that .csv and import the .csv then it would automatically add a field.

Danny - I've pitched that too, it makes sense.

Adam - it would work with plain fields but once we get into entity relationships things get nested and hard to write into a .csv.

Kristina - if you want all the details on your taxonomy, you should be able to click a button and get everything out.

Sarah: Does the Islandora Defaults discussion exist in some place? (The discussions that have happened in the past). Should we draw up use cases around some of the things we've discussed. Does this go out for further discussion?

Danny: was there a google doc? We do that a lot?

Jordan found the doc: https://docs.google.com/document/d/1ilcAqFJmV1tJeLbwUkajdr9I6OBlQ-6JVFMzcPpFPNA/edit

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