https://emory.zoom.us/j/97449753231?pwd=NXZMcWNoMlFISnhuS2dXWjh2Zys5dz09
Meetings are held every other Tuesday at 8:00 AM PT / 11:00 AM ET / 4:00 PM CET.
List goals for this meeting (e.g., Set design priorities for FY19):
Notetaker?
Discuss challenges to One-off contributions from https://docs.google.com/document/d/16q35KCOH5JOIu_FMxUMgJXz-q9ujy5tjxboJefVx62Y/edit#heading=h.7ftptft88anw
Are there missing challenges not documented?
Solutions: what would reduce/eliminate/mitigate these challenges?
Next steps and action items
Does one-off include bug fixes? Yes, anything that is not part of a specific effort (WG, dev congress, etc)
Thoughts on the listed Time challenges:
Learning curve for those not in the community
communication issues
often the process is creating a fork, making a PR for an unknown person
Who responds? No SLA for first touch. Can fall through the cracks and be addressed weeks later
Requires research, potentially they have no cCLA, there is a long async feedback loop
CLA checker could help with triage
What org are you from, did they sign a iCLA? It takes a lot of time. A week to a month or more.
Time challenges for someone with a CLA already can still be hard because we don’t have the resources for triage of requests. An effective tactic is posting in Slack. Is this described anywhere?
We have the tech call for outstanding PR review. Do things get missed?
Maintenance WG has not had a task for outstanding PRs from outside the WG. Should it be?
It is part of the standing agenda, and it was helpful when it was in the half hour after the call.
How hard is it to find the PRs across the repos?
A dashboard would be helpful for all PRs. Anna will try to bring that up, to see all the PRs from an org in GitHub. https://github.com/pulls?q=is%3Aopen+is%3Apr+user%3Asamvera
Hygiene issues: hard to close stuff out with a lot of items
Only a handful of people feel comfortable doing the review. Doing it in tech call would have a process for others to see the review happen, and what they would need to look for if they were doing it.
How to quality control PR review – is it true that we don’t want just anyone reviewing? Functionally anyone can but they tend to be timid. We don’t have a hierarchy of who can accept it. There isn’t a problem of lots of reviewers. A first pass would be very helpful to the people who would make the final call.
Multiple levels to review – broader set who can do first level review, but if it is changing something functional it swings by a leadership role. Two ways it comes in: bug fixes are easier for others to approve. When functionality comes in, the tech lead has a bigger role in reviewing and determining what goes in core (in Hyrax, there would do that for other major components).
Julie might also look at things that would be new functionality in Hyrax.
Limited set of PR reviewers in the community creates a wait time. We definitely need more reviewers and we’ve not had an issue with quality control.
PR checklist is documented, can we incorporate more: https://samvera.github.io/pr-checklist.html
Can we make a github project board to pull from across repos in the org?
Making sure the PR template in github is up to date and easy to follow
Acceptance notes (see notes in the doc as well)
Lack of designated reviewers
Plugin architecture aspect: is it known and understood how to extend in this manner? Elevating documentation could help with this. To make things shareable you have to hook into Hyrax and also preserve the boundary set by a tech or product lead. Can be hard to get the resources.
Could have specialized owners of specific features such as search builders. Identify tech leads for a specific area: works, collections, etc. Would have to enumerate these things and orient collectively and some could have a functional owner with a name put to it and/or do documentation for that section. This could help with some of the cognitive load of Hyrax.
Could we move to a culture where the tech leads are in the tech call every week. Triaging the open PRs and talking every week. Make this a more central meeting than it has been in the past. Could frame as a six week experiment to build this and then do a retrospective. Same people come every week to the tech call, not reaching a large part of the community. Would like to see it be a more vibrant place. At one time there was a 5 min demo of the code each week to raise awareness. Someone ran a newbie group the half hour before the call to dive into a subject every week. That was excellent. Would need someone to organize and make it happen.
Heather has thought about an office hours, very similar. Heather could do the scheduling and promoting and a tech person would just need to show up for a deep dive scheduled every week.
Skill:
Office hours idea could help with this. A lot of this covered in other sections
Frustration:
Getting reviews working more quickly would help with this.
Can’t underestimate the damage done if someone doesn’t get their PR looked at. A tech call PR review time would help with this. A lot of the items above could reduce this frustration.
Office hours would also help with this. So would the summer dev congress.
Have also seen times when people said thank you for this PR, here is my review, and I’m happy to help move it forward.
Documenting patterns would also help. Someone new to thew community would not know what some things are.
Can ping product owners for PRs related to components
Type /decision to record the decisions you make in this meeting: