Samvera Tech Call 2018-02-14

How to connect: https://psu.zoom.us/j/613720745 (link will launch Zoom client – if you do not have Zoom, expand the instructions below)

Time: 9:00am PDT / Noon EDT

Moderator: Jim Coble

Notetaker: LaRita Robinson

Attendees:

• Jim Coble (Duke University)
• LaRita Robinson (Notre Dame)
• Critchlow, Matthew (UC San Diego)
• Steve Van Tuyl (oregon state)
• Chris Diaz (Northwestern)
• Jennifer Lindner (DCE)
• James Griffin (Princeton University Library)
• Thomas Scherz (Cincinnati)
• Chris Colvard (Deactivated) (Indiana University)
• Lynette Rayle (Cornell)
• jrudder (UNC-Chapel Hill)
• Andrew Myers (WGBH)
• Jacob Reed
• Seth A Johnson (UMich)
• Conor?
• Kevin Musiorski (AIC)

Agenda

1. Roll call by timezone per following order - ensure notetaker is present (moderator)

   1. folks outside North and South America

   2. Eastern timezone

   3. Central timezone

   4. Mountain timezone

   5. Pacific timezone

   6. folks who were missed or who dialed in during roll call

   7. Welcome all newcomers!
2. Agenda (moderator)
   1. Call for new agenda items (moderator)
   2. Track progress on Hyrax PR resolution strategies (follow-up from previous week's call)
   3. Allow members to create repositories in samvera-labs 
      1. "Allow members to create repositories for this organization" is unchecked.  Can we check it?
   4. Long-running feature branches (Steve Van Tuyl)
      
      1. Where should analytics work be done?
      2. Future large feature development
   5. Update on Hyrax 2.1.0 release ( jrudder ) - Sign up to help with QA and bug fixes at...  Hyrax 2.1.0 - QA and Release
   6. Questioning Authority - bug fix PR #159 approval and release of 2.0.1 (Lynette Rayle)
      
   7. Hydra-works - release 0.17.0? ([~cjcolvar] on behalf of Noah Botimer)
   8. Capybara 2.18.0 causing errors in Travis - problems with pin (Lynette Rayle)
      
   9. add agenda item here
3. Notetaker and moderator for next time
   
   1. Notes: James Griffin
   2. Moderate: Steve Van Tuyl
4. After call, this week's notetaker should create the agenda for the next call.
5. After call, discussion on reviewing PRs and initial look at open PRs

Notes

• Follow-up on Hyrax PR resolution strategies
  • Chris Colvard sent an email to the tech list regarding the code reviewer's list, but got no response. Anyone wanting to be part of that list should add themselves or request to be added. 
  • Will discuss after the tech call, and will stay on line after with anyone interested to do a first time grooming of PR's.
  • Steve Van Tuyl commented that we may want to consider a similar process to groom issues as well.
• Allowing all members to create repositories in samvera-labs
  • This was discussed on slack last week. The point is to allow members to create new repositories at will. Can we check the option to allow anyone to create?
  • Lynette questioned whether there is a downside to this, and Drew mentioned maintenance issues - "when to retire". 
  • Drew recommended an auto-move to deprecated side if nothing is done in x amount of time, as a back and forth communication takes effort when someone is unreachable. Steve agreed that it makes sense to check the box, AND to create a process regarding retiring.
  • Chris Colvard suggested that this should be discussed within the components working group, and James Griffin agreed to bring it to them at the meeting next week. James stated that the group is still determining what is going to be needed from each product owner, so there are many repositories and labs to discuss with the community (i.e. life cycle, should it be deprecated, etc?). He agreed that the working group can decide the process for the samvera-labs space as well.
  • Action Item: Drew checked the box immediately after today's tech call, and James James Griffin will follow-up in the working group regarding the deprecation process. 
• Long running feature branches
  • Steve: The analytics working group has started their development effort, and one big questions is how to avoid a long-running feature branch, since it has been stated that this is something we want to avoid? Since we are in the middle of the testing process for Collection Extensions, there may be some interaction between. How do we work through Analytics during the CE release process? What does "long-running feature-branch" mean, and when is too long for people to be comfortable with it? 
  • Lynette commented that one of the challenges is that we release off of master. If we stay in the process where master is the release branch, then until we cut the release, nothing should go in master that isn't intended in that release. If it's not part of the upcoming release, it must be on a feature branch until the release occurs.  Another option would be if we had a release branch with testing and bug fixing on that branch.
  • Steve commented that a lot of the current work is back-endy and not exposed because it is off by default via a feature flipper. Do we not want anything in master, or is it ok to put it in master if we are willing to test against it.
  • Lynette asked if we want it in the next release? That is the bar that must be in use since we are working on the QA process for release. Is it at a point where it can go into master and not extend the time to release? This is the general question regarding feature branches, and the reason CE ended up in a feature branch... because we wanted a release prior to the expected feature release. Should Analytics be in 2.1? Will it affect the release dates? In general, feature branches should be merged as soon as possible due to the overhead to keep them in synch with master.
  • Jen Lindner commented that she likes the idea of release branches, as it keeps the focus on master and the focus on release separate. She also wondered about what we can do regarding processes to allow small commits sooner (flippable config would allow the ability to add features but keep them turned off). This would help keep things stable when we don't know how long something will take, but allow it to release back to master. We need to define a really good process to insure that it is stable no matter what, and work using that process going forward.
  • Drew asked if using git flow would solve any of this, as it has a process regarding long-running features. He commented that we had talked of using this before but rejected it... maybe due to extra learning time? But if we need a pattern for release branches, that might solve it.
  • Jim Coble said they use git flow and gave +1 on considering it.
  • Steve - Analytics group needs to figure out what to do now, and we need to sort out a process for going forward as well. Should we spin off a group?
  • Lynette strongly supported a short-running working group to decide on a process, update documentation and educate the community.
  • Action Item:  Jen Lindner Jennifer Lindner will take on the organization of a short-running working group.
• Update on Hyrax 2.1.0 release
  • The current master branch is on Nurax, doing preliminary tests for user acceptance testing. This is in prep for a larger testing effort where they will be looking for help with bug fixes. Julie will be attending calls to give updates.
  • The release includes Collection Extensions, new UI, IIIF universal viewer, browse everything.
  • Action Item: signup link to help with QA and bug fixes: Hyrax 2.1.0 - QA and Release
• Questioning Authority PR and release
  • Lynette Lynette Rayle will release version 2.0.1 following approval of a bug fix PR. No objections were raised to an immediate release.
• Hydra-Works release
  • A bug fix PR has been merged. Noah Botimer wants the release, but doesn't have authority to do it.  No objections were raised, so Chris Colvard Chris Colvard (Deactivated) will do the release.
• Capybara issues
  • Capybara 2.18.0 is causing errors in Travis, and Lynette has not been able to get the pin to 2.17 to work. Anyone who can help track down the problem should discuss it in dev channel.
• Post-call PR reviewing discussion and initial look at open PRs
  • Reviewed hydra-code-reviewers github team
  • How to determine who should review?
    • Look at gitblame to determine who knows that part of the code best to assign a reviewer?
      • Need to make sure this doesn't call out same people all of the time  (specifically those who aren't available to do PR reviews right now)
    • Maybe some kind of rotation system?
  • Standing time for group PR reviewing can be used for education of those wanting to help review
  • Good to have more help reviewing but also good for those with deep knowledge of code to do reviews
  • Would be good to have checklist for PR reviewing.  Maybe a template?
    • Work started on PR checklist for use when submitting or reviewing: https://github.com/samvera/samvera.github.io/pull/198
  • Outside of group PR reviewing time those wanting to review but unsure could pair up as PR review buddies
  • Need to keep an eye out for backwards compatibility
  • Started reviewing PRs skipping those in 2017 since all of them are waiting for changes or WIP
  • Chris Colvard (Deactivated) will look through 2017 and ping appropriate people to check on their status
  • Looked through pretty much all of the 2018 PRs
  • Flagged #2641 as a good PR to review next time if not reviewed before then