2026-02-17 Documentation Interest Group meeting notes

Zoom link

Participants

@Sarah Proctor - co-facilitator
@Morgan McKeehan - co-facilitator
@Heather Greer Klein
@Nic Don Stanton-Roark
@Rebekah Kati
@Sudha Anand

Roles

Meeting facilitator: Morgan
Meeting notetaker: Sarah

Action items

Announce a documentation sprint for week of May 18, 2026

@Rebekah Kati - Copy the Confluence page from the community sprint last year in prep for the print in May Documentation Community Sprint Event May 2025

Ensure any accessibility-focused documentation tickets are flagged prior to the community code sprint next month

Ping Nick S to see if more feedback is needed on this ticket:

Admin Sets: Create beginner-friendly graphics to introduce the concept of Admin Sets · Issue #2698 · samvera/hyku

@Rebekah Kati take a look at the draft Hyrax tickets that need to be filled out with actionable items and additional details

@Sarah Proctor flexible metadata documentation needs to move to Hyrax, updated, and have the technical section removed

Morgan - for draft: “assess usability of Flex Metadata Confluence page” → assign to me, review referenced page, and note into draft that we restructured the FM pages with the goal of: make more accessible to users. Determine if there is still a gap in the updated pages, that needs more examples/jargon terms defined to meet the goal of this ticket. Use this draft as a test of gh permissions - check if I can convert it to an issue in a repo, etc.

Goals

Any questions or topics from DocIG participants?
Check in with HGK about possible Doc Sprint this year
Categorizing/prepping tickets in Doc Tasks Board
- Any issues that need coordination/feedback with other groups?
- Questions/blockers:
  - Admin Sets: Create beginner-friendly graphics to introduce the concept of Admin Sets · Issue #2698 · samvera/hyku
- “inProgress” column - check for issues not-assigned to anyone?
- “ready” column - check that all drafts have been converted to issues, assigned to a repo.
- “todo” column - prep tickets and convert to “Ready to work”. Check that tags are assigned. Add clarifying info to description if needed.
  - required tags: Audience, doc-location, SamveraProject
  - optional tags: workflow (IGdiscuss, triage); events (if good for a DocSprint, etc.)

Decisions

Documentation for items in Hyrax and Hyku should be in Hyrax and be linked as needed to the Hyku pages

Discussion notes

Annual Doc Sprint was discussed at Sept.2025 Doc IG mtg – sounded like May 2026 was tentative timeframe. Also wanted to align Doc Sprints with major releases though. Any updates on timing?
- Community code sprint will take place in about 4 weeks with a focus on accessibility features and concerns in Hyrax and Hyku
  - Many interest groups have been talking about this with the accessibility deadline coming up
  - We will need documentation on the new Bulkrax import feature
  - Documentation or QA can be picked up during this time
- This group can pick a couple days to do a documentation sprint
  - Samvera Virtual Connect is in May so we can do one after that so it gets promoted during Connect
Documentation board overview
- Can create views from the labels
- There are quite a few tickets that were created during the making of the new Hyrax documentation hub
  - The tickets need a little more detail and actionable items
Flexible metadata needs to move to Hyrax and have the technical section removed
Q: For modules/functionality that are in both Hyrax and Hyku, do we have a policy/established approach about: is there a “default” location where the documentation for it resides?
- possible/example scenarios to consider:
  - a module is in both Hyrax and Hyku, and it’s not customized in Hyku → documentation for it is in Hyrax. In Hyku docs, for that module, points at the Hyrax doc as record of authority.
  - a module is in both Hyrax and Hyku, and it has addt’l customization in Hyku → documentation for baseline functionality is in Hyrax. In Hyku docs, for that module, points at the Hyrax doc for baseline, and has addt’l info about Hyku customization/divergences.
  - a module is not in Hyrax. It is an addt’l feature that is only in Hyku. → documentation for it is in Hyku only.
- Maybe we could formalize:
  - what we expect as the most likely/common Hyrax/Hyku scenarios (such as the examples above)
  - for the scenarios, outline a recommendation for where the docs should be/general approach, and propose formalizing that as a guideline that we can document and point people to. Maybe put this in a table format? So it’s easy to reference.
  - Goal: provide a general guideline that folks can try to follow when deciding how to structure their overlapping Hyku/Hyrax doc areas.