Main »

Research Assistant Guide

Research Assistant Guide

This is a very short guide to working as a Research Assistant at the University of Alberta. They reflect my (Geoffrey Rockwell's) views about assistantships; others will manage RAs differently. If you think something in this guide is exploitative, unethical, poorly thought out, or unfair please tell me so I can address it. Collaborating with assistants on research projects is one of the joys of doing digital work, these guidelines are designed to help us get the most out of the collaboration.

General Principles

As a research assistant you are paid to be part of a research collaboration, usually one funded by a grant.

  • Make sure you understand the grant and its goals so you can participate in achieving them. The RAship is not only to fund you, but to get research done. Ask for the grant proposal and learn about the others in the grant. Make sure you have a sense of what the team expects to achieve this year and your role in that. If you are feeling anxious then write down what you think will happen and what you expect to do and we can use that to draw up a charter.
  • The point of collaborative teams is that not everyone has to do every task. Therefore we will depend on you doing your task well in order for us to do ours. If people have to redo your work or spend as much time fixing it as it would take them to do it then they stop asking you to collaborate. It is important that you therefore understand what you have to do, get the help you need, communicate about the doing, and do it well.
  • You also have to document what has been done for later reuse. Your work is not a course assignment with no audience - it will feed into projects that may not see fruition until years later. For this reason others will need to have confidence that you did it well and will need to be able to reconstruct what you did. Documenting your work so that others can use it later is therefore as important as doing it.
  • In a research project that can go in unexpected directions it is hard to predict exactly what you will be doing. Feel free to suggest directions you think the project should go and take leaedrship where you see opportunities. The less I have to supervise you the better. The more you manage the subprojects you are working on the more satisfying the experience will be. Take initiative and surprise us.
  • Tell me what you are good at and what you would like to try doing (even if you aren't good at it yet) so we can find tasks that are rewarding to both you and the larger project.
  • The contracts are typically for 12 hours a week. If 2 hours are spent on meetings that leaves 10 hours for working on the project. That is a full day. Make sure you set aside that amount of time.
  • If something is going wrong or you are feeling poorly treated please talk to a fellow graduate student or me. If I am part of the problem then consider talking with the Director of Humanities Computing or contact FGSR (Faculty of Graduate Studies) and talk to an Associate Dean there or talk with the folk at the Graduate Student Association - they are there to help you and have a Student Ombudservice. Don't let things fester.
  • I will inevitably ask you to do things you haven't done before. Part of doing research is trying to do things never done before and learning what you need as you go. Try to figure out how to do new tasks on your own. Don't be afraid to ask others for help - part of learning to learn is learning how to ask the right people for help. Please tell me if you are stuck - I can get you help or change the task.
  • We mostly manage ourselves through weekly meetings. See below.
  • Enjoy doing research with others! Enjoy the moments when we realize we have achieved something!

Meetings

We will set a weekly time to meet to keep the projects on track. Here are some thoughts on the meetings:

  • At the meetings we will usually set the tasks for the next week. Make sure you take note of what you will be expected to do over the week. I keep notes, but don't have the time to remind you.
  • Don't leave the work until the last moment. If your contract is for 12 hours a week then you should be setting aside a good day or a number of blocks to do the work.
  • The point of meeting is to quickly discuss what has been done and what needs to be done and then not have to remind people. We usually use no other management aides though I will send emails if needed. We try to keep the time spent on management to a minimum.
  • I often have to travel and therefore have to cancel meetings. Check with others if you are unsure if a meeting is happening or has been moved.
  • The meetings are not a class, though we talk about a lot of the same things discussed in classes. The point is to do the research together not have me lecture you.
  • In the meetings we will often talk about tasks that you are not part of; take advantage of the breadth of projects we are involved in to learn about the field. Tell us if you see ways you could contribute to other projects.
  • You will be asked to present information you have gathered or ideas you are developing to the group. Don't waste our time - be prepared to teach us what we need to know.
  • You will often be asked to then document what we did somewhere for future use. Learn the habits of documenting research at the time of doing.
  • Ask questions and be interested in the research goals. There is nothing more important to a research project than thinking it through together.
  • If I ask a lot of questions it is because I am really interested and you are doing something really neat that I want to learn about. Questions are good!

Types of Tasks for New R As?

While projects can take unexpected directions, here are some types of tasks that new R As are often asked to undertake:

  • Develop good questions related to the project that the team can try to answer. It is surprising how far a really good question can get us. Often we find ourselves wandering for lack of a really good question that can help us focus.
  • Do an environmental scan of what others have done to meet a need or prototype an answer. This is extremely useful as it helps us figure out what others have done that we can build on. It is the equivalent to a literature review for digital work and often feed right into papers we give on what we do. Get creative when you look for what others have done - don't assume they will have developed solutions exactly as we would.
  • Do a literature review around the question/hypothesis the team is working with. An environmental scan and literature review often go hand in hand. The way we learn about neat projects is through publications and vice versa. When you do a literature review you should remember that you are helping us all get up to speed on what others have thought on a question. This is a crucial task that needs to be done with imagination (to gather ideas that we can learn from) and care (to develop a bibliography we can trust months later when we are publishing.) An important aspect of a good literature review is your ability to share it so others can learn from your work.
  • Develop hypotheses that provide testable answers to a question or questions the team is working on. Again, like a good question, a good hypothesis can help us focus our work prototyping and testing. In many cases a good hypothesis will evolve into a sketch for an innovative interface, or a prototype, or a workflow idea, or a rough theory.
  • Sketch and document candidate prototypes. Sketching prototypes allows the team to then focus in on what we want to actually implement.
  • Create a prototype or work with programmers developing a prototype.
  • Testing the prototype in different ways and helping refine it.
  • Writing a conference abstract or parts of one for submission.
  • Writing a conference paper or parts of one.
  • Delivering a conference paper or demonstrating resulting prototypes.

Time Management

As an RA you are being paid for so many hours of work a week. I don't want to police how much time you spend on the research exactly and trust you to manage your time and to talk to me if I am asking too much or too little. I do, however, have a sense of what a graduate RA can achieve and will talk to you if I feel you are doing way too much or too little.

  • The time spent meeting is part of the contract don't feel that is over and above. Time spent researching how to do things can also count unless they are something you should know how to do.
  • If you feel you are spending more than the hours contracted please tell me. We will look at what you are doing and cut out or down some of the tasks.
  • If you feel you can't afford the time contracted please tell me and we can change the contract.
  • You don't have to spend exactly the amount of time contracted each week - if you need to work on something else one week I have no problems with your then making up the time later. Talk to me if there are project deadlines you don't think you can meet.

Credit

If you have contributed to a project you deserve to get appropriate credit. Academic credit is the currency of the academy so you should familiarize yourself with the issues and speak to me if you feel you are not properly being credited. Academic crediting practices also vary widely. Some faculty feel that if an RA or employee is paid to do work then they do not need to be credited as a co-author if they didn't do the writing. I am not of that view, but recognize that in some fields that is the norm. I tend to try to err on the side of crediting everyone which creates its own problems because it can dilute the credit of the major contributors. Here are the general guidelines I ask you to follow:

  • The grant and the funding body should be recognized in public presentations and papers. In many cases it is a courtesy to also name the PI of the grant even if she had nothing to do with the project you are reporting on.
  • In many situations you should identify the institution that you and others are associated with. This helps people hearing a presentation or reading a paper find more information if they want.
  • Provide links to stable web sites if possible so that people can learn more about the project and about those involved.
  • List as a co-author anyone who contributed significantly to the project. That includes the professor who directed the project even if she (I) didn't actually do any programming, design or writing. Remember that getting the funding, setting the research directions, and managing the research process is part of the research.
  • The order of co-authors is important. Typically the member of the team that was responsible for initiating and following through on the particular presentation/paper gets to be first author. So, if you are the person who takes the lead on submitting a conference abstract and submits it then you should be the first person listed. Same applies when we actually give the paper at the conference and publish it.
  • Note that the first author can change - one RA might have led the submitting of the abstract but then another led the writing of the paper. Likewise we will often give multiple papers on the same project with different first authors depending on who did the work for each particular paper.
  • You are strongly encouraged to identify opportunities to report on our collaboration. If you find a venue then consider leading the proposal of a paper and the writing of it. Take the initiative and be the first author, but always remember to credit the others.
  • When in doubt invite others to join in preparing a paper or talk to them about it.
  • Often the professor who directed the project is listed last unless they wrote the paper.
  • I and you will give talks and write papers about questions in the digital humanities where I mention projects we collaborated on as examples. In those questions I do not list others as co-authors because the paper is not about the project. The trick is to know the difference between a general paper where the project is being quoted and a paper about the project where all the collaborators should be credited.
  • Some granting agencies and larger project will have their own explicit guidelines that should be respected.
  • Make sure you record what you do and that you grab screen shots and documentation of projects you work on so that you can use them when promoting yourself or trying to get a job. Digital projects have a way of disappearing just when you want them on your CV for a neat job. Document them for the future.
  • As with other issues, you should talk with me and/or others if you have problems with the way credit is being allocated. This is not a trivial issue and should be dealt as early as possible.

Please look at the Collaborator's Bill of Rights and the Student Collaborator's Bill of Rights.

The Graduate Student Association has a web page about the Collective Agreement here with lots of helpful information including information about their Ombudservice.

Conferences

During the year we will write conference paper proposals and send them in. You may end up leading the writing, in which case you will be the first author. Some of the papers will be accepted at which point we will try to find the funding to send you to the conference to give the paper. I can't always find sufficient funding, together we usually can. To support you there are various

I know it is time consuming, but make sure you apply for these. They look good on your CV. Then I will try to cover the rest.

What this has not covered

There is a lot this document doesn't cover. Here are some things that can crop up:

  • Intellectual property (IP)
  • Methods and techniques
  • How to deal with conflict
  • Larger and important questions about power, internships, precarious labor in the academy and the hierarchical structures we operate within
  • How to deal with stress and graduate research

For many of these the Graduate Student Association is a great place to go for fellow grad students to talk to.


This work is licensed under a Creative Commons Attribution 4.0 International License.

Navigate

PmWiki

edit SideBar

Page last modified on October 24, 2015, at 12:24 PM - Powered by PmWiki

^