2018-11-27 Meeting Notes and Agenda

Connect:

Meeting ID: 688 749 301

Phone Dial-in
+1.408.740.7256 (US (San Jose))
+1.888.240.2560 (US Toll Free)
+1.408.317.9253 (US (Primary, San Jose))
Global Numbers: http://bluejeans.com/numbers

Room System

199.48.152.152 or bjn.vc

Attendees:

Regrets:

Rob Kaufman

Agenda:

Discuss white paper and its progress

Minutes:

Jen: Emailed and got a reply from Richard—they have working group/interest group agendas on the docket and will make decisions soon.

White paper progress. Not much progress as of yet.

Mark updates: core components working group was set to re-charter after connect, Ben and Mark have updated the charter and will send it out to interested partners (samvera-tech) shortly for call of participation. Took what was there last cycle and updated it to recharter every six months. Looking at the core components list, make sure it reflects reality, make additions and subtractions, and evaluate anything that has enough tech debt that it requires some community work.

Mark also had a chance to talk with Rosalyn Metz about the Fedora pieces. She's writing some things for the Fedora community docs and will base in the next couple of weeks regarding Fedora text for the white paper.

Ben: we got a release candidate for blacklight 7 out, which addresses breaking api issues. Ben's been doing minor release management. The RC and a compatible version of blacklight-marc are out, and everything will be put out in the next week or so. That should loosen up work plans for some of the other projects. Ben has been trying to reach out as many channels as possible. Ben will pop into some Slack channels and needle specific people.

Steve: Given the representatives on this group, Steve will probably write things that are incorrect about core components, Avalon etc. Steve will throw text in and people can go in and do corrections or add comments. What isn't in the bulleted list is the "roll your own." We should also have text that reach out to people who create bespoke software with our components. Steve isn't sure how to word that, so we could work together to break that section. Want to be sensitive to how things are ordered in the white paper—people may read things into the order in which things are listed. We could have a discussion here or in the comments about the ordering and what that looks like.

Mark: We usually tell people to pick the solution bundle closest to their needs and start there, and do a gap analysis. That's how we walk people through whether to do a bundle, or how bespoke their needs are. One of the scaffolds is to take a bundle and look at it, as a starting point of gap analysis and institutional priorities.

Steve: Does it make sense to order this as core components, working groups (or reverse those), Hyrax, Avalon, then bespoke? As you go up the layers, you may wind up as bespoke, but that may not be where you want to start thinking about stuff.

Mark: Thinking about interest or working groups feeding into solution bundles, and solution bundles being customizable, leading to the components. An issue that comes up is people thinking they need to understand all of the core components before they can start using Samvera, which isn't the case. It's only a small portion of the community which actually creates something completely new from core components. This as something talking to Jonathan's blog post.

Julie: Coming back to who we're writing this for: professionalizing Samvera. We definitely don't want to overcomplicate it.

Nabeela: What does the community offer, and what are the products?

Steve: I'm putting things in the roadmap section that may actually need to go in the strengths section. Getting stuff down and then moving around is primary at the moment.

Nabeela: Going back to the structure—what are we trying to say there?

Jen: Weird to me that Fedora has its own section. Why are we calling Fedora out specifically?

Julie: Think about a section that talks about the underpinnings—we're not just writing all this stuff ourselves, but instead using components outside our community.

Mark: If we change that from Fedora to else; there's Rails, Sol; Fedora surfaced because it's driven more of the discussion and change in the community that Solr has, but we should also mention Blacklight and others. We could expand that section but give some prominence to discussion of Fedora, probably in the historical context.

Julie: We shouldn't fence sit on Fedora or be nervous or lack confidence in what we say about Fedora.

Jen: We can also talk about in the current struggles section the issues with Fedora in the community. Thinking of architecture in the greater community.

Julie: As the community gets bigger, having options, and so having descriptions of the different options (solution bundle, roll your own) can come in.

Mark: We know the tech will change over the time in which we'll be managing the content we have. If we present that we present this as static, it won't be good. Having a mature mechanism for change is a positive thing to put out there.

Julie: We will have a draft by the next meeting.

Mark: On Governance it was broken into smaller groups for drafting, we could take the same approach here with the whitepaper.

Everyone agrees that this is a good idea.

Mark will do current struggles section, Nabeela and Mark will draft out the community section. This will be next week; we could split off and do the same for the other sections.

Steve: Samvera 2019 roadmap still valid?

Julie: It should be more focused on the actual roadmap, and existing text there could be pulled into the products section.

Jen: We could change the heading.

Steve: What roadmap are we talking about specifically?

Julie: I'm only aware of the Hyrax one. We could build a table. The core components group does maintenance, having that fresh. Hyrax and Hyku are building it out... how do we present it?

Steve: Significant overlap in roadmap section between products represented and community sections.

Mark: Other than the interest groups and working groups, in the roadmap it feels like talking about this group being air traffic control, and our role coordinating and saying out loud: Avalon has a roadmap, Hyrax has a roadmap, core components has a maintenance mechanism. Giving people pointers to those things and saying it's a multi-threaded thing, but it doesn't mean that these things don't have roadmaps, but rather that each thing has its own roadmap which are connected to the others.

Steve: If we want to talk about that it's tied together and we can coordinate. The concern is that people don't read this as "Samvera Roadmap."

Julie: Give it a different header, just don't call it "Governance."

Ben: Hyrax has a roadmap and part of it includes Valkyrie. It would be appropriate for us to say, on the roadmap is some assurance that if you work in Avalon and Hyrax, you're not working with fundamentally different way to use your repository backend. As a community, our roadmap should suggest that the other solution bundles are using the same repository remediation. Saying simple "these products both have the same abstraction that they work from"

Steve: Samvera roadmap: and beyond! If folks could pull things out in the from beyond section, I'll have a better idea of what to include.

Julie: Partners vote has gone out on the roadmap council. We're assuming everyone will say yes.

To Dos:

Have a draft done by next meeting

Next Meeting; Dec 11 2018

Facilitator: Mark Bussey

Note taker: Steve Van Tuyl