...
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.
Action Items: