 It's time to get started. I'm Cliff Lynch. I'm the director of the Coalition for Networked Information and I welcome you to another project briefing session that's part of the spring 2020 CNI virtual meeting which will be running until the end of May. Today we have two presenters, Tim Marconi and Chrissy Rissmeyer. Tim is from UC San Diego and Chrissy is from the University of California Santa Barbara and they will be giving us a presentation on a project called Project Surfliner which is a really quite unusual and deep collaboration between the two organizations centered around work with Sam Vera and they'll fill you in on all the details of that. After the two talks, Diane Goldenberg Hart will come, will materialize and will moderate a question and answer session with our two speakers. There is a chat box and we'll be posting a couple of URLs out to that that may be helpful and you're also free to use the chat box of course. There's also a Q&A tool at the bottom of your screen and we'd invite you to use that to pose questions. Feel free to enter questions using that Q&A tool at any point during the presentation when those questions occur to you and Diane will come and moderate them and we'll try and answer them all at the end of the presentation. With that I'll just thank you for joining us today and I want to thank Tim and Chrissy for contributing their insights in this project briefing and with that over to you Tim. Okay thank you Cliff and a big thanks to CNI for putting this together virtually. It has been amazing to have access to the recordings as well as just be able to see so much more content than we could normally if it was trying to go in that day and a half so thank you for making it and done so quickly and gracefully so thanks to CNI on that. All right thank you for the introduction so one more time. My name is Tim Marconi I'm from the UC San Diego Library and I'm the Director of Technology and Digital Experience. And I'm Chrissy Rissmeyer from the UC Santa Barber Library and I'm the Director of Digital Library Development. Excellent. Today we're going to talk about Project Surfliner and Every Great Project has an origin story and that is where we'd like to start today. We'll then discuss how we work together a few DevOps practices and we'll follow that up with what we've learned so far. So what is Project Surfliner? Project Surfliner is a collaborative project UC San Diego and UC Santa Barber libraries to create our next generation San Vera based digital library products. The collaboration has been named Project Surfliner after the Amtrak route that links our two campuses together. If you aren't familiar with it, San Vera, formerly Hydra is a grassroots open source community of library and cultural heritage professionals who've been working together over the past 10 years to create digital repository solutions. San Vera software is based around an open source framework that generally combines four major components Fedora, Solar, Blacklight and San Vera Ruby Gems. Both UC San Diego and UC Santa Barbara are San Vera partner institutions. Sticking with the train analogy here this project got started because both of our engines were stuck at our respective stations. We had the engineers and we had an idea of where we wanted to go but we didn't want to take the wrong tracks. It was easier to do nothing than pick the wrong direction. So we started some informal conversations. We did some collective research and found that many of our other colleagues were in the same situation. So to minimize our risk and to maximize the benefit for the University of California, we decided to go together. This slide has obviously some links that I'm not going to click into. You'll have access to the slides via the portal and all these are just articles that helped us shape our vision. A document was created and shared proposing a UC centric collaborative project with San Diego and Santa Barbara to start. When successful, it could expand to other campuses in the system. The document is shared here if you're interested. We talk about risks in that document. My favorite line is doing nothing is our biggest risk. Something better is always on the horizon. We can build something now and pivot in the future if it makes sense at that point. Shortly after our way forward document was agreed upon we had our first project surfliner in person meeting and the buzz around the room was this new fancy project and what it was and how it was going to be and what it was going to be. The first order of business in that meeting was clarifying to all of our wonderful colleagues in the room that the project was not a product. Surfliner would never be done. More importantly, project surfliner is a collaboration effort. It is building and leveraging the strengths and experiences of the different campuses to focus on shared concepts and products. The project incorporates the San Berra community where it makes sense including core components but will not be defined by what the community at large develops. Well, what does make this different? We have been trying to approach the collaboration in a thoughtful manner. Mindful that what we are developing might be of interest to other folks within the UC system or within the larger San Berra and library community. So keeping that in mind, we have come up with a couple of general approaches to help guide this collaboration. The first is the idea of shared code separate installations. Ideally, this means that each campus does not have to maintain their own forks of the code. This is currently a widespread problem within the San Berra community. Rather, we truly want to have a shared code base that each campus is using for their own standalone systems. This means that we are doing a lot of work up front to make it easy for each campus to deploy on their own infrastructure without needing local code changes or to separately maintain that code. The code can be pristine, but if another campus can't deploy it in their own environment, it is useless within the surfliner context. We also know that each campus has unique needs, so rather than trying to design a single monolithic stack, we're working to develop a suite of products that are designed to work together, but can be mixed and matched based on an individual campus need. Finally, we want to be transparent with our work, so we've adopted a strategy of open communication. In addition to a project blog, all of the product documentation, code, sprint review, sprint review recordings, etc., it's all open to anyone who's interested in learning more. We're working to be totally open about our failures, in addition to our successes. That's our origin story, and I'm going to pass this on to Chrissy to tell us more about how we work together as a team. Thanks, Tim. So when you consider how we work together as people, it's important to remember that surfliner is a cross-campus and remote first by design. We don't divide if the products develop them separately and then share the results with each other. Every product that we work on includes team members from each campus, ideally with cross-campus leadership. This has helped us in several ways. The first is avoiding local bias and development decisions. For example, if both the product donor and technical leads for a particular product were from UCSB, we might unintentionally prioritize the development in such a way that benefits us more. It also helps avoid accidentally excluding team members at other campuses because of conversations happening among co-workers who regularly work together. We don't want water cooler conversations to influence development decisions. As Tim mentioned, we have worked to adopt an open communication strategy. Coming from two campuses, we have a lot of stakeholders and wanted to make sure that everyone who is interested in knowing what we were doing, when we were doing it, and more importantly, why we weren't doing something, could find out. We have tried to build that into the way that we work together. For example, our sprint reviews are publicly available and we try to hold all of our Slack conversations in our Surfliner channel, which is open to any member of the UC community who wants to join. We have also created a communication channels page on our blog that points people to our GitLab so that interested folks can find out the status of any work at any time. From the beginning, we recognized that for the project to succeed, we needed to develop a strong framework for how we work together, including good collaborative remote work practices. This has helped us to build a strong working relationship through the collaboration and ensures that the needs of individual campus stakeholders are being met by our product designs. We don't just want to leverage the strengths and experiences of each campus, but also want to continue to build individual team knowledge and capacity at each campus. At an early Surfliner planning meeting, we developed a sprint framework for the collaboration during inspiration from agile and scrum methodologies. This framework includes clearly defined roles in sprint cycles. Because we have multiple products being developed as part of the collaboration, we identified two distinct types of teams which meet on a regular basis as part of our ongoing work. Product teams are only those people working on a given product where the project team includes all the team members working on any Surfliner project. Every Surfliner product team follows the same overall philosophy and methodology. This helps team members more easily transition between working on different products. Each product team includes a product owner who represents the user community and is responsible for working with stakeholders to determine what features will be in each product release and also a tech lead who is responsible for the technical decision-making on that product. Tech leads also provide facilitation and direction to guide development and architectural decisions. Ideally, but not always in practice, the product owner and the tech lead come from different campuses. Product teams also include the developers who build and create the applications. Whenever possible, developers only participate as part of one product team during any given sprint in order to minimize context switching. These first three roles are involved with the project on a daily basis when on sprint. Product teams also include domain or subject experts who are authorities in a particular area, for example metadata to a spatial or operation specialist or accessibility experts. These folks work alongside the developers on the team and depending on the product may be involved daily or pulled in only as needed. Stakeholders are responsible for informing the decisions that the product teams make and have specific knowledge and influence that help the product. Stakeholders include user advocates, staff, administration, faculty, researchers, etc. and are engaged on a regular but not daily basis. While on sprint, core stakeholders are invited to participate in the sprint review meetings that happen every two weeks to provide iterative feedback to the team about their work. At the project level, we have project champions who are those higher level administrators who help with resourcing, advocacy, and clearing major blockers. This is in addition to our respective university librarians who are the official project sponsors and definitely helped pave the way for the collaboration to get started. Surfliner Development follows two-week sprint cycles that include both Santa Barbara and San Diego team members for all products. In the first year of the collaboration, we experimented with working in dedicated work cycles and in ongoing sprints. It turned out that for us, ongoing sprints was a disaster. As I talk about more later, scheduling and calendaring has been one of our biggest challenges working together, which probably isn't surprising to anyone who has tried to schedule a meeting for more than a few people. So starting in 2020, we have settled on a 60-day on-off work cycles, meaning that we're currently working together approximately six months a year. During every two-week sprint, each product team holds their own sprint planning at the beginning to negotiate and select tickets and then their own sprint review and demo at the end to show what the team has accomplished for stakeholders. The sprint reviews are recorded and shared on our blog, so stakeholders who can't attend the meetings can stay up to date. Each team is also responsible for scheduling their own backlog refinements as needed prior to sprint planning to refine and prioritize tickets. Daily stand-ups and retrospectives are held as project-wide meetings. In daily stand-up, the project team as a whole meets briefly to discuss ongoing work in blockers. Given our developmental methodology and shared monorepo, this has been an effective way at resolving issues as they arrive. The whole project team also participates in a retrospective on the last day of each sprint to discuss how things went and what to change for future sprints. Another really important aspect of how we work together to build individual team knowledge and capacities through pair programming. If you aren't familiar with it, pair programming is an agile technique in which two programmers work together, usually at one workstation. Usually one is the driver who actively codes and the other person is the navigator who reviews the code and then they switch roles frequently. The navigator is also in charge of looking out for future problems that might come up from the code in doing something a certain way and looking for ways the code might be improved. Whenever possible, we encourage cross-campus pairing as this also helps team members build individual relationships with each other. I think that because we were collaborating with another campus, we were hyper aware of the need for inclusive remote work practices. During the project's first work cycle, we had team members located both on and off site in Santa Barbara and San Diego, but also in Los Angeles, Portland, Oregon, Seattle, and Bethel, Ohio. Some team members were full-time remote throughout the project, others were primarily remote but still live locally, so others were temporarily remote for only parts of the project. But even if all of our respective team members worked on-site at our respective campuses, they would still be remote from each other. This was such an important takeaway for me. Once one member of a team is remote, essentially your whole team is remote, and that means that you need to change the work the way you work together as a team. I know that right now we are in a time where most if not all of us are working remotely. However, as members of your teams begin to slowly transition back to the workplace, some of these practices may be especially useful. First, surfliner, and now for my team at UCSB, this means a couple of concrete things in practice. The first is we use agreed upon communication channels and encourage surfacing important conversations to those channels so that all team members can see and participate. We also feel really strongly that good documentation is a crucial tool for inclusion, both in our code and to document when and why decisions are made. This extends to recording important meetings and of course our sprint reviews. We also do our best to avoid what I call conference room Zoom calls. If you've ever been the one person calling into an in-person meeting, you can know how tough it can be to fully participate. You miss facial expressions and it can be really difficult to interrupt the flow of conversation if you have a point to make. If one person is on Zoom, then if possible, everyone should call in via Zoom. But this does mean that in practice I frequently participate in Zoom meetings with members of my development team sitting 10 feet away, which is admittedly a little awkward. This slide may also represent much of your daily work toolkit now. Things have definitely changed for all of our lives since we proposed this talk. However, I thought it would still be helpful to run briefly through the tools that we found most useful for remote work in surfliner. Zoom and Slack form the backbone of our day-to-day interactions, providing voice and video calls for synchronous communication and texts for near synchronous day-to-day chatter. For Slack, we use the UC Tech Slack team. This makes our chat highly visible to internal stakeholders as well as to prospective collaborators around the University of California system. We have a shared Google Drive that we use for collaborative document editing and use it for meeting notes, reports, and white papers, and also slide decks like this one. GitLab supports most aspects of the day-to-day technical work, including ticketing and campin boards for products, version control, development lifecycle and code review, and CI CD pipelines. We chose GitLab because it provided a comprehensive DevOps platform for the team. But probably the team's overall favorite discovery is a platform called Retrium, which is what we use to do our retrospectives remotely. If anyone has worked on an agile team, retrospectives are usually done in a conference room, and there's a stack of post-it notes. People take a moment without the bias of anyone else's opinions to write down responses to whatever topic the person leading the retro put forth to discuss, like what worked well during the sprint, what didn't, or what you have learned. Finding a replacement for an in-person retro that we could do effectively online seemed impossible. But fortunately, a team member at UCSD discovered Retrium, which does this really, really well. It can be super tempting to skip retros when you're working on a team, but I can't tell you enough how important retros have been to Surfliner. They really enhanced the team's experience by being able to act on problems that came up in a past sprint immediately. And because participants are able to share feedback anonymously, it encouraged folks who are less likely to speak up in other settings to provide their feedback. Much of our daily practices in Surfliner came out of our retrospectives. So for example, in daily stand-ups, we now have a volunteer who always shares the board in Zoom, and team members use ticket numbers when sharing updates. We always end our DSUs with a board check and a check of the merge request to see if any work is waiting to be reviewed. As successful as our remote collaboration has been, we do still find it incredibly useful whenever possible to hold quarterly in-person meetings. These meetings have been really useful in strategic planning, determining next steps, and building team cohesion. As much as possible, we should try to center these in-person gatherings around something the team members might already be traveling to, such as Simvir Connect or UC Tech to keep down travel costs. So this is how we've been working together, and now I'm going to pass it back on over to Tim to talk about our DevOps practices. Excellent. Thank you, Chrissy. In the interest of time, I'm going to move through these DevOps slides rather quickly, as there are a ton of rabbit holes. We could go down. So please consider this a high-level overview. We're happy to answer any questions in Q&A, or if it gets down further technical, I might need to direct you towards our team. So DevOps is a culture shift. I really love this quote by Jez Humble, who wrote the DevOps handbook with Jean Kim. And on that note, if you haven't had a chance to read the Phoenix project and the Unicorn project, I strongly recommend it. It really does a good job. Of describing DevOps as a culture, as well as incorporating it into kind of from the IT side of things. They're good books. DevOps can enlist at all kinds of different reactions in 2020. Some feel like it's still a horrible buzzword that lacks real meaning. Some people think it should be in all the titles, and that if you have a development and an operations team that you're living in the distant past. So it makes sense that DevOps has a different meaning depending on your organization and where you are along the continuum. I come from an operations background, serving as a sysadmin for many years before getting into management. I supported Hyzer applications previously and had little to no idea what we were deploying. Simply, what was required from the build procedures and that the development team gave us. Given the proverbial code over the wall scenario, it isn't a surprise that our initial builds had difficulty scaling in production as our ops team had very little interest or buy-in for what development was giving us. Project surfliner needed to be different. Each library in the UC has very different staffing. The technology on some campuses is centralized in a campus IT shop. Some libraries had developers, while some others have one or two do-it-all technology folks. We didn't want to point at a code repository and say, there's the open source code. We documented as well as we could. Good luck. We wanted to make a design that could incorporate limited ops or dev with deployment options that could go in the cloud on premise or a mix of both depending on the solution they needed to solve. Wanted to look at the shared infrastructure, where it made sense. Make sure everyone could operate in their silos if they preferred. The best of both worlds, which comes back to development and operations together, DevOps. Recognizing that each have important jobs and that their identity isn't being taken away. We did this by making some difficult design decisions early on. One of our earliest design decisions was to go with the single mono code repository, also known as we'll continue to refer to as a mono repo, which is a unique aspect of this project and the thing that stops most folks in their tracks because it is very different than how the open source community does their development. But it has worked really well for us so far. Mono repos are common in big companies like Google, Twitter, Facebook, and other tech giants because they need to move quickly and updating a bunch of individual dependencies creates more technical debt and unplanned work than simply adhering to a shared practice. We follow 12 factor methodology, which a quick overview means we build one application and deploy it to many environments. We build applications for modern cloud deployments. We build applications that can be deployed continuously. We build applications that can scale. 12 factor means clean separation of the application from its environment. Environments may vary between development, staging, and production, but also between campuses. We want to know that we can deploy our applications anywhere. Christy already mentioned our agile processes and we have a bit more of that in our further section. We also build code review into our processes as a best practice. It is proving very beneficial along with paired programming as mentorship and learning opportunities in new staff onboarding. Because we wanted to make everything super hard, both teams left the comfort of their respective GitHub repositories and adopted GitLab from the beginning simply because of their advanced auto DevOps features. If we stayed with GitHub, we would need to introduce another piece of complexity for CI CD like CircleCI or one of Jenkins, one of the many other products that exist out there. GitLab had the tooling that we needed, but it did mean leaving the comfort of GitHub, which we are all very familiar with and still use to this day in different scenarios. For us, CI is a practice we adhere to. We keep branches short, lived, and up to date. This allows us to move the mainline rapidly and bring developers up to speed on it quickly. For continuous delivery, we deploy to multiple environments. Both campuses are using Rancher and EKS standardizing on Helm charts in Chart Museum. I'm going to apologize to everyone that felt like I spoke a different language the last couple of slides. DevOps relies on a lot of different products, the names of which can be more confusing than the products and orchestration layers themselves. The good news is I'm passing this back to Christy for what we learned. Thanks, Tim. Just so that you don't get the impression that all of this was super easy, we definitely had some challenges along the way. So many challenges. It has been wonderful working with the team at UTSD, but throughout the project, the absolute hardest challenge has definitely been calendaring. In addition to just the sheer logistic challenge of scheduling lots of people at two campuses, we also had some really specific problems. One of the biggest causes of all of this is that our campuses use different calendaring platforms, Google and Outlook, which, surprise, don't always work well together. Team members at different campuses couldn't see each other's availability without jumping through major hoops, canceled events didn't get deleted, and updates to events didn't make changes. It was and still is an ongoing technological headache. We also don't have a project manager, so scheduling all of these meetings isn't really part of anyone's overall responsibility. In our first work cycle, the two product owners took on the work of calendaring, which worked okay, except for we did it in different ways. One team had a set schedule in advance, the other was more ad hoc, different team members had different expectations, that led to miscommunications, and it was all kind of a mess. Ultimately, we figured it out for that work cycle, but once we started new sprints, calendaring continued to be a problem, and then we made it even worse for ourselves. We decided to try out working together in a series of ongoing sprints instead of a dedicated work cycle. We're just some teams work together during a given time period, and then as the project got more complex, more products, more product owners, more tech leads, we discovered that some of the sprint meetings weren't being scheduled. It became pretty apparent how scheduling had happened in the first work cycle, wasn't really visible to the rest of the team. The original product owners had done the work so that it would get done, but we didn't really share that this was additional work that had been taken on top of our official PO responsibilities. And this became very, very clear when one of our new product owners asked, why hasn't anyone been scheduling demos or retrospectives for my team? Which this leads me to our next challenge, onboarding. We totally failed at this. Following our first successful work cycle, we spun up two new product teams. The tech leads and developers had worked on the first work cycle, but the product owners were both new. We had tons of documentation and sent them to two days of formal product owner training, but then never really watched them through helping a PO worked within the surfliner framework as opposed to the peer agile scrum that they had learned in training. But to give another shout out to the value of retros, again, all of this came out in a retro. We ended up addressing both of these challenges in several ways. We clarified for the project team who is responsible for calendaring what meetings. So now team meetings, stand-ups and retros are at set times every work cycle, and it's now the responsibility of individual team members to add those to their calendars. We also explicitly made the product owners responsible for their individual team meetings and decided that dedicated work cycles were a better fit for the way we worked together. Finally, we developed a checklist for onboarding future product owners. Ones for other roles are also in development to help ensure that we don't miscommunicate, miscommunicating these types of crucial information again. The project came together sort of eerily fast, and I think because of this, we expected the team to jump into working together. I think a lot of us forgot that it takes a while to build trust. Some of us have been working together in the open source community for quite a while, but really missed that not all of our team members had worked together that often. For the product teams, this meant that they went easy on each other when reviewing each other's code during merge requests and didn't speak up when they had questions. We have worked to resolve this in several ways, encouraging pair programming among team members, calling out merge requests daily in stand-up, providing guidance on how to provide constructive and kind code reviews, and talking about this awkwardness and retros. And speaking of retros, we sent all of our product owners to formal training, and most of our development team members had some kind of scrum or agile backgrounds. But guess what we forgot? No one else had any agile experience. None of our stakeholders and definitely none of the subject matter experts who are actually participating in the product teams. So that was a big flop. We learned that moving forward, we need to make sure that everyone involved in the project understands at least the basic principles and vocabularies of how we work together. Like Tim mentioned, we ended up choosing GitLab because it provided a comprehensive DevOps platform. However, we really underestimated the time it would take for the development team to transition to working in the new development platform. We also had, and truthfully, continue to have issues with our GitLab licensing. The short version of the story is that early on, our free trial with lots of features ran out before our licensing negotiations were complete. This ended up causing some major problems because our deployment infrastructure relied on features we no longer had access to. Fortunately, our developers have been able to implement a workaround, but we all spent way too many hours trying to resolve these issues. We also had several challenges related to communication. While open communication is one of our principles, we learned that there is such thing as overcommunication. Several months in, we received feedback that stakeholders and subject matter experts didn't know what meetings were important, and they got too many infights and too many emails. Following that feedback, we tried to clarify whose attendance was required and optional during sprint meetings. This way, we're not excluding folks, but they know when they can opt out. We also stopped holding a weekly public stand up because team members and stakeholders alike felt it didn't provide additional value over what they could learn via other channels. The transparency aspect of our communication strategy will always be challenging because transparency can be super scary, and the things that you're bad at, everyone knows what you're bad at by the end of the project. We also found that communicating openly is a really great way of getting attention, and that gets people interested in participating. I would argue that this is a reason people hide their work from the larger community until it's complete. You're working on something cool and then someone else wants to join, but you feel that getting them up to speed or incorporating their criteria for a product might slow you down, which is completely understandable. So how did we handle it in Surfliner? We decided early on to limit the people in the sprints and the product planning sessions to the teams that were actually contributing resources immediately, which for us was UCSD and UCSB. But we also did a ton of information sessions. If someone from another campus was interested in joining, we wanted to be upfront and honest about what we were doing and how. We also decided early on to create a matrix of what participation meant and what the expectation from our end and their end for being part of the collaboration was. This took a lot of pressure off of us and off the other UC campuses who wanted to stay in the loop about what we were doing, but weren't at a point where they were ready to commit resources. But despite all of these challenges, the impacts of the collaboration have been more than worth it. I know we haven't really talked about any of the products we're developing, but they are of course a major outcome of the collaboration. So far, we have both successfully put our exhibits platform Starlight into production at both campuses and have several additional products coming soon, including a geospatial platform shoreline, a shared linked data authority platform LARC, and a staff-facing digital objects management platform Comet. And yes, we do name all of our products after historic California trains. I also feel like some of the more idealistic benefits of the collaboration have become reality, but UCSB and UCSD are in similar situations. We have significant legacy infrastructure, which requires maintenance and relatively small development teams. However, the collaboration has increased our capacity to innovate and make progress towards our next generation digital library platforms. When we are on work cycle, we effectively double each of our team sizes. Over time, as each of us is able to slowly replace portions of our legacy systems with surflander developed infrastructure, that capacity to innovate should hopefully increase. Knowledge sharing among individuals on the teams has had a major impact on our overall success. Neither campus needs to be the expert in all the things, but we are able to leverage those strengths that do exist. For example, UCSB has more expertise in working with geospatial materials, so we took the lead on the geospatial product, whereas UCSD has a really strong operations unit, which UCSB in turn has been able to benefit from. Beyond just sharing knowledge with each other, we are also learning new skills as part of the collaboration, which in turn have also improved our local practice. Our local teams have been able to apply this knowledge to improve our existing infrastructure. We really have been able to build and leverage the strengths and experiences of both of our campuses. And finally, while this has been immediately difficult at times to balance our local work with our surflander work, even when we aren't working together, the lessons we learned and the practices we have developed have resulted in lasting cultural shifts for our local teams. Speaking now from the UCSB perspective, our development team enjoyed working in the surflander agile framework so much that we have begun adopting a modified version for our local work, likewise for our DevOps practices. It has also deeply affected our cultural perspective on remote work. Since the launch of surflander, we were able to hire our first full-time remote developer and have since had another developer transition to full-time remote work and move out of state. When my department was formed late last year, remote first practices were a major influence guiding how we wanted to all work together as a team. And moving forward, I believe that any new develop developer position in my department will also be able to work remotely if they so choose. So finally to wrap up, what's next for surflander? As we continue to work together, we are continuously reevaluating practices and processes to ensure that we can meet growing demands, especially how to manage development on so many products without the overall coordination of a project manager. We purposely tackled some of the smaller products first, but now that those start to be put into production, we also need to figure out how we can best collaboratively support those now that they've stopped being active development projects. And as we begin to plan for our larger products, we also need to figure out how to do things that weren't necessary at the same scale for the smaller projects, like how to conduct multi-campus requirement gatherings with very large groups of stakeholders. However, whatever the challenges we continue to face to bring it back to our train puns, I'm really excited for the journey to continue down the track. So thank you all. Before we move on to questions, I do want to take a moment to recognize that this is truly all a team effort and want to acknowledge all of the individuals at both campuses that have contributed to the project. A listing of all of those team members are included at the end of the slide deck. So with that, are there any questions? Thanks. Thanks so much, Tim. Thank you, Chrissy. Very thorough and candid overview of your collaboration. We really appreciate that. I think this was part of your radical transparency mantra, and we're really delighted that you came to CNI to share that with us. So with that, and as Chrissy said, I'd like to reiterate that the floor is now open for questions or comments. Please take a moment to type your questions into the Q&A box, and I'll be happy to read them aloud here, and Tim and Chrissy will respond live. There's also a chat box if you prefer to use that where we shared a few links to their project, links to the project briefing page, which also contains a link to their slides, and we will embed the video of this webinar at that URL after the presentation as well. So while we're waiting to see if we've got some questions, I just want to take a moment to remind everybody that this webinar is part of CNI's spring 2020 virtual membership meeting, which is continuing on through the end of the month. So we have a couple more weeks of webinars. I've just chatted out to you there, a direct link to the schedule for the rest of the meeting, and there's lots to come. We actually have a very packed agenda for the next two weeks. So Tim and Chrissy, I was wondering if you could comment a little bit on, or rather, share maybe a short list. So you gave us a very comprehensive overview of the process, which was definitely a challenge by any measure. If we have folks listening here now who are thinking about trying to implement a similar kind of collaboration, have you got some kind of top of the list? These are the things to look out for, and these are the things you would have done in advance if you'd had it to do over again. Maybe too hard to get this still down. It's a great question. Did you want to take one? I have a little bit of an idea. Yeah, why don't you jump in? The one thing I would make sure is that we were very lucky, I'll be very honest, we were very lucky with this, that we had pretty much, we had executive buy-in and support pretty early on. There are a lot of things that made that happen, but the fact that we were working with another UC within the UC system, there's safety in doing that. I think we would have had a much bigger issue going forward with this project if we didn't have that executive buy-in from the beginning. I would recommend that if folks are planning on this, it would be very good to start with that. I know that's silly if I, of course, start with executive buy-in, but have that ready and be ready to get their feelings on it and figure out maybe if there's some modifications you're going to have to make. I know initially we had talked about being like, whoa, we could really expand this to multiple campuses and our scope got well out of our, it was going to be way too difficult to try and deal with, it was difficult enough to work with two schedules to deal with one of the 10 campuses was going to be very hard. So getting the executive buy-in was really helpful and we took their advice if they gave us any on how that worked. Yeah, and I'll just add to that, there are also very practical things when putting a collaboration like this together that were easier because we were part of the UC system's issues like copyright. So all of our copyright is owned by the UC region. So just having, there was some lack of friction because we are part of the same university system. But I do actually want to chime in and talk a little bit about on the other side too. Tim had alluded to some grassroots relationship building and this didn't just come out of nowhere. This wasn't, you know, oh, a couple people got this idea and we ran it by our ULs and all of a sudden we're working together is that the teams had actually been talking and collaborating on things like our metadata models and discussing that for probably about three years before we actually jumped in and started working together. So we actually had a really good sense that our philosophical approach to some of these big questions was very similar. Our teams do work very well together, just the personalities on our team. So I think we already had a good sense that the personalities on the team, that it was a really, really good fit for the collaboration. So I think that that can't be stressed enough too, is you kind of need to do your homework and you need to have built some of those relationships first. And in some ways, I feel like it was just a sort of a logical continuation of a lot of those relationships that we had already been building, which I think is just added, especially combined with the really amazing support we had from our administrations, did set us up to be quite successful. Yeah, so setting, setting a solid foundation at the outset, doing a lot of the legwork in advance really will set you ahead later. So that's great advice. Thank you. And forgive me if you spoke to this. I know you mentioned the, you know, how we're working now given the current crisis. But has that really impacted your workflow now, the current situation? Or is it, are you just set up to be able to continue work as usual on this project? And so that's actually, I would be happy to speak to that. There's a couple things about this project that have, I think really impacted our ability to respond to the current crisis. I mean, I think first thing to acknowledge is that, yes, things are just able to continue as normal. That has been great, except for, I do think for everyone, no matter how long you've been working remote and how good you are at it, you know, there is the added, sort of the added situation that we're all in. And so, you know, how we're all feeling at home, I think has, you know, impacted everybody. But actually a really major benefit of this is because our teams had gotten really good. We were actually able to offer our support to the rest of our organizations as this started. So at UCS, me and myself and my senior digital library architect, Tom Johnson, actually held a series of remote work sessions for our staff who had no experience to really hopefully get them up to speed. And this was in a time when our governor had not yet shut things down, but we had started to already have some folks transition to remote work. And so, you know, that was just a really fantastic resource that we had for our institutions that we were able to lend and give some advice and help folks really prepare for our new reality. And I really appreciated that. Tim, did you have anything you wanted to add to that? Just the same kind of feelings, like when I remember being asked in that emergency response team to try and detail how we were going to start working remote, I was like, we'll just not come into work. But otherwise, we'll just continue doing what we're doing. Like there really isn't the team was already because we had some remote developers, we had some remote folks already and telecommuting kind of built in. We just said, don't come into the building, keep the equipment that you're still using that you normally use on your day to day and just do that. Obviously, as Chrissy mentioned, there's plenty of other complications. Folks have families, they're caring for folks, for other folks in the place. Some folks, you know, ended up getting sick. So it is all just like there's the difficulties of the pandemic, but there is just the idea that remote work was we're well suited for it. I will say there was, you know, you forget how many people don't live on Zoom, like we do every day. So there is a couple of times when you're like, no, you gotta just press the mute button. Like that isn't, it wasn't a big thing to us because that's been our lives for years. It did come into a crashing remembering that this isn't how people normally operate. So yeah, we were well positioned and that helped a lot. Yeah, I'll also mention that the timing of this, I said we're on 60 day on off work cycles. So we were sort of in the last couple of weeks of our existing work cycle when this started. And so we did sort of finish that out the last, you know, really since now I'm trying to think it back. So all of May we've been off work cycle and we start up again in June. So but yeah, we don't really anticipate that this will affect our progress at all. You know, it's funny, we say all this except it absolutely affected Chrissy and I's progress, because we were on a sprint together, known as an administrative sprint, which way we were, we were working through writing an annual reports, finishing up some of the slides for this presentation as well as a couple of others. And all of a sudden, both of us as respective directors were told like, you need to prepare the organization for this remote work. And so that administrative sprint, all of a sudden went to the side, I'd get alerts for, you know, hey, you're supposed to be meeting like whatever can't can't handle the sprint meeting right now. Because like, there's no way I've spent any time looking at an annual report. Yeah, no one escapes the pivot. All right, I see Cliff has a question for us now. So let me go ahead and read that. He asks when the world went remote, the transition was obviously easier because you had already built up a lot of social capital. Have you had to onboard anyone new into the collaboration since we went remote? And if so, how well has that worked? So that's a great question, Cliff. I'll say we haven't had to onboard anyone new into surfliner since the world went remote. But we have actually at UCSB, we had one of our new associate university librarians begin in the middle of that. And actually several other team member or library staff members start in the middle of that. And so I can't really speak directly to how that experience has been for them. But it is definitely, it has been really interesting to sort of only meet people remotely. But I will also mention that, you know, one of our developers that use UCSB, Tom Johnson, who was our first remote hire, has always been a remote worker. He lives in the Pacific Northwest. I think some of the other folks, I don't know if this is true for all the San Diego staff, but I think it had been much more common for people to sort of gradually add days to telecommuting as opposed to starting remotely. And Tom is someone that reports directly to me. And so all of our relationship as a supervisor and an employee has all been done in these virtual channels. And so that's actually a very different practice and is probably more time than we have to sort of talk about my approaches to supervising remote staff. Although the biggest takeaway is it's really no different than physical staff. You have the same expectations. You just have to be very thoughtful about things like we mentioned, you know, making sure that you have agreed upon communication for your whole team, making sure you can have calendars, making sure that you're building those two relationships. So I think all of that is very different just having that sort of extra consciousness that once really once one member of your team is remote, your whole team is remote, that as a, you know, I have all of my employees that are remote. I am also a remote employee in my day-to-day life because I am remote from the folks that I supervise and, you know, that has really influenced the way that I approach my relationships with everyone on my team, regardless of whether or not they're in the building with me or not. Tim, did you have anything that you wanted to share? Not that I mean just that obviously this collaboration has been going on for about two years and we have had to onboard folks outside of the pandemic that were remote because they had to get on the remote team. So it wasn't so much the hiring practice of hiring someone remote, but it was the idea of like we had a couple of new ops folks that had to join the team. They had to get up to speed on a new project with the project was respectively remote because none of the UC Santa, we haven't had a chance to meet with the team ever since a couple of our folks have joined. I think UCSB's had an ops person join and San Diego's also had an ops person join. So it's tough to have them, they've never physically met these folks, but they've absolutely participated on sprint reviews and been, you know, slacking with them for, gosh, months now, six months or so. And that's really where, you know, when we, when we are allowed to again, we do really, you know, I love our in-person meetings, they're fantastic. It's a really great, it's really nice to be able to see people in person. I'm sure all of you can relate to that now. It will be really nice when we can see each other. And so, you know, we do still try to build that into our team relationship, those quarterly meetings when we were able to have them were really fantastic. It's the same for, you know, my staff, we try to do a quarterly all hands where everyone comes to Santa Barbara, just because there really isn't a substitute for seeing each other in person. I think we've been able to be really successful in our remote working relationship, but that has also been an equally important part of just building the relationships in the team. Perhaps a glimpse into our future. Thank you. Thank you so much. And Cliff says, he thanks you. He says, I find that if one is remote, you are all remote, a really compelling insight, which we're all living right now for sure. Yeah. And it is, it is one of, as we're creating these emergency plans to come back, one of the things that is commonly referenced is if you can work from home, continue working from home for, you know, until things get a little, little more clarity, but the folks that obviously have to come in the building to work with the collection, like that makes sense. The emphasis that we kind of keep keeping the mantra up is that if you are doing this hybrid idea, it is not a great experience to do the hybrid Zoom sessions. It's your remote folks feel ostracized, that the rooms are never set up right for it, the mics are not great, doesn't matter. I've seen the best audio in the world and it still fails when someone asks a question or something happens on the side. So it does, it is important as we all start transitioning back to respective workplaces to think of that hybrid in this area. Sometimes it's just not as effective. So start thinking of these remote practices, at least while you're transitioning staff back into the building to think about that and really try to have the Zoom meetings from your desks or whatever, so everyone feels like they're on the same platform. It's a really good tip. Thank you. With that, I just want to thank you both again for coming and I want to thank Oliver. All right, thank you so much.