status update for where we are on the Hyrax Roadmap - Hyrax issues review club and back porting and previous solutions
COllections extension work is nearing the end. 2.1 release - Lynette - not a lot of issues (< 30). Get resources on cranking on issues.
Shake the tree for folks who can help resolve issues for 2.1 release. About 1/2 the issues are general Hyrax issues and don't need C.E. knowledge, but Lynette will get people up to speed.
Looking for 1-2 people who can jump on for rest of March to finish up ANALYTICS. Don't have to talk about it now, but get people in touch with Van Tuyl.
Group in responsibility MGMT. Addressing that set of issues - LaRita from Notre Dame is watching that. How roles and groups are managed or not.
Accessibility 360 call. Contracted for an accessibility audit in Hyrax. Write up report of findings, 140 issues to resolve. Indicated that Hyrax is in decent shape, work to be done. Follow up for next steps. GitHub project for accessibility issues, decide method for tackling issues. Not a huge amount of work.
Start building out documentation for how we address accessibility up front.
New life in Bulk Import/ Export/ Edit convo - Tom Johnson put together a working group to hash out requirements. Needed batch functionality.
Swappable back-end/ Valkyrie - Trey led a 3rd dev effort - what does it mean to finish that work? How do we make that happen?
Community exhaustion for dev efforts? Fatigue from CE stuff, analytics has a hard time bringing people in. Guess: Valkyrie work and bulk/ import/ export - maybe summer?
There's continued interest in Vaklyrie in Slack - start soon, plan, line-up resources. Maybe start work in early summer. Lots of work left, get 6-8 week effort spun up. (Justin Coyne was lead on last 2 efforts)
Swappable back-end will be in 3.0 and not before. A migration has to happen.
Big part of ask - good chunk of work - if using Hyrax 2 and Hyrax 3 - data doesn't have to change. Valkyrie adapters - can deal with 2 data.
Hyrax issue review Club: PR reviews after tech call on a weekly basis. That seems like its helping get PRs moving forward. This type of thing might be useful for traiging Hyrax issues. SVT can't do all of it at 20%. Build outa subgroup of SIGAHR to look at new and existing issues on Hyrax, that would be useful.
Vialbilty of having people look at issues - unexpectedly reported vs. big feature efforts -
As far as issue triage - body of volunteers represents diversity of interests - could cover issue triage with the assumption that you could bring in other people to offer opinions about prioritization or labeling or whatnot
Volume of notifications is insane - one person knowing and a group knowing. Smaller group 3-4 people. Hard for one person to read through the issues. Handful of people looking at issues, and handful of people thinking on issues and how they should be prioritized.
Is that a working group as part of the interest group - what's the best thing to do there? Julie - maybe give it a term limit for review group. It's only for 6 months at a time.
The group can be a triage group to send the issues to specialists who can resolve the specific area of trouble.
Define components not just as gems - but things that appear within Hyrax - those could be definied as components as well.
Jess: speaks to anayltics project - transfer of knowledge - group that triages - new people find their sounding board who they can talk to on special issues and a traige group they can talk to in order to get familiar/ find expertise
Small groups - give it a go for a month, meeting periodically.
3 people to be in the review meeting - Steve will drum up help.
Support for Legacy versions of Hyrax - general question of backward compatibility - Tom Johnson working toward 2.0 on something, and it was clear we aren't clear on what we'll support and what we won't.
Mike: the challenge is - the folks most likely to contribute to code bases - they're furthest along and pushing Master Branch forward. Folks who need most backported work or support for older versions - most challenged to contribute to dev cycles.
How much support do people actually want?
Who will do the work? How much support can we provide?
On Avalon, this is an issue as well. We provide a clear migration path from v. to v. If there's a major bug, we will support that back version. Avalon doesn't support more than one version back.
As a version matures - we pin what we're supporting. We're not going to backport to point releases.