About a month ago, bionicteaching (aka Tom Woodward) proposed a way to assess and reflect upon institutional maintenance of DoOO, “midstream”. Another way to frame this question might be, “how can an institution sustain their DoOO work?
This focus on maintenance is important, and widely observed to be a point of a particular kind of stress. Coders and bug-squashers, catalogers, archivists, OER creators and maintainers, all sorts of information management work knows this pinch point.
If we were to consider this longest, often tedious, rarely glamorous middle phase of the cycle as “sustenance” with all the vitality and necessity that word connotes, would we tend it differently?
Tom is coming into an institution considering what he’s calling “mid-stream arrival” and asks for four things (with my abridgment):
- Advice – how could you improve?
- Success – what’s worth repeating?
- Proof – how do you know it’s worth repeating?
- Management – what saves time & makes it fun?
Thinking of sustenance (I’ve skipped lunch, can you tell?), here are several things I’ve experienced at Muhlenberg that may prove helpful to others at my institution (as roles change), and hopefully to folks at other DoOO institutions who may be tending a DoOO initiative already underway.
Advice / Management
At my institution, DoOO (we call it Berg Builds) exists outside of our administrative IT and outside of our institutional web presence. My college is muhlenberg.edu but Berg Builds is bergbuilds.domains. On the whole, I think this is a very good thing. Our Digital Learning group coordinates closely and has a good relationship with our colleagues in our Office of Information Technology. But our attitudes are, appropriately, a little different. OIT is rightly risk-averse and we (digital learning) openly encourage folks to break their Berg Builds and see what happens. Because we can, and because it won’t bring down the college website. If the web were pillows, we’d want and expect OIT to ensure our pillows weren’t stuffed with sawdust, or shards of glass, or cooties. OIT is that “do not remove” tag on the pillow warning us to not sleep by open flames. DoOO is a bunch of pillow forts.
So having these conversations and building trust across groups is essential and is always something that can improve. Because DoOO sits outside of our administrative IT, I don’t have much direct connection to our Student Information System (SIS). When it is time for me to expire accounts, I have no easy way of knowing class year, for example. Also, we utilize a Single Sign-On (SSO) tool. But because of the positioning of DoOO, there is a lot of duplicated administrative effort that I just accept. While student and faculty LMS, email, and related administrative accounts are scripted into existence, I manually create and remove all DoOO accounts in one or two places. In a perfect scenario, I would have trust and independence AND a capacity to connect to central IT in all the ways it saves time, effort, and potential error. So if your mid-stream arrival permits a nice long sit-down with your institutional IT, set that up. But first, have a nice long chat with the folks at Reclaim Hosting and learn how they can help, too. There are a lot of hooks and reports and stuff that they can provide. Then, bring a data map, or an ER diagram, or a workflow, or some other model that illustrates points of connection between what you manage, what Reclaim can automate, and what your OIT manages. See what might come of that.
Advice / Proof
We provide access to our Berg Builds accounts for a full year after graduation. We do this because a main use of Berg Builds is as a portfolio. When someone is applying to post-graduate programs or seeking work, a portfolio that disappears a few weeks after graduation isn’t much use. But because our institutional email accounts expire much sooner, it’s a challenge for me to contact folks once they leave. I’d love a better way to make contact with expiring account holders to offer assistance with migration, and to encourage folks to keep going in some way with their domains. I’d love better numbers on who continues to maintain some kind of self-hosted presence on the web. But trying to do anything in the last month or two before graduation is basically impossible. The demands on students’ time are just too great then. And too much before that, it seems far enough in the future that it doesn’t warrant much attention. The answer is out there, I just haven’t found it.
I also would like to close the loop with our faculty who integrate Berg Builds into their coursework and/or their collaborative research projects with students. Honestly, this mostly comes down to workload. Keeping things moving, supporting new projects, and publicizing and growing awareness of what our Digital Learning group has to offer is really important. I could do a better job of following up with folks after the semester concludes and learning from their experiences and find improvements. I’m not a fan of paperwork, but tracking pre-semester and early semester contacts from faculty and then building a reminder to follow-up is a goal of mine for the next academic year.
Success/Proof – Digital Learning Assistants (DLAs)
Our Berg Builds initiative wouldn’t be anything without our Digital Learning Assistants (DLAs). We learned well and early from UMW’s Digital Knowledge Center that peer learning and peer support are crucial. Our DLAs spend a paid semester working through training, dialogue, and observation while working on their own Berg Builds sites. Afterward, they become the first and main point of contact for students seeking assistance with their own Berg Builds work. DLAs often present Berg Builds/WordPress to classes when instructors request a class visit. And DLAs are our partners in dialogue with faculty when imagining how assignments might incorporate working on the web.
DLAs help us understand what sorts of problems students may be encountering, and they share with us their awareness of how faculty are using Berg Builds in classes and across whole programs. DLAs likely have the best overall sense of what works and how things can be made better.
Proof
Full disclosure – I built our Berg Builds Community site after seeing Marie Selvanadin’s, Yianna Vovides’s, and Tom’s presentation at the first Domains conference, so Tom likely already has in mind a community portal of some kind at Middlebury College. I think a community portal is so important as a way to promote the DoOO work that’s happening, but also to assess the strength and growth of the DoOO initiative over time. A community site helps surface which programs and departments are involved, and which are absent. A community site helps designers recognize pedagogical innovation by faculty. A community site is central to our goal of spotlighting the best work happening by students, faculty, and staff each year. Another thing we’ve borrowed is an annual award ceremony (thank you OU Creaties!) that is only possible because we have a way to collect and browse the best examples of Berg Builds domains on our campus.
But a community portal is trickier than I expected, mainly for two reasons. The first reason is that we recognize a human must evaluate sites before we include them. We won’t just ingest every site. This is the only ethical way to do it, I believe. A lot of work on Berg Builds is in-process or not ready for unsolicited visibility. We build an opt-in/opt-out process into our community site, so that anyone can ask to be included, and anyone can ask to have their site left out. And folks can change their minds whenever they want.
Also, we only select sites that meet a minimum set of non-subjective criteria like: Is the site using the default theme? Is the title “My Blog” and/or the tagline: “Just another WordPress site”? Did the owner delete the “Hello Word!” post?
There is no easy way to automate (i.e., script) this kind of evaluation, and we have over 2,000 WordPress sites to consider. That’s a lot of clicking and scanning. I’m currently working on ways to make this more efficient, but I look at lots of sites, as do our Digital Learning Assistants. This is something we can only reasonably accomplish during a big push, once or maybe twice a year.
The other reason a community portal is tricky has to do with the absence of an archival plan and the finite number of accounts we can afford to carry. We’ve had many excellent examples of Berg Builds sites go dark because our students (and some faculty) have moved on. Such is life. But I wish there was a way for me to maintain as proof of success some examples. I also think having aspirational models for students and faculty helps them imagine their own work, communicates high expectations for domains-related assignments, and facilitates a conversation between present students and Muhlenberg students of previous years.
As with everything awesome about DoOO, the folks at Reclaim Hosting are central to this conversation and likely have the keenest minds and best ideas for how to have it all. I feel like things are really good as they stand, and the workflow and presentation improvements I have in mind will make the effort lower and the utility of the community portal higher in its next version. But the preservation and presentation of archival accounts is a big dream and I would welcome the help of other folks who work with DoOO, and obviously folks at Reclaim, to figure something out.
Success
Our faculty development approach to Berg Builds centers on community. We are now mid-way through our second Pedagogical Learning Community where faculty and staff receive a domain and engage with one another over the course of a semester. These faculty and staff incorporate DoOO into their teaching, research, and scholarship while building their own presence online. Over time, we’ve relied on our first DoOO cohort to present on Berg Builds, to connect with new faculty, and to help us recruit new DLAs. The idea exchange and exploration continues long after the semester ends.
Advice / Management
The last thing I’d offer is to look for the next Workshop Of One’s Own / Reclaim Roadshow offered, once we’re all cleared to move about again. I learned so much from the one I’ve attended, and I’ve followed the developments on the Reclaim site for other Roadshows, too. The tips and tricks for using WHM/WHMCS, as well as diagnosing & troubleshooting WordPress and cPanel issues are invaluable. And if you want to talk about fun…I attended in Fredericksburg after Reclaim Video, but BEFORE Reclaim Arcade. Personally, I think I’m due a refresher and I really think I need a visit to Reclaim Hosting home base for some post-workshop arcade time and for the enormous Benny’s pizza (remember that bit about me skipping lunch?).
These are my few additional thoughts, I hope they are helpful. Also, and this goes for all DoOO folks — reach out if I can ever lend a hand.