Generally speaking, the UWDCC been focused on content creation. We work with campus faculty, librarians and students to digitize resources that support teaching and research. These resources are delivered to users by the systems and platforms developed and supported by LTG and LIRA. In the past, most of us in UWDCC have not been directly involved in this technology development process. Like other units within the library, we are an end user of those systems and platforms created by LTG and LIRA.
At one point, there was discussion as to whether or not UWDCC should continue to be grouped with library technology, with suggestions that collection development, preservation or public services might be a more appropriate place for our group to live within the library system. I'm not advocating one way or the other but simply asking:
1. What will be UWDCC's role within this new UWDCC/LTG/LIRA working environment?
2. What is the expectation for our group? More digitization? Less digitization? Different formats? Quality vs. quantity? More staff? Different skills sets?
3. What about digitization for preservation vs. digitization for access?
4. How might we be more involved in the technology development process (platforms, systems, widgets, etc.)? Should we be more involved in the technology development process?
5. While it's exciting to ponder development of new technologies, the UWDC is a large digital collection that requires day-to-day maintenance. How can we be sure our trouble-shooting needs for core systems/platforms (e.g. EFacs, SiteSearch, Litmus, etc.) are given priority over new development? For example, our production staff depends on Litmus functioning correctly. When Litmus dies, our production "machine" screeches to a halt, the result of which may be 10-15 students with no work for several hours (wasted resources), pushed or missed deadlines, unhappy content providers (faculty!), or all of the above. With 60+ projects in our production queue at any given time, any system breakdown is problematic, especially when some of our projects are grant-funded with inflexible deadlines.
Subscribe to:
Post Comments (Atom)
Posts
4 comments:
I wholeheartedly agree with point number five above. In addition to planning for the future, support for the present needs to remain a high priority.
At least on my part, if/when the shared development group becomes a working reality, we're going to specifically allocate people to application support roles during each work cycle -- there are lots of good reasons for this, going in both directions. We'll also have well-defined escalation procedures to handle unplanned excitement -- nobody is going to refuse access to someone just because they're wearing a "developer" hat that week.
I think my general desire is that I'd rather have seven people doing development, and three people doing application support, on any given day; rather than having ten people each split 70/30 on a minute-to-minute basis.
I think the major concern is that there is a committment to support, that we in UWDCC know exactly who to get help from and that there is follow-up to the problems. If the development group fills that role, I'm all for it.
One other concern, and I'll be blunt about it: What percentage of assistance will UWDCC receive? In the past we had a position dedicated 100 percent to our support needs, helping us meet our day to day production needs and our deadlines (we have outside stakeholders that expect our work to be public on a certain date), so I'm trying to understand where our needs fit into the development group work.
I don't know how much of Thursday is supposed to be about organizational concerns, versus more services/interfaces/etc. discussion.
BUT ... This part of the development group organization is still getting figured out, so I absolutely want to have more information about how we make it work. If it doesn't come up on Thursday proper, buttonhole me at the end of it, and we'll figure out what needs to happen, and then I'll make sure it happens that way.
Open invitation to anyone else to participate, of course.
Post a Comment