Date
2-3PM EST
Call-in Info
BlueJeans: https://bluejeans.com/223781975
Wiki: https://wiki.duraspace.org/pages/viewpage.action?pageId=90976017
Attendees
- Michael Joseph Giarlo (Stanford)
- Collin Brittle (Emory)
- Kevin Musiorski
- Steve Van Tuyl (oregon state university)
- rsteans
- Lynette Rayle (Cornell)
- ajweidner (Houston)
- Brian McBride (University of Utah)
- Chris Colvard (Deactivated) (Indiana University)
- you!
Goals
- Understanding of State of Hyrax Roadmap
- Identification of Possible roles/ outcomes
- Identification of Meeting schedule
Discussion items
Time | Item | Who | Notes |
---|---|---|---|
Start | Status of Hyrax Roadmap and whats next
| ||
Governance Discussion Input - does SIGAHR have specific feedback? | |||
Hyrax issue review club
| |||
Backporting - how far back do we want to support Hyrax? | |||
Towards the End |
Action items
- @
NOTES
Steve - go over agenda
...
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.
Action Items: