I view my relationship with students and postdocs as a partnership. My job is to ensure people in the lab get the training and opportunities they need to advance in their chosen careers, whether in academia, industry, teaching, or other options. Below you can find information on the lab philosophy and expectations of lab members. Text and ideas in places borrow heavily from Rubén Rellán-Álvarez.

General Rules

Safety first

Your health and safety are more important than your research. This includes adhering to lab safety codes, as well as maintaining your physical and mental health.

Never work in the lab or field if you are feeling sick, under medication that might affect your ability to work normally and definitely not under the effects of any kind of drugs. Avoid working by yourself doing potentially dangerous activities, and please be aware of UC Davis resources and training on lab safety.

Your mental health is equally important. UC Davis has a number of resources available for mental health concerns (see here and here). If you are struggling with mental health issues, please reach out to me or to one of these resources.

Respect

I expect lab members to contribute to a productive and friendly environment conducive to learning and research. This includes treating your colleagues with respect, listening to others’ viewpoints and ideas, and ensuring the lab is a place where everybody feels welcome and appreciated. Racist, sexist, or other inappropriate comments or behavior will not be tolerated under any circumstance. The university provides a number of resources to report or discuss any such activity you feel is inappropriate, including help resolving any conflicts you may have other lab members (including myself).

Accommodations

If you have a disability, health condition, or family circumstance that affects your work, please talk with me — I am happy to work with you to find what works. You do not need to share details you are not comfortable sharing. Students can request formal academic accommodations through the Student Disability Center, and postdocs and other employees through Disability Management Services. The campus accessibility site has more information on resources for students and employees.

Expectations (for all members)

Work hours

We are lucky enough to work in an area where flexible working hours are the norm. In order to be able to interact with the rest of the persons in the lab, we generally expect lab members to be present the majority of normal business hours (9-5pm) during the work week, since this is when most academic activities occur. There may be times when your project requires work late at night or on the weekends, but you are not expected to regularly work more than a normal 40-hour work week. It is important that you take time off for personal life, vacations, etc. I do ask, however, that you notify me if you will be absent for ≥1 day, and let me know in advance of any extended leave.

Communication

Most lab communication happens on Slack. I am embarrassingly online and often send messages at odd hours, but I do not expect a response outside of normal working hours — please don’t feel you need to reply to me at night or on weekends. Likewise, while I usually respond quickly, sometimes it may take me a day to get back to you.

Please give me at least two weeks’ notice for letters of recommendation and for reading manuscript drafts, fellowship applications, and similar documents.

Seminars, journal clubs and other lab and institutional activities

Attendance to regular weekly lab meetings is expected of all lab members. Participation in weekly lab coffee, Zeavolution and other regular meetings, and journal club is encouraged but not required. Note that if you are funded on one of the lab’s current grants, you are expected to attend those meetings as well. There are a number of seminars (Plant Biology, Genetics, CPB, Ecology & Evolution, Plant Genomics Working Group, Zeavolution) each week. You are strongly encouraged to regularly go to one or more each week.

Conferences

Everyone is encouraged to attend at least one conference a year. Members of the lab regularly attend such meetings as the maize meeting, SMBE, Evolution, and ESA. The department and university offer travel funding for graduate students and postdocs, and you should apply for external sources of funding to help cover travel expenses. Whenever possible, I will help fund attendance at one conference per year for each member of the lab on the condition that you are presenting a poster or talk at the meeting. Please provide ample time before the deadline for reviewing abstracts and posters or practicing talks.

Authorship

We follow the ICMJEE rules for authorship:
1. Substantial contributions to the conception or design of the work; or the acquisition, analysis, or interpretation of data for the work; AND
2. Drafting the work or revising it critically for important intellectual content; AND
3. Final approval of the version to be published.
4. Agreement to be accountable for all aspects of the work in ensuring that questions related to the accuracy or integrity of any part of the work are appropriately investigated and resolved.

We are fans of the CRediT author taxonomy, and will use these when possible.

We recognize that projects evolve over time and authorship inclusion and author order will be re-evaluated accordingly. We strive to be as transparent about this as possible, and welcome discussion or questions from coauthors or collaborators. We also recognize that authorship is not the only way to contribute to science, and we encourage lab members to acknowledge contributions of others in their work.

Open Science

We feel strongly that open science is important. We write papers on github or overleaf, often in public repos. We publish preprints as soon as a manuscript is ready for submission. We publish our data as soon as we can, and I am pushing to start doing so as separate data papers. We document our work – with github, R markdown, readme files, etc. – so it is intelligible and reusable in the future. I expect members of the lab to practice open science.

Computing and data

Information on using the cluster, data storage, and lab data policies can be found on the lab-docs wiki. Please read it when you join the lab.

Research integrity and mistakes

I expect everyone in the lab to conduct research honestly and carefully. Mistakes are a normal part of science — everyone makes them, including me. What matters is catching and correcting them, so if you find an error in your work (or anyone else’s), please tell me as soon as possible. You will never be in trouble for reporting a mistake, and finding one early is far better than finding it after publication.

Specific rules for the different members of the lab

Postdocs and senior PhD students

My responsibilities to postdocs and senior PhD students:

  • Assist with identifying and writing postdoctoral fellowships.
  • Develop project ideas, including independent projects that can be taken with the postdoc.
  • Interpret results.
  • Proof-read manuscripts.
  • Discuss future career goals (e.g., do you want to teach, go into academia, industry, continue in research?), and plan ways to facilitate these goals.
  • Meet weekly to discuss progress & pitfalls.
  • Help develop and revisit an Individual Development Plan (IDP).

Expectations of postdocs and senior PhD students:

  • Developing an Individual Development Plan (IDP) is strongly encouraged.
  • PhD students: meet with your dissertation committee every 6 months, as recommended.
  • Prepare for our regular progress/pitfalls meetings and a follow up email of progress and goals.
  • Write and submit manuscripts. I strongly encourage collaboration, and a quick glance at our publications should show that this generally works well. On average I expect your time as a postdoc in the lab to generate ~2 papers per year (first or co-authored), and in general this expectation seems to be not unreasonable.
  • Proof-read manuscripts from other lab members.
  • Apply for external funding (either individual postdoc fellowships or contributing to larger lab grant writing).
  • Maintain a set of lab notes, including directories of data, annotated codes & versions, detailed methods. These need to be sufficient to reproduce results without additional instructions.
  • Participate in general lab responsibilities (servers, maintain common areas, taking turns hosting visitors). Participate in talk rehearsals of your colleagues.
  • Optional, but encouraged: Mentor at least one undergraduate student.

Master and junior PhD students

My responsibilities to Master and junior PhD students:

  • Develop project ideas.
  • Interpret results.
  • Proof-read and contribute to writing of thesis, abstracts and manuscripts.
  • Discuss future career goals (e.g., do you want to teach, go into academia, continue in research?), and plan ways to facilitate these goals.
  • Meet weekly to discuss progress and pitfalls.
  • Help develop and revisit an Individual Development Plan (IDP).

Expectations of Master and junior PhD students:

  • Prepare for our regular progress/pitfalls meetings and a follow up email of progress and goals.
  • Developing an Individual Development Plan (IDP) is strongly encouraged.
  • Meet with your thesis/dissertation committee every 6 months, as recommended.
  • Write and submit manuscripts. On average, I expect most students to produce three publications over the course of their PhD, including at least one first-author paper.
  • Maintain a set of lab notes, including directories of data, annotated codes & versions, detailed methods. These need to be sufficient to reproduce results without additional instructions.
  • Write thesis in due time.
  • Proof-read manuscripts from other lab members
  • Participate in talk rehearsals of your colleagues.
  • Participate in general lab responsibilities (servers, maintain common areas, taking turns hosting visitors, communal sampling and field work etc).
  • Present multiple research talks/posters at conferences over the course of your time in the lab. You are encouraged to do so annually, but this isn’t always possible.
  • Optional, but encouraged: Mentor at least one undergraduate student.

Funding for graduate students

Graduate students in the lab are funded either as Graduate Student Researchers (GSRs), working on a grant-funded project, or as Teaching Assistants (TAs). Both require ~20 hours of work per week, on a grant or on teaching respectively. Students are strongly encouraged to apply for external funding (e.g., fellowships), which provides both independence and valuable experience in grant writing.

Undergraduates

Undergraduates in the lab may be directly mentored by a graduate student or postdoc, but I strongly encourage you to also join occasional group meetings with me. Undergraduates generally work in the lab in one of two ways:

  • For credit hours on a research project. You can expect mentoring and some independence in developing and carrying out your own project.
  • As paid hourly support for an existing project. You will help with ongoing lab research under the direction of a lab member.

If you are interested in a funded summer research experience, check out the EVE Scholars Program.

AI Usage Policy

This section outlines RILab guidelines for using AI tools in research, writing, and coding. The expectations differ by experience level: what is appropriate for an expert may not be appropriate for a beginner, because part of training is learning to do the work yourself first. Your relevant experience level will likely differ for different tasks, so please use your best judgment and ask for clarification if you are unsure. The goal is to ensure that you are learning the skills you need to be a successful researcher, while also using AI tools responsibly.

General Best Practices

These principles apply to everyone in the lab, regardless of experience level:

  • Always check AI output before relying on it.
  • Ask for sources and verify them.
  • Accountability — independently validate what the AI produces.
  • Ask questions about assumptions the AI (or you) may be making.
  • Ask before sharing others’ writing and code with AI tools.
  • Feedback from a human will almost always be more helpful than AI.
  • When in doubt, ask someone!
  • Should you learn it? If knowing this is important to your development, do it yourself. If not, you can use AI.
  • Generally: Could you do it without AI? If not, do not use it until you can.
  • Ask for point-by-point review of text, rather than have AI rewrite anything.
  • Ask to see code rather than blindly accepting it.
  • Reading, interpreting facts, and synthesizing content are core scholarly skills you are expected to develop and own.
  • AI should never outline a draft or rewrite your writing — the thinking embedded in drafting and writing is yours to do.

Usage Guidelines by Experience Level

The tables below specify what is appropriate at each level across three task categories — writing, research, and coding & analysis — under three permission tiers:

  • Never okay — do not use AI for these tasks.
  • Case-by-case — acceptable in some situations; use judgment and check in if unsure.
  • Always okay — AI use is fine for these tasks.

Beginner

Category Never okay Case-by-case Always okay
Writing Outline a draft; rewrite anything — Typos and spelling
Research Read; interpret facts; synthesize content Find articles Basic facts (with a source)
Coding & analysis Basic syntax; writing functions; writing a whole pipeline Code review (checking for errors) Explaining code

Intermediate

Category Never okay Case-by-case Always okay
Writing Outline a draft; rewrite anything Editing and feedback Typos and spelling
Research Read; interpret facts; synthesize content — Find articles; basic facts (with a source)
Coding & analysis Writing a whole pipeline Writing functions; code review Basic syntax; explaining code

Expert

Category Never okay Case-by-case Always okay
Writing Outline a draft; rewrite anything Editing and feedback Typos and spelling
Research — Read; interpret facts; synthesize content Find articles; basic facts (with a source)
Coding & analysis — Writing a pipeline; directly analyze data Basic syntax; writing functions; code review; explaining code