Paula’s Spring 2018 Update

I am eager to jump into spring term as I have several new projects underway, some that will wrap up in the term & others just getting rolling. While IRA has been short-staffed I’ve chipped in to help with a couple of interesting assessment projects. For these I’m working with Elise Eslinger and Stephanie Huston, and Iris Jastram and Claudia Peterson to set up the next iteration of surveys in Qualtrics.

The DataSquad <> continues to be active with all levels of data-related projects, enough so that I’ve added two additional data-eager students; a proposed statistics major and another data science/CS enthusiast. Last term we worked on projects with Barbara Allen (resulting in new data visualizations for her latest book), Beatriz Pariente-Beltran (facilitating their departmental assessment process), Meghan Tierney (saving her research database from oblivion), and Marty Baylor (designing and building a database for managing equipment in Physics).

This term will also mark the end of my first experiment with mentoring a technical project intern. Veronica Child has done a wonderful job as we’ve explored sustainable ways of integrating project management tools like Asana, Jira, and basic process tools within Google Drive – while also helping Squad members grow into working on professional software development teams. I’ll be hiring for a new technical project management intern so please consider sending your candidates my way!

In a completely different arena, I am eager to get back into exploring the newest iterations of online data visualisation tools. I’m thinking here about their potential for use in QRE courses; in particular, for those which have no quantitative prerequisites.

After a flurry of publications in the past year or so, I took this year off of writing to attend more to my parents. As they stabilize, I am eager to return to a dropped project regarding simple and sustainable strategies for managing image collections as research materials.

After an overly booked IASSIST’17 (I had 5 accepted papers and presentations!) – I’m thrilled to go to IASSIST ‘18 in Montreal as a participant only. This is an international association of research data professionals who never cease to energize my thinking and reward my engagement with fantastic collaborations. For instance, last summer I placed two DataSquad students in extraordinary research-data internships in eastern and southern Africa and one at Harvard (that went so well that he’ll be returning for another summer.) And I’ve accidentally set one up for myself! .. well, it turned into a Fulbright Specialist appointment. (All I need now is for the Zimbabwean elections to proceed calmly next summer and my parents to stay stable.)

Demystifying project communications for students (part 2)

kermit the frog looks at screen of Mac laptop

**crossposted from Celeste’s blog**

This post expands on my previous post about some of the basics of project communications, with the idea that these can be helpful references for students who are new to doing project/community/client work. In this post, I want to talk a bit more about time (which makes my historian heart happy!) and managing expectations.

The obvious: people are busy. People lead complex lives. It’s incredibly rare that anyone has huge swaths of time dedicated to one thing and one thing only. And scope creep is all too common.

The idea of “working hours” is fraught and complicated: technology affords us the ability to respond quickly, at all hours, to issues as they pop up. And lots of folks find there are certain times of day when they’re more productive (night owls, early birds…why are these all bird related?)–which is great. But it becomes a problem when these start to create implicit expectations about responding on demand or at any time of day. The responsibilities people have in their lives outside of their academic or professional selves are present and important, so finding ways to be open and realistic about communication is key. Here are some ways to do the best you can to keep project work contained on a personal level, and work with others toward solid practices:

  1. Think about how you work, how you manage tasks, and meet deadlines. Write down when you think your most productive hours are and what is realistic for you in terms of being able to turn around responses.
    1. Example: I know that I’m best from 10-2 for generative work (writing, coding). I check emails 3 times a day (9a, noon, 4p) for ideally 30mins. I respond in those windows of time and try my hardest to avoid checking email outside of those times (I fail at this all the time, but I strive toward this goal daily).
  2. At the outset of a project, ask how the group prefers issues and notes to be communicated.
  3. Discuss with your collaborators what the expectations are for responding to emails, issues, messages, etc.  
  4. Do what you can to triage and manage incoming and outgoing communications. A couple examples:
    1. I use Boomerang (Gmail, Outlook, Android): I schedule the emails I write at 11p to send to collaborators the following morning at 9am when I know they’re at work or in their productive hours.
    2. Manage your notifications: for example, I’ve turned off push notifications for email because email is a huge distraction for me, but I’ve turned on push notifications for Slack because I know those are usually more time-sensitive messages.

The hardest part of all this is sticking to the boundaries set. But, setting and maintaining those boundaries helps deter burnout and unfair encroachment on collaborators’ time, while managing the expectations of all involved. Just because it can be done right away by you, does not mean that it needs to or should. Busy is not a virtue in itself.

Demystifying communications for student workers

person types in collaborative Google Doc at conference table

My colleagues Sarah Calhoun, Austin Mason, and I are collaborating on creating 4 new undergraduate internship positions related to front end/back-end development for digital humanities and digital scholarship projects, accessibility and inclusive design, and digital ethics. The DHAs and AT student workers are fabulous, but their job roles are written so that they wear several hats: tech support, triaging reported problems with campus-supported technologies, in-class support, etc. At Carleton, internships are distinguished from student worker positions by their additional expectations of mentorship, professionalization opportunities, and engagement with relevant fields.

Since we’re envisioning these internships as project-oriented, I thought it useful to start to think through some of our expectations for communication both during the internship, but also during projects. It’s likely that the interns will be able to see projects through from start-to-finish, but it’s also likely that they’ll come into a project in-process to contribute to a specific aspect. And in the interest of being explicit about expectations and minimizing the perils of tacit knowledge, I wanted to outline a few preliminary draft guidelines I’ve come up with so far:

Tl;dr: be generous and respectful, always.

  • Communicate information generously: it is better to include too many people than too few. Unless directed otherwise, share information, documents, code, etc. with the entire team and all the internship supervisors. If you are emailing someone on behalf of a small group, include all of the group members names in the closing signature and cc everyone.
  • Address collaborators respectfully and thoughtfully. This includes things like asking for preferred pronouns, and using appropriate titles and names. When interacting with a faculty or staff member for the first time, listen for how they refer to themselves and use what they said. If you’re emailing someone for the first time, use their formal title (Dr., Prof.) if applicable. Which leads us to…
    • Email etiquette: generally, this rundown by Laura Portwood-Stacer covers a lot. In addition, try to keep your emails shorter rather than longer. 4-5 sentences max and try to include all relevant info upfront.
  • Credit your collaborators: be generous and acknowledge contributions from your collaborators. This can be everything from help talking through an idea to a recommendation about where to find a code snippet to a comment someone made in a meeting that stuck with you. This kind of work and support often goes underappreciated–everyone (hopefully) knows it’s important but it’s often forgotten or left unmentioned in favor of a finished product.
  • When dealing with collaborators and “clients,” be sure to show up to all meetings on time, do any follow-up work promptly, and be highly responsive and polite over email. Loop in all relevant people.
  • When things come up at the last minute (because they will!): sometimes you will need to call in a favor from a collaborator to help you get work done rapidly. When this happens, make sure to acknowledge that this is a favor you are asking, give them an easy out, and thank them profusely if they are able to help you.

This is a general outline that will live in some other form TBD. But for now, I’d appreciate and comments/feedback/additions you think would help demystify project communications for students working on collaborative projects!

**huge thanks to Sarah Calhoun for her insights and suggestions!

**cross-posted on Celeste’s site.