| What new skills would be necessary? | What new technology would be necessary? | | If someone could investigate (research, sprint, etc) and report back, they would need to do the following: |
|---|
1 Speed, performance, scale | cloud- based solutions training and upskilling
experiencing developing and using performant and scaled software
benchmarking tools skills (understanding, testing correctly -- easy to get wrong)
test suite skills for benchmarking tooling (what are we measuring, how are these developed and managed)
research and learning is a constant for these new tools in a could environment -- exploring and experimentation mindset vs problem-solving
lots of options and tools all the time
finding the performance balance point | suite of benchmarking tools | supporting experimentation and trying new things
think about the user experience as primary: process to prioritize the user experience
What do we mean by scaling? What are the pain points?
Defining performance for the use case -- hard and a lot of work!
challenging for community development - devs are a step removed. Things are slow sometimes because the skillset to articulate what is needed is missing
data seeds for both functionality testing and performance testing | Notre Dame did a lot of this asset pipeline work in an AWS mindset. I was not part of the development, but it was an AWS first mindset. GitHub - ndlib/marble-blueprints: MARBLE-related The "Infrastructure as Code" repo for all pieces of the Marble project. Will contain CloudFormation Templates, Ansible playbooks, deploy scripts, etc for all components of the new system. Differentiate scale and performance
What are the performance metrics we want? Get feedback on those. Working group could be useful for this.
Fedora tried to develop sample data and recipes -- help us test data that looks like your data |
2 Delivering IIIF solutions: players, tooling. | IIIF training in general
players are implemented in Javascript; typescript and javascript training
formal UX skills for improvement of players | IIIF spec 3 -- making use of clover
Improved implementation and strategy in current IIIF 3.0 consuming applications | If you pick samvera this is the documentation you get -- group to determine this
Recipes Model for the interconnectedness Good communication with the IIIF consortium--maybe some sort of formal communication bridge. | We have a lot of IIIF in labs: do a sweep and evaluate what should come out of labs
Propose best practices for Samvera software (generating or consuming IIIF) |
3 Clear technical strategy for the community. Defining a standards based approach and products. | doing these activities! Defining who were are technologically
should be a checklist for what samvera partners/adopters should work toward to support in standards, and build to that spec model (like the iiif support checklist)
prioritizing development to meet the checklist, and discouraging other features | | formal strategic planning ensuring there is a process by which the full community has an opportunity to provide input training resources | who would be tasked to create the checklist idea? what is the desired outcome of the spec? Marketability -- you get these 5 things; technological appeal of having a clear direction to make the next milestone easier to get to. Having a spec would guide this. Design and implement a technical vision in a working group with the support of partners. Validate that vision with the community. |
4 easy upgrades | What makes software easy to upgrade?
Discernment on what is likely winning strategies of software frameworks and libraries | reliable calendar of EOL notices for software versions (Blacklight, Ruby, etc)
avoiding data migrations; this follows on the idea of meta-modeling (modeling how we model)
deployment tooling for upgrading in-place
Software that can be upgraded in place | Persons of contact for projects outside of Samvera (Ruby, Rails, Blacklight)
Documentation and training materials
James will draft a working group charter
Local customization/individual constraints are a concern | Identify the external projects of which Samvera should be aware
Define roles/responsibilities for contact persons for each external project
Perhaps this is a Working Group? This would ensure that the role for each person of contact can be rotated per WG phase
Active use of the Samvera Community Calendar (or, investigate a new calendar)
Understanding what "easy" means for organizations
We have barriers to folks committing their orgs changes upstream, for ease of upgradability, we must remove that barrier and understand it. |