/
CCMWG - 06/11/18

CCMWG - 06/11/18

Owned by Trey Pendragon
Last updated: Jun 11, 2018 by James Griffin

Attending

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

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


Participants


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