2021-05-17 Meeting notes
Date
May 17, 2021
https://emory.zoom.us/j/92846796957?pwd=dU5SYjI4QjRQN3JxMkF6SU9Dd3V3QT09
Participants
@Heather Greer Klein
@Lynette Rayle
@Juliet Hardesty
@Jeremy Friesen
@Maria Whitaker
@Maxence Gévaudan
Kevin Kochanski sends regrets
Agenda
Notetaker?
Review https://docs.google.com/document/d/16q35KCOH5JOIu_FMxUMgJXz-q9ujy5tjxboJefVx62Y/edit#heading=h.7ftptft88anw
How do we want to document proposed solutions to address these challenges?
What is our timeline?
Presenting to Board and to Partners
How do we propose addressing the training need?
Summer Dev Congress – planning team?
Next steps and action items
Schedule next meeting
Notes
What training is missing? DCE training was getting Hyrax up and running and discussing common places for doing work in the system
Fundamental problem of learning Rails, and them conceptually about engines. Franmework to understand and then ecosystem with a meta application. Organizationally an application is difficult. Closer with the work on Dassy (sp?). But it is a challenging ask.
From a Community standpoint, what training do we need – need to figure out how to clarify that
Where can we point to resources(ie Rails), and where do we need to focus on training.
DCE training is one thing, training for contributing to the community is another training entirely
Perhaps training on how to push something locally up to the community
Need to clarify CLA process (this is in process, with Heather and the OASIS attorney)
Do we focus on Hyrax, or focus on how to contribute? Abstract how to contribute needs to be integrated.
In France it is difficult to find high level Rails developers – many junior developers. In Rails, you don’t write a lot of code. Have to use retro engineering to see how things work, but many things are black boxes. Very hard to understand where to start.
Can have many kinds of documentation – FAQs would be a good place to start for documentation. Anther kind would be to explain design patterns – why things are done in one way and not another. It is hard to get the explanation. The code is clean but cryptic. Feels weird to ask massive pattern questions in Slack.
Would be helpful to share how to approach a Rails application/Hyrax and how it was developed
This could open training to more people who might be able to contribute
To improve the application we need to know why decisions were made, and those are often opaque because the core did not have that kind of documentation as a focus – the deliverable was the focus, but not documenting decisions.
Anything that helps the wayfinding would be great. We need to sustain the effort tamsin has had for preventing problems from spinning out.
Joining the community to contribute
Easing triage – sharing the burden of triage.
We’re in the best place we’ve ever been, but also at a critical, delicate place as to who in the community can help with this.
There is a tendency to hire senior devs instead of building the pool with junior devs who need to orient to this reality. When you hire devs, what training to you have for those new to the stack, new to community code?
Implementation solution – office hours, one hour a week for a contributor who can talk about how to triage, and others can document it, vet it, promote it into our ecosystem.
After each tech call is an office hour to help with debugging, triage, with a request to document solutions for sharing
Combine the dev congress with the hyrax maintenance working group – anyone can join and get up to speed on the community process. dev congress wrapper on the maintenance wg. Someone would be in charge of orientating, capturing the needs of the attendees. Facilitated meeting where those who are new can share their issues too.
Having a cohort who all goes through training together is very helpful.
Jeremy can be a facilitator.
we should do community training every 6 months as the first week of the WG kickoff, and iterate needs from it. Reliable schedule and access to very knowledgable community members.