Attending

Time:12:00PM PDT/03:00PM EDT - 01:00PM PDT/04:00PM EDT

Zoom: https://princeton.zoom.us/j/397525264

Participants

Trey Pendragon (Princeton University Library)
Thomas Johnson (Data Curation Experts)
Benjamin Armintor (Columbia University Libraries)
Noah Botimer (University of Michigan Library)

Agenda

Additional Agenda Items?
Identify priorities
Analyze spreadsheet and order projects by importance.
Scheduling of Sprints?

Notes

Deliverables

Scheduled for 2018
- Deprecate relevant projects from samvera to samvera-deprecated
- Ensure samvera Projects belong there
- Promote samvera-labs
- Respond to security alerts
- Review successes and failures (recharter if appropriate)

Prioritization

How should we handle deprecation?
- Johnson: Reach out to product owners and discuss the possibility of scheduling sprints
- Product Owners should have a model for sprints which allows them to assign work
Asking if we should deprecate
- Do we need to further identify projects which have a Product Owner but don't meet standards
- That's every Gem identified (i. e. none meet the requirements)
  - Maybe some small percentage does (example: hydra-derivatives)
Sprint Structure
- This group should decline to schedule sprints for projects which don't meet the minimum requirements
- Getting all of the projects classified as Core Components up to minimum requirements should be the highest priority
Phase 2
- Pendragon:
- Understood Phase 2 to be less focused upon generating sprints and demand to product owner requests for features
- Instead, getting Core Components up to spec consistently
  - Following this, then scheduling sprints for future features would be possible
- Johnson:
  - Understood Phase 2 to be a more general call for availability for Core Component development sprints
  - Has work ready on Active Fedora, but no mechanism to schedule a sprint using this Working Group
- Botimer:
  - Where there is more ambiguity, push these off to gain more momentum later
- Pendragon:
  - Taking ActiveFedora as an example
    - Cannot perform maintenance as it does not have a code coverage measure for testing
    - Need to address this first (as well as for all Core Components)
- Johnson:
  - Then, an initial sprint should be scheduled with addressing code coverage as the initial tickets for the sprint
  - How would I proceed in doing this?
- Pendragon:
  - Contact product owners instead, and then look to schedule sprints
  - Otherwise, if we wait for product owners to contact us, the work might not be taken
- Armintor:
  - Perhaps start with ActiveFedora, document where we find the gaps, and then proceed to reach out to less related projects?
- Pendragon:
  - Looking at the spreadsheet...ActiveFedora just needs Coveralls (15 minutes)
- Johnson:
  - Assumed that we follow the Product Owner's lead
  - If no one shows up to own it, we propose deprecation at a later date
- Botimer:
  - This could be dangerous...adversarial
  - We've got volunteers for Product Owners
  - But, this becomes a threat, "if you don't ask us", we don't act to assist to these volunteers
- Armintor:
  - Assess what the gaps are in the project
    - Send the report to the Product Owner
  - We are chartered with assessing whether or not a project is supported any longer
- Johnson:
  - We aren't here to deprecate projects
  - We are here to perform maintenance work
  - Not looking to threaten deprecation...but to line up productive work
    - Then punt the question of deprecation down the road
    - Definitely opposed to needless bureaucracy
  - Set up project in GitHub, generate a backlog of issues, and organize a sprint to iterate over those issues in the backlog
- Pendragon:
  - Concerned that we would pick up maintenance issues for projects which don't prioritize making it meet the minimum standards

GitHub Projects

Waffle seems to be comfortable for project management
Pendragon
- Create a Waffle project
- CCMWG label
- Communicate that this exists to the Product Owners
No one objects to this
https://waffle.io/samvera-labs/maintenance
Waffle Labels
- CCMWG, backlog, and ready
- Alternative is to have a Core Components Project in samvera-labs
- There, have a cross-repository Waffle board there
Could do it in the "hydra" Gem
- ...but it does have a Product Owner
Created in samvera-labs
- samvera-labs/maintenance
Johnson needed to leave at 12:35PM PDT/03:35PM EDT
Split Projects up for each of us
- Add to the board, add the necessary labels in the GitHub repository
- Reference the Google Sheet
  - https://docs.google.com/spreadsheets/d/1IICaXpwzxSFPB_G7k4jzUiPMTmT5OulUQKtF0jSYqvM/edit#gid=0
Projects without Product Owners
- om
- jetty-wrapper
- hydra-jetty
- Delay further discussion, but perhaps call for deprecation for these?
hyrax, curation_concerns, sufia
- samvera Repositories should have maintenance plans
- Hyrax has a maintenance plan, but it does not fall upon this WG
- curation_concerns and sufia should be discussed during the next meeting
Sprint availability
- Pendragon will send a Doodle Poll in order to determine the availability of those involved in the WG to dedicate time to sprinting
Homework
- Go through repositories assigned to us
- Review documentation for minimum requirements
  - http://samvera.github.io/samvera_labs.html
- Create issues where there is a gap
- Where coverage is low, create an issue "Is coverage high enough for you to be comfortable?"
- Documentation requirements
  - This WG hasn't evaluated documentation requirements
  - Use requirements (e. g. used in the last 6 months) also will not be considered

Browser not supported