Onboarding for Researchers

Onboarding for Research Fellows

Hiring Research Assistants

As a research fellow at Tilburg Science Hub, you can hire (or embed already hired) Research Assistants in Tilburg Science Hub's RA Pool.

Benefits:

• we will onboard the RA to Tilburg's research infrastructure
• automated tracking of the RA's working hours via an app and handling monthly billing with your department
• the RA will learn state-of-the-art open science tools and embed them, where suitable, in your work

Requirements:

• a budget code (at Tilburg University) that allows you to hire RAs
• a cool project that aligns with what we do
• sending us an email, asking whether we have currently supervision capacity

Steps to take:

1. Get a budget code that allows you to hire RAs (e.g., for starter grants at Tilburg, you need to have budget RA costs - you can check with your department's secretary)
2. Adapt one of the currently available job ads to suit your needs (see https://tilburgsciencehub.com/jobs)
3. Email us your job ad, and we'll promote it via our channels (e.g., social media, among students; of course, it would be great if you could help with promoting it as well)
4. You will interview suitable candidates
5. Once you've decided for an RA, you let your department's secretary know you would like to hire the RA (give name, Tilburg email address) and indicate you would like to hire the RA on an on-call basis for max. 16 hours per week (usually, RAs work 8 hours, but sometimes, it's good to go a bit higher).
6. Let us know the start date that your department is communicating to us.

That's ok!

More

The RA Pool at Tilburg Science Hub supports researchers at Tilburg School of Economics and Management to apply open science practices in their empirical research.

We would like to stress that our way of working may be different from what you're used to, so we ask for your time to familiarize yourself with it.

Leading principles

• The academic has an overview and a clear idea on what the final product should look like.
• The academic maintains a (private or public) GitHub repository and invites members of the RA pool as contributors
• The academic sets up a project board with the columns "backlog", "to do", "in progress", "done".
• The academic then initiates the following (repeating) workflow:
  • The academic writes Issues on GitHub (check out this building block on how to write good issues)
  • The academic prioritizes issues, by adding (and then sorting them) in the backlog column of the project
  • The academic meets with the RAs, to discuss which issues move to the "to do column"
  • The RAs independently work on the issues and indicate their status on the project board (e.g., move to "in progress" or "done"). Any communication is kept on GitHub exclusively (i.e., in the issues)
  • The academic meets with the RAs and reviews the board: what has been done? what's still in progress (and why?), and what (potentially new items) move from the backlog to the to-do list.

Foster an understanding of the entire workflow

• before RAs can work on their own and solve issues, it’s important that they fully understand the workflow for the entire project. This needs to be worked out together before they start working on their own.
• Instructions should be put on the readme.md of the repository and can be very brief. For example
  • "The raw data should be stored here: "
  • "We want to have the following folder structure: ..."
  • "We want to have the following files: build.do and analyse.do"
  • "We want to use make and tablefill"

A few more notes on writing issues

• ➡️ your go-to resource on learning to write good issues is this document
• Recall that issues need to be very concrete (solve this concrete problem, do this concrete thing), for instance: “create folder structure”, “put raw data in the right place”, “write first version of build.do”, “set up make”, “write first version of analyze.do to produce simple summary stats”, “add regressions of a on b to analyze.do”.
• The instructions should also share advice on how RAs can do the things, for instance by pointing them to resources or giving them instructions on how to look for what they need (you need to google “ab cd” in order to get started; (“look at this example code to see what I mean: …”, “look at this paper which has used the same data for some instructions on how to construct variables”, etc.)
• It is generally a good idea to provide starter code or pseudo code to convey the idea of what one wants: “program up a procedure that does this: … add pseudo-code … taking into account this that etc.

Your RAs are not alone!

• your RAs have regular lab meetings with team members of Tilburg Science Hub
• check our core values to understand our approach of getting work done