Samvera Tech Call 2020-07-01

How to connect: (link will launch Zoom client – if you do not have Zoom, expand the instructions below)

 Click to view telephone/H.323/SIP connection instructions
Meeting ID: 940 3021 4208 One tap mobile Dial by your location Meeting ID: 940 3021 4208 Find your local number: Join by SIP Join by H.323
  • (US West)
  • (US East)
  • (India Mumbai)
  • (India Hyderabad)
  • (EMEA)
  • (Australia)
  • (Brazil)
  • (Canada)
  • (Japan)
Meeting ID: 940 3021 4208

Time: 9:00am PDT / Noon EDT

Moderator: Jeremy Friesen

Notetaker: James Griffin



  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. Remind everyone to sign in on agenda.
    8. Welcome all newcomers!
  2. Agenda (moderator)
    1. Call for new agenda items (moderator)
    2. Deprecation message style guide
      1. Should we make one?
      2. Passive third-person vs. accountable "we"
    3. Normalizing location of CONTRIBUTING document (see related PR for discussion) (Jeremy Friesen )
    4. Samvera help follow-up
      1. Custom renderer is ignored -- what do I need to look for?
    5. Pull request review
      1. (Jeremy Friesen) I want to look at the failing specs
      2. (Jeremy Friesen) I'd like to see if others get these errors locally
      3. (Lynette Rayle) Move valkyrie create strategy to share specs
      4. (Lynette Rayle) Fix comments and one test that was testing the wrong thing
  3. Moderator & notetaker for next time
    1. Moderator: 
    2. Notetaker: 
  4. After call, this week's notetaker should create the agenda for the next call:
    1. Open template agenda titled "Samvera Tech Call 2020-xx-xx"

    2. Click on ... in the top right corner, and select copy.
    3. Popup will open for location. It should contain: 
      1. Space: Samvera
      2. Parent page: 2020
    4. Select copy. New page should be created.
    5. Modify the title to remove "copy of", update it with the next date, add moderator, notetaker, and any carry-over agenda info. Click Publish.
  5. PR Review
    1. Review issues:
    2. PR review coordinator for next time: 


  • Deprecation Message Style
    • Jeremy submitted a PR where a method was deprecated, active voice used, "we will be deprecating"
    • Question: Who is "we"?
    • Passive voice: "Will be deprecated" is used elsewhere, there is a lack of accountability
      • Active voice has more accountability, but perhaps shouldn't be "we"
      • Perhaps "Samvera will deprecate..."
      • Doesn't a deprecation message already give some indication as to where in the code base the message is originating?
        • Yes, usually the line is referenced
      • Some feel as if determining whether "we" is used might not that be that important, the deprecation warning itself is the essential factor
        • Also, ensuring that the line of code where the deprecation message originates should be in place
      • Conclusion: Usage of "We" is inconclusive
  • Renaming GitHub repository `master` branches
    • Connotations of slavery with the usage of `master`
    • Emory is switching to using `main`, Cornell supports this change
    • We should be mindful of links to URLs containing branch names in documentation or elsewhere
    • There should be a time period for when this is occurring
      • We can use this opportunity to then also explain to the community why this change is being introduced
    • Emory: Created a separate "main" branch without deleting "master", and fast-forward pushing commits to "main"
      • git merge --ff-only
      • In the process of issuing pull requests against "main"
      • Still in the process of switching to "main" as the default
      • Will retain "master" for a time period, just to ensure backwards compatibility
    • Samvera should frame the rationale, and then draft a series of action items for the migration plan
    • Gemfile Support
      • Adopters of Gems and forks use `master` against GitHub projects can break when the `master` branch is specified 
        • Also, coordinating builds between repositories which explicitly reference to specific commits on `master` or referencing `master` generally can introduce issues
      • Renaming the git branch `master` is possible
        • But, it might be an easier transition to support two branches for the immediate future
      • Specify a date by which to permanently end support for `master`
        • Offer a README detailing why adopters should not use `master` any longer
      • Nurax Cases
        • There are customizations atop of GitHub `master` branches
        • This could break automated deployments
    • How to determine the new name of the default branch
      • When the initial message is sent to the community, no name should be given
        • `main` and `trunk` have been proposed
        • Perhaps a very short-lived WG could be formed in order to draft a document?
          • This has been successful once before
          • All attendees agreed that this would be good, Jeremy volunteered to investigate what would be necessary
            • The WG, then, would produce the document shared with the community
    • Rachel will investigate the impact that these updates will have on Nurax
  • samvera-tech Group Question
  • Pull Request Review
  • (Postponing the discussion for the until the next call)
  • Next Call
    • Moderator: Jeremy Friesen
    • Notetakers: Tom Johnson
  • Meeting adjourned at 09:37 PDT/12:37 EDT