...
Max Kadel , UNC-CH
Chris Colvard (Indiana University)
you!
...
Faraday 2.0 release
most Samvera gems are restricted to below Faraday 1.0
Lynette upgrading QA to Faraday 2.0
Blacklight also looking to upgrade
another Faraday release might have restored backwards-compatibility
Faraday is middle layer over HTTP libraries, moved connectors out to separate gems but might have changed default back to what it was befroe
Need someone to review this, upgrade to latest Faraday release, and see if anything breaks or if we’re good
just in Hyrax or test other things as well?
LDP and ActiveFedora use this as well
Component Maintenance WG not formed up yet again but there is a Slack channel
Lynette’s understanding, 1.0 had default set and 2.0 doesn’t have a default set
could possibly set default in Hyrax which would also set things for any related gems, so it might just be solved with Hyrax change only (if change is needed)
need to create issue, good for Component Maintenance WG, not sure this is urgent right now
Chris write issue, send through CMWG, maybe work on during Dev Congress
Not a concern for Hyrax release
Proposed iCLA process
Will be discussed at partners meeting this Friday
Heather has been investigated and done some testing of proposed process
Current process is cumbersome, slow, and error prone
Proposed process will have a bot monitoring PRs and automatically let new contributors how to esign e-sign iCLA and send Heather an email
Downside is users who have signed iCLA but haven’t contributed yet will be flagged by the bot
Heather should be able to resolve this or developers can reference list of contributors
List of all contributors with iCLA on file will be in read-only google sheet instead of current wiki page
Question: Could this bot check for two factor auth?
Heather doesn’t think so
Requirement for 2FA needs a larger conversation
Require for at least admin functions?
How would a 2FA requirement affect contributors?
Stale PRs in Hyrax
A number just got marked as stale and will be closed in 2 weeks…do we want to keep any of them open?
Should we review stale PRs at dev congress?
When PRs are closed by stale bot the branch is left so it is easy for the contributor to reopen the PR
Maybe the wait time for marking PRs stale should be increased? Or is stale bot still relevant?
Further discuss at dev congress?
Next week:
Moderator: Heather Greer Klein
Notetaker: Juliet Hardesty