Skip to content

Exit Procedures and Documentation

This page sets out what is expected of you, in terms of documentation and handoff, as you finish your time at MItHRIL. It is separate from the practical return of your lab-issued computer, which is covered on the Computer Use Policy page under Computer Return; this page covers the research artifacts you leave behind: code, CAD files, and hardware you built or maintained.

The lab has not had a formalized process for this until now, so treat this page as a working checklist rather than a rigid form. If something about your project doesn't fit neatly into a category below, talk to your supervisor about what makes sense to document.

When to Start

Begin your exit documentation and handoff well before your last day; four to six weeks ahead of your expected departure is a reasonable target, so there's time for your supervisor or a successor to review what you've written and ask questions while you're still around to answer them. Don't leave this to your last week.

Code

  • All code should already live in the MItHRIL GitLab group (see Repositories and Version Control with Git), not only on your personal machine or under a personal GitLab namespace. If any of your work isn't there yet, push it before you leave.
  • Every repository you own or significantly contributed to should have a README covering: what the project does, how to build and run it, key dependencies and their versions, known issues or limitations, and any context a future lab member would need to pick it up cold.
  • If your project is mid-development, tag or clearly note the last known-working commit or version, so a successor doesn't have to guess which state was stable.
  • Transfer ownership or maintainer status of any repositories under your personal GitLab namespace to the MItHRIL group, or to Prof. Pan directly.

CAD Files

  • Final CAD files should be stored in the lab's shared file storage (SharePoint, per the Computer Use Policy) under a clearly named project folder, not left only on your personal machine or in a personal cloud account.
  • Include a bill of materials for any custom or purchased components, with vendor part numbers where applicable, so parts can be re-ordered or re-machined without reverse-engineering your files.
  • Note which CAD software and version you used, and export a neutral format (e.g., STEP) alongside the native file, so the design stays usable even if a software license lapses or the lab moves to different tooling.

Hardware Documentation

  • Custom-built hardware, such as the lab's Ridgeback + KUKA LBR iiwa mobile manipulator, needs written documentation of what was built, why, and how, since there is often no external manual to fall back on. At minimum: wiring diagrams, assembly notes, configuration or calibration values, and any firmware or software specific to the build.
  • Label physical wiring and connectors where practical, not only in a diagram, so a successor can match documentation to the actual hardware in front of them.
  • List any safety-relevant configuration changes you made (e.g., safety zones, e-stop wiring, protected-space monitoring settings) so a successor does not have to rediscover them by trial and error, and so the lab's safety documentation for that platform stays current.

Before Your Last Day

Review this checklist with your supervisor before your final day, so they can confirm each relevant item is complete. Bring specific questions about what applies to your project rather than assuming every bullet above is relevant; a member who never touched CAD, for instance, only needs to worry about the code and general sections.

Migration note: this page is newly authored to address a gap the lab identified (no formal exit/documentation process previously existed) and did not appear on the original SharePoint site. Please review and adjust to match how you actually want handoffs to work, particularly whether this should tie into any formal administrative sign-off (e.g., a clearance step tied to final paperwork).