/
CCMWG - 06/11/18

Samvera Community Wiki

CCMWG - 06/11/18

Jun 11, 2018

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

  • 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

    • 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