 |
 |
Drew- Thank you very much, this is great information. It sounds like we are on the right track with planning for server resources and our anticipated staffing needs. I'm glad to hear that it has been a reliable system over several years. Everything you covered will be very helpful for us moving forward with planning. Thanks again -David On Tue, Dec 5, 2017 at 8:32 AM, Drew Heles <[log in to unmask]> wrote: > David- > > We have been using Vireo at Johns Hopkins Libraries for several years now, > and have been well pleased with it as an efficient and reliable system. We > are running our production instance on a “standard” VM (1 CPU, 4GB RAM, > 40GB disk space). We haven’t had cause to tinker much with that allocation, > you might be able to get by with less, I’m not sure. The ETDs themselves > are stored on a mount to our production storage system, the space > requirements for such dependent on the student population supported and the > retention policy in effect. If you prioritize getting ETDs out of Vireo and > into your institutional repository, you can probably save some resources > here. > > Our ETD program is essentially run by a single administrator and a single > technical person, backed by our operations folks who administer the > network, storage system, and VM infrastructure. None of us work exclusively > on ETDs. Said admin would probably tell you that this is not ideal, but > depending on your available resources, it can be done. Our administrator > conducts trainings, supports thesis and dissertation administrators in our > various academic programs, reviews submissions for format and policy > compliance, and fields most questions. Program administrators have access > to the system for generating reports, etc. Technical issues, > troubleshooting, upgrades and occasional maintenance are handled by myself. > Technical issues are rare and have decreased over time. Overall, we have > been well pleased by how much volume we can handle in Vireo with a fairly > modest commitment of time and resources. Again, the size of your student > population and the policies you implement (particularly the extent of > academic review conducted within the system) will impact your staffing > requirements. > > We deposit ETDs into the institutional repository once per semester, after > the graduation records are made available. Our administrator moves eligible > submissions into the appropriate state in Vireo (manually, by eye, using > paper… definitely an opportunity for some systems integration here). > Because our out-of-date IR used to not integrate properly and because we > occasionally had problematic data that wouldn’t ingest properly (1), we > have what may be a more involved semesterly ingest testing process than > needed. I replicate our production data into a staging environment, use > Vireo to filter for the eligible submissions, test the SWORD deposit into a > staging copy of the IR, and then confirm that all the data flowed as > expected and that the totals match those of our admin. When everything > checks out, I do it again on production. Automation (using Ansible) has > helped a lot with this process. An up-to-date SWORD-capable IR (2), > up-to-date Vireo installation, and a (un)willingness to trade up-front > testing time for risk on your production systems can all impact your > investments here (3). > > We use home-grown student record software, rather than PeopleSoft, so we > haven’t done much integration there. Depending on needs, we can either > export data (in CSV format) via Vireo’s admin interface or provide admin > access to those who need it. My understanding is that the new version of > Vireo (which is going into beta this winter) will have an API, so > investments in such integrations will probably pay off better once that has > been released, provided you can wait for it. > > Apologies to the list for such a lengthy response (footnotes, even... > sheesh). I’d be happy to answer further questions if you’d care to contact > me directly. > > -drew > > > (1) e.g. invisible unicode characters cut & pasted into the abstract field > by students using atypical software > (2) DSpace is the one for which Vireo was designed, though I imagine one > could integrate with others, if one had sufficient resources and motivation > (3) It may be worth noting that failure in the Vireo-to-IR ingest is not > catastrophic. Any time I have had a problem, I have simply found the > problematic data, corrected it, and picked up where I left off. Over time, > Vireo has gotten better about handling oddities in the data, as well. > > > Drew Heles > Software Engineer > Library Applications Group > Sheridan Libraries > Johns Hopkins University > > > Date: Fri, 1 Dec 2017 15:56:43 -0500 > From: David Cirella <[log in to unmask]<mailto:[log in to unmask]>> > Subject: Vireo ETD Experiences/Feeback > > Hello All, > > At my institution we are evaluating Vireo ETD <http://vireoetd.org/> for > the primary component of our thesis submission process. Beyond the great > information provided in the project's Institutional Profiles, I am hoping > to get some feedback from anyone that is currently using the system. > > We are currently considering issues around the following questions: > How (server) resource intensive have you found the application? > What type and/or amount of technical or user support is typically needed? > What level of staffing is involved with regular maintenance and support? > If you ultimately move the theses to an institutional repository, what does > this workflow look like at your institution? > Have you extended the system to interact with you student record software > (PeopleSoft)? > > Any information about your experiences would be greatly appreciated. > > > Thanks! > > David Cirella > NYIT Library > >